BSI TR-02102 explained: post-quantum deadlines and a migration path for long-lived software

Last reviewed: November 3, 2026, against TR-02102-1 version 2026-01 and the German national guideline of October 12, 2026. Changes since then are listed at the end of the page.

• TR-02102 is the cryptography guideline of Germany's Federal Office for Information Security (BSI). Part 1 lists recommended algorithms and key sizes. It is a technical guideline, not a law, and it is written mainly for developers who plan new cryptographic systems from 2026 on.
• Key exchange: version 2026-01 recommends RSA, Diffie-Hellman, and ECDH on their own only until the end of 2031, and only until the end of 2030 for very high protection needs. After that, only in a hybrid with a quantum-resistant scheme such as ML-KEM.
• Signatures: classical signature schemes on their own are expected to stay recommended until the end of 2035.
• 2030 and 2035 for whole use cases come from the EU's coordinated roadmap: high-risk use cases by 2030, medium-risk by 2035. Germany adopted that timeline on October 12, 2026.
• Reach: outside regulated German contexts, TR-02102 binds you only through a contract. If you sell to German customers, expect to see it there.

A product owner forwards a customer question to the architect of a fifteen-year-old .NET application: “Is your product compliant with BSI TR-02102, and when will it be quantum-safe?” The application talks TLS through the platform, signs PDF reports with an RSA certificate, and encrypts an export file with a key that was wrapped with RSA in 2014. The first instinct is to wait. The standards are still moving, and nobody wants to migrate twice.

That instinct is reasonable. Hybrid certificate formats are still IETF drafts. NIST treats hybrids as a transitional step, and the UK's NCSC accepts them as an interim measure while preferring pure post-quantum schemes. A team that rebuilt its cryptography in 2022 around an early draft would be rebuilding it again now.

What waiting doesn't change is where the work is. Hybrid key exchange for TLS 1.3 has been a Proposed Standard since August 2026 (RFC 10024). OpenSSL ships ML-KEM from version 3.5. And the slowest parts of a migration are the ones teams tend to leave for last: signatures, certificate chains, and update mechanisms. The EU roadmap estimates that fully migrating all relevant systems “might easily take about 5 to 10 years” (section 4.2). So the useful question is not “PQC or not yet?” It is “where in our system are the decisions that a migration has to touch, and can we change them without touching the rest?”

The guideline has four parts, all currently at version 2026-01:

BSI reviews the recommendations every year. Part 1 states them only for the period through the end of 2032, because longer forecasts are unreliable (section 1.2).

What it doesn't promise. The guideline rates algorithms, not systems. It explicitly rejects the idea that a system is secure just because it uses only recommended primitives (section 1). To demonstrate that a product conforms, it asks for Common Criteria certificates or a comparable BSI procedure such as an approval (section 1.2). “BSI-compliant” in a vendor answer therefore means little until you know what was evaluated, and by whom.

How it becomes binding.

All three major sources agree on the direction and roughly on the dates. They differ on hybrids:

• BSI recommends post-quantum key exchange only in a hybrid, and post-quantum signatures only combined with a classical signature, except hash-based ones.
• NIST plans to deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them in its standards after 2035 (NIST IR 8547, October 2026). According to the EU's FAQ, NIST sees hybrids as likely temporary.
• The UK's NCSC accepts hybrids as an interim measure and recommends pure post-quantum schemes in general (EU FAQ, question 3.4).

If you ship to both Germany and the US, design for a hybrid now and for dropping the classical half later. That is crypto agility in practice, not as a slogan.

What “high risk” means. The EU roadmap calls a use case high-risk if a loss of confidentiality would still cause significant damage ten or more years later. That's the “store now, decrypt later” case: traffic recorded today and decrypted once a cryptographically relevant quantum computer exists. The German guideline adds two factors, how vulnerable the algorithms are and how long the migration takes (section 4.5). It also cites a BSI study that considers such a computer likely within 15 years at most, so by 2040 or earlier.

Where 2031 comes from. Only TR-02102-1 uses 2031. It bases the date on a 2024 joint recommendation of BSI and partner agencies in other European countries. The EU roadmap works with risk levels and the years 2030 and 2035 instead.

