The Widest Intent-to-Execution Gap in Enterprise Security
There is no shortage of executive intent around post-quantum cryptography. DigiCert's 2026 survey of 1,001 enterprise security leaders found 87% reporting plans to adopt quantum-safe encryption. Only 7% had broadly deployed it. An eighty-point gap between stated plan and shipped reality is unusual even by the generous standards of enterprise security roadmaps.
The standard explanations don't hold up well. This isn't a standards problem: NIST finalised its primary post-quantum algorithms — ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures — and the specifications have been stable long enough for implementations to mature. It isn't a vendor problem: OpenSSH, TLS libraries, HSM vendors, and cloud KMS products all ship post-quantum options now. It isn't primarily a budget problem either, given the market has grown from roughly $1.6 billion in 2025 toward a projected $2.2 billion in 2026.
The gap persists because of what the migration actually consists of. Replacing a cryptographic algorithm in a real production estate is not a purchase or a configuration change. It is a code change, repeated across every place a system negotiates a key, validates a signature, pins a certificate, or hardcodes an algorithm identifier — and in most organizations, nobody holds an accurate map of where those places are. The 7% figure isn't measuring appetite. It's measuring how many organizations have completed a difficult refactor.
Why This Is an Engineering Problem, Not a Procurement One
Consider what a cryptographic migration touches in a typical codebase of any age. Algorithm identifiers hardcoded as string constants because there was only ever one right answer. Certificate pinning logic in a mobile client, shipped to devices you don't control, with a hardcoded expectation about key size. Custom protocol code written when a library didn't quite fit, now load-bearing and unowned. Key material serialised into database columns with fixed widths. Signature verification in a licence check, a webhook handler, an internal service mesh, a firmware update path.
None of these are hard problems individually. Collectively they are a discovery-and-refactor programme spanning quarters, across systems whose original authors have often left, with the unusual property that a subtle mistake produces a security regression rather than a visible failure. Cryptographic code that is wrong frequently still works — it interoperates, tests pass, traffic flows — while providing materially less protection than intended. That is the worst possible feedback profile for a large mechanical refactor.
It's also work with no visible product outcome. A completed PQC migration ships no feature, closes no customer request, and moves no adoption metric. Its entire value is the absence of a future failure. In any organization where engineering capacity is contended between roadmap commitments and infrastructural hygiene, this is the category of work that loses every quarterly prioritisation discussion — which is a sufficient explanation for an eighty-point gap between plan and execution without needing any others.
The Deadlines That Actually Bind
Public discussion of quantum risk tends to orbit the question of when a cryptographically relevant quantum computer will exist, which is genuinely uncertain and therefore easy to defer. The compliance deadlines are not uncertain, and several land inside the current planning horizon.
On September 21, 2026, NIST moves all remaining FIPS 140-2 certificates to Historical status, leaving only FIPS 140-3 validated implementations acceptable for new US federal procurement. The NSA's CNSA 2.0 framework requires quantum-safe algorithms for new national security system acquisitions from January 2027, with full application migration expected by 2030 and complete infrastructure migration by 2035. Those requirements do not stay inside government: they cascade through defence contractors, federal suppliers, and regulated industries as procurement conditions, which is how a national security standard becomes a commercial deadline for companies that never sell to a government directly.
The eight-to-fifteen year migration horizon that analysts describe for large enterprises is not a reason to relax. It's the reason the near-term deadlines matter: if the total programme runs a decade, the organizations that haven't started have already consumed a meaningful fraction of their available runway. Migration timelines published this year make the point plainly — the clock started before most security teams noticed it.
Key Takeaways
- September 21, 2026: remaining FIPS 140-2 certificates move to Historical; only FIPS 140-3 counts for new US federal procurement
- January 2027: CNSA 2.0 requires quantum-safe algorithms for new national security system acquisitions
- 2030 for application migration, 2035 for infrastructure — and these cascade to contractors and regulated industries
- A decade-long programme means organizations that haven't started have already spent part of their runway
Harvest Now, Decrypt Later Makes Delay a Decision With a Price
The argument for waiting rests on a reasonable-sounding premise: no cryptographically relevant quantum computer exists today, so data encrypted with today's algorithms is safe today. That premise is true and largely irrelevant, because it addresses the wrong threat model.
Harvest now, decrypt later is the operative risk. An adversary who captures encrypted traffic or exfiltrates encrypted archives today does not need to break the encryption today. They need only to store it until a capable machine exists. This inverts the usual logic of security deadlines: for confidentiality of long-lived data, the cost of delay is incurred now and the consequence materialises later, which means the deadline for protecting a given piece of data is not when quantum computers arrive but when that data is first transmitted.
The practical consequence is that data lifetime, not algorithm availability, should drive migration sequencing. Data with a confidentiality requirement measured in decades — health records, financial identities, source code and trade secrets, government and defence material, long-term contracts — is already exposed if it crosses the wire under classical encryption. Session data that is worthless in a week is genuinely not urgent. Most organizations have never performed this triage, which is why PQC programmes often begin by migrating whatever component was easiest rather than whatever data was most durable.
What Deployment Actually Looks Like on the Ground
Survey data captures intent. Network telemetry captures reality, and Forescout's 2026 analysis is bracing. PQC-capable SSH servers grew 72% year over year, from 11.5 million to more than 19 million — genuine, fast progress. That growth still leaves total PQC support at 11.8% of SSH servers, meaning nearly 90% remain incapable. Rapid growth from a small base is still a small base.
The distribution matters more than the aggregate. Among enterprise network devices, 50% of IT devices run PQC-capable OpenSSH versions, falling to 28% for IoT, 16% for OT, and 6% for connected medical devices. TLS shows the same shape: post-quantum support reaches 8% on enterprise IT devices, 5.6% on IoT and IoMT, and 0.8% on OT. Forescout's sharpest finding is the risk correlation — two-thirds of OT devices and nearly half of IoT devices carry critical risk ratings while lacking any PQC capability. Quantum exposure is concentrating precisely where remediation is hardest and where device lifecycles are measured in decades.
This is the empirical case against treating PQC as a vendor-driven upgrade that will arrive on its own. Standard IT infrastructure does broadly get carried along by library and OS updates. Everything else — embedded systems, industrial equipment, medical devices, long-lived firmware, and bespoke protocol implementations — requires deliberate engineering effort per system. That is the long tail where the actual programme cost lives, and it does not shrink by waiting.
Key Takeaways
- PQC-capable SSH servers grew 72% in a year to 19 million — yet that is still only 11.8% of all SSH servers
- Enterprise PQC-capable OpenSSH: 50% of IT devices, 28% IoT, 16% OT, 6% connected medical devices
- Enterprise TLS post-quantum support: 8% IT, 5.6% IoT/IoMT, 0.8% OT
- Two-thirds of OT and nearly half of IoT devices are rated critical risk while lacking PQC capability
Crypto-Agility Is the Actual Deliverable
The most common strategic error in PQC planning is scoping the project as 'migrate to ML-KEM and ML-DSA.' That framing guarantees you will repeat the entire exercise the next time the cryptographic landscape shifts — and the post-quantum algorithm landscape is still moving, with ongoing refinements and additional candidates.
The durable deliverable is crypto-agility: the ability to change cryptographic algorithms without rebuilding the application around them. Concretely, that means cryptographic operations behind an abstraction rather than called directly with hardcoded algorithm identifiers; algorithm selection driven by configuration and negotiation rather than compiled-in constants; key and signature storage sized for change rather than for today's exact byte lengths; and protocol implementations that can advertise and accept multiple algorithms during a transition period.
Building this costs meaningfully more than a point migration to a specific algorithm, and it is the correct investment. An organization with crypto-agility handles the next transition as a configuration rollout. An organization without it handles every transition as another multi-quarter refactoring programme, competing again against the roadmap and losing again. NIST's own migration guidance treats agility as a first-class objective rather than a nice-to-have, and that emphasis is well placed.
The Discovery Phase Nobody Budgets For
Every serious PQC migration begins with an unglamorous phase that organizations consistently underestimate: finding the cryptography. You cannot migrate what you cannot enumerate, and few organizations possess an accurate inventory of where cryptographic operations occur across their code, infrastructure, devices, and third-party integrations.
This is where a cryptographic bill of materials earns its keep — an inventory of algorithms, key sizes, certificate dependencies, and protocol versions, mapped to the systems and data they protect. Forescout's recommendations point the same direction: build real-time cryptographic inventories of network assets with and without PQC support, correlate that inventory against risk factors like criticality and exposure, and use secure remote access gateways to contain exposure for unmanaged devices that cannot practically be upgraded during the migration window.
Discovery routinely surfaces the surprises that determine programme scope: a vendor integration still negotiating a deprecated cipher, a mobile client with pinning logic that will reject rotated certificates, an internal service still using a hand-rolled signature scheme from a decade ago, a firmware image nobody can rebuild because the toolchain is gone. Each of these is a small project. Discovered early, they schedule. Discovered late, they become the reason a deadline slips.
Key Takeaways
- Build a cryptographic bill of materials before planning migration waves — enumeration precedes remediation
- Correlate the inventory with data lifetime and system criticality to sequence work by actual risk
- Use secure remote access gateways to contain exposure for devices that cannot be upgraded in time
- Expect discovery to surface unowned bespoke crypto and unbuildable firmware; these define real scope
Who Actually Does This Work
The staffing question is where most PQC programmes quietly stall. The work requires engineers who can read unfamiliar code carefully, reason correctly about cryptographic properties, and grind through a long inventory of small mechanical changes without losing precision. It requires continuity, because the map of where cryptography lives in a large estate is knowledge that accumulates over months and evaporates when contractors rotate off. And it competes for exactly the senior capacity that product roadmaps also want.
It's also a poor fit for the two most common fallbacks. Project-based outsourcing struggles because the scope genuinely cannot be specified up front — discovery defines it, and a fixed-scope contract written before discovery is a contract written against the wrong project. Handing it to whichever internal engineers have slack means the work advances in whatever fragments remain after feature commitments, which for an infrastructural programme with no visible output means it advances very slowly or not at all.
This is the shape of problem dedicated nearshore teams handle well, and it's a large part of why Stepto builds engagements as persistent senior teams rather than fixed-scope projects. A dedicated team accumulates and retains the cryptographic map of your estate, works through the long tail at a steady cadence on European hours, and — crucially — is not competing with your product roadmap for the same people, which is what allows infrastructural work to actually finish. When the deliverable is crypto-agility rather than a single algorithm swap, having the same senior engineers across the whole programme is the difference between building a capability and accumulating half-finished migrations.
Key Takeaways
- PQC migration needs senior engineers who can reason about cryptography and sustain precision through mechanical work
- Fixed-scope outsourcing fits badly: discovery defines the scope, so it cannot be specified in advance
- Internal teams lose this work to roadmap prioritisation because it produces no visible product outcome
- A dedicated team that isn't competing with the roadmap is what lets infrastructural programmes reach completion
The Bottom Line
The 87%-plan-versus-7%-deployed gap in post-quantum cryptography is not a story about executives failing to take quantum risk seriously. It's a story about a category of engineering work that organizations are structurally bad at completing: long, invisible, precision-demanding refactors that produce no feature and lose every prioritisation debate. The deadlines are no longer comfortably distant — FIPS 140-2 certificates go Historical on September 21, 2026, CNSA 2.0 binds new national security acquisitions from January 2027, and those requirements cascade into commercial procurement well beyond government. Meanwhile harvest-now-decrypt-later means the exposure window for long-lived confidential data opened years ago. The organizations that will finish this work are the ones treating it as what it is: a multi-quarter engineering programme whose real deliverable is crypto-agility, resourced with senior engineers who can hold the map of the estate in their heads and who aren't being pulled onto the roadmap every sprint.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversation