Post-Quantum Migration in DACH Enterprise IT: Which Crypto Holdings Can Actually Move by 2026

NIST’s post-quantum cryptography standards have been final since August 2024—ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures. A year and a half later, the first migrations are going live in DACH companies. This article cuts through the roadmap romance to show which crypto assets will actually move by 2026—and which will remain in place until 2028 or beyond.

RelatedCloud Repatriation 2026: The TCO Model  /  Platform Engineering 2026: Internal Developer Platforms

The state of play in April 2026

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. In parallel, Germany’s BSI is updating its TR-02102 series, with the first binding recommendations for federal agencies and critical infrastructure (KRITIS) operators set to arrive in 2026. There’s no hard deadline for mandatory migration in Germany, but audit questions are getting specific.

Since Q1 2026, two questions have been systematically appearing in security audits for banks and insurers. First: Which of your systems currently use crypto methods deemed “quantum-critical”? Second: What migration roadmap have you documented through 2028? The answers circulating in most companies are far thinner than the slides suggest.

Few organizations are starting post-quantum migrations in 2026 out of choice. The trigger is almost always a compliance requirement, a supplier audit, or a C5 attestation review where the auditor explicitly asks about PQC readiness. Standalone “preparedness” projects rarely secure budget—PQC is being pulled along as part of broader crypto hygiene initiatives.

The banking sector plays a special role in this shift. In early 2026, BaFin and the ECB made it clear in several circulars that post-quantum readiness belongs in operational risk assessments—not as a deadline-driven obligation, but as a documentation requirement. This has accelerated crypto inventory efforts in banking IT, a pace other industries don’t yet need. Insurers followed in Q2 2026, while energy providers and healthcare KRITIS are already in focus under the updated BSI law.

Industry, however, is operating on a longer timeline. Here, IT teams are negotiating with OT teams, machine manufacturers, and control system suppliers—a chain that only shifts within investment cycles. An automotive supplier planning new production lines is now including PQC-capable hardware in requirements discussions, but existing manufacturing environments will remain in place until 2028 or later.

Which assets will realistically migrate by 2026

Migration reality falls into three clusters: what’s already live in production, what’s currently migrating, and what remains firmly in place. This classification is based on project observations from enterprise environments between Q4 2025 and Q1 2026—including major banking groups, two DAX-listed industrial firms, and three larger mid-sized companies.

The clearest progress is happening in TLS termination for public endpoints. Google enabled the hybrid group X25519+Kyber768 in Chrome back in 2024, with Firefox following in 2025. On the server side, Cloudflare, Akamai, and major load balancers handle the handshake transparently—if you’re running a modern reverse proxy today, you’re already doing PQC-TLS without lifting a finger. The real question isn’t the handshake itself, but which internal services behind the proxy have even noticed this shift.

Code signing is the second area where 2026 brings movement. Microsoft is testing ML-DSA signatures for Windows driver catalogs, while Sigstore experiments with hybrid signature chains. For enterprise software, if you’re rolling out your own product signatures (for app store publications or internal deployment pipelines, for example), 2026 is a practical time to switch, as verification libraries are now widely available on the consumer side. For firmware signatures tied to hardware root-of-trust, however, the topic remains on hold until at least 2027.

The pattern is consistent. Where cryptography is software-based and can be updated in sync with regular cycles, migration happens in 2026. Where hardware, firmware, or long validity periods are involved, little changes before 2028—or migration occurs with the next device replacement, not as a standalone project.

Where Post-Quantum Roadmaps Fall Short

Nearly every post-quantum roadmap drafted in 2025 shares one or more of these three critical flaws. First, they overestimate how quickly libraries and certifications will catch up. OpenSSL 3.5 with native ML-KEM support has been available since Q1 2026—but enterprise middleware, databases, and legacy TLS terminations often rely on much older OpenSSL versions. It takes 12 to 24 months for PQC support to propagate through the entire dependency graph of a production environment.

Second, roadmaps underestimate the complexity of certificate management in parallel trust structures. If you’re planning a PQC root CA alongside your existing one, you must carefully consider rollout mechanics for browser trust stores, internal systems, and partner PKIs. This isn’t just a cryptography challenge—it’s identity and certificate lifecycle management, an area most companies already struggle with today.

The real quantum threat to a typical DACH company isn’t a crypto-capable quantum computer in 2030—it’s the operational question of who, in the next 36 months, will clean up PKI hygiene enough to even make migration possible.

Third, many roadmaps overlook the supply chain dimension. Third-party software—especially enterprise SaaS with TLS handshakes managed by external providers—falls outside direct control. Ask Salesforce, Microsoft 365, or HubSpot when their TLS termination will switch to hybrid PQC, and you’ll typically get a roadmap statement without a firm date. This isn’t negligence on the providers’ part; it’s a realistic assessment of their own dependencies.

One detail that often surfaces late in projects: the performance costs of hybrid TLS handshakes are real but negligible in most scenarios. ML-KEM-768 in hybrid mode adds roughly one to two kilobytes to the ClientHello and extends the handshake by a few milliseconds. For user-facing HTTPS, this is imperceptible. The real challenge arises in high-frequency mTLS pipelines where every connection is re-established—those extra milliseconds can become a bottleneck, particularly in service meshes with short session timeouts. That’s why benchmarking your mTLS traffic before rollout is worth the effort, so production latency doesn’t become an unpleasant surprise.

A second point roadmap papers rarely address: KMIP integrations and certificate templates in existing PKI software are usually not PQC-ready. If you’re running Microsoft Certificate Services, Dogtag, EJBCA, or commercial enterprise CA products, check the version—PQC signatures only appear in recent release cycles. Migrating the PKI stack is a mid-sized project in its own right, separate from the algorithm transition itself.

What needs to be done in practice by 2026

Companies that tackle their post-quantum cryptography (PQC) homework in earnest this year follow a decidedly unglamorous pattern. They start with a crypto inventory—not as a theoretical document, but as an actionable scan using CycloneDX SBOMs, TLS inventory tools, and manual reviews of all signing processes in their CI/CD pipeline. This inventory forms the foundation for everything that follows—and it alone takes three to four months to complete.

In parallel, library upgrades are rolled out as part of regular platform releases. OpenSSL 3.5+, the latest LibreSSL or BoringSSL versions, Java TLS stacks with PQC support, Go crypto packages—those who treat the upgrade as a standalone project will miss the mark. But those who tie it to their standard patch cycle will complete it in six to nine months.

The crypto inventory is, in practice, the most demanding part. TLS inventory tools like testssl.sh, sslyze, or commercial scanners like Venafi provide an initial map of publicly visible endpoints. But inventory questions crop up in places no scanner can automatically detect: Which messaging layer signs with which key? Which ERP module interfaces use which cipher suites? Which JWT signing keys rotate at what frequency, and which libraries verify them? These questions require multiple iterations across teams—and can’t be resolved in a single sprint.

The third pillar is supplier engagement. Companies running software in the cloud should, by 2026, explicitly ask their top three SaaS providers when their TLS termination will switch to hybrid PQC and when their internal signing infrastructures will support PQC methods. The answers are rarely precise, but they highlight dependencies that should be documented as residual risks in your own roadmaps. A good practice: an annual PQC status update in supplier review meetings, recorded in the vendor risk register alongside GDPR and NIS2 topics.

Finally, communication matters. Executive teams questioned by auditors or regulators in 2027 about their PQC status will need a clear, no-nonsense status report—not a glossy document. A one-page overview with three key figures (share of migrated TLS endpoints, code-signing status, documented supply chain dependencies) beats any 40-page concept no one will read.

The Roadmap to 2028

A realistic timeline from a project perspective—not as a mandate, but as a guide for CIOs who need to justify to management and auditors why each step comes when it does.

What Stays—and What Doesn’t

The expectation that post-quantum cryptography will be fully operational by 2027 is unrealistic. Just as unrealistic is the assumption that nothing will happen at all. 2026 is the year hybrid TLS becomes mainstream for public web services, code-signing projects gain real traction, and crypto inventories are established. The actual migration of the toughest cases—root CAs, HSM-bound keys, embedded firmware—will stretch into the end of the decade.

For CIOs and security leads, the operationally relevant question isn’t how far along quantum computers are. It’s which crypto hygiene practices your organization can survive in the next audit—and which groundwork needs to be laid now to make migration feasible in three years. If you already maintain a clean crypto inventory and keep libraries up to date, you’ve completed 70 percent of post-quantum preparation—without running a single PQC algorithm in production.

Frequently Asked Questions

Do I need to deploy PQC in production by 2026?

No—unless you’re operating in contexts with long-term key validity or clear compliance requirements. For most DACH companies, 2026 is the year hybrid TLS becomes widely available and crypto inventories are established. Pure PQC migration remains the exception, not the rule.

Which libraries currently support PQC in production?

OpenSSL 3.5 (March 2025) with native ML-KEM in TLS 1.3, BoringSSL (Chrome, Edge), and Mozilla NSS (Firefox) since 2025 with X25519+ML-KEM hybrid support. Sigstore is testing ML-DSA for code signing. Java offers experimental PQC support starting with OpenJDK 24. For embedded systems, wolfSSL and mbedTLS provide PQC branches.

What does a post-quantum migration cost for a mid-sized enterprise?

Reliable figures are scarce because migration typically folds into platform patch cycles and rarely stands as a separate project. The isolated effort for crypto inventory, PKI refactoring, and trust-store management for a 1,000-employee enterprise usually runs into the mid-six-figure range over three years—less than most NIS2 implementations.

Is “harvest-now-decrypt-later” a realistic threat model?

For state secrets, long-term contracts, and identity data with a ten-year shelf life: absolutely. For typical business data with a short operational half-life: not so much. BSI-TR-02102 makes this distinction clear. If you’re encrypting TLS traffic today that will be worthless in five years, post-quantum isn’t a future-proofing priority.

What role does BSI-TR-02102 play for non-KRITIS companies?

Legally, none—it’s not mandatory. In practice, however, TR-02102 serves as the benchmark for auditors, insurers, and framework contract partners. When bidding for projects or securing cyber insurance, expect increasing scrutiny over TR-02102 compliance—even outside formal obligations.

Source: Pexels / Markus Spiske (px:1089438)