2032 and 2036. Some overviews give 2032. That's the same boundary as 2031, counted from the first year in which classical key agreement is recommended only in a hybrid: the guideline recommends it beyond 2031 only together with a quantum-resistant scheme (section 2.3). Likewise, 2036 is the first year after the signature date of end-2035; there it's an announcement, not yet a rule.

The idea. Two key exchanges run side by side, one classical and one quantum-resistant, and one shared key is derived from both. It's meant to stay secure as long as either scheme is secure (TR-02102-1, section 2.2).

Why not just the new scheme. BSI notes that the post-quantum schemes don't yet earn the same trust as the classical ones, because their side-channel resistance and implementation security are less studied (section 2.2). So the guideline currently recommends them only in a hybrid.

Which schemes. For the quantum-resistant half, TR-02102-1 lists (section 2.4):

• ML-KEM-768 and ML-KEM-1024 (FIPS 203), the scheme most libraries and protocols use;
• FrodoKEM-976 and FrodoKEM-1344, the more conservative choice based on unstructured lattices, in ISO standardization;
• Classic McEliece, with listed parameter sets. After cryptanalytic progress in 2026, however, BSI advises against using it in new developments;
• HQC, which BSI intends to add once the standard is published.

How the secrets are combined. For your own protocols and file formats, the guideline recommends two combiners (section 2.2, table 2.1):

• CatKDF from ETSI TS 103 744, with KMAC or HKDF;
• KeyCombine from NIST SP 800-227, with the function H implemented by a recommended KDF or KMAC.

A good combiner binds more than the two secrets: it also takes in the ciphertexts and public keys. Protocols such as TLS 1.3 define their own combination, which Part 1 doesn't cover (remark 2.5). If you hash two secrets together in a homegrown format, that is the place to look first.

Where it works today.

• TLS 1.3: RFC 10024 has been a Proposed Standard since August 2026. BSI will recommend the groups SecP256r1MLKEM768 and SecP384r1MLKEM1024 in the next version of TR-02102-2. It says both can already be used in line with the guideline, and X25519MLKEM768 can be used in addition. X25519MLKEM768 is the group marked “Recommended” in the IANA registry.
• SSH: RFC 10042 (Informational, August 2026) defines mlkem768x25519-sha256 and two NIST-curve variants.
• IPsec: RFC 9370 allows multiple key exchanges in IKEv2. ML-KEM for IKEv2 is still an Internet-Draft as of October 2026.

What it costs. An ML-KEM-768 encapsulation key is 1,184 bytes and a ciphertext 1,088 bytes (FIPS 203). The handshake grows by a bit over 2 KB, and the client's first message no longer fits in a single packet. Older firewalls and middleboxes that inspect traffic can choke on that. Test it before production does.

“Store now, decrypt later” doesn't apply to signatures. A classical signature remains trustworthy until a cryptographically relevant quantum computer exists (TR-02102-1, section 2.1), which is why the deadline is later. Two things make it urgent anyway:

• PKI takes years. Root certificates are often valid for a decade or more, and every relying party has to understand new formats before you can issue them. BSI explicitly expects long migration times for signatures in a PKI (section 5.3). The EU FAQ suggests building a post-quantum PKI alongside the old one if a full migration by 2030 isn't feasible (question 2.4).
• Updates have to outlive the update key. Products expected to be in use beyond 2030 should be upgradable to quantum-resistant algorithms, and the update mechanism itself should use post-quantum signatures. BSI calls this “dringend empfohlen,” strongly recommended (section 5.3). A device whose firmware signature can't be swapped can't load anything that fixes it later.

What the guideline recommends for signatures (section 5.3.4):

• A post-quantum signature generally only together with a classical one: both are concatenated and accepted only if both are valid.
• ML-DSA-65 and ML-DSA-87 (FIPS 204), in the “hedged” variant.
• Hash-based schemes may be used on their own: SLH-DSA (FIPS 205), and XMSS and LMS. The last two are stateful, so they're recommended only where the counter is managed reliably, for example when signing software and firmware updates.

Composite certificate formats (Composite ML-DSA, Composite ML-KEM) are still IETF drafts as of October 2026.

TR-02102-1 is reissued every year, usually in January. An answer that was right in 2020 or 2023 can be wrong today without anyone having made a mistake. So before a vendor questionnaire, an audit checklist, or a forum answer about “BSI-compliant” cryptography means anything, it needs a version number.

