Executive summary
Three clocks are running simultaneously in every critical infrastructure enterprise today.
The first clock is the adversary clock. Nation-state actors have been harvesting encrypted enterprise traffic for years — VPN sessions, code signing operations, firmware updates, PKI handshakes, inference calls to enterprise LLM APIs. The harvesting is not a future threat. It is a completed activity for anything captured before today, and it is an ongoing activity for everything the enterprise transmits from this point forward. When a cryptographically relevant quantum computer arrives, the private keys become derivable, and the stored traffic becomes readable. The Harvest Now, Decrypt Later timeline has already been running.
The second clock is the CRQC clock. NIST, the Department of Defense, the National Security Agency, and the major national intelligence agencies now converge on a projected arrival window in the late 2020s to early 2030s for cryptographically relevant quantum computers capable of breaking RSA-2048 and ECDSA-P256. Estimates vary by two to five years. None of them place the arrival beyond the current decade with high confidence. This clock is counting down.
The third clock is the enterprise infrastructure clock. It is gated by change control cycles, safety revalidation requirements, vendor firmware roadmaps, regulatory approval processes, and the operational reality that Cloud, IT, OT, and AI cryptographic surfaces cannot be migrated at the same pace or by the same teams. For most critical infrastructure enterprises, this clock has not yet started. It is the only one of the three the enterprise controls.
This whitepaper describes what it means to run those three clocks in parallel, why the enterprise's own clock is the one that determines outcomes, and what operating model the moment requires. It introduces the Full Stack approach to post-quantum cryptographic migration as the discipline that makes the enterprise's clock catch up.
The stakes are not abstract. Every day the enterprise delays starting its migration clock, the gap between when its infrastructure will be protected and when the adversary will have quantum-relevant compute widens. Enterprises that begin now will arrive at 2035 with a defensible cryptographic posture across Cloud, IT, OT, and AI. Enterprises that delay will arrive at 2035 explaining why they did not.
Act 1: The three clocks
The adversary clock
Harvest Now, Decrypt Later is not a hypothetical strategy. It is a documented, operational adversary technique that intelligence agencies have publicly acknowledged, that CISA has explicitly warned about, and that the mathematics of Shor's algorithm makes economically rational for any state-level actor with the storage capacity to capture and hold enterprise traffic for a decade.
The adversary's cost to execute is low. Passive network capture at internet backbone tap points is a solved problem. Storage costs continue to drop. The captured traffic does not need to be usable today — it needs only to be preserved for the moment the corresponding private keys become derivable. Every TLS session, every IKE handshake, every SSH connection, every mTLS authentication, every LLM API call that transits the internet is a potential harvest target.
The enterprise's cost to detect harvesting is essentially infinite. Passive capture is invisible from the enterprise's vantage point. There is no log entry that says "your session was captured." There is no anomaly to investigate. The adversary is not inside the enterprise's perimeter. The adversary is at the ISP, at the carrier exchange, at the international submarine cable landing station. The enterprise cannot see what the adversary has already collected, and the enterprise cannot prevent what the adversary will collect from every session transmitted before PQC migration is complete.
This clock has been running for years. It started when the first serious quantum research programs began signaling the eventual arrival of Shor-capable machines and it accelerated when NIST published the first PQC standardization drafts. Every day the enterprise transmits classically-protected traffic is a day added to the pile the adversary is holding.
The CRQC clock
The cryptographically relevant quantum computer is the machine that runs Shor's algorithm on a sufficient number of stable logical qubits to derive the private keys used in RSA-2048 and elliptic curve cryptography at production scale. Multiple credible sources have published arrival estimates:
- The National Institute of Standards and Technology positions its PQC standards as ready for deployment with the expectation that CRQC-capable systems will exist within the current decade.
- The Department of Defense CIO memo of November 2025 directed the Pentagon to inventory all classical cryptography across every system type, citing quantum arrival timelines that made the inventory operationally urgent.
- The National Security Agency's CNSA 2.0 suite, first published in September 2022 and updated in early 2025, targets full PQC-only cryptography for national security systems by 2033, implicitly acknowledging that classical crypto will not be defensible past that horizon.
- Multiple national intelligence assessments from allied nations, including the United Kingdom's NCSC and Germany's BSI, position CRQC arrival within the same late 2020s to early 2030s window.
These estimates have moved earlier in each successive publication cycle. Five years ago, credible sources placed CRQC arrival in the 2040s. Three years ago, the mid-2030s. Today, the late 2020s to early 2030s. The trend line is toward earlier arrival, not later.
The exact arrival date does not matter for planning purposes. What matters is that the arrival window is inside the operational lifetime of infrastructure being deployed today. A programmable logic controller commissioned in 2026 will still be running in 2036. A safety system commissioned in 2026 will still be running in 2041. A cloud workload deployed in 2026 will migrate through multiple generations of PQC readiness before it retires. Every infrastructure decision made this year has to assume that the CRQC will arrive during that infrastructure's lifetime.
The enterprise clock
The third clock is different from the first two in one critical way: the enterprise controls when it starts and how fast it runs.
For most critical infrastructure enterprises today, this clock has not started. Cryptographic inventory across Cloud, IT, OT, and AI has not been assembled. Migration priority has not been assigned. Vendor PQC roadmaps have not been formally requested. Executive reporting infrastructure for PQC posture does not exist. The enterprise cannot yet answer the question its board or regulator will eventually ask.
Even for enterprises that have started the clock, it runs slowly for structural reasons. Cloud migration is fastest because cloud infrastructure is software-defined and updates continuously. IT migration is next fastest, gated by PKI transition cycles, HSM certification, and enterprise change control. OT migration is dramatically slower, gated by functional safety revalidation, vendor firmware availability, maintenance window availability, and the operational reality that most industrial assets cannot be migrated in place. AI migration is a newly-recognized surface that most enterprises have not yet formally scoped.
The enterprise clock therefore has four sub-clocks, each with different maximum speeds. The Full Stack migration timeline is set by the slowest of the four — which is typically OT, followed by AI in AI-forward enterprises. Even the fastest sub-clocks require years to complete when done properly. The critical implication is that starting the clock late does not permit accelerating it later. The clock's speed is set by the physics of the environments being migrated, not by the enterprise's willingness to hurry.
This is why the enterprise clock is the one that determines outcomes. The adversary clock cannot be paused. The CRQC clock cannot be delayed. The enterprise clock is the only one within the enterprise's control, and it is the clock that will either bring the infrastructure to PQC readiness before the CRQC arrives or leave the enterprise exposed at the moment of arrival.
Act 2: The four surfaces
Post-quantum cryptographic migration does not touch one thing. It touches four distinct architectural surfaces, each with different physics, different owners, different vocabularies, and different timelines.
Cloud is the fastest-migrating surface. Cloud crypto lives in KMS metadata, TLS session logs, API gateway configurations, workload identity systems, and cloud service provider PKI hierarchies. It is software-defined and continuously updatable. Cloud service providers have public PQC roadmaps and are shipping hybrid PQC support in production. The cloud surface is instrumentable through cloud platform APIs and updatable through configuration changes. It is owned by cloud engineering teams who are accustomed to continuous change.
IT is the second-fastest surface. IT crypto lives in enterprise certificate authorities, machine identity systems, VPN concentrators, HSM catalogs, SSH host key infrastructure, code signing pipelines, and the vast surface of endpoint and server TLS configurations. Migration is gated by PKI transition cycles, HSM certification schedules, and enterprise change control. Standards are mature — NIST FIPS 203/204/205 are ready to deploy, and major PKI vendors are shipping hybrid PQC support. The IT surface is largely instrumentable through enterprise inventory systems and updatable through coordinated migration programs. It is owned by IT security and enterprise infrastructure teams.
OT is the slowest-migrating surface and the highest-consequence one. OT crypto lives in industrial protocol implementations, PLC firmware, RTU configurations, historian TLS sessions, safety system interfaces, and the extensive fleet of embedded devices deployed on operating floors, in substations, in refineries, in pumping stations, and in industrial control environments across every critical infrastructure sector. Migration is gated by functional safety revalidation requirements, vendor firmware release schedules, maintenance window availability, and the operational reality that many industrial assets cannot be migrated in place at all — they must be protected by boundary gateways or replaced during natural end-of-life cycles. The OT surface is minimally instrumentable through existing tools and slowly updatable through vendor cooperation. It is owned by plant operations, industrial engineering, and OT security teams.
AI is the newest surface and the least mature in terms of visibility and standards. AI crypto lives in model registry signatures, inference gateway TLS sessions, confidential computing attestations, agent identity certificates, RAG pipeline authentication, and AI Bill of Materials artifacts. Migration is gated by AI infrastructure vendor roadmaps, model registry signing algorithm support, and the emerging state of AI governance frameworks. The AI surface is partially instrumentable through model registry APIs, inference gateway logs, and confidential computing attestation services, but the operational discipline of AI PQC inventory is still emerging. It is owned by AI platform teams that in most enterprises did not exist two years ago and are still defining their operational scope.
Four surfaces. Four sets of physics. Four owners. Four vocabularies. Four migration timelines running in parallel. The Full Stack migration program is the coordination discipline that runs all four simultaneously as one governed enterprise activity, rather than four uncoordinated projects that produce four disconnected results.
This whitepaper series treats the four-surface reality as the central operational fact of PQC migration. Whitepaper 2 describes how to run the migration operationally across all four surfaces from a single dashboard. Whitepaper 3 zeroes in on the five questions the AI surface generates that most security teams cannot answer. Whitepaper 4 provides the deep technical taxonomy of the AI surface for architects and standards bodies.
Act 3: Why this is different from every prior security migration
Enterprises have executed large cryptographic transformations before. Y2K remediation. PCI DSS adoption. HIPAA cryptographic controls. GDPR data protection requirements. SOX audit trails. Every one of these was a major program that touched the enterprise's technology fabric.
Post-quantum cryptographic migration is not like any of them.
It spans four surfaces that no prior transformation did. PCI DSS touches payment infrastructure. HIPAA touches clinical systems. Y2K touched date-handling code across the enterprise but did not require re-architecting cryptographic primitives. GDPR touches data processing surfaces. PQC migration touches every place classical asymmetric cryptography is embedded — which is essentially every network session, every certificate, every code signature, every firmware image, every model artifact. No prior transformation had this scope.
It requires coordination across teams that do not currently coordinate. Cloud engineering, IT security, plant operations, and AI platform teams operate on different budgets, different tool stacks, different reporting lines, and different vocabularies. Prior transformations were typically owned by a single organizational silo — payments, clinical, legal, finance. PQC migration cannot be owned by any single silo. It must be run as an enterprise-wide program that produces one unified posture across four organizational domains that were not designed to produce unified anything.
It operates on a timeline the enterprise does not fully control. Y2K had a fixed deadline the enterprise could plan against. PCI DSS deadlines are set by the payment card industry and enforced through merchant agreements. HIPAA and GDPR are set by regulators with published enforcement timelines. PQC migration has three timelines — the adversary clock, the CRQC clock, and the enterprise clock — and the enterprise controls only the third. The other two set the deadline the enterprise must meet, and neither publishes a definitive date the enterprise can plan against.
It has no clean end state. Y2K ended when calendars rolled over. PCI DSS certification is a discrete audit event. HIPAA compliance is a defensible operational posture. PQC migration does not end when classical algorithms are retired — it continues as an ongoing governance discipline because new AI systems deploy weekly, new industrial firmware ships continuously, new cloud services launch monthly, and new cryptographic vulnerabilities emerge on unpredictable schedules. PQC migration is a program the enterprise will run indefinitely, not a project it will complete.
The consequence: the operating model that worked for prior transformations will not work for PQC migration. Y2K was run by task force. PCI DSS is run by compliance team. GDPR is run by legal and data governance. PQC migration must be run by an operating discipline that spans all four architectural surfaces and produces continuous governance rather than periodic certifications. This is a category of program most enterprises have never run before.
Act 4: The regulatory arc
Regulatory frameworks are moving toward PQC readiness on timelines that align with the CRQC clock. The enterprise that treats PQC migration as a future compliance problem will discover it is a current compliance problem inside the next audit cycle.
NIST FIPS 203, 204, and 205 — the finalized post-quantum standards for key encapsulation (ML-KEM), digital signatures (ML-DSA), and hash-based signatures (SLH-DSA) — were published in August 2024 and are ready for production deployment. Federal agencies are now migrating. Federal contractors and defense industrial base suppliers are being pulled onto the same timeline through contract flow-down.
NIST SP 800-208 — the standard for stateful hash-based signatures used in firmware signing and other long-lifecycle use cases — was published in October 2020 and provides the deployable specification for LMS and XMSS signatures. Firmware signing is the CNSA 2.0 first mandated PQC use case, meaning defense-adjacent firmware suppliers are being pulled onto PQC signing timelines already.
CISA's Automated Cryptography Discovery and Inventory strategy is the emerging cross-sector framework for continuous cryptographic posture visibility. It applies to all sixteen CISA critical infrastructure sectors and is being cited by sector regulators as the benchmark for what continuous cryptographic governance should look like. Enterprises that build to ACDI now will be aligned to what sector regulators will require within the next two audit cycles.
Sector-specific frameworks are converging with the cross-sector standards. NERC CIP for energy, HIPAA and FDA premarket review for healthcare, FFIEC and NYDFS for financial services, TSA Security Directives for transportation, EPA for water and wastewater, and the emerging DoD Responsible AI guidance for defense are all moving toward explicit cryptographic assurance requirements that reference NIST PQC standards.
The EU AI Act high-risk system provisions require cryptographic assurance for provenance, integrity, and access control. The AI Act's compliance clock is running now for high-risk system operators, and the classical crypto stack will not satisfy the assurance requirement once quantum-relevant compute arrives.
The pattern across sectors is consistent. Regulators are not waiting for CRQC arrival to require cryptographic assurance. They are requiring the operational visibility and migration posture now, because the enterprise that cannot demonstrate current PQC posture cannot demonstrate migration readiness, and cannot defend its risk posture to any regulator, insurer, or Authorizing Official who asks.
The regulatory clock is now aligned with the adversary clock and the CRQC clock. All three are running toward the same horizon.
Act 5: What the enterprise must build
The operating model the moment requires is the Full Stack approach — a coordinated discipline that runs cryptographic posture management across Cloud, IT, OT, and AI as a single continuously-governed program rather than four uncoordinated projects.
Three capabilities define the Full Stack approach.
Full Stack visibility. The enterprise must be able to answer, at any moment, what its current cryptographic posture is for every asset it owns across Cloud, IT, OT, and AI. Not four separate answers from four separate teams. One unified answer, generated from live data, expressed in vocabulary a board or regulator can act on. The enterprise cannot decide what to migrate first without knowing the current state of all four surfaces at once.
A living migration roadmap. Once visibility is established, the enterprise must prioritize migration actions across all four surfaces using a consistent scoring model — quantum exposure, data sensitivity, and migration ease — and the roadmap must re-order itself continuously as the underlying data changes. A VPN concentrator that was medium-priority last week becomes high-priority this week when the vendor ships PQC-capable firmware. An AI inference gateway becomes high-priority when passive traffic analysis discovers it started handling regulated data. The roadmap is not a slide deck built quarterly. It is a live operational artifact updated as reality changes.
Continuous governance. The enterprise must generate executive reporting from live data, on demand, for the audiences that require it. The board asking for current posture. The Authorizing Official signing an ATO. The regulator conducting an examination. The insurance underwriter assessing quantum risk. The audit committee reviewing enterprise risk. Every one of these audiences must receive an answer generated from the current state of the visibility layer and the migration roadmap. No manually-assembled slide decks. No spreadsheets that go stale between quarters. Continuous governance is what turns visibility and prioritization into defensible posture.
The Full Stack approach is not defined by any particular tool. It is defined by the operational discipline of running the three capabilities continuously across four surfaces as one program. The enterprise that builds this discipline can catch its own clock up to the adversary clock and the CRQC clock. The enterprise that does not will arrive at 2035 as an enterprise that could not.
Coda: The one question
Every critical infrastructure enterprise should be able to answer one question about its post-quantum cryptographic posture at any moment on any Monday morning:
What percentage of our cryptographic surface is currently PQC-ready across Cloud, IT, OT, and AI, and what is our projected date to complete migration of the remainder?
That question has one right answer format: a current-state percentage across all four environments and a projected completion date grounded in the enterprise's actual migration velocity. Not four separate percentages from four separate teams. Not a promise to assemble the answer by Wednesday. Not a slide deck stale on arrival.
The enterprise that can answer that question can walk into any board meeting, any audit committee, any regulator examination, any Authorizing Official conversation, and demonstrate that its clock is running fast enough to close the gap before the CRQC clock arrives.
The enterprise that cannot answer that question is not late. It has not yet started.
The three clocks are running. The adversary clock has been running for years. The CRQC clock is counting down. The enterprise clock is the only one within the enterprise's control, and it does not start on its own. Someone has to start it.