BSI Germany PQC Guidance

What the BSI guidance means

The cited BSI document is titled Migration to Post-Quantum Cryptography and is identified in the source set as a current BSI source. Its language is recommendation-oriented: it describes “recommendations for action” and explains how migration can be initiated today. Nothing in the cited BSI passages creates a universal date by which every organisation in Germany must replace every public-key algorithm. The appropriate interpretation is therefore strategic and risk-based rather than a blanket legal conclusion. Organisations should still check sector-specific obligations and applicable contracts separately; those matters are outside the cited passages.1

BSI frames the question differently from a simple prediction about when a quantum computer will exist. It states that whether or when quantum computers will become available is no longer the issue in the foreground, because post-quantum cryptography will become the long-term standard. At the same time, BSI says that the decision about whether and when to switch in a particular use case should begin early and continue within appropriate risk management, adapted to current developments.1

Why organisations should start before a cryptographically relevant quantum computer

The BSI evidence records two apparently competing points that should be considered together. A BSI-commissioned study estimated that short-term development leaps toward cryptographically relevant quantum computers were rather unlikely and that enormous effort would currently be needed to scale quantum computing to that level. The same passage says development has gained momentum through industrial players and large research programmes, and that further commercial applications could accelerate it. The passage therefore does not provide a reliable arrival date or justify waiting for one.1

The immediate concern for some information is the “store now, decrypt later” scenario. Messages exchanged during key negotiation and the data encrypted with negotiated keys may be collected in advance and decrypted in the future with a quantum computer. This makes the required protection period of the information a key planning variable. Data that must remain confidential for many years may require earlier action than data with a short useful life, even if a cryptographically relevant quantum computer is not currently available.1

The migration is broader than selecting an algorithm. ENISA’s cited guidance states that transition does not end with selecting and standardising post-quantum algorithms: integration with existing systems and protocols is also required, and the process is expected to take years because of technical complexity and financial cost. This supports treating PQC as an enterprise architecture and lifecycle programme involving applications, protocols, products, certificates, key management, hardware, suppliers, and operational processes.2

Crypto-agility is BSI’s core practical recommendation

BSI recommends paying particular attention to making cryptographic mechanisms as flexible as possible in both new application development and maintenance of existing applications. The purpose is to react to developments, implement upcoming recommendations and standards, and replace algorithms in the future if they no longer provide the desired security level. BSI calls this capability crypto-agility and says it should become a design criterion for new products, not only because of quantum computers but also because classical attacks can evolve and previously acceptable algorithms or key lengths can become obsolete.1

• Identify where cryptographic algorithms, key lengths, protocol choices, certificates, trust stores, and cryptographic libraries are selected or hard-coded.
• Separate cryptographic policy from application logic so that an approved mechanism can be changed without redesigning the entire business service.
• Record dependencies on hardware security modules, embedded devices, operating systems, middleware, cloud services, suppliers, and external communication partners.
• Require a controlled mechanism for introducing new algorithms, changing parameters, rotating keys, and retiring mechanisms.
• Test upgrade and rollback paths before a migration is urgent, including certificate, interoperability, performance, and operational recovery scenarios.

Crypto-agility is not equivalent to using an unreviewed algorithm or changing cryptography casually. The cited ETSI guidance warns that post-quantum algorithms can have different functionality and security properties from traditional algorithms, and that protocol security analysis must account for those differences. It also advises against deploying post-quantum algorithms that have not undergone standardisation or sufficient analysis, even in a hybrid scheme or hybrid protocol.3

How to prioritise a PQC migration

A practical first step is a cryptographic inventory tied to business services rather than a disconnected list of algorithms. The cited migration guidance from the UK NCSC, while not a BSI document, provides a useful planning structure consistent with BSI’s risk-management approach: identify key services and applications, record the data held together with its expected lifetime and value to an adversary, identify how data is protected in transit and at rest, and map the systems through which the data is processed.4

Prioritisation should distinguish confidentiality, authentication, integrity, and availability. Public-key mechanisms used for key establishment are especially relevant to long-lived confidentiality and store-now-decrypt-later exposure. Signature mechanisms require a different analysis: the BSI evidence specifically discusses stateful hash-based signatures for firmware updates, where only a small number of signatures may be needed. Industrial and embedded environments also show why integrity cannot be treated as secondary: faulty sensor readings or commands can cause control-system failures, and devices may be difficult or impossible to upgrade.4

1. Create an inventory of public-key cryptography and the services that depend on it.
2. Classify information by confidentiality lifetime, business value, regulatory or contractual sensitivity, and exposure to interception.
3. Identify systems that cannot be upgraded, are embedded in larger products, use proprietary protocols, or depend on suppliers that do not yet support suitable mechanisms.
4. Prioritise long-lived confidential information, externally exposed key-establishment channels, high-impact authentication, firmware signing, and systems with long replacement cycles.
5. Assign owners, dependencies, target states, test activities, and review dates; update the plan as standards and implementation guidance mature.

Algorithms, signatures, and firmware updates

The cited evidence includes final NIST standards FIPS 203, FIPS 204, and FIPS 205, published on 13 August 2024. FIPS 203 specifies ML-KEM and states that it becomes effective immediately upon final publication. FIPS 204 specifies ML-DSA, and FIPS 205 specifies a stateless hash-based digital signature standard. These documents are important external standards, but their existence does not by itself establish that BSI mandates a particular algorithm for every German use case. They also do not remove the need for secure implementation, system-level analysis, and appropriate deployment decisions.56

The NIST standards expressly limit what conformance means. FIPS 203 says that conformance does not ensure that a particular implementation is secure and places responsibility on the implementer to build a secure module. FIPS 204 and FIPS 205 similarly state that conforming implementation or a product containing one does not guarantee security of the overall system. These limitations are directly relevant to procurement and assurance: an organisation should evaluate implementation security, key protection, randomness, protocol integration, certificate and identity binding, operational controls, and the security of the surrounding system.576

BSI’s cited recommendation on stateful hash-based signatures is narrower and use-case specific. Stateful methods such as LMS and XMSS require exact tracking of already-used one-time signature keys, and the number of signatures available from a key is fixed when the private key is created. BSI nevertheless identifies them as particularly suitable for firmware updates when only a small number of signatures are required, and notes their history in BSI recommendations such as TR-02102 and TR-03140. The operational state-management requirement must be treated as a security control, not as an implementation detail.1

Hybrid deployment: useful transition tool, not automatic protection

ETSI’s deployment guidance explains that combining post-quantum and traditional algorithms in a hybrid scheme or protocol can mitigate potential vulnerabilities in a post-quantum implementation or provide backward compatibility during migration. Hybrid approaches can reduce interoperability barriers, but they also increase protocol, implementation, and key-management complexity. Their security properties depend on the specific construction, use case, and whether confidentiality or authentication is being addressed.3

A hybrid design must be analysed carefully. ETSI warns that an inappropriate hybrid can be less secure than a non-hybrid post-quantum mode. Algorithm negotiation must be protected against downgrade attacks, and the security guarantee that remains if one component is broken must be understood. ETSI also says that, once confidence in post-quantum algorithms and implementations is sufficient, moving to purely post-quantum algorithms can avoid hybrid overhead and the risks of retaining traditional components vulnerable to quantum adversaries.3

Enterprise implications for governance, procurement, and operations

PQC migration should have an accountable owner and a documented risk basis. BSI’s recommendation to begin early and adapt continuously implies a governance cycle: establish the current cryptographic baseline, approve priorities, track standards and implementation maturity, test changes, record residual risk, and revisit decisions as the environment changes. The cited evidence does not prescribe a particular German governance model, reporting template, or deadline, so organisations should avoid presenting an internal roadmap as a BSI requirement.1

Procurement is a practical control point. The cited Canadian government roadmap recommends contract provisions for PQC support, conformance with applicable cryptographic recommendations, cryptographic module validation where relevant, and crypto-agility for future configuration changes. Although that roadmap is not German or BSI guidance, the procurement lesson is transferable as a planning consideration: contracts and product requirements should address upgradeability, standards-based interoperability, support duration, implementation assurance, and access to migration information. It should not be described as a binding BSI rule.8

• Ask suppliers which public-key algorithms, protocols, certificates, and hardware components are used and where they are configured.
• Require a documented upgrade path and testing support for future standards-based mechanisms.
• Assess products whose lifecycle exceeds the confidentiality lifetime of the data they protect.
• Include firmware-signing key state, backup, recovery, separation of duties, and incident procedures where stateful signatures are used.
• Record exceptions for systems that cannot yet migrate and define compensating controls, retirement plans, or risk acceptance.

Limits of the evidence and status distinctions

This article distinguishes BSI’s current migration guidance from other cited sources. The BSI source is identified as current but has no document version or publication date in the cited metadata. The NIST FIPS documents are final and dated 13 August 2024; ETSI TR 103 966 V1.1.1 is final and dated October 2024; ENISA’s cited report is dated 13 May 2021; and the UK NCSC timeline guidance is current and dated 20 March 2025. Those dates describe the cited source records and should not be converted into a German compliance timetable.3

The evidence also does not provide a complete BSI algorithm catalogue, a German statutory instrument, sector-specific obligations, certification requirements for every product category, or a universal transition date. It supports a direction of travel and practical preparation: use risk management, design for agility, protect long-lived information, evaluate standards and implementations, and maintain the ability to revise decisions. Legal, regulatory, and contractual conclusions require the applicable German or sector-specific authority, which is not cited here.1

Conclusion

BSI Germany’s PQC guidance supports starting migration preparation now without claiming that every organisation faces one universal deadline. The central actions are to inventory cryptographic dependencies, prioritise long-lived confidential information and high-impact integrity or authentication functions, make systems crypto-agile, evaluate standards and implementations carefully, and govern migration as a continuing risk-management programme. Stateful hash-based signatures may be valuable for suitable firmware-update cases, while hybrid deployment may help interoperability only when its construction, downgrade protection, and residual security are analysed. The evidence supports preparedness, not a blanket legal conclusion.13