The big shifts so far: in 2020 the first post-quantum schemes entered the guideline, for hybrid use only. In 2023 the security level went up to 120 bits, since 2024 2048-bit RSA is no longer conformant, and DSA is recommended only until 2029. In 2026 came the migration deadlines. The change log at the end of the page shows when we updated this reference for each version.

Classic McEliece shows why crypto agility matters. BSI has listed it since 2020, and today only for hybrid use. In a note dated September 29, 2026, following new cryptanalysis that BSI itself contributed to, it advises against Classic McEliece in new developments and points to FrodoKEM, ML-KEM, and, once standardized, HQC. Systems that already run it in a hybrid aren't facing an emergency: according to BSI, the combination still provides at least the security of the classical scheme. That is exactly what the hybrid rule is for. The other lesson is about code. If the algorithm is a setting, a change like this means a configuration update and a test run. If it's hard-coded, it means a release (check 9).

What to take from the history.

• Treat every compliance statement as versioned. “BSI-compliant” without a version can't be checked.
• Plan for changes that reach into a design: the security level in 2023, RSA key sizes from 2024, DSA's end date in 2024, Classic McEliece in 2026.
• Contracts with German customers often say “in der jeweils gültigen Fassung,” meaning whatever version is current. Negotiate a transition period, so a new edition doesn't put you in breach on the day it's published (check 10).

TR-02102 is written for new systems. In an existing one, the work concentrates at a handful of decision points:

• Transport (TLS, VPN, SSH). Usually your code doesn't negotiate this. The component that terminates the connection does: the OS, the web server, a reverse proxy, a VPN gateway, a database driver. The questions are which component that is, which version, and whether it supports the RFC 10024 groups. A connection only becomes hybrid when both ends can do it.
• Application-level crypto in .NET. Hard-coded choices are the problem: RSA with 2048-bit keys in code, custom signature formats, algorithm identifiers stored in a database. Where the application calls cryptography itself (issuing certificates, CMS messages, XML signatures, its own encryption), the call changes. The application doesn't have to be rewritten for that.
• Legacy front ends such as Access/VBA. An Access application usually doesn't encrypt anything itself. The ODBC driver opens the connection to SQL Server, and web calls go through Windows components. Whether those negotiate a hybrid depends on the driver and on Windows, not on the VBA code. Inventory the driver and its version, the encryption options in the connection strings, and any signed VBA projects.
• Data access through a service. If a data service sits between the application and the database, the question moves to that service's HTTPS endpoint and the platform it runs on.
• Data at rest. AES-256 stays. Watch for archives and backups whose key was once transported with RSA or ECDH: if that exchange was recorded, they're only as safe as the exchange. BSI adds that keys negotiated with a scheme that loses conformity should no longer be used (remark 2.1).
• Long-lived devices. If the firmware signature can't be changed, replacement is the only path. The German guideline mentions both options: wait for a PQC-capable successor, or replace early (section 4.6).

A sequence that keeps each step small enough to test and roll back. Each phase ends with evidence, not with a slide.

1. Inventory and ownership. Name an owner. List where cryptography happens, who controls it (your code, the platform, a vendor), and how long the data must stay confidential. Evidence: the inventory, with an owner per entry.
2. Transport first. Upgrade the components that terminate TLS on high-risk paths, enable a hybrid group, and measure what is actually negotiated. Evidence: handshake captures and the negotiated group per endpoint.
3. Application calls behind a policy. Move hard-coded algorithms and key sizes into configuration or a library with a defined policy, so the next change is a setting. Evidence: a test that switches an algorithm without a code change.
4. Signatures and PKI in parallel. Build a new chain next to the old one, start with update signing, and keep classical verification alive until relying parties can read the new formats. Evidence: a signed update verified by the new chain on a test device.
5. Retire classical-only paths. Remove fallbacks once both sides support hybrids, and record every exception with an end date. Evidence: an exception register that shrinks.

Twelve checks for existing applications and the vendors behind them. Each one names what to check, where, who owns it, what counts as evidence, and what's left afterward. Four status values are enough:

