BSI TR-02102-1 version 2026-01 names migration dates: classical-only key agreement ends 2031, high-protection systems by 2030, signatures by 2035. Here is who is in scope under BSIG and what to do first.
Germany does not hide its post-quantum position behind a single statute that names ML-KEM. The Federal Office for Information Security (BSI) publishes Technical Guideline TR-02102-1 as the national reference for cryptographic mechanisms and key lengths, and the January 2026 revision is the first version that puts calendar dates on the retirement of classical-only key agreement. Those dates become an operational obligation for a large set of organisations through the revised BSI Act (BSIG), which already requires "concepts and processes for the use of cryptographic procedures," and through BSI minimum standards that bind the federal administration more tightly than the Technical Guideline itself.
This guide covers four things: what the BSI actually said in TR-02102-1 version 2026-01, who sits in scope under the BSIG and related federal rules, the migration timeline those documents now set, and the practical first steps that matter before any algorithm swap: cryptographic inventory, HSM/KMS readiness, and hybrid PQC deployment.
On 23 January 2026 the BSI published TR-02102-1 version 2026-01, Cryptographic Mechanisms: Recommendations and Key Lengths. The guideline remains a Technical Guideline, not a statute. It is still the document German auditors, federal IT projects and KRITIS-adjacent operators treat as the working definition of acceptable cryptography.
Three statements in the 2026-01 text matter more than the rest:
Protocol detail for TLS, IPsec and SSH lives in the companion guidelines TR-02102-2, TR-02102-3 and TR-02102-4. If you terminate TLS or IPsec in Germany, those companions are part of the same BSI package, not optional reading.
TR-02102 itself is recommendatory. Scope comes from how other German instruments use it.
| Layer | Who it binds | How cryptography shows up |
|---|---|---|
| BSIG §30 (post NIS2 transposition) | Entities of particular importance and important entities under the revised BSI Act | Explicit duty to maintain concepts and processes for the use of cryptographic procedures, alongside risk management, incident handling and supply-chain controls |
| Federal administration | Federal authorities and systems covered by BSI minimum standards under BSIG | Minimum standards (for example TLS) are binding for the federal administration and point into the TR-02102 series for technical content |
| KRITIS / critical operators | Operators previously under the KRITIS regime and the wider set captured by NIS2UmsuCG | Assessed against BSIG risk-management measures; BSI Technical Guidelines are the practical technical reference for "state of the art" |
| DORA / financial entities | EU financial entities operating in Germany | DORA's RTS still set the detailed encryption and key-management bar for those entities; see our DORA checklist. TR-02102 remains the German national algorithm reference underneath that EU layer |
| GDPR / BDSG | Controllers and processors of personal data | Article 32-style "appropriate" security, interpreted against current risk and recognised technical guidance, including BSI publications |
Germany's NIS2 implementation act (NIS2UmsuCG) has applied since December 2025 and rewrote the BSIG around the EU categories of particularly important and important entities. Cryptography is no longer an implied control inside a general ISMS obligation. Section 30 names it. That does not turn every TR-02102 table into statute, but it does mean a regulated entity that cannot show a cryptography concept, inventory and migration path has a direct statutory gap, not just a best-practice gap.
If you sell into the federal administration, treat BSI minimum standards plus TR-02102 as the floor your product cryptography has to clear. If you are an important or particularly important entity under BSIG, treat TR-02102's migration dates as the concrete content of the cryptography concepts §30 already requires you to maintain.
| By | Milestone (BSI TR-02102-1 v2026-01 / EU roadmap) |
|---|---|
| End of 2030 | Complete migration to quantum-safe mechanisms for applications with very high protection requirements |
| End of 2031 | End of recommended sole use of classical key agreement; classical methods beyond this date only in combination with quantum-safe mechanisms |
| 2035 | Migration to quantum-safe signature mechanisms, following the European Commission roadmap that TR-02102 explicitly adopts |
Compared with the UK NCSC timeline (discovery by 2028, priority migration by 2031, full migration by 2035), Germany front-loads the key-agreement problem and is more explicit that classical-only KEMs should not still be running after 2031. Signatures get the longer runway both jurisdictions now share.
There is no separate German "PQC Act" with a single compliance filing date. The calendar lives in TR-02102. Enforcement pressure arrives through BSIG assessments, federal procurement and minimum standards, and sector supervision that already asks whether your cryptography concept is current.
BSIG §30's "concepts and processes for the use of cryptographic procedures" is empty without a map of what you actually run. Build an inventory that covers:
A CycloneDX Cryptography Bill of Materials (CBOM) is the practical artefact format. Our CBOM guide covers generating one from filesystem, source and domain scans. Prioritise systems that still use classical-only key agreement on paths carrying long-lived confidential data; those are the 2030/2031 problem, not a 2035 problem.
Algorithm choice is only half of what BSI assessors and BSIG reviewers look for. Key lifecycle (generation, storage, rotation, backup, destruction) has to survive a change of algorithm. Before you pilot hybrid PQC:
If a device or cloud KMS cannot support hybrid or PQC key establishment, put it on the replacement or decommission list now. Waiting until 2030 to discover that fact is how programmes miss the high-protection deadline.
TR-02102's transition recommendation is hybrid key agreement: classical plus a quantum-safe KEM, combined through a suitable KDF so the result stays secure if either component holds. That matches the hybrid groups already shipping in common TLS and IPsec stacks (for example X25519MLKEM768-style combinations).
Start on internet- and partner-facing termination points where harvest-now-decrypt-later exposure is highest:
Keep the hybrid step transitional in documentation as well as configuration. TR-02102's logic is that classical-only agreement ends; hybrid is the bridge, not the permanent resting state for every system. Signature migration (ML-DSA, SLH-DSA, or stateful hash-based schemes where appropriate) can follow on the longer 2035 track, but firmware and code-signing paths with long device lifetimes should not wait until the last year.
The inventory behind BSIG §30 and TR-02102's migration dates is exactly what a CBOM captures: algorithms, certificates and keys in a machine-readable form you can re-scan instead of rebuilding for each audit. Our CBOM guide covers generation and the get_qrs_score / get_vulnerable_assets tools for tracking classical-only key agreement that still sits past your 2030/2031 cut lines.
For hybrid deployment on common German enterprise edge gear, the F5 and FortiGate guides cover ML-KEM hybrid profiles, including the MCP tools that turn a prioritised inventory into configuration changes. Key lifecycle that has to survive algorithm change maps to DuoKey's KMS and MPC-based vault controls, so the cryptography concept you maintain for §30 is enforced configuration rather than a PDF that ages poorly.
Q: Is TR-02102 legally binding?
Not as a standalone statute. It is a BSI Technical Guideline. It becomes the practical bar through BSIG §30's cryptography-process duty, through binding BSI minimum standards for the federal administration, and through assessments that treat BSI guidance as state of the art. Ignoring the 2030/2031/2035 dates while claiming a current cryptography concept is a weak position.
Q: Does BSI require ML-KEM combined with FrodoKEM?
No. TR-02102 recommends hybrid use of a classical mechanism with a quantum-safe KEM. FrodoKEM, Classic McEliece and ML-KEM are listed as quantum-safe options. Dual quantum-safe stacking is not what the guideline means by hybrid.
Q: How does this relate to NIS2?
Germany's NIS2 transposition rewrote the BSIG and expanded who must implement the §30 risk-management measures, including cryptography concepts. The EU implementing regulation for certain digital entities still applies where it is more specific; see our NIS2 crypto-agility guide. TR-02102 fills in the German algorithm and migration detail NIS2 does not name.
Q: We are a bank in Frankfurt. Do we follow BSI or DORA?
Both. DORA's RTS set detailed EU financial-sector encryption and key-management rules. TR-02102 remains the national cryptographic reference German supervisors and auditors recognise for algorithm choice and migration timing. Design once against the stricter reading of both.
Germany's PQC posture is unusually concrete for a country without a single named-algorithm PQC statute. BSI TR-02102-1 version 2026-01 sets the dates: high-protection quantum-safe key agreement by 2030, end of classical-only key agreement by 2031, signatures by 2035, with hybrid classical-plus-PQC as the recommended bridge. BSIG §30 and federal minimum standards are what turn that guidance into an expectation you can be assessed against. Build the inventory, prove your HSM/KMS estate can change algorithms, and deploy hybrid on the paths that already carry long-lived confidential data.
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
