In January 2026 Germany's Federal Office for Information Security updated its technical guideline on cryptographic mechanisms and did something it had long avoided in such clear terms: it put an end date on classical-only key agreement. For companies across the DACH region that moves a task out of the “someday” category and into the project plan. And the first step is neither cryptography nor procurement — it is an inventory.
This article is an in-depth expert contribution from our content cluster. Discover the complete overview on our main page:IT Security & Compliance →
- The deadlines are set: BSI guideline TR-02102-1 in its January 2026 version recommends classical-only key agreement only until the end of 2031; for classical signature mechanisms, sole use is deprecated by the end of 2035. The European roadmap expects highly critical systems secured by 2030.
- Symmetric stays, asymmetric goes: AES-256 and modern hash functions remain sound. Only the asymmetric mechanisms RSA, ECDH, ECDSA and Diffie-Hellman are affected — but they sit inside practically every connection.
- The bottleneck is the inventory, not the algorithm: The standards have been final since August 2024. What most companies lack is an answer to the question of which mechanism is in use where — and that answer takes months.
The quantum computer need not exist for the damage to occur
Anyone recording and archiving encrypted traffic today will decrypt it in ten years. For design data, contracts and personnel records that is not a theoretical scenario but a question of retention periods.
1. What the BSI decided in January 2026
Technical Guideline TR-02102-1 of the German Federal Office for Information Security describes which cryptographic mechanisms and key lengths are considered suitable. Formally it is a recommendation, but it is used as the basis for further federal requirements and therefore takes on indirect binding force in public sector and regulated industries.
The version of 23 January 2026 differs from its predecessors in one fundamental respect: it names dates. Classical-only key agreement is recommended only until 31 December 2031. For classical signature mechanisms, the BSI deprecates sole use by the end of 2035. A complete abandonment of RSA or ECC is not mandated — the guideline focuses on combinations of classical and quantum-safe algorithms.
BSI President Claudia Plattner described the migration to Post-Quantum Cryptography as imperative in February 2026. In parallel, the European Union pursues its own roadmap under which highly critical systems should be secured by 2030 at the latest; together with 17 European partner authorities, the BSI has called for an active transition of the most sensitive applications by 2030.
2. What is affected — and what is not
The most common misconception is that quantum computers will break “encryption”. In reality the threat is precisely bounded and touches only part of the mechanisms in use.
Comparison: at risk vs. still suitable
- RSA: Key exchange and signatures in TLS, S/MIME, code signing and VPN certificates.
- ECDH and DH: Session key negotiation in practically every encrypted connection.
- ECDSA: Signatures in certificates, firmware signing and blockchain mechanisms.
- Every PKI hierarchy built on them: Certificate authorities, smartcards, hardware tokens.
- AES-256: Disk, backup and database encryption remain quantum-safe by current understanding.
- SHA-256 and stronger: Integrity checking and hash-based mechanisms retain their effect.
- HMAC: Symmetric message authentication remains sound.
- Symmetric key lengths: The protection requirement rises moderately; no change of mechanism is needed.
This distinction is practically valuable because it shrinks the scope of the exercise dramatically. An encrypted backup archive does not need re-encrypting as long as it is secured with AES — but the key exchange that delivers the key does. Migration concerns connections, certificates and signatures, not data blocks at rest.
A word on scale, because it is routinely underestimated in budget discussions: asymmetric mechanisms sit inside well over ninety per cent of all encrypted internet connections. They are not one component among many but the layer on which trust between systems is established in the first place. Migration is therefore not a security team project alone; it touches operations, procurement, product development and supplier management alike.
A second practical point: quantum-safe keys are considerably larger than their classical predecessors. Public keys of a few hundred up to more than fifteen hundred bytes, against a few hundred for RSA, change handshake sizes, certificate chains and occasionally fragmentation at the network layer. For ordinary web and VPN connections this is uncritical. For resource-constrained devices or protocols with tight packet boundaries it is the actual migration effort — another reason to know your estate early.
3. Harvest Now, Decrypt Later
When a cryptographically relevant quantum computer will become available is contested; common estimates range between 2030 and 2040. For planning purposes, however, that question is secondary. What matters is the Harvest Now, Decrypt Later strategy, which the BSI explicitly cites in its reasoning: data intercepted and archived today can be decrypted later.
From that follows a simple prioritisation rule that requires no forecasting at all: add the protection period of your data to the current year. If the result lies beyond 2035, that data flow is already at risk today.
Design and product data
A tool or a formulation stays competitively relevant for twenty years. Transmitting that data today to suppliers over a classically secured connection effectively accepts disclosure in the 2030s.
Contracts and personnel records
Statutory retention periods and employment-law protection interests reach far beyond the critical window. Personal data with long protection requirements is moreover a data protection matter, not only a security matter.
Health and client data
Here protection periods of thirty years and more are common, sometimes with open-ended confidentiality duties. These sectors sit at the very top of any prioritisation — regardless of company size or regulatory status.
Short-lived operational data
Day-to-day telemetry, status messages and logs with short relevance are barely exposed to harvest risk. They belong in the third migration wave and should not block the first two.
4. The standards and the hybrid approach
Unlike many security topics, the technical foundation here is settled. NIST published three final standards in August 2024: FIPS 203 with ML-KEM for key exchange, FIPS 204 with ML-DSA and FIPS 205 with SLH-DSA for signatures. A fourth standard for a mechanism from the FALCON family is still in process.
For the transition period the BSI explicitly recommends Hybrid Key Agreement: a classical and a quantum-safe mechanism are executed together and their results combined into one session key through a suitable key derivation function. The reasoning is conservative and persuasive: the new mechanisms have not been subject to cryptanalysis for as long as RSA and ECC, particularly regarding implementation errors and side-channel attacks. A hybrid construction stays secure as long as at least one component holds.
It is worth noting how far the transition has already progressed in the background. Cloudflare enabled hybrid key agreement for TLS 1.3 in production in March 2024, Google Chrome activated it by default from version 124 in April 2024, and Firefox followed in the autumn of the same year. OpenSSL 3.5 integrated ML-KEM and ML-DSA natively in April 2025. For many companies this means part of their external traffic is already hybrid-protected without anyone having made a decision. Which is precisely why the inventory matters — it separates what already runs from what has been left behind.
Quantum key distribution deserves a passing mention, as it is often confused with post-quantum cryptography. Together with partner authorities from France, the Netherlands and Sweden, the BSI concludes that the technology is usable only in very specific applications because of technological constraints and is currently not ready for deployment. The priority lies unambiguously with post-quantum cryptography.
5. The crypto inventory
The real effort of migration lies not in swapping algorithms but in finding where they are. For a large organisation the cryptographic inventory alone can take six to twelve months. Even in mid-sized companies it is rarely done in two weeks, because the mechanisms sit in places that appear in no software list.
Certificates and PKI
Every TLS certificate with mechanism, key length and expiry date, plus internal certificate authorities, client certificates and smartcards. Hardware-bound keys are the most laborious item because replacing them requires physical processes.
Connections and tunnels
VPN links to sites and partners, site-to-site tunnels, remote maintenance access, encrypted database connections and interfaces to service providers. Frequently overlooked: old connections nobody actively manages any more.
Embedded systems and firmware
Machine controllers, sensors and devices with hard-wired mechanisms. Where cryptography is embedded in firmware and the manufacturer offers no update, the migration path is device replacement — with corresponding lead time.
Service providers and cloud services
Which vendors already support hybrid mechanisms, which have a roadmap, and which stay silent? That question belongs in every contract renewal from now on — and the answer belongs in your inventory.
Expert tip: start with the certificate estate
An automated scan of the certificate estate produces a solid basis within days: mechanism, key length, expiry, issuing authority. It covers a substantial part of the inventory and has a pleasant side effect — almost every first scan surfaces expired, forgotten or outdated certificates whose clean-up is worthwhile in its own right.
Two organisational points have proven decisive in our projects. First, the inventory does not belong in a one-off spreadsheet but in the place where assets are already maintained. A separate document is out of date within twelve months; a field in the existing asset register survives. Second, ownership must be named. In most mid-sized companies cryptography falls between network operations, application development and an external provider — and therefore, in case of doubt, to nobody.
It also helps to give the inventory an assessment column from the outset: migrated, hybrid in production, vendor roadmap available, no path known. The fourth category is the interesting one. It typically holds few entries but causes most of the later effort, because behind it sit hardware replacements or vendor changes. Knowing that list in 2026 means spreading it across five budget years instead of one.
6. Crypto agility in procurement
The single most effective measure in 2026 is not technical but contractual. Every piece of software and every device procured from now on should carry Crypto Agility as a requirement. Otherwise you are buying systems today that will have to be replaced again before 2031.
Mechanisms as parameters, not as code. The question to every vendor is: how do we change the key agreement mechanism in your product, and which version supports that? An answer describing a redevelopment is a knock-out criterion.
Documented migration path. The vendor names which quantum-safe mechanisms it supports or will support, and on what timeline. Naming no date is also an answer.
Re-keying in production. Existing data stores must be convertible to new mechanisms without a full reimport. For archive and document management systems this is the most expensive gap to close retrospectively.
These three questions cost minutes in a procurement process and can spare you a six-figure replacement project. They also fit seamlessly into the security requirements already travelling down the supply chain under NIS2, which we described in NIS2 in the Supply Chain.
Anyone who has to justify budget should connect the topic to existing obligations. NIS2 explicitly requires regulated entities to have policies on the use of cryptography; in Germany the obvious reference for “appropriate” is TR-02102. For affected companies the post-quantum migration is therefore not a project alongside cybersecurity compliance but a component of it — and can be run from the same budget under the same governance.
7. Migration roadmap to 2031
-
Phase 1 — 2026: inventory and risk assessment
Certificate scan, capture of connections, embedded systems and service providers. In parallel, assess data lifetime per flow to identify harvest risks. The output is a prioritised list, not a technology decision.
-
Phase 2 — 2026: crypto agility in procurement and policy
Add the three procurement questions to tenders and contract renewals, and update the internal cryptography policy with reference to TR-02102. From this point the problem stops growing.
-
Phase 3 — 2027: pilots for critical connections
Hybrid key agreement for TLS at the most important external interfaces, for partner VPN links and for the internal PKI. The goal is operational experience with larger keys and altered handshake timings.
-
Phase 4 — 2028 to 2029: broad rollout
Convert the remaining connections, renew the certificate hierarchy, replace hardware that cannot be migrated. This is the longest phase and should therefore carry the largest buffer.
-
Phase 5 — 2030 to 2031: complete key agreement migration
No classical-only key agreement left in production, in line with the BSI date of end-2031 and the European 2030 target for highly critical systems. Signatures follow on their own track through 2035.
Cryptography is the only security measure whose failure applies retroactively. Everything transmitted with inadequate protection today stays exposed — long after the systems themselves have been switched off.
Quick check: your post-quantum readiness
Conclusion
Post-quantum cryptography is one of the few security topics where technical uncertainty is low and the organisational challenge is high. The mechanisms are standardised, the recommendations are published, the browser and library landscape has already moved. What most companies lack is simply an overview — and that cannot be bought, only produced.
The deadlines are less dramatic than they sound. End of 2031 for key agreement and end of 2035 for signatures are ample windows if you start the inventory in 2026. They are tight if you start in 2029, and they are unachievable if your estate contains devices whose manufacturer offers no migration path — something you only learn once you have asked.
Our recommendation for mid-sized companies is therefore narrow: run the certificate scan in 2026, assess the protection period of your three most important data flows, and add the three procurement questions to your contract templates. That is a few days of work, and it prevents an orderly transition from turning into an expensive emergency migration.
Do you have questions about the post-quantum migration?
Book a free initial consultationOur Regional Expertise
We are your digital partner – regionally anchored and successfully scaling across borders.
Have a vision?
Let's check together how we can make your idea take flight.
Book your free strategy call nowExtended Specialized Glossary
Post-Quantum Cryptography
Cryptographic mechanisms that, according to current knowledge, cannot be broken even by quantum computers. They run on classical hardware and replace the asymmetric mechanisms RSA and ECC, not symmetric encryption.
Harvest Now, Decrypt Later
The attack strategy of intercepting and storing encrypted data today in order to decrypt it later with a capable quantum computer. It makes migration urgent for all data whose protection requirement extends beyond ten years.
Crypto Agility
The ability of a system to exchange cryptographic mechanisms and key lengths without being redeveloped. Algorithms exist as configurable parameters rather than being hard-wired into the code.
ML-KEM
Module-Lattice-Based Key-Encapsulation Mechanism, standardised as NIST FIPS 203 and derived from CRYSTALS-Kyber. It replaces RSA and ECDH in key exchange, for example in TLS, VPN and email transport.
Hybrid Key Agreement
The combination of a classical and a quantum-safe key agreement mechanism whose results are combined into one session key. The connection stays secure as long as at least one of the two mechanisms holds.