• verified: the “done when” condition is met and the evidence exists;
• partial: met for some systems, with the rest named;
• not verified: still open;
• not applicable: with a written reason, such as “no public-key cryptography in use.”

• Check: Is a person or group responsible for the migration, with time and budget?
• Where: org chart, a management decision.
• Owner: management.
• Evidence: a named owner with tasks: plan, priorities, progress, vendor coordination (German guideline, section 4.2).
• Done when: the owner is named and has a date for the first inventory.

• Check: Where are which algorithms used? Protocols, certificates, signatures, encrypted storage, key stores, libraries, devices.
• Where: configuration, network scans, source code, SBOMs, vendor answers.
• Owner: operations and development, collected by the owner.
• Evidence: a list with system, algorithm, key size, protocol version, library and version, and the person responsible; machine-readable as a CBOM (for example CycloneDX) where you can.
• Residual risk: cryptography inside third-party products and firmware that nobody sees.
• Done when: every system in scope is listed with these fields. It doesn't have to be complete before you start planning (EU FAQ, question 4.2).

• Check: How long must the data on each flow stay confidential?
• Where: data classification, retention rules, customer contracts.
• Owner: the business owner of the data, with security.
• Evidence: a confidentiality lifetime per data flow, with a reason.
• Done when: every flow that uses public-key cryptography has a lifetime. Ten years or more means high risk under the EU roadmap.

• Check: Which use cases are high, medium, or low risk, and when does each migrate?
• Where: risk management; method from the EU roadmap and the PQC Migration Handbook, compatible with ISO/IEC 27005.
• Owner: security.
• Evidence: risk register entries with deadlines.
• Residual risk: the rating rests on a forecast; the German guideline asks for a contingency plan in case progress is faster (section 1).
• Done when: every use case in the inventory has a level and a date.

• Check: Can both endpoints do TLS 1.3 with a hybrid group from RFC 10024? The same for VPN and SSH?
• Where: server, proxy, and client configuration; a capture of the handshake.
• Owner: operations; the vendor for third-party systems.
• Evidence: a test record with the group actually negotiated.
• Residual risk: if the peer can't do hybrid, the connection falls back to classical. That fallback must be visible, not silent.
• Done when: the negotiated group is measured, not just configured, for every high-risk connection.

• Check: Do you encrypt outside TLS, for files, messages, or license keys? Is that hybrid, and with which combiner?
• Where: source code, design documents.
• Owner: development.
• Evidence: a design that names the combiner (CatKDF or KeyCombine), plus test vectors.
• Done when: no format combines secrets other than per table 2.1 of TR-02102-1, or the deviation has a reason and an end date.

• Check: Which certificate authorities exist, how long are their certificates valid, and can every relying party read new formats?
• Where: PKI documentation, certificate stores, devices that validate certificates.
• Owner: PKI operations.
• Evidence: a list of CAs with validity periods; a plan for a parallel chain.
• Residual risk: composite certificate formats aren't RFCs yet.
• Done when: every CA whose certificates are valid beyond 2035 has a plan.

• Check: Can the signature scheme for software and firmware updates be replaced?
• Where: vendor statements, the update process, the bootloader.
• Owner: product owners; the vendor for third-party devices.
• Evidence: a vendor statement with version and date, or your own test.
• Residual risk: devices without a replaceable trust anchor can only be replaced.
• Done when: every product with a lifetime beyond 2030 has a documented quantum-safe update path or a replacement plan.

• Check: Where are algorithms, key sizes, or identifiers hard-coded?
• Where: code search for algorithm names, key sizes, and OIDs; configuration.
• Owner: development.
• Evidence: a list of locations; a test that switches an algorithm through configuration instead of code.
• Done when: every location is configurable or scheduled for change.

• Check: Which vendors ship cryptography to you, and what are they planning?
• Where: contracts, questionnaires, CBOMs.
• Owner: procurement with security.
• Evidence: answers with versions and dates. The German guideline suggests making CBOM delivery part of the contract (section 4.6).
• Residual risk: an answer isn't proof.
• Done when: every vendor of a high-risk system has answered in writing.

• Check: Is there a test plan for handshakes, packet sizes, performance, and peers, and a way back?
• Where: test environment, change process.
• Owner: operations.
• Evidence: a test report; a documented rollback with a trigger.
• Residual risk: rolling back to classical is a deliberate deviation. Record it with an end date.
• Done when: every change was tested before production and has a rollback.

