What deadlines does Germany's PQC guideline set?

Germany's post-quantum cryptography (PQC) guideline sets three dates: the initial preparation and planning phase complete by the end of 2026, high-risk use cases quantum-safe by the end of 2030, and medium-risk use cases by the end of 2035. The guideline is the national implementation of the EU roadmap for the transition to post-quantum cryptography, issued jointly by the Federal Ministry for Digital Transformation and Government Modernisation (BMDS), the Federal Ministry of the Interior (BMI) and the Federal Office for Information Security (BSI), and announced on 12 October 2026.

The guideline takes a risk-based approach, classing use cases as high, medium or low risk. By the end of 2026, the first migration steps should also be under way. It addresses federal, state and municipal administrations as well as organisations and companies, including operators of critical infrastructure.

This means the nearest deadline is the end of 2026. Therefore organisations that want to follow the roadmap need their preparation phase finished within weeks.

What is the first step in Germany's PQC guideline?

The first step in Germany's PQC guideline is a cryptographic inventory. Section 4.3 of the guideline says every organisation should build an overview of its cryptographic components, and that the initial version should be complete by the end of 2026. The BSI's recommendations rest on three steps in that order: inventory, prioritisation and implementation.

The order is deliberate. Section 4.5 explains that the assessment of quantum risk is needed to prioritise the use cases taken from the cryptographic inventory, and that this assessment should be part of regular risk management. Without the inventory, there is nothing to prioritise.

Therefore an organisation's migration plan can only be as good as its inventory. A plan built on an incomplete list will leave systems out, and those are the ones that surface late.

What does a cryptographic inventory contain?

A cryptographic inventory, as the guideline describes it, is an overview of an organisation's cryptographic components and of their internal and external dependencies. The guideline compares it to the crypto register described in the BSI's IT-Grundschutz (requirement CON.1.A19). Its example of a dependency is a card reader and its cards: both have to implement quantum-safe methods before communication between them is quantum-safe.

The guideline names the tools that can support this work: cryptographic inventory tools, repository scans and cryptographic bills of materials (CBOMs), for example based on the CycloneDX standard. A CBOM is a machine-readable record of which algorithms are in use, where, and in which components.

That's why the inventory has to reach into the code. Algorithms sit in application code and in the libraries underneath it, and many of them were never chosen by the team that ships the product. Therefore a repository scan is one of the few ways to find cryptography that nobody wrote down.

How often does the cryptographic inventory need checking?

The cryptographic inventory has to be checked regularly for currency, according to section 4.3 of the guideline. That requirement is easy to read past, and it is the one that decides whether the inventory stays useful.

The first inventory is a starting point. Every dependency update and every change written by a coding agent can add or change cryptography. An inventory compiled once for a project review describes a codebase that has already moved on.

The BSI's own emphasis on crypto-agility, the ability to replace cryptographic methods quickly when threats change, assumes the organisation knows where those methods are today. Therefore the inventory has to be maintained as part of normal development.

Earnie builds the inventory from the code and keeps it current

Earnie inventories every cryptographic algorithm in your estate and checks each one against your policy, with flags on what won't survive the post-quantum transition. It generates the CBOM from what is actually in the code, alongside the software bill of materials (SBOM), so the record matches the software you ship. Your code stays on your server. On SaaS, only fingerprints leave it.

Because Earnie scans a repository once and then checks every commit and every pull request after it, the inventory changes when the code does. That is the regular check the guideline asks for, built into the development workflow. The same scan covers open source licences and AI models, so the cryptographic inventory sits alongside the rest of the composition record. Therefore the prioritisation step in section 4.5 can start from evidence: a current list of algorithms and where they live, with the ones that need to change already flagged.

What should security and crypto leaders do before the end of 2026?

Security and crypto leaders should start by naming at least one body or person responsible for coordinating the transition, as the guideline recommends. That is the first decision to take, because an inventory without an owner tends to stop being checked.

The second is to establish the inventory itself, from the code, and to agree how it will be kept current. The third is to feed it into risk management, so the quantum risk assessment the guideline asks for has something concrete to rank. Each of these steps is achievable before the end of the year, and each makes the 2030 milestone more realistic.

Earnie gives crypto and security leaders the inventory those steps depend on, kept current with every change. See it on your kind of codebase: request a demo.