7 min read<\/p>\n
The NIST standards for post-quantum cryptography have been final since August 2024 – ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures. About a year and a half later, the first migrations will begin to run in DACH companies. This text dispels the roadmap romance and shows which crypto stocks will actually be replaced by 2026 – and which will still be in place by 2028 or later.<\/strong><\/p>\n Key Takeaways<\/p>\n Related<\/span>Cloud Repatriation 2026: The TCO Model<\/a> \/<\/span> Platform Engineering 2026: Internal Developer Platforms<\/a><\/p>\n ML-KEM (formerly CRYSTALS-Kyber), ML-DSA (formerly CRYSTALS-Dilithium), and SLH-DSA (formerly SPHINCS+) have been final U.S. federal standards (FIPS 203, 204, and 205) since August 2024. Concurrently, the BSI is updating the TR-02102 series, which will include mandatory action recommendations for federal agencies and KRITIS operators in 2026. There is no mandatory migration with a hard deadline in Germany, but audit questions will be concrete.<\/p>\n Since Q1 2026, security audits at banks and insurers have consistently revealed two questions. First, which of your systems currently use cryptographic methods deemed “quantum-vulnerable”? Second, what migration roadmap have you documented to be completed by 2028? The answers circulating in most organizations are notably thin compared to what might be expected.<\/p>\n Those starting a post-quantum migration in 2026 rarely do so voluntarily. The trigger is almost always a compliance issue, a supplier audit, or a C5 audit round where the examiner explicitly asks about PQC readiness. The classic “precaution” as a standalone project is rarely budgeted; PQC is integrated into larger crypto-hygiene initiatives.<\/p>\n The banking sector plays a unique role in this movement. BaFin and the ECB made it clear in several circulars at the beginning of 2026 that post-quantum readiness should be included in operational risk assessments – not as a mandatory requirement with a deadline, but as a documentation requirement. This leads to a rapid inventory build-up in bank IT, a pace that other sectors do not need to match. Insurers will follow in Q2 2026, while energy suppliers and health KRITIS entities are already in focus due to the revised BSI law.<\/p>\n Industries, on the other hand, are working with a longer time horizon. Here, IT departments are negotiating with OT teams, machinery manufacturers, and control suppliers – a chain that shifts only within investment cycles. An automotive supplier planning new production lines is already discussing PQC-capable hardware in cost estimates, but the existing manufacturing environment will remain in place until 2028 or longer.<\/p>\n The migration reality follows three clusters: what is already productive today, what is in migration, and what remains stable. The classification is based on project observations from enterprise environments between Q4 2025 and Q1 2026 – banking conglomerates, two DAX industrial companies, and three larger medium-sized enterprises.<\/p>\n Source: NIST FIPS 203\/204\/205 (August 2024), BSI TR-02102-1 (Update 2026), project observations from banking conglomerates and DAX industrial companies Q4\/2025-Q1\/2026.<\/p>\n<\/div>\n The clearest progress is in TLS termination for public endpoints. Google has already activated the hybrid group X25519+Kyber768 in the Chrome browser in 2024, and Firefox followed in 2025. Server-side, Cloudflare, Akamai, and major load balancers transparently handle the handshake – those running modern reverse proxies will have PQC-TLS without active intervention by 2026. The interesting part is not the handshake itself but the question of which internal services behind the proxy have noticed this upgrade so far.<\/p>\n Code signing is the second area where significant movement is expected by 2026. Microsoft is testing ML-DSA signatures for Windows driver catalogues, while Sigstore is experimenting with hybrid signature chains. For enterprise software, those rolling out their own product signatures (e.g., for app store publications or internal deployment pipelines) will have a meaningful migration point in 2026, as verification libraries will be widely available on the consumer side. Firmware signatures with hardware root-of-trust will remain a topic at least until 2027.<\/p>\n The pattern is consistent. Where crypto can be swapped on the software side and included in the update cycle, migration will occur by 2026. Where hardware, firmware, or long validity periods are involved, little will happen until 2028 – or migration will occur during the next device replacement cycle, not as a separate project.<\/p>\n Almost every post-quantum roadmap written for 2025 has one or more of the following three weaknesses. First, they overestimate the speed at which libraries and certifications can be adopted. OpenSSL 3.5 with native ML-KEM has been available since Q1 2026, but many enterprise middleware, databases, and older TLS terminations still use much older OpenSSL versions. It can take 12 to 24 months for PQC support to permeate the entire dependency graph of a production environment.<\/p>\n Secondly, the roadmaps underestimate certificate management in parallel trust structures. Anyone planning to add a PQC root CA in addition to their existing root CA must consider the rollout mechanisms for browser trust stores, internal systems, and partner PKIs. This is not a crypto issue; it’s identity and certificate lifecycle management \u2013 an area that many companies are already struggling with today.<\/p>\n \n”<\/span><\/p>\n The actual quantum threat to a typical DACH company lies not in a crypto-relevant quantum computer in 2030 \u2013 but in the operational question of whether they can clean up their PKI hygiene enough in the next 36 months to even make a migration possible.<\/p>\n<\/blockquote>\n<\/figure>\n Thirdly, many roadmaps ignore the supply chain dimension. Software from third-party vendors, particularly enterprise SaaS with TLS handshakes in foreign control, is beyond direct control. Asking Salesforce, Microsoft 365, or HubSpot when their TLS terminations will switch to hybrid PQC typically results in a roadmap statement without a date. This is not a neglect on the part of the providers but a realistic assessment of their own dependencies.<\/p>\n A detail that often emerges late in projects: the performance costs of hybrid TLS handshakes are real but negligible in most scenarios. ML-KEM-768 in the hybrid approach adds about one to two kilobytes to the client hello and extends the handshake by a few milliseconds. For user-facing HTTPS, this is not noticeable. It becomes significant in high-frequency mTLS pipelines, where each connection is rebuilt \u2013 there, the few milliseconds can become a stumbling block, especially in service meshes with short session timeouts. A benchmark on the own mTLS path before rollout is worth it to avoid unexpected production latencies.<\/p>\n A second point rarely mentioned in roadmap papers: KMIP integrations and certificate templates in existing PKI software are often not PQC-ready. Anyone running Microsoft Certificate Services, Dogtag, EJBCA, or commercial enterprise CA products must check the version \u2013 PQC signatures only appear in current product cycles. The migration of the PKI stack is a separate medium-sized project alongside the mere algorithm change.<\/p>\n Companies that take their PQC homework seriously this year follow an unsurprising pattern. They start with a crypto inventory – not as a theoretical document, but as an executable scan through CycloneDX-SBOMs, TLS-Inventory tools, and manual verification of all signature methods in their CI\/CD pipeline. This inventory is the foundation for everything else and typically takes three to four months.<\/p>\n Parallel to this, library upgrades are carried out as part of regular platform releases. OpenSSL 3.5+, current LibreSSL or BoringSSL versions, Java TLS stacks with PQC support, and Go crypto packages are all included. Those who plan the upgrade as a separate project miss the mark – those who integrate it into the regular patch cycle complete it in six to nine months.<\/p>\n Operational Changes in 2026<\/p>\n Rollout Challenges<\/p>\n The crypto inventory is the most labor-intensive part in practice. TLS inventory tools like testssl.sh, sslyze, or commercial scanners like Venafi provide an initial map of the publicly visible endpoints. However, inventory questions arise at points that no scanner can automatically find: Which messaging layers are signed with which key? Which ERP module interfaces use which cipher suites? Which JWT signing keys rotate at what frequency and are verified by which libraries? These questions require multiple iterations across multiple teams – they cannot be completed in a single sprint.<\/p>\n The third pillar is the supplier conversation. Companies operating software in the cloud should explicitly ask their three most important SaaS providers in 2026 when their TLS termination will switch to hybrid PQC and when their internal signature infrastructure will support PQC methods. The answers are rarely precise, but they highlight dependencies that should be documented as residual risks in their own roadmaps. A good practice: annual PQC status in supplier review meetings, documented in the vendor risk register alongside DSGVO and NIS2 topics.<\/p>\n Lastly, the communication aspect is crucial. Executives who will be asked about their PQC status by an auditor or regulatory body in 2027 need a straightforward status report – not a glossy document. A one-page summary with three numbers (percentage of migrated TLS endpoints, status of code signing, documented supply chain dependencies) beats any 40-page concept that no one reads.<\/p>\n A realistic timeline from a project perspective – not as a mandate, but as guidance for CIOs who need to justify their actions to the board and auditors. This roadmap provides a plausible explanation for why certain steps are taken at specific times.<\/p>\n Guidance values. Specific steps depend on industry, regulatory exposure, hardware inventory, and the supply chain speed of the vendors used.<\/p>\n<\/div>\n The expectation that post-quantum cryptography will be widely operational by 2027 is unrealistic. Conversely, the belief that no changes will be necessary is equally incorrect. 2026 will mark the year when hybrid TLS is broadly deployed in the public web, code signing projects commence in earnest, and crypto inventories are established. The actual migration of critical cases – root CAs, HSM-bound keys, embedded firmware – will extend until the end of the decade.<\/p>\n For CIOs and security leaders, the operationally relevant question is not how far quantum computers are. It is which crypto hygiene measures will ensure the house passes the next audit and what immediate actions are required to make the migration feasible in three years. Those who maintain a clean crypto inventory and keep libraries up to date today have already completed 70 percent of the post-quantum preparation – without deploying a single PQC method.<\/p>\n No, unless in specific contexts with long key validity or clear compliance requirements. For most DACH companies, 2026 is the year when hybrid TLS becomes widely available and crypto inventories are built. Pure PQC migration is the exception, not the rule.<\/p>\n<\/details>\n OpenSSL 3.5 (March 2025) with native ML-KEM in TLS 1.3, BoringSSL (Chrome, Edge), Mozilla NSS (Firefox) since 2025 with X25519+ML-KEM hybrid. Sigstore is testing ML-DSA for code-signing. Java supports PQC experimentally from OpenJDK 24. For embedded systems, wolfSSL and mbedTLS with PQC branches are available.<\/p>\n<\/details>\n Serious figures are scarce because migration is integrated into the platform-patch cycle and rarely accounted for as a separate project. The separate effort for crypto inventory, PKI refactoring, and trust store management typically falls in the mid-six-figure range over three years for a 1,000-employee enterprise – less than most NIS2 implementations.<\/p>\n<\/details>\n For state secrets, long-lived contracts, and identity data with ten-year exploitation: yes. For typical business data with short operational half-life: less likely. The BSI-TR-02102 differentiates accordingly. If you’re encrypting TLS traffic today that will have no value in five years, you don’t need to adopt post-quantum as future-proofing.<\/p>\n<\/details>\n Formally, it’s not mandatory. In practice, TR-02102 serves as the reference framework that auditors, insurers, and framework partners align with. When bidding or in cyber insurance, you’ll increasingly be asked for TR-02102 compliance – even beyond formal requirements.<\/p>\n<\/details>\n Editor’s Reading Tips<\/p>\n\n
The Status in April 2026<\/h2>\n
Which Stocks Are Realistically Expected to Move by 2026<\/h2>\n
\n\n
\n \nCrypto Stock<\/th>\n Today’s Typical<\/th>\n PQC Target 2026-2028<\/th>\n Migration Reality<\/th>\n<\/tr>\n<\/thead>\n \n TLS Termination (Public)<\/strong><\/td>\n ECDHE + ECDSA\/RSA<\/td>\n Hybrid X25519+ML-KEM (TLS 1.3)<\/td>\n 2026 broad rollout in Chrome\/Edge\/Firefox, server-side via OpenSSL 3.5+ and BoringSSL<\/td>\n<\/tr>\n \n Code Signing (Software)<\/strong><\/td>\n RSA-3072 \/ ECDSA-P-256<\/td>\n ML-DSA or SLH-DSA<\/td>\n First productive deployments with Sigstore, Microsoft testing signature verification – broad adoption expected by 2027<\/td>\n<\/tr>\n \n Root CAs \/ Intermediates<\/strong><\/td>\n RSA-4096 \/ ECDSA-P-384, 10-20 year lifetime<\/td>\n Parallel CA hierarchy with ML-DSA<\/td>\n Little productive – planning phase, first Bund CAs and large enterprise PKIs building parallel trust stores<\/td>\n<\/tr>\n \n VPN Gateways (Site-to-Site)<\/strong><\/td>\n IKEv2 with ECP256\/ECP384<\/td>\n Hybrid IKEv2 + ML-KEM<\/td>\n Hardware-dependent. Firewall vendors providing first firmware updates, rollout realistic by 2027<\/td>\n<\/tr>\n \n IoT \/ Embedded Firmware<\/strong><\/td>\n ECDSA, partially RSA-2048<\/td>\n ML-DSA or Hybrid<\/td>\n Constructively tied – migration mostly during next hardware replacement cycle (2028+)<\/td>\n<\/tr>\n \n HSM-bound Keys<\/strong><\/td>\n RSA \/ ECC per FIPS 140-2\/3<\/td>\n PQC firmware from HSM vendors<\/td>\n Dependent on Thales, Utimaco, Entrust. Firmware cycles are long, certification process ongoing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What’s Shaking on the Roadmaps<\/h2>\n
What to Do Practically in 2026<\/h2>\n
\n
\n
The Roadmap to 2028<\/h2>\n
What Stays – and What Doesn’t<\/h2>\n
Frequently Asked Questions<\/h2>\n
Do I need to start using PQC productively by 2026?<\/strong><\/summary>\n
Which libraries support PQC production-ready today?<\/strong><\/summary>\n
What does a post-quantum migration cost for a medium-sized enterprise?<\/strong><\/summary>\n
Is “Harvest-Now-Decrypt-Later” a realistic threat model?<\/strong><\/summary>\n
What role does BSI-TR-02102 play for non-KRITIS companies?<\/strong><\/summary>\n