• Check: Is the strategy written down, and are exceptions recorded with deadlines?
• Where: cryptography policy, exception register.
• Owner: security.
• Evidence: a dated policy version; exceptions with reason, deadline, and approval.
• Done when: an auditor can tell from these documents what migrates when, and what doesn't and why.

We build two products for post-quantum cryptography in existing software. Both are published as a preview.

The cryptography library for .NET adds ML-KEM and ML-DSA to existing code one call site at a time: certificates, CMS messages, XML signatures, and hybrid key agreement. Its defaults follow TR-02102-1 version 2026-01, and the mapping is documented (post-quantum policy):

• ML-KEM-768 and -1024 and ML-DSA-65 and -87 run only together with a classical scheme.
• Hybrid keys are combined with KeyCombine from NIST SP 800-227, with HKDF-SHA256 as the function H.
• Parameter sets the guideline doesn't recommend, and pure post-quantum modes, create new data only with an explicit exemption set at startup. Every deviation raises an event.
• A call that asks for a post-quantum part and can't produce it fails. It never quietly falls back to classical.

What it doesn't do:

• CatKDF, SLH-DSA, XMSS, LMS, FrodoKEM, and Classic McEliece aren't implemented.
• There is no TLS handshake in the library.
• OpenSSL 3.5 or later is yours to install and patch.
• It isn't certified under FIPS 140-3 or any other scheme. Defaults that follow the guideline are not an approval.

The crypto service offers ML-KEM and ML-DSA as a separate process on L4Re and Windows. Combining them into a hybrid is up to the caller.

Database Gateway and the OData ODBC driver speak HTTPS. Their key exchange is the platform's. We make no post-quantum claim for those connections; they belong under check 5 like any other connection. What we're doing about that is in the next section.

We didn't come to this topic through a textbook. We came to it through a data path. In March 2020, when everyone was suddenly working from home, we built an emergency access route in a few days: line-of-business applications fetched their data over HTTP instead of straight from the database. It kept operations running. But it only checked who was asking, not what that person was allowed to do. Database Gateway grew out of that gap, with authentication on every request, rules per object and method, and a log that includes rejected requests. The full story is in "Remote work was urgent. Building a secure data gateway took years."

One limit remains, the one stated above: the gateway controls permissions, but the platform protects the transport, with a classical key exchange. We're working on that from two directions.

An extra quantum-resistant key for HTTPS. The model comes from the VPN world. Rosenpass runs alongside WireGuard, negotiates its own key with post-quantum algorithms, and hands it to WireGuard as the pre-shared key for its handshake, refreshing it every two minutes. WireGuard keeps encrypting as before, so the connection never ends up weaker than WireGuard alone. We're researching how to carry that pattern over to TLS 1.3 between the gateway and the driver, since TLS 1.3 can already use an externally agreed key together with the usual Diffie-Hellman exchange. We're adopting the pattern, not the algorithm choices: Rosenpass uses Classic McEliece alongside Kyber, and BSI now advises against Classic McEliece. For the post-quantum part, we're planning on ML-KEM and a combiner as described in section 2.2 of the guideline.

An edge gateway for field equipment. In the research consortium “Postquantensichere Verschlüsselung in automatisierten Systemen” (post-quantum encryption in automated systems), co-funded by the European Union and the German state of North Rhine-Westphalia, we're working with TU Dresden (the L4Re operating-system kernel), ISS (hardware), and other partners on a gateway that sits in front of equipment such as a wind turbine. The goal: a control command reaches the equipment only if its sender can prove who they are and is authorized, so nobody can take over a site through its remote access. Our part in the consortium is the algorithm and PKI as a service, meaning the certificates the parties use to recognize each other.

Where this is heading. Both directions lead back to the question that mattered in 2020: who may do what, and who can prove it? So we're extending Database Gateway into infrastructure for a supply chain. Each installation becomes its own trust domain for the companies involved in it, such as the operator, the manufacturer, and service providers. Inside it, every request is verified no matter which network it comes from (zero trust), and the parties authenticate each other with certificates from that installation's PKI instead of trusting each other by default (mutual trust). The aim includes crypto agility: when an algorithm has to change, it should change in the installation's PKI and gateway, not in every application.

This is our direction, not a current product feature. Dates and scope aren't set yet, and in a research project the path can still change. Until then, what's stated above applies to Database Gateway connections. If you're part of a supply chain like this and want a say early on, get in touch.

• You don't know yet where your cryptography lives: start with checks 1 to 4 and phase 1. You don't need outside help for that, and the German guideline sets the end of 2026 for a first inventory.
• Your .NET application signs or encrypts on its own: the library documentation walks through a first hybrid certificate chain. Features, requirements, and limits are on the product page.
• You'd rather not take the inventory alone: on our Cryptography page you can request a crypto inventory. A first conversation settles which systems are in scope.

Does TR-02102 apply outside Germany?
Not as law. It reaches you through contracts with German customers and through German procurement. The EU roadmap behind the 2030 and 2035 milestones is addressed to every EU member state.

Should we go hybrid or pure post-quantum?
BSI recommends hybrid for key exchange and for lattice-based signatures. NIST and the UK's NCSC see hybrids as transitional. If you ship to more than one market, go hybrid now and make the classical half removable later.

Can X25519MLKEM768 be used in TLS 1.3 under TR-02102?
Yes. BSI says it can be used in addition to SecP256r1MLKEM768 and SecP384r1MLKEM1024, the RFC 10024 groups it will recommend in the next version of TR-02102-2. If a contract promises “recommended under TR-02102,” offer one of those two.

What changed in TR-02102-1 in 2026?
Version 2026-01 adds migration deadlines for the first time, reworks key derivation and hybridization, and deprecates classical asymmetric schemes on their own. What earlier versions changed is in Why older answers differ.

Is replacing RSA with ML-KEM enough?
No. BSI recommends ML-KEM only in combination with a classical scheme, and a migration also covers signatures, certificates, protocols, and stored data.

Do we need FIPS 140-3?
That's a separate question. FIPS 140-3 validates cryptographic modules for US and Canadian government use. Conformity with TR-02102 is demonstrated through Common Criteria or a BSI procedure. Your customers' contracts decide which one, if any, you need.

What about Classic McEliece?
TR-02102-1 lists parameter sets, for hybrid use only since 2020, but after cryptanalytic progress in 2026, BSI advises against using it in new developments.

How long does a migration take?
The EU roadmap estimates 5 to 10 years to fully migrate all relevant systems. For a single application, the inventory and phase 1 tell you more than any general estimate.

What is a CBOM?
A Cryptographic Bill of Materials, for example in CycloneDX: a machine-readable list of the cryptographic components in a product. The German guideline recommends CBOMs for comparing vendors and notes that their delivery can be written into a contract.

Sources (checked November 3, 2026):

• BSI: TR-02102-1 "Kryptographische Verfahren: Empfehlungen und Schlüssellängen", version 2026-01 of January 23, 2026, sections 1, 1.2, 2.1 to 2.4, 5.3, 5.3.4; parts 2 to 4 at version 2026-01; notes on RFC 10024 and Classic McEliece on the same page (in German)
• BSI: press release of February 11, 2026 (in German)
• BMDS, BMI, BSI: "Nationale Umsetzung der EU-Roadmap zur Umstellung auf Post-Quanten-Kryptografie", September 11, 2026, published October 12, 2026 (in German)
• NIS Cooperation Group: "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography", Part 1, version 1.1 of June 11, 2025, and its FAQ of April 15, 2026
• European Commission: Recommendation (EU) 2024/1101 of April 11, 2024
• Section 30 of the BSI Act (in German)
• NIST: FIPS 203, FIPS 204, FIPS 205 (August 2024); SP 800-227 (September 2025); IR 8547 (October 2026)
• IETF: RFC 10024, RFC 10042, RFC 9370
• ETSI TS 103 744 V1.2.2 (2026-02)

What we're watching: the next version of TR-02102-1 (usually in January), the announced recommendation of the RFC 10024 groups in TR-02102-2, the addition of HQC, composite certificate formats becoming RFCs, and the next parts of the EU roadmap.

Regulatory statements age. If you're reading this after the date above, check the deadlines against the primary source.