Publication note: This article provides a technical and strategic assessment; it does not constitute legal advice or a binding compliance statement.
Executive Insight
Germany’s quantum security agenda has moved beyond research laboratories and the narrow technical domain of cryptography specialists. Progress in quantum computing is challenging the long-term security assumptions behind the public-key mechanisms that underpin digital trust today. As a result, Post-Quantum Cryptography (PQC) is becoming a strategic transition domain at the intersection of cybersecurity, critical-infrastructure resilience, regulatory compliance, supply-chain security and digital sovereignty in Germany.
The central question is no longer: “When exactly will Q-Day arrive?” The more relevant question is: will the cryptographic infrastructure we use today remain reliable for as long as the data needs to stay protected?
For organisations, the starting point is not the immediate selection of a new algorithm. It is visibility: understanding which algorithms, protocols, certificates, keys, HSM/KMS components and supplier dependencies are currently in use. This is why crypto inventory and the Cryptography Bill of Materials, or CBOM, form the first operational foundation of any serious PQC transition programme.
Core thesis
Quantum security is not primarily a story about a future attack. It is a discipline for managing the relationship between data lifetime and risk horizon. PQC readiness is therefore not just technical modernisation; it is a GRC problem expressed through cryptographic architecture.
1. Why quantum security is already a present-day issue
Quantum computers may not yet appear as active attack tools in the daily threat models of most organisations. However, treating quantum risk as a distant future topic would be strategically misleading. The issue is not only when a cryptanalytically relevant quantum computer will emerge; it is also about a passive attack model that is already viable today: Harvest Now, Decrypt Later.
Under this scenario, an attacker collects traffic or archived data protected today by classical algorithms, intending to decrypt it later once sufficient quantum capability becomes available. The data may be unreadable today, yet become exposed years from now. The real impact of the attack may appear long after the original collection took place.
This risk is particularly relevant for health and genetic data, public-sector and citizen records, defence and intelligence information, strategic R&D outputs, long-term financial contracts, intellectual property, critical supply-chain information and critical infrastructure architectures.
A technical distinction is essential: the main quantum break is expected in public-key constructs such as RSA, Diffie-Hellman and elliptic-curve cryptography. Symmetric cryptography is not in the same position; Grover’s algorithm may reduce effective security levels, but the risk is more manageable with sufficiently long keys. The priority therefore lies in public-key infrastructure, certificate chains, TLS/VPN/SSH key-establishment mechanisms and long-lived digital signatures.
Question for the reader
Will the data considered secure today remain protected for the full period during which it must stay confidential?
2. Germany’s strategic context: BSI, technological sovereignty and KRITIS
Germany does not position quantum technologies merely as a scientific research domain. They are increasingly treated as a matter of industrial policy, technological sovereignty and security capability. This framing turns quantum security into a two-sided strategic issue.
The first side is defensive. The potential impact of quantum computers on today’s public-key cryptography requires a reassessment of the long-term assumptions behind digital trust. The second side is capability development. Germany and Europe aim not only to use quantum technologies, but also to produce, standardise and deploy them. PQC sits at the intersection of these two lines: it addresses defensive needs while supporting the technical foundations of digital sovereignty.
The BSI’s role is central. It is not merely a body issuing technical recommendations; it is one of the main reference points shaping security expectations for the public sector, critical infrastructure and high-security systems in Germany.
The distinction between QKD and PQC should also be kept clear. Quantum Key Distribution may be meaningful as a complementary layer on selected point-to-point physical links, but it does not replace PQC across large-scale enterprise networks, internet protocols, cloud connectivity, software-signing processes or supply-chain security. QKD may serve specialised physical links; PQC is the scalable transition mechanism for existing digital infrastructure.
3. Standards and regulation: what is binding, what is guidance, and what is a planning horizon?
Germany’s quantum security roadmap cannot be read as a purely national agenda. BSI technical guidance, EU-level PQC policy, NIST algorithm standards, ENISA integration work and IETF/ETSI protocol standardisation need to be considered together.
The 2026-01 edition of BSI TR-02102-1 creates an important technical-recommendation horizon for the standalone use of classical asymmetric key-agreement mechanisms: the end of 2030 for high-sensitivity applications and the end of 2031 for general systems. This should not be read as a uniform statutory prohibition date, but as a strong technical reference for state-of-the-art assessments in the German market.
At EU level, the 2024 Commission recommendation called on Member States to develop a coordinated strategy and implementation roadmap for the transition to PQC. The 2025 coordinated implementation roadmap then set a more concrete policy horizon: Member States should start transitioning by the end of 2026, and high-risk use cases, especially critical infrastructures, should transition to PQC no later than the end of 2030. These targets are not automatic legal deadlines for every individual organisation; they are policy-coordination targets that create a strong compliance expectation around auditability, supply-chain security and state-of-the-art risk management.
At the global standards level, NIST’s FIPS 203, FIPS 204 and FIPS 205 now shape the product and protocol ecosystem. FIPS 203 standardises ML-KEM for key encapsulation and key-establishment scenarios. FIPS 204 standardises ML-DSA for digital signatures. FIPS 205 standardises SLH-DSA as a stateless hash-based signature alternative.
DORA requires particularly cautious wording. The DORA text does not explicitly mention “post-quantum” or “PQC”. Nevertheless, its ICT risk-management, protection and prevention, operational-resilience and third-party-risk framework requires financial entities to manage cryptographic weaknesses proactively. PQC should therefore be treated not as a named standalone DORA clause, but as an indirect technical-compliance and resilience expectation derived from ICT risk management.
NIS2 should be framed with the same care. PQC readiness is not an explicitly named independent mandate for every entity under NIS2. However, when read together with risk management, supply-chain security and state-of-the-art security expectations, as well as the EU PQC roadmap, it is likely to become part of audit and governance discussions.
Decision-maker meaning: In a 2027 budget discussion, the question is: which systems, suppliers and long-lived data classes must become visible before 2030?
4. 2026–2035: the critical planning window
The roadmap should not be reduced to a single date. The years 2026, 2030, 2031 and 2035 do not all carry the same legal or technical character. Some are EU roadmap targets, some are BSI technical-recommendation horizons, and some are strategic planning windows that organisations should use to avoid falling behind.
| Period | Strategic meaning | Organisational priority |
|---|---|---|
| 2024 | NIST standards were finalised and algorithmic uncertainty was reduced. | PQC awareness, algorithm impact analysis, supplier questionnaires and initial crypto inventory. |
| 2025–2026 | PQC became a coordinated cybersecurity agenda item across EU Member States. | Management-level risk reporting, CBOM methodology, data-confidentiality-lifetime analysis and low-risk pilot plans. |
| 2027–2029 | Hybrid architecture testing matures in KRITIS, finance, government and high-sensitivity SaaS environments. | Controlled pilots across TLS, VPN/IPsec, SSH, PKI, HSM, code signing and firmware signing. |
| 2030–2035 | Preparation becomes production-scale resilience, auditability and supply-chain compliance. | PQC-ready architecture for high-risk systems; continuous CBOM, weak-cryptography detection and a crypto-agility operating model. |
The key conclusion is clear: between 2026 and 2030, PQC readiness is primarily about visibility, inventory and piloting. After 2030, it becomes a matter of production-scale resilience, auditability and supply-chain compliance.
5. Sectoral impact: one-size-fits-all migration is not enough
The organisational impact of PQC migration is not uniform across sectors. A Germany-focused strategy should therefore be based on sector-specific risk and prioritisation, not a generic technical migration plan.
| Sector | Main driver / exposure | Priority action |
|---|---|---|
| KRITIS | Service continuity, public safety, OT/SCADA access, VPNs and certificate chains. | OT crypto inventory, segment-based risk analysis, remote-access and certificate-management pilots. |
| Finance | DORA, transaction integrity, HSM dependencies, API security and third-party ICT risk. | HSM/PQC compatibility analysis, hybrid TLS pilot and supplier-contract updates. |
| Public sector | Long-term archival confidentiality, e-government, authentication, signing infrastructure and public-sector PKI. | CA transition planning and PQC impact analysis for long-lived certificate chains. |
| Mittelstand / SMEs | Indirect pressure through major customer requirements, supply-chain clauses, insurance and audit expectations. | Managed CBOM, supplier questionnaire and practical crypto-agility maturity assessment. |
| SaaS / software | TLS/API, SDKs, code signing, dependency management and product roadmaps. | Crypto abstraction layer, PQC-ready product roadmap and secure release/signing process. |
| OT / IoT | Long product lifecycles, constrained processing power, firmware signing, device certificates and field-update limitations. | Lightweight PQC assessment, gateway-based protection, segmentation and hardware-refresh planning. |
6. CBOM and crypto-agility: from visibility to governability
The first question in a PQC transition is not “which algorithm should we choose?” The first question is: does the organisation know which algorithms it currently uses, and where? Without this knowledge, transition timelines, budgets, supplier dependencies, regulatory impact and technical prioritisation cannot be soundly determined.
CBOM is not merely a list of software libraries. It is a broader cryptographic visibility model covering algorithms in use, key lengths, certificate chains, TLS/IPsec/SSH/S/MIME/VPN configurations, HSM/KMS infrastructure, SaaS and open-source dependencies, and data-confidentiality lifetime.
A secondary but highly valuable output of the CBOM exercise is crypto hygiene. During PQC readiness work, organisations often uncover outdated TLS versions, weak cipher-suite usage, forgotten certificates, residual SHA-1 usage or undocumented third-party cryptographic dependencies. In this respect, CBOM is not only a tool for post-quantum transition; it is also a measurement tool for current cybersecurity maturity.
| Level | Definition | Typical indicator |
|---|---|---|
| 0 — Unaware | Cryptographic assets are not visible. | No CBOM; certificates tracked manually; high exposure to outdated protocols. |
| 1 — Inventoried | Partial crypto inventory exists for critical systems. | Manual CBOM, limited supplier questioning and limited certificate visibility. |
| 2 — Standardised | PKI, HSM/KMS and certificate management are run under central policies. | Regular CBOM updates and weak-algorithm scanning. |
| 3 — Agile | Algorithm changes can be tested without architectural breakage. | Abstraction layer, hybrid PQC pilots, automated certificate lifecycle and rollback plans. |
| 4 — Predictive | Cryptographic risk is monitored continuously and fed into processes. | Real-time CBOM, policy-as-code, supplier dashboards and automated reporting. |
Crypto-agility is the capacity to turn cryptographic algorithms from rigid, hard-coded architectural elements into replaceable, observable and manageable security components. This is not only a technical architecture feature. It is a GRC capability: management decisions, supplier contracts, product roadmaps, audit preparation and budget planning should align around it.
7. Hybrid PQC migration: the architecture of controlled transition
During the transition period, the most realistic approach for many high-security use cases is a hybrid architecture. Hybrid PQC migration combines classical and post-quantum mechanisms within the same security operation. Its practical purpose is to adopt PQC algorithms without fully detaching from the mature security assumptions of the existing ecosystem.
TLS 1.3, IPsec/IKEv2 and SSH are among the first layers where the transition will become visible. IETF RFC 10024 defines three hybrid key agreement mechanisms for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. However, standardisation does not mean enterprise production environments are automatically ready; operating systems, TLS libraries, network-security products, HSM/KMS platforms and vendor release cycles must be tracked separately.
PQC algorithms can produce larger keys, ciphertexts or signatures than their classical equivalents. This may affect MTU, packet fragmentation, handshake duration, device memory, log volume and monitoring-tool parsing. Hybrid migration should therefore be designed as a controlled programme consisting of laboratory testing, piloting, limited production deployment and phased rollout.
8. GRC, privacy and ethics: why quantum security is not purely technical
Quantum security begins technically in cryptography, but at organisational level it must be governed through GRC. Which data classes must remain confidential for many years, which systems support critical business processes, which suppliers create cryptographic dependencies and which risks should be reported to executive leadership are not questions that technical teams can answer alone.
This is also an ethical and privacy issue. If a health record, citizen file or long-term public archive collected today becomes decryptable in the future, the consequence is not merely a technical security gap. Individual privacy, institutional trust, public safety and confidence in democratic digital infrastructure may also be affected.
The better question is therefore not only “which algorithm is secure?” The full question is: which data must be protected, for how long, against which threat horizon, and under which organisational responsibility?
9. Actionable roadmap for organisations
- Establish management-level ownership of PQC risk; the topic should not remain confined to technical research teams.
- Launch an organisation-wide CBOM exercise to make algorithms, protocols, certificates, HSM/KMS components and third-party dependencies visible.
- Conduct a data-confidentiality-lifetime analysis and prioritise health, government, financial, R&D and strategic-contract data exposed to HNDL risk.
- Measure crypto-agility maturity and define the target level, budget and roadmap as a management decision.
- Select low-risk pilot use cases across TLS, IPsec/VPN, SSH, PKI and code/firmware signing.
- Verify, vendor by vendor, whether HSM/KMS and certificate-authority infrastructure is ready for ML-KEM, ML-DSA and hybrid flows.
- Add PQC readiness, crypto-agility, CBOM-sharing and weak-algorithm-remediation clauses to critical supplier contracts.
- For organisations within scope of NIS2/DORA, integrate PQC risk into regular risk reporting and the board-level cyber-resilience agenda.
- Design separate training modules for technical teams, ISMS teams and executives; the topic should not be narrowed to cryptography specialists alone.
Conclusion: Germany’s strategic window is open
Germany’s quantum security roadmap is shaped by the BSI’s technical cryptography recommendations, the EU’s coordinated PQC transition targets, NIST’s global algorithm standards and Europe’s broader digital-sovereignty agenda.
The direction is clear: long-term exclusive reliance on classical asymmetric cryptography is diminishing, while PQC, hybrid architectures and crypto-agility are becoming part of corporate security planning.
For organisations, the critical point is that this transition cannot be handled as a last-minute product update. Without CBOM, the scope of the transition is unknown. Without crypto-agility, algorithm change cannot be managed. Without pilot deployments, performance and compatibility risks cannot be measured.
The greatest organisational need in Germany’s PQC transition window is not a complex algorithmic narrative, but a clear risk map decision-makers can understand and a concrete transition plan technical teams can execute. Quantum security has moved beyond the narrow technical domain of cryptography specialists. It is becoming part of national resilience, corporate risk management, critical infrastructure protection and European-scale digital sovereignty.
Sources
This blog article is based on Quantum-Safe Dynamics’ technical whitepaper “Germany’s Quantum Security Roadmap” and the following primary sources.
- BSI — TR-02102-1: Kryptographische Verfahren: Empfehlungen und Schlüssellängen, Version 2026-01.
- BSI — BSI empfiehlt Ende klassischer asymmetrischer Verschlüsselungsverfahren, 11.02.2026.
- BSI / ANSSI / NLNCSA / Swedish NCSA — Position Paper on Quantum Key Distribution, January 2024.
- European Commission — Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, 11.04.2024.
- European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, 23.06.2025.
- NIST — FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
- NIST — FIPS 204: Module-Lattice-Based Digital Signature Standard.
- NIST — FIPS 205: Stateless Hash-Based Digital Signature Standard.
- ENISA — Post-Quantum Cryptography: Integration Study.
- ETSI — TS 103 744 V1.2.2: Quantum-Safe Cryptography; Quantum-safe Hybrid Key Establishment.
- IETF / RFC Editor — RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes.
- IETF / RFC Editor — RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3.
- Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA).