[{"data":1,"prerenderedAt":1907},["ShallowReactive",2],{"whitepapers-index":3},[4,213,540,793,1060,1586],{"id":5,"title":6,"author":7,"authorTitle":8,"authorUrl":9,"body":10,"canonical":9,"category":161,"cover":9,"date":162,"description":163,"draft":164,"extension":165,"faqs":9,"findingsSource":9,"image":166,"keyFindings":167,"meta":171,"modified":9,"navigation":172,"path":173,"pdfUrl":9,"pullquote":9,"recommendations":174,"references":178,"related":9,"seo":203,"signposts":9,"slug":204,"stats":9,"stem":205,"tags":206,"tldr":211,"__hash__":212},"whitepapers\u002Fresources\u002Fwhitepapers\u002Ffive-questions-ai-security.md","The Five Questions Your AI Security Team Cannot Answer Today","Shadya Maldonado","Co-Founder & CEO",null,{"type":11,"value":12,"toc":150},"minimark",[13,18,22,25,28,32,35,38,41,44,46,50,53,56,59,62,64,68,71,74,77,80,82,86,89,92,95,98,100,104,107,110,113,116,118,122,125,132,138,144,147],[14,15,17],"h2",{"id":16},"executive-summary","Executive summary",[19,20,21],"p",{},"Enterprises deploying AI at scale are running production systems whose cryptographic foundations they cannot see. Not because the security team is careless. Because the tools that give them visibility into cloud posture, endpoint posture, and network posture were not designed to answer questions about the AI stack.",[19,23,24],{},"Five questions define the visibility gap. Every AI-forward enterprise should be able to answer them in real time. Most cannot answer any of them today. This brief defines the five questions, explains why they matter, and describes the operational posture that closes the gap.",[26,27],"hr",{},[14,29,31],{"id":30},"question-1-which-of-our-production-models-are-signed-with-quantum-vulnerable-algorithms","Question 1: Which of our production models are signed with quantum-vulnerable algorithms?",[19,33,34],{},"Every foundation model, fine-tuned variant, and inference endpoint in production carries a cryptographic signature. That signature is what the deployment pipeline validates before loading the model. If the signature is valid, the model is trusted. If the signature was created with RSA or ECDSA — which almost every model signature is today — then a cryptographically relevant quantum computer will make it forgeable.",[19,36,37],{},"Most enterprise security teams cannot produce a list of every model in production with its signature algorithm. They can produce a list of models. They can produce a list of registries. But the mapping from model to signing algorithm to quantum exposure is not something existing tools surface, because existing tools were built to catch malware, not to inventory cryptographic provenance.",[19,39,40],{},"The consequence: when a nation-state adversary forges a signature on a poisoned foundation model and pushes it to a public registry, every enterprise pulling from that registry accepts it as legitimate. The poisoning targets specific edge cases — a misdiagnosis on a particular pattern of chest X-rays, an incorrect approval on a particular loan profile, a subtle miscalibration in an industrial control loop. Standard benchmarks do not catch it. Production monitoring does not catch it. Only the adversary knows when to invoke the poisoned behavior.",[19,42,43],{},"The team that can answer Question 1 in real time can migrate the model signing pipeline before that scenario becomes executable. The team that cannot is exposed.",[26,45],{},[14,47,49],{"id":48},"question-2-how-many-of-our-enterprise-prompts-have-been-captured-on-classical-tls-sessions","Question 2: How many of our enterprise prompts have been captured on classical TLS sessions?",[19,51,52],{},"Every prompt sent to an enterprise LLM API travels over a TLS session. The session key is derived from a classical key exchange — RSA or ECDHE. Nation-state adversaries with tap points on the internet backbone are capturing these sessions today and storing them. When a CRQC arrives, the private keys become derivable and the stored sessions become readable.",[19,54,55],{},"The average enterprise has sent thousands to millions of prompts to LLM APIs over the past two years. Those prompts contain legal strategy, patient records, source code, engineering designs, financial analysis, M&A modeling, and classified reasoning. Every one of them is a Harvest Now, Decrypt Later target that has already been harvested.",[19,57,58],{},"The security team is expected to know how much data has been sent to which LLM APIs over which sessions using which cipher suites. That data exists — it is in inference gateway logs, in cloud API telemetry, in enterprise firewall records. But it is not aggregated into a single answer. No dashboard in most enterprises produces the number: \"the number of enterprise prompts currently at risk of retroactive decryption.\"",[19,60,61],{},"That number is not zero. The team that can produce it can begin protecting future traffic today. The team that cannot has no baseline for how bad the exposure will get before it is contained.",[26,63],{},[14,65,67],{"id":66},"question-3-which-of-our-confidential-ai-workloads-depend-on-quantum-vulnerable-attestation","Question 3: Which of our confidential AI workloads depend on quantum-vulnerable attestation?",[19,69,70],{},"Confidential computing is the fastest-growing security architecture for enterprise AI. Intel SGX, AMD SEV-SNP, and NVIDIA H100 confidential compute enclaves promise that models run in verified enclaves where neither the cloud provider nor the adversary can extract the data. That promise depends entirely on remote attestation — a cryptographic proof that the enclave is genuine and running the expected code.",[19,72,73],{},"Every remote attestation certificate today is RSA or ECDSA-signed. When a CRQC arrives, the attestation can be forged. The adversary presents a \"verified\" enclave that is not verified at all. The confidentiality guarantee evaporates.",[19,75,76],{},"Most enterprises building confidential AI cannot list which workloads depend on which attestation service and which cryptographic algorithm. Attestation is an infrastructure primitive that \"just works\" until it doesn't. When it doesn't, the entire confidential AI investment thesis is defeated.",[19,78,79],{},"The team that can answer Question 3 can prioritize migration of the highest-risk confidential workloads, request PQC attestation roadmaps from chip and CSP vendors, and put compensating controls in place for workloads whose attestation cannot yet be migrated. The team that cannot is trusting cryptography that has a defined shelf life.",[26,81],{},[14,83,85],{"id":84},"question-4-in-our-multi-agent-architectures-which-agent-identities-can-be-forged","Question 4: In our multi-agent architectures, which agent identities can be forged?",[19,87,88],{},"Enterprise AI is moving fast toward multi-agent architectures. LangGraph, CrewAI, AutoGen, MCP-based agent networks, Agentforce, Microsoft Copilot Studio — every major AI platform is building agent-to-agent workflows where one agent authenticates to another, executes actions, accesses data, and returns results. That authentication is a certificate-based operation, and the certificates are classical crypto.",[19,90,91],{},"When a CRQC exists, agent identity certificates become forgeable. An adversary inserts a malicious agent into a legitimate workflow. It authenticates correctly. It participates in reasoning chains. It executes tools. It accesses data. It terminates its session. No trace remains beyond audit logs that look completely legitimate — because they are cryptographically legitimate.",[19,93,94],{},"The security team is expected to know how many agent identities exist in the enterprise, which are internal versus vendor-supplied, which certificate authority issued each one, and what algorithm secures each one. That inventory is not something most enterprises have built. Agent frameworks are recent. Governance frameworks for agents are still emerging.",[19,96,97],{},"The team that can answer Question 4 can begin migrating agent identity PKI on the same timeline as the rest of the enterprise. The team that cannot has a permanent invisible back door growing at the rate their agent architecture grows.",[26,99],{},[14,101,103],{"id":102},"question-5-when-our-board-asks-for-a-single-number-describing-our-ai-cryptographic-risk-what-do-we-say","Question 5: When our board asks for a single number describing our AI cryptographic risk, what do we say?",[19,105,106],{},"Every other AI risk category has a governance answer. Model bias has metrics. Hallucination has evaluation frameworks. Data privacy has DLP controls. Prompt injection has guardrails. Every one of these can be reported to a board or a regulator with a defensible number.",[19,108,109],{},"Cryptographic posture of the AI stack has no such number in most enterprises today. There is no metric that answers \"what percentage of our AI cryptographic surface is PQC-ready, and what is our target date for the remainder.\" There is no unified report that spans model provenance, inference session integrity, attestation, agent identity, RAG authentication, and governance controls.",[19,111,112],{},"The consequence: when a board or regulator or Authorizing Official asks the question, the answer is a promise to look into it. That answer will not survive the next audit cycle in any regulated sector. NIST AI RMF is developing PQC guidance. EU AI Act high-risk system provisions are moving toward cryptographic assurance requirements. FDA premarket review for AI medical devices is heading in the same direction. Financial services regulators are following the same path.",[19,114,115],{},"The team that can answer Question 5 with a single defensible number can walk into any board meeting, any audit, any regulator conversation and demonstrate current posture, current trajectory, and current gap closure timeline. The team that cannot will spend the next three years explaining why they were surprised.",[26,117],{},[14,119,121],{"id":120},"what-closes-the-gap","What closes the gap",[19,123,124],{},"The visibility gap defined by these five questions closes when three capabilities are in place simultaneously.",[19,126,127,131],{},[128,129,130],"strong",{},"First",", continuous ingestion of cryptographic posture data from every AI infrastructure component in the enterprise — model registries, inference gateways, confidential compute attestation services, agent identity systems, RAG pipelines, AI governance platforms, and the vulnerability scanners, PKI lifecycle tools, and OT visibility platforms the enterprise has already invested in for the rest of its stack.",[19,133,134,137],{},[128,135,136],{},"Second",", reconciliation of that data into a single unified inventory that answers each of the five questions with a live, current, defensible number — not a quarterly snapshot, not a manually-updated spreadsheet, not four separate dashboards from four separate teams.",[19,139,140,143],{},[128,141,142],{},"Third",", a prioritized migration backlog that translates the current posture into forward-moving work: what to migrate first, what to migrate next, what to accept as compensating-control risk in the interim, and what the projected completion date is based on current data.",[19,145,146],{},"Enterprises that build this capability now — while procurement leverage still exists with AI vendors, while regulatory frameworks are still emerging, while the CRQC timeline still allows a graceful migration — will be able to answer their board's simplest question. Enterprises that wait will face the question and the CRQC arrival at approximately the same time.",[19,148,149],{},"The AI cryptographic surface is real. It is quantum-vulnerable. It is being harvested. And the tools to see it — to answer these five questions in real time — exist today.",{"title":151,"searchDepth":152,"depth":152,"links":153},"",2,[154,155,156,157,158,159,160],{"id":16,"depth":152,"text":17},{"id":30,"depth":152,"text":31},{"id":48,"depth":152,"text":49},{"id":66,"depth":152,"text":67},{"id":84,"depth":152,"text":85},{"id":102,"depth":152,"text":103},{"id":120,"depth":152,"text":121},"Policy","2026-06-01","The five questions your AI security team cannot answer today: model signing, prompt harvest, attestation, agent identity, and a single AI cryptographic-risk number.",false,"md","\u002Fassets\u002Fog-default.png",[168,169,170],"Most teams cannot list every production model with its signing algorithm and quantum exposure.","Enterprise prompts sent over classical TLS are Harvest-Now-Decrypt-Later targets already being collected.","Confidential-AI attestation and multi-agent identities rely on forgeable classical signatures.",{},true,"\u002Fresources\u002Fwhitepapers\u002Ffive-questions-ai-security",[175,176,177],"Continuously ingest cryptographic posture from every AI component: registries, gateways, attestation, and agent identity.","Reconcile it into one live inventory that answers each of the five questions with a defensible number.","Produce a prioritized AI migration backlog before the quantum computer and the audit arrive together.",[179,182,185,188,191,194,197,200],{"label":180,"url":181},"National Institute of Standards and Technology, \"Artificial Intelligence Risk Management Framework (AI RMF 1.0),\" NIST AI 100-1, January 2023.","https:\u002F\u002Fnvlpubs.nist.gov\u002Fnistpubs\u002Fai\u002FNIST.AI.100-1.pdf",{"label":183,"url":184},"European Union, \"Regulation (EU) 2024\u002F1689 on Artificial Intelligence (AI Act),\" Official Journal of the European Union, July 2024.","https:\u002F\u002Feur-lex.europa.eu\u002Feli\u002Freg\u002F2024\u002F1689\u002Foj",{"label":186,"url":187},"U.S. Food and Drug Administration, \"Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions,\" Guidance for Industry, December 2024.","https:\u002F\u002Fwww.fda.gov\u002Fregulatory-information\u002Fsearch-fda-guidance-documents\u002Fmarketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence",{"label":189,"url":190},"National Institute of Standards and Technology, \"Module-Lattice-Based Key-Encapsulation Mechanism Standard,\" FIPS 203, August 2024.","https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F203\u002Ffinal",{"label":192,"url":193},"National Institute of Standards and Technology, \"Module-Lattice-Based Digital Signature Standard,\" FIPS 204, August 2024.","https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F204\u002Ffinal",{"label":195,"url":196},"National Institute of Standards and Technology, \"Stateless Hash-Based Digital Signature Standard,\" FIPS 205, August 2024.","https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F205\u002Ffinal",{"label":198,"url":199},"International Organization for Standardization, \"ISO\u002FIEC 42001:2023 — Information Technology — Artificial Intelligence — Management System,\" December 2023.","https:\u002F\u002Fwww.iso.org\u002Fstandard\u002F81230.html",{"label":201,"url":202},"Cybersecurity and Infrastructure Security Agency, \"Automated Cryptography Discovery and Inventory (ACDI),\" Strategic Framework, 2024.","https:\u002F\u002Fwww.cisa.gov\u002Fresources-tools\u002Fservices\u002Fpost-quantum-cryptography-initiative",{"title":6,"description":163},"five-questions-ai-security","resources\u002Fwhitepapers\u002Ffive-questions-ai-security",[207,208,209,210],"AI security","AI risk","AI governance","PQC migration","Enterprises run production AI on cryptographic foundations they cannot see; five questions define the AI visibility gap, and most teams cannot answer any of them today.","aLGwcwrguxxcf6qaXQUJo4J8e1sYQgVjts6zLOh3XEg",{"id":214,"title":215,"author":7,"authorTitle":8,"authorUrl":9,"body":216,"canonical":9,"category":493,"cover":9,"date":162,"description":494,"draft":164,"extension":165,"faqs":9,"findingsSource":9,"image":166,"keyFindings":495,"meta":499,"modified":9,"navigation":172,"path":500,"pdfUrl":9,"pullquote":9,"recommendations":501,"references":505,"related":9,"seo":530,"signposts":9,"slug":531,"stats":9,"stem":532,"tags":533,"tldr":538,"__hash__":539},"whitepapers\u002Fresources\u002Fwhitepapers\u002Fledger-already-harvested.md","The Ledger Already Harvested: Post-Quantum Cryptography for Blockchain and Web3",{"type":11,"value":217,"toc":478},[218,220,223,226,229,232,235,237,241,244,247,250,253,256,259,261,265,268,273,276,279,282,286,289,292,295,298,302,305,308,311,314,318,321,324,327,329,333,336,342,348,351,354,360,362,366,369,372,406,409,412,415,417,421,424,427,430,433,436,439,441,445,448,457,460,463,466,469,472,475],[14,219,17],{"id":16},[19,221,222],{},"Blockchain and Web3 systems face a post-quantum cryptography challenge that is architecturally different from every other enterprise environment. In most infrastructures, Harvest Now, Decrypt Later is a passive collection risk — adversaries capture encrypted traffic today and decrypt it when a cryptographically relevant quantum computer arrives. For blockchain, the harvest is not a collection activity. It is a design feature.",[19,224,225],{},"Every public blockchain address that has ever transacted has already published its public key to a permanent, immutable, adversary-readable ledger. Every Bitcoin address that has ever spent, every Ethereum account that has ever sent a transaction, every Solana wallet that has ever signed a message, every Cosmos validator that has ever produced a block — the corresponding public keys are already in the adversary's collection. Not because the adversary tapped a fiber. Because the ledger published them by design.",[19,227,228],{},"This single fact makes blockchain PQC migration different from every other environment. The Cloud, IT, OT, and AI surfaces described in earlier whitepapers in this series involve migrating cryptography that adversaries are still working to collect. The blockchain surface involves cryptography whose public keys have already been collected. The clock is not counting down toward harvest completion. It is counting down toward decryption.",[19,230,231],{},"This whitepaper defines the four cryptographic surfaces of blockchain and Web3, explains why pre-launch is the only clean migration path for any new chain or application, describes how blockchain intersects the Cloud, IT, and application-layer surfaces enterprise CISOs already govern, and outlines the operating model for running PQC migration on a blockchain application before it goes live.",[19,233,234],{},"For any blockchain application currently in pre-launch — any new chain, any new rollup, any new bridge, any new Web3 application — the design decision to build with post-quantum cryptography from day one is dramatically cheaper than the coordinated community upgrade that will be required after launch. Every classical signature scheme deployed to production is an asset with a defined shelf life. Every public key published to the ledger is a harvest already complete. The right time to migrate is before the launch. The second-best time is now.",[26,236],{},[14,238,240],{"id":239},"act-1-the-harvest-is-already-complete","Act 1: The harvest is already complete",[19,242,243],{},"Start with the strongest fact about blockchain PQC — the fact that most non-blockchain audiences have never had explained to them, and that many blockchain audiences have not confronted the operational implications of.",[19,245,246],{},"Every public blockchain address is a public key, or a hash of one. On Bitcoin, an address is typically the hash of a public key until the moment the address spends — and the moment it spends, the public key is published to the blockchain as part of the transaction signature. On Ethereum, the address is a truncated hash of the public key, and every transaction the address sends publishes the public key in the transaction envelope. On Solana, on Cosmos, on Polygon, on every major public chain, the same pattern holds: the public key becomes visible on chain as soon as the address transacts.",[19,248,249],{},"This means an adversary interested in harvesting blockchain public keys does not need to run passive network capture at internet backbone tap points. The adversary runs a full node. The public keys are already indexed by every block explorer. Every public key on every public chain is queryable in real time by any adversary with a laptop and an internet connection.",[19,251,252],{},"The scale of what has already been harvested is staggering. Bitcoin has over one billion transactions in its history. Ethereum has over two billion. Every one of them published a public key. Add every Solana transaction, every Cosmos SDK chain, every Polygon transaction, every Layer 2 rollup transaction, every cross-chain bridge transaction, and the total number of quantum-vulnerable public keys already in adversary collection is measured in tens of billions.",[19,254,255],{},"When a cryptographically relevant quantum computer arrives, the adversary does not need to decide which harvested keys to prioritize. They can run Shor's algorithm against every public key that has ever appeared on any public chain. The private keys become derivable. The wallets become drainable. The bridges become forgeable. The governance votes become injectable. Every historical transaction whose corresponding address is still holding value becomes a target.",[19,257,258],{},"The security assumption underlying every public blockchain today is that classical elliptic curve cryptography will remain unbreakable within the useful lifetime of the chain. That assumption was defensible when Bitcoin launched in 2009. It is not defensible in 2026. The lifetime of a public chain is indefinite. The lifetime of classical elliptic curve cryptography is not.",[26,260],{},[14,262,264],{"id":263},"act-2-the-four-cryptographic-surfaces-of-blockchain","Act 2: The four cryptographic surfaces of blockchain",[19,266,267],{},"Blockchain systems have four distinct cryptographic surfaces. Each has its own migration challenge, its own gating factors, and its own consequences of not migrating in time.",[269,270,272],"h3",{"id":271},"consensus-signatures","Consensus signatures",[19,274,275],{},"Every block on every proof-of-stake and proof-of-work chain is signed. The signature schemes are quantum-vulnerable. Bitcoin uses ECDSA with the secp256k1 curve. Ethereum's execution layer uses the same. Ethereum's consensus layer uses BLS signatures on the BLS12-381 curve. Solana uses Ed25519. Cosmos SDK chains use Ed25519. Polkadot uses Sr25519. Every one of these signature schemes is breakable by a sufficiently capable quantum computer.",[19,277,278],{},"Migrating the consensus signature scheme is the deepest and most disruptive form of blockchain PQC migration. It requires a coordinated hard fork of the entire protocol. Every validator must upgrade simultaneously. Every wallet, every exchange, every block explorer, every downstream integration must upgrade with them. The political complexity of coordinating a hard fork on a major public chain is documented — Bitcoin's SegWit adoption took years, Ethereum's Merge took half a decade of preparation, and both are considered engineering successes precisely because of how difficult they were.",[19,280,281],{},"The candidate PQC replacements are known. NIST FIPS 204 (ML-DSA) is a lattice-based signature scheme with reasonable performance characteristics. NIST FIPS 205 (SLH-DSA) is a hash-based signature scheme with conservative security assumptions. FALCON is a NIST-selected lattice-based signature with smaller signature sizes. Each has trade-offs in signature size, verification cost, and key size that matter enormously for blockchain applications where every byte on chain has permanent cost.",[269,283,285],{"id":284},"wallet-key-management","Wallet key management",[19,287,288],{},"Every wallet on every chain manages private keys corresponding to public keys that have been published to the ledger. The public key exposure is complete for any address that has ever transacted.",[19,290,291],{},"The mitigation strategies available today are limited and imperfect. Wallets that never spend from an address preserve the public key hash abstraction and only expose the hash, not the full key. This is why Bitcoin best practice recommends never reusing addresses — the moment you spend, you publish. Hierarchical deterministic wallets partially mitigate the problem by generating fresh addresses for each transaction, but every generated address that ever spends still publishes its public key.",[19,293,294],{},"For addresses that have already transacted, the exposure is permanent. The public key is on chain. The historical harvest is already complete for that address. The only defense is to move funds to fresh addresses generated with PQC-compatible key derivation before the CRQC arrives — which requires that the wallet software, the chain, and the receiving parties all support PQC.",[19,296,297],{},"The candidate PQC wallet architectures are still emerging. Post-quantum key derivation, PQC-compatible hierarchical deterministic wallets, and hybrid classical + PQC signature schemes are active areas of research but are not standardized. Wallets that want to be PQC-ready today have to make architectural bets on protocols that have not yet stabilized.",[269,299,301],{"id":300},"smart-contract-cryptography","Smart contract cryptography",[19,303,304],{},"Smart contracts perform cryptographic operations far beyond simple signature verification. They verify cross-chain messages using bridge protocols. They authenticate oracle price feeds using signature aggregation. They validate zero-knowledge proofs using elliptic curve pairings. They enforce access control using signature-based authorization schemes.",[19,306,307],{},"Every one of these operations uses classical elliptic curve cryptography. BLS signatures over BN254 or BLS12-381 are used in Ethereum precompiles, ZK rollup validity proofs, and consensus signatures. KZG polynomial commitments are used in EIP-4844 blob data availability. Groth16 SNARKs are used in most ZK rollups. Every one of these primitives is quantum-vulnerable.",[19,309,310],{},"Migrating smart contract cryptography is a per-contract migration problem multiplied by the number of contracts on every chain. Each contract that performs classical cryptography must be redeployed with PQC alternatives. Since smart contract code is typically immutable once deployed, migration requires either upgrade proxy patterns, which introduce their own risks, or wholesale replacement of the contract, which requires migrating all associated state and coordinating with every downstream user.",[19,312,313],{},"The candidate PQC alternatives for smart contract cryptography are underdeveloped. Lattice-based zero-knowledge proof systems are active research but not production-ready. Post-quantum signature aggregation schemes exist but have not been standardized. Verifiable delay functions with post-quantum security assumptions are still theoretical. The smart contract PQC toolchain is where the blockchain community has the most work to do.",[269,315,317],{"id":316},"blockchain-infrastructure","Blockchain infrastructure",[19,319,320],{},"Enterprise blockchain applications and Web3 services depend on infrastructure that sits above the chain itself. Wallet infrastructure providers. RPC node operators. Indexing services. Block explorers. Custodial services. Cross-chain bridges. Layer 2 sequencers. Rollup provers.",[19,322,323],{},"Every one of these services runs classical cryptography for its own operations — TLS for API endpoints, mTLS for validator communications, signed messages between services, KMS-protected private keys for custody, and so on. This is the surface where blockchain infrastructure most closely resembles traditional enterprise IT and cloud infrastructure, and it is the surface where existing PQC migration guidance applies most directly.",[19,325,326],{},"For blockchain infrastructure, the migration path is the same as for any Cloud and IT surface: inventory the cryptographic dependencies, prioritize by exposure and consequence, migrate to PQC-capable alternatives on the vendor and standards timeline. The difference is that blockchain infrastructure sits above chains that have their own PQC migration timelines, and the infrastructure providers must plan their migration alongside the chains they support.",[26,328],{},[14,330,332],{"id":331},"act-3-why-pre-launch-is-the-only-clean-migration-path","Act 3: Why pre-launch is the only clean migration path",[19,334,335],{},"The asymmetry between pre-launch and post-launch blockchain PQC migration is not incremental. It is categorical.",[19,337,338,341],{},[128,339,340],{},"Pre-launch migration is a design decision."," A new chain, a new rollup, a new bridge, a new Web3 application that has not yet gone live can choose its consensus signature scheme, its wallet architecture, its smart contract cryptographic primitives, and its infrastructure PQC posture as part of its initial design. The choices propagate through the codebase, through the wallet specifications, through the exchange integrations, through the tooling ecosystem, before any user has adopted the chain and before any value is at stake. The design cost is bounded. The community coordination cost is zero because there is no community yet.",[19,343,344,347],{},[128,345,346],{},"Post-launch migration is a coordinated community upgrade."," Once a chain is live, migrating its consensus signature scheme requires a hard fork. Every validator, every wallet, every exchange, every block explorer, every integration must coordinate the upgrade simultaneously. Users must migrate their funds from classical addresses to PQC addresses, which requires that every recipient party support PQC addresses. Smart contract migration requires either coordinated upgrade proxies for every affected contract or wholesale contract replacement with state migration. The infrastructure ecosystem — RPC providers, indexers, block explorers, custody services — must upgrade in lockstep.",[19,349,350],{},"The engineering complexity of a post-launch PQC migration for a major public chain has no precedent. Even Bitcoin's SegWit adoption, which was a relatively contained upgrade compared to a signature scheme migration, took years of political debate and years of ecosystem coordination. An Ethereum-wide migration from ECDSA and BLS to PQC alternatives is difficult to imagine happening in less than a decade of preparation. And that timeline assumes the community begins seriously planning it now.",[19,352,353],{},"For any blockchain application currently in pre-launch, the calculus is unambiguous. Building with PQC from day one costs a bounded amount of engineering work at design time. Building with classical crypto and migrating later costs an unbounded amount of engineering work at hard fork time, plus the security exposure of every user's funds during the migration window, plus the reputational cost of having built on a foundation with a known expiration date.",[19,355,356,359],{},[128,357,358],{},"The permanent lesson from every major blockchain security incident"," is that cryptographic decisions made at launch propagate forward permanently. Address formats, signature schemes, precompile contracts, curve parameters — every one of these choices made at genesis persists for the lifetime of the chain. A chain that launches with classical elliptic curve cryptography in 2026 has committed to running on quantum-vulnerable cryptographic foundations until it hard-forks. That hard fork will happen. The only question is whether it happens on the schedule the founders chose or on the schedule the CRQC forces.",[26,361],{},[14,363,365],{"id":364},"act-4-where-blockchain-intersects-cloud-it-and-enterprise-applications","Act 4: Where blockchain intersects Cloud, IT, and enterprise applications",[19,367,368],{},"Enterprise blockchain applications are not just chain code. They run on cloud infrastructure. They integrate with enterprise identity systems. They connect to Web2 backends. They handle regulated data. They fall under the same cryptographic governance frameworks as every other enterprise application.",[19,370,371],{},"An enterprise deploying a blockchain application has cryptographic surfaces at every layer of the stack:",[373,374,375,382,388,394,400],"ul",{},[376,377,378,381],"li",{},[128,379,380],{},"Cloud infrastructure"," — the workloads that run the application backend, the KMS-protected wallet keys, the API gateways that broker chain interactions, the confidential compute enclaves that host signing services",[376,383,384,387],{},[128,385,386],{},"Identity and access"," — the enterprise identity systems that authenticate users into the application, the machine identities that authenticate services to the blockchain, the certificates that protect service-to-service communication",[376,389,390,393],{},[128,391,392],{},"Web2 backend integration"," — the databases, message queues, and API endpoints that connect the blockchain application to the rest of the enterprise",[376,395,396,399],{},[128,397,398],{},"The blockchain surface itself"," — the chain's consensus cryptography, the wallet key management, the smart contract cryptography, the bridge and oracle integrations",[376,401,402,405],{},[128,403,404],{},"Compliance and audit"," — the cryptographic evidence trail required by regulators for any application that handles regulated data on chain",[19,407,408],{},"The Full Stack PQC migration framework established in the earlier whitepapers in this series applies directly to enterprise blockchain applications. The four environments — Cloud, IT, OT, and AI — are the general framework. Blockchain becomes a fifth environment layered on top for enterprises that build or use blockchain applications. The dashboard that shows unified cryptographic posture across Cloud, IT, OT, and AI extends naturally to include blockchain-specific cryptographic surfaces alongside them.",[19,410,411],{},"The critical operational insight is that an enterprise cannot govern its blockchain application's PQC posture in isolation from the rest of its infrastructure. The wallet keys live in cloud KMS. The user authentication runs through enterprise identity. The API endpoints traverse the same enterprise network. The regulatory reporting flows into the same compliance framework. Blockchain PQC migration is not a separate program from enterprise PQC migration. It is a specialized subset of it.",[19,413,414],{},"For enterprises building blockchain applications today, this has a specific implication: the blockchain application should be included in the enterprise's Cloud, IT, OT, and AI PQC visibility dashboard from the moment the application is in pre-launch. Not later. Not when the application scales. Not when the regulator asks. From day one.",[26,416],{},[14,418,420],{"id":419},"act-5-what-arcqubit-brings-to-blockchain-pqc-migration","Act 5: What ArcQubit brings to blockchain PQC migration",[19,422,423],{},"ArcQubit's Full Stack PQC migration approach was designed for critical infrastructure enterprises across all sixteen CISA sectors and any AI-forward enterprise. The same approach extends naturally to blockchain and Web3 organizations building applications that must operate through the quantum transition.",[19,425,426],{},"QuTrust delivers the Full Stack PQC migration dashboard for the blockchain application. The dashboard hosts the living migration roadmap and generates the Quantum Exposure Report — the live cryptographic inventory that answers, on demand, what the current PQC posture is for every asset in the application across Cloud, IT, application-layer, and blockchain surfaces.",[19,428,429],{},"For a pre-launch blockchain application, the value of the dashboard is different in character from a post-launch enterprise migration. Pre-launch, the dashboard is a design tool. It maps the cryptographic exposure of the architecture as it is being built. It highlights the classical signature schemes, the classical key management, the classical bridge protocols that are being deployed. It gives the engineering team the visibility to make PQC design decisions before the code ships, when those decisions are still cheap.",[19,431,432],{},"For a post-launch blockchain application, the dashboard is a migration tool. It maps the existing cryptographic exposure across cloud infrastructure, wallet management, smart contract cryptography, and infrastructure services. It prioritizes migration actions using the same three-axis scoring model — quantum exposure, data sensitivity, and migration ease — that governs all other Full Stack migrations. It generates the executive reporting that boards, regulators, insurers, and audit committees require.",[19,434,435],{},"Across both pre-launch and post-launch, the dashboard's function is the same: unify the cryptographic posture of the application across every layer of its architecture, present it in one report the CISO or founder can defend to any audience, and produce the prioritized roadmap that translates current posture into forward-moving migration work.",[19,437,438],{},"QuTrust does not decide the migration strategy. The blockchain team decides. QuTrust does not choose the PQC signature scheme. The team chooses. QuTrust does not fork the chain. Only the community can do that. QuTrust delivers the visibility, the prioritization, and the evidence that make the migration executable — pre-launch as a design constraint or post-launch as a coordinated program.",[26,440],{},[14,442,444],{"id":443},"coda-the-permanent-question","Coda: The permanent question",[19,446,447],{},"Every blockchain application launching today has to answer one question that no application built in Web2 had to answer:",[449,450,451],"blockquote",{},[19,452,453],{},[454,455,456],"em",{},"Will my cryptographic foundations still be defensible in the twenty-year lifetime of my chain?",[19,458,459],{},"For a Web2 application, this question does not apply. Web2 applications retire and get replaced. Their cryptographic foundations migrate with them. A Web2 API launched in 2016 with TLS 1.2 has been migrated to TLS 1.3 in the years since, and will be migrated to hybrid PQC TLS in the years to come, without any user ever knowing the transition happened.",[19,461,462],{},"Blockchain is different. The chain does not retire. The addresses do not migrate. The historical transactions do not un-publish their public keys. Every cryptographic decision made at launch persists in the immutable record forever.",[19,464,465],{},"An enterprise deploying a Web2 application built with classical cryptography can shrug off the PQC migration timeline as a general infrastructure problem to be solved over the next decade. A protocol team launching a blockchain application built with classical cryptography is committing to a specific hard fork sometime before the CRQC arrives, or accepting that every wallet and every bridge and every smart contract they ship will be drainable by a quantum-capable adversary within the useful lifetime of the chain.",[19,467,468],{},"The right answer to the permanent question is to build the cryptographic foundations to withstand the twenty-year horizon at launch. That is the design discipline ArcQubit exists to support. That is why the pilot ArcQubit is launching with a blockchain company that has state-of-the-art applications is the right kind of engagement at the right kind of moment — pre-launch, when the design decisions can still be made cheaply, when the community coordination cost is zero, and when the resulting application can go live with quantum resilience built in from day one.",[19,470,471],{},"The ledger is already harvested. The question is what happens after the CRQC arrives. Every classical signature on the chain becomes forgeable. Every classical wallet becomes drainable. Every classical bridge becomes exploitable. Every classical smart contract becomes untrustable. This is the future the chain must survive.",[19,473,474],{},"The blockchain applications that build on post-quantum cryptography from day one will survive it. The blockchain applications that do not will spend their working lifetimes racing a clock they did not know had already been running.",[19,476,477],{},"Pre-launch is the right time to fix crypto debt. Not after.",{"title":151,"searchDepth":152,"depth":152,"links":479},[480,481,482,489,490,491,492],{"id":16,"depth":152,"text":17},{"id":239,"depth":152,"text":240},{"id":263,"depth":152,"text":264,"children":483},[484,486,487,488],{"id":271,"depth":485,"text":272},3,{"id":284,"depth":485,"text":285},{"id":300,"depth":485,"text":301},{"id":316,"depth":485,"text":317},{"id":331,"depth":152,"text":332},{"id":364,"depth":152,"text":365},{"id":419,"depth":152,"text":420},{"id":443,"depth":152,"text":444},"Technical","Post-quantum cryptography for blockchain and Web3: why every published public key is already harvested, and why building PQC pre-launch is the only clean migration path.",[496,497,498],"Every public blockchain address that has transacted has already published its public key to a permanent, adversary-readable ledger — tens of billions of quantum-vulnerable keys.","Blockchain has four cryptographic surfaces (consensus, wallets, smart contracts, infrastructure), each with different migration gating.","Post-launch migration requires a coordinated hard fork; pre-launch migration is a bounded design decision.",{},"\u002Fresources\u002Fwhitepapers\u002Fledger-already-harvested",[502,503,504],"For any pre-launch chain, rollup, bridge, or app, choose PQC signature schemes and wallet architecture at design time.","Include the blockchain application in the enterprise Cloud, IT, OT, and AI PQC dashboard from pre-launch.","Treat blockchain PQC as a specialized subset of the enterprise program, not a separate effort.",[506,507,508,511,514,517,520,523,526,527],{"label":192,"url":193},{"label":195,"url":196},{"label":509,"url":510},"National Institute of Standards and Technology, \"Recommendation for Stateful Hash-Based Signature Schemes,\" Special Publication 800-208, October 2020.","https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Fsp\u002F800\u002F208\u002Ffinal",{"label":512,"url":513},"P. W. Shor, \"Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,\" SIAM Journal on Computing, vol. 26, no. 5, pp. 1484-1509, October 1997.","https:\u002F\u002Fdoi.org\u002F10.1137\u002FS0097539795293172",{"label":515,"url":516},"S. Nakamoto, \"Bitcoin: A Peer-to-Peer Electronic Cash System,\" 2008.","https:\u002F\u002Fbitcoin.org\u002Fbitcoin.pdf",{"label":518,"url":519},"G. Wood, \"Ethereum: A Secure Decentralised Generalised Transaction Ledger,\" Ethereum Yellow Paper, Berlin Version, 2022.","https:\u002F\u002Fethereum.github.io\u002Fyellowpaper\u002Fpaper.pdf",{"label":521,"url":522},"D. Boneh, B. Lynn, and H. Shacham, \"Short Signatures from the Weil Pairing,\" Journal of Cryptology, vol. 17, no. 4, pp. 297-319, September 2004.","https:\u002F\u002Fdoi.org\u002F10.1007\u002Fs00145-004-0314-9",{"label":524,"url":525},"S. Bowe, A. Gabizon, and I. Miers, \"Scalable Multi-party Computation for zk-SNARK Parameters in the Random Beacon Model,\" IACR Cryptology ePrint Archive, 2017\u002F1050.","https:\u002F\u002Feprint.iacr.org\u002F2017\u002F1050",{"label":201,"url":202},{"label":528,"url":529},"Cybersecurity and Infrastructure Security Agency, \"Post-Quantum Cryptography Initiative,\" 2024.","https:\u002F\u002Fwww.cisa.gov\u002Fquantum",{"title":215,"description":494},"ledger-already-harvested","resources\u002Fwhitepapers\u002Fledger-already-harvested",[534,210,535,536,537],"post-quantum cryptography","quantum risk","blockchain","web3","For blockchain the harvest is not a risk but a design feature: every public key that ever transacted is already on an immutable ledger, so pre-launch is the only clean PQC migration path.","UoLhJ0T1VfEBcNpGIniQ21Lh0MnxT8EZccKYy3gERuE",{"id":541,"title":542,"author":7,"authorTitle":8,"authorUrl":9,"body":543,"canonical":9,"category":493,"cover":9,"date":162,"description":764,"draft":164,"extension":165,"faqs":9,"findingsSource":9,"image":166,"keyFindings":765,"meta":768,"modified":9,"navigation":172,"path":769,"pdfUrl":9,"pullquote":9,"recommendations":770,"references":774,"related":9,"seo":784,"signposts":9,"slug":785,"stats":9,"stem":786,"tags":787,"tldr":791,"__hash__":792},"whitepapers\u002Fresources\u002Fwhitepapers\u002Fpqc-migration-one-dashboard.md","Running Your PQC Migration From One Dashboard",{"type":11,"value":544,"toc":755},[545,547,550,553,556,558,562,565,572,575,578,581,584,587,590,593,596,598,602,605,608,611,614,617,620,623,626,629,631,635,638,641,644,647,650,653,655,659,662,668,674,680,695,697,701,704,707,710,713,716,719,722,724,728,731,734,740,743,746,749,752],[14,546,17],{"id":16},[19,548,549],{},"Every enterprise running a post-quantum cryptographic migration program eventually confronts the same operational reality. The migration spans four distinct environments — Cloud, IT, OT, and AI — and no single team owns them all. The board asks a simple question. The answer requires four teams, four tools, four cadences, four vocabularies, and four different definitions of what \"current posture\" even means.",[19,551,552],{},"This is not a technology problem. It is an operating model problem. And it is the problem that determines whether a critical infrastructure enterprise arrives at 2035 with a defensible cryptographic posture or arrives there explaining why it did not.",[19,554,555],{},"This whitepaper describes the Full Stack approach to running PQC migration from one dashboard — the operational discipline of unifying cryptographic posture across all four environments into a single living roadmap, generating one report the CISO can defend to any audience, and treating migration as a continuous program rather than a periodic project. It introduces QuTrust as the platform that implements the approach, and it identifies what stays with the customer regardless.",[26,557],{},[14,559,561],{"id":560},"act-1-a-monday-morning","Act 1: A Monday morning",[19,563,564],{},"Consider a CISO — call her Maya — at 8:47 AM on a Monday. She has three minutes before a leadership call and her board chair has just emailed a single question:",[449,566,567],{},[19,568,569],{},[454,570,571],{},"\"What's our post-quantum posture? I'm being asked at Thursday's audit committee.\"",[19,573,574],{},"Maya does what CISOs do when the board asks a question that touches four departments at once. She writes an all-hands note to her direct reports asking for status by end of day. Then she goes to her call.",[19,576,577],{},"By afternoon, four replies land in her inbox.",[19,579,580],{},"Her cloud architect writes back first. She has good data. The workloads are running on hyperscaler platforms and the KMS and secrets management posture is visible through the cloud provider's admin console. She can give Maya a percentage — how many workloads are on TLS 1.3, how many are still on 1.2, how many use RSA-based key exchange. But she notes that the cloud provider's own PQC roadmap is unclear beyond a general commitment to \"quantum-safe hybrid support by 2028.\"",[19,582,583],{},"Her IT security lead answers next. His posture is a mix of confident and vague. He knows the enterprise PKI hierarchy well because he owns the certificate authority. He can list the RSA-2048 versus ECDSA-P256 breakdown of issued certificates. But he does not have visibility into the machine identity crypto for the twelve thousand service accounts that authenticate across the environment, and the VPN concentrator firmware needs a lift he cannot schedule this quarter.",[19,585,586],{},"Her plant operations security lead — she calls him her OT lead — is the last to respond, and his answer is different in character. He does not have a percentage. He has a paragraph. Some assets are on modern industrial protocols with configurable crypto. Some assets are on legacy protocols with no crypto at all. The safety systems cannot be touched without functional safety revalidation. His team can name specific PLCs and safety controllers by vendor and firmware version, but there is no aggregate posture number because the operational reality does not aggregate that way.",[19,588,589],{},"Her AI platform lead responds with the most honest answer of the four. She says the model registries have signature information but she has never mapped the signature algorithms to a PQC posture. The inference gateway logs exist but they were not built to answer this question. Confidential compute attestations exist for a subset of models but she does not know which subset. She promises to have \"something coherent\" by Wednesday.",[19,591,592],{},"Maya sits with four responses in four formats using four vocabularies with four different confidence levels. There is no aggregate number to give her board chair. She does what CISOs do in this situation — she builds a slide deck that assembles the four partial views into something that looks like an answer. The deck takes her security operations team six hours to produce. It will be stale within days. And the board chair will ask the same question at the next quarterly meeting, and the six hours will happen again.",[19,594,595],{},"This is the operational reality of PQC migration in most critical infrastructure enterprises today.",[26,597],{},[14,599,601],{"id":600},"act-2-why-this-happens","Act 2: Why this happens",[19,603,604],{},"The four-environment problem is not caused by tools or teams doing anything wrong. It is caused by the architectural reality that Cloud, IT, OT, and AI are cryptographically distinct surfaces with different physics.",[19,606,607],{},"Cloud crypto lives in KMS metadata, TLS session logs, API gateway configurations, and cloud provider admin APIs. It updates in real time. It is instrumentable. It is owned by cloud engineering.",[19,609,610],{},"IT crypto lives in Active Directory, certificate authorities, VPN concentrators, HSM catalogs, SSH host keys, and code signing pipelines. It updates on longer cycles. It is partially instrumentable. It is owned by IT security.",[19,612,613],{},"OT crypto lives in industrial protocol implementations, PLC firmware, RTU configurations, historian TLS sessions, safety system interfaces, and vendor firmware release notes. It updates slowly, on maintenance windows, gated by change control and safety revalidation. It is minimally instrumentable. It is owned by plant operations.",[19,615,616],{},"AI crypto lives in model registry signatures, inference gateway TLS sessions, confidential compute attestations, agent identity certificates, RAG pipeline authentication, and AIBOMs. It updates continuously as models deploy and agents spawn. It is emerging in instrumentability. It is owned by AI platform teams that in most enterprises did not exist two years ago.",[19,618,619],{},"Four surfaces. Four physics. Four owners. Four vocabularies. Four update cadences. Four confidence levels.",[19,621,622],{},"No single existing tool covers all four. Cloud posture tools handle cloud. Enterprise PKI tools handle IT. OT visibility platforms handle OT. AI security platforms are just now emerging. Each of these tools produces a report. None of them produces the unified report the CISO needs to answer her board.",[19,624,625],{},"The operational failure mode of PQC migration is not that any single tool is inadequate. It is that four adequate tools produce four adequate reports and no unified answer exists in any of them. The unified answer has to be assembled — manually, quarterly, at high cost, with unavoidable staleness — by the security operations team. Every enterprise doing PQC migration today is either building that assembly process or delaying the moment they will need to.",[19,627,628],{},"This is the problem the Full Stack approach solves.",[26,630],{},[14,632,634],{"id":633},"act-3-the-full-stack-dashboard","Act 3: The Full Stack dashboard",[19,636,637],{},"The Full Stack approach starts from a simple architectural premise: the enterprise needs one dashboard for PQC migration, not four.",[19,639,640],{},"Not one dashboard that replaces the four existing tools. The cloud posture platform still runs. The enterprise PKI system still runs. The OT visibility platform still runs. The AI security tools still run. They are all doing their jobs. What the enterprise needs is one dashboard that ingests from all four — and from cloud APIs, identity systems, network telemetry, model registries, and vendor advisory feeds directly — and produces one unified view.",[19,642,643],{},"QuTrust is that dashboard. It is the analyzer that sits above every existing data source in the enterprise — ingesting from each of them, analyzing the cryptographic posture they collectively describe, and producing the unified view no single source can produce on its own.",[19,645,646],{},"The dashboard hosts the living migration roadmap. It shows every asset in the enterprise with its current cryptographic posture, its migration priority, its projected completion date, and the compensating controls in place while it waits. It updates as the underlying data changes. It does not require a quarterly assembly cycle. It is the answer to the board's question, always current.",[19,648,649],{},"From the dashboard, the CISO generates the Quantum Exposure Report — the named artifact that answers, on demand, what the enterprise's current PQC posture is for every asset it owns across Cloud, IT, OT, and AI. Cipher suite by cipher suite. Certificate by certificate. Model signature by model signature. Attestation by attestation. This is the report the CISO walks into board meetings with. This is the report she hands to the auditor. This is the report the regulator asks for. This is the report the Authorizing Official signs against. Always current. Always defensible. Always aligned to NIST FIPS 203\u002F204\u002F205, NIST SP 800-208, and CISA ACDI.",[19,651,652],{},"The Quantum Exposure Report is not a scan output. It is not a vulnerability list. It is a unified cryptographic posture statement across four environments, generated from live data, in the vocabulary a board or a regulator can act on. It is what Maya from Act 1 needed on Monday morning and did not have.",[26,654],{},[14,656,658],{"id":657},"act-4-how-it-actually-works","Act 4: How it actually works",[19,660,661],{},"Under the dashboard, QuTrust runs three continuous loops that produce the unified view.",[19,663,664,667],{},[128,665,666],{},"The analysis loop"," runs constantly. It ingests from every data source class in the enterprise — cloud platform APIs, KMS and secrets management, PKI and certificate lifecycle systems, HSM catalogs, network telemetry, OT visibility platforms, model registries, inference gateways, confidential computing attestation services, agent identity systems, and vendor advisory feeds. Each source refreshes on its own cadence and pushes deltas into QuTrust. QuTrust analyzes the ingested data and reconciles it into one live cryptographic inventory per asset. This is the ground truth every other loop depends on. Its audience is the security engineers, cloud architects, OT engineers, and AI platform teams who need current state to do their jobs today.",[19,669,670,673],{},[128,671,672],{},"The prioritization loop"," runs daily. It takes the current inventory and applies the three-axis scoring model — quantum exposure, data sensitivity, and migration ease — to produce a ranked backlog of migration actions across all four environments. Every asset re-scores as the underlying data changes. A VPN concentrator that was Tier 2 last week becomes Tier 1 this week because a vendor firmware version enables PQC hybrid mode. An AI inference gateway becomes Tier 1 because passive traffic analysis discovered it started handling regulated data. The backlog re-orders itself automatically. Its audience is the security operations leads, migration program managers, and platform engineering leads who translate current posture into forward-moving work.",[19,675,676,679],{},[128,677,678],{},"The reporting loop"," runs monthly, quarterly, and on-demand. It takes the current posture and the prioritized backlog and synthesizes them into executive artifacts: board packages, audit committee updates, regulator responses, insurance underwriter documentation, ATO evidence, and the Quantum Exposure Report itself. These are generated from live data, not from a manually-updated spreadsheet that goes stale between quarters. Its audience is the CISOs, CIOs, boards, Authorizing Officials, regulators, and insurance underwriters who are accountable for the risk position but not doing the day-to-day work.",[19,681,682,683,686,687,690,691,694],{},"Together the three loops produce the operational experience the Full Stack approach promises. Analysis answers ",[454,684,685],{},"what is our current state."," Prioritization answers ",[454,688,689],{},"what should we do next."," Reporting answers ",[454,692,693],{},"how do we explain this to the people who need to know."," All three run continuously. All three span all four environments. All three feed one dashboard, one roadmap, one report.",[26,696],{},[14,698,700],{"id":699},"act-5-what-stays-with-the-customer","Act 5: What stays with the customer",[19,702,703],{},"The Full Stack approach carries a specific philosophical commitment: the customer stays in control.",[19,705,706],{},"QuTrust does not decide the enterprise's migration strategy. The CISO decides. The Authorizing Official decides. The board decides. QuTrust does not choose which post-quantum algorithm to deploy where. The customer chooses — from the full NIST PQC suite, aligned to whatever regulatory profile the sector requires, following whatever hybrid transition pattern the operational reality supports. QuTrust does not certify anyone. QuTrust does not audit anyone. QuTrust does not replace the existing security investments the enterprise has already made.",[19,708,709],{},"QuTrust delivers the visibility, the prioritization, and the evidence that make the customer's decisions executable across the environments they already own.",[19,711,712],{},"This has a specific implication for how QuTrust relates to the tools the enterprise already runs. QuTrust integrates with every cryptographic data source class in the enterprise — vulnerability scanners like Tenable, Qualys, and Nessus; PKI lifecycle tools like Venafi, Keyfactor, DigiCert, and Entrust; OT visibility platforms like Claroty, Dragos, Nozomi Networks, and Tenable OT; cloud posture tools, model registries, inference gateways, and vendor advisory feeds. QuTrust ingests from all of them.",[19,714,715],{},"This is the operational leverage the Full Stack approach creates. The enterprise has invested millions of dollars in scanners and posture tools that each produce their own report. Each report is accurate within its scope. None of them individually can answer the board's question. QuTrust connects to every one of them and analyzes their collective output into a single unified cryptographic posture across Cloud, IT, OT, and AI.",[19,717,718],{},"The scanners tell the enterprise what is broken. QuTrust analyzes what they collectively find and tells the enterprise what to do about it, in what order, across all four environments. QuTrust is where the scanner outputs and the cloud API telemetry and the OT visibility exports and the model registry metadata come together to become a migration program.",[19,720,721],{},"This is not a replacement narrative. It is a completion narrative. The tools the enterprise already runs are essential — they produce the raw cryptographic posture data QuTrust analyzes. QuTrust is what makes those existing investments finally answer the board's question.",[26,723],{},[14,725,727],{"id":726},"coda-monday-morning-revisited","Coda: Monday morning, revisited",[19,729,730],{},"Consider Maya again, six months after her enterprise has implemented the Full Stack approach.",[19,732,733],{},"It is Monday. Her board chair emails at 8:47 AM.",[449,735,736],{},[19,737,738],{},[454,739,571],{},[19,741,742],{},"Maya opens the QuTrust dashboard. The current Quantum Exposure Report is generated as of this morning. Cloud posture: 68% migrated to hybrid PQC, 22% on active migration path with vendor commitments, 10% flagged as compensating-control risk with documented containment. IT posture: 74% PQC-hybrid or PQC-only, 18% on defined migration timeline, 8% pending PKI root re-issuance scheduled for Q3. OT posture: 34% migrated, 41% on vendor PQC firmware roadmap through 2029, 25% under gateway protection with no direct migration path yet. AI posture: 51% of model signatures dual-signed with SLH-DSA, 71% of inference gateways on TLS 1.3 with hybrid PQC key exchange, 100% of confidential compute workloads inventoried with a PQC attestation migration plan.",[19,744,745],{},"The report generates in fourteen seconds. Maya reads it while her coffee cools. She forwards it to her board chair with a two-sentence note that describes the current posture, the trajectory, and the three specific items her team is prioritizing this quarter.",[19,747,748],{},"Her Thursday audit committee will not require a slide deck built from four partial responses. It will require her to walk the board through a document they already have. Her security operations team will not spend six hours assembling a stale answer. They will spend those six hours executing on the prioritized backlog the dashboard produced for them this morning.",[19,750,751],{},"This is what Full Stack visibility looks like in operation. This is what the living migration roadmap enables. This is what continuous governance means when it is actually implemented.",[19,753,754],{},"The Full Stack approach is not a promise about a future state. It is an operational discipline that changes how the enterprise experiences PQC migration — from a quarterly assembly problem to a continuous program that produces defensible artifacts on demand.",{"title":151,"searchDepth":152,"depth":152,"links":756},[757,758,759,760,761,762,763],{"id":16,"depth":152,"text":17},{"id":560,"depth":152,"text":561},{"id":600,"depth":152,"text":601},{"id":633,"depth":152,"text":634},{"id":657,"depth":152,"text":658},{"id":699,"depth":152,"text":700},{"id":726,"depth":152,"text":727},"The Full Stack approach to running post-quantum migration from one dashboard — a single living roadmap and one Quantum Exposure Report across Cloud, IT, OT, and AI.",[766,767],"Cloud, IT, OT, and AI are cryptographically distinct surfaces with different owners, tools, cadences, and vocabularies; no single existing tool covers all four.","The operational failure mode is four adequate tools producing four reports and no unified answer to the board’s question.",{},"\u002Fresources\u002Fwhitepapers\u002Fpqc-migration-one-dashboard",[771,772,773],"Unify posture in one dashboard that ingests from the tools you already run rather than replacing them.","Generate the Quantum Exposure Report from live data on demand, not a quarterly manual assembly.","Keep migration strategy with the customer; the platform delivers visibility, prioritization, and evidence.",[775,776,777,778,779,780,783],{"label":189,"url":190},{"label":192,"url":193},{"label":195,"url":196},{"label":509,"url":510},{"label":201,"url":202},{"label":781,"url":782},"National Security Agency, \"Commercial National Security Algorithm Suite 2.0,\" Cybersecurity Advisory, September 2022 (revised 2025).","https:\u002F\u002Fmedia.defense.gov\u002F2022\u002FSep\u002F07\u002F2003071834\u002F-1\u002F-1\u002F0\u002FCSA_CNSA_2.0_ALGORITHMS_.PDF",{"label":528,"url":529},{"title":542,"description":764},"pqc-migration-one-dashboard","resources\u002Fwhitepapers\u002Fpqc-migration-one-dashboard",[210,788,789,790],"cryptographic discovery","quantum readiness","critical infrastructure","A PQC migration spans four environments no single team owns; running it from one dashboard turns a quarterly slide-deck scramble into a continuous, defensible program.","SrMuDEF_AF1aUqwrLVoVGtJUlmbzduxSdiAt923EovE",{"id":794,"title":795,"author":7,"authorTitle":8,"authorUrl":9,"body":796,"canonical":9,"category":1025,"cover":9,"date":162,"description":1026,"draft":164,"extension":165,"faqs":9,"findingsSource":1027,"image":166,"keyFindings":1028,"meta":1032,"modified":9,"navigation":172,"path":1033,"pdfUrl":9,"pullquote":9,"recommendations":1034,"references":1038,"related":9,"seo":1053,"signposts":9,"slug":1054,"stats":9,"stem":1055,"tags":1056,"tldr":1058,"__hash__":1059},"whitepapers\u002Fresources\u002Fwhitepapers\u002Fprioritizing-pqc-migration-rand.md","Prioritizing the Post-Quantum Migration: What the Federal Government Already Told Us",{"type":11,"value":797,"toc":1016},[798,800,803,806,813,816,818,822,825,828,830,834,837,863,866,868,872,875,919,922,924,928,931,952,955,961,967,969,973,976,982,988,994,1000,1002,1006,1013],[14,799,17],{"id":16},[19,801,802],{},"In 2022, the Cybersecurity and Infrastructure Security Agency (CISA) did something most organizations still have not done: it commissioned a federally funded think tank to run a portfolio-level risk assessment on the entire U.S. economy. The question was simple. When quantum computers become powerful enough to break today's encryption, which parts of the country break first, and where should the government put its limited attention?",[19,804,805],{},"The answer came from RAND's Homeland Security Operational Analysis Center (HSOAC), the FFRDC RAND operates under contract to DHS. Analysts triaged all 55 National Critical Functions (NCFs) — the government's official list of the sectors and activities that keep the country running — and scored each one for urgency, scope, cost, and priority.",[19,807,808,809,812],{},"The headline finding for any executive building a business case: ",[128,810,811],{},"this is not a uniform problem, and it does not require a uniform response."," A small number of dependencies carry a disproportionate share of national risk. Fix those first, and the rest of the economy gets a meaningfully easier migration.",[19,814,815],{},"That is a resource-allocation story, not a technology story, and it is exactly the kind of finding a board wants stated in plain terms before it approves budget.",[26,817],{},[14,819,821],{"id":820},"who-funded-this-and-why-it-matters","Who funded this and why it matters",[19,823,824],{},"CISA does not commission independent, arm's-length risk assessments casually. This one was sponsored by CISA's National Risk Management Center and executed by RAND's HSOAC under a standing DHS task order. In other words, this is not vendor research, not a think-tank thought piece, and not marketing collateral from a cybersecurity company with a product to sell. It is the closest thing the private sector has to a government-validated risk map for post-quantum cryptography.",[19,826,827],{},"For any executive vetting vendor claims about quantum risk, this report is a useful baseline. It predates most commercial PQC marketing, and it was built with no incentive to inflate urgency across the board. In fact, the analysts explicitly rated 34 of the 55 functions as low priority. A study designed to sell fear would not have done that.",[26,829],{},[14,831,833],{"id":832},"the-methodology-in-plain-terms","The methodology, in plain terms",[19,835,836],{},"Think of this as a classic risk-adjusted prioritization exercise — the kind an operating committee would run before allocating capital across business units. RAND scored each of the 55 functions on four dimensions:",[373,838,839,845,851,857],{},[376,840,841,844],{},[128,842,843],{},"Urgency"," — how soon does this need to be fixed, based on how long sensitive data must stay confidential",[376,846,847,850],{},[128,848,849],{},"Scope"," — how many organizations have to act",[376,852,853,856],{},[128,854,855],{},"Cost"," — how expensive is the fix per organization",[376,858,859,862],{},[128,860,861],{},"Other factors"," — anything that makes the problem structurally easier or harder (workforce availability, existing modernization efforts, regulatory fragmentation, and so on)",[19,864,865],{},"Those four scores rolled up into a single priority-for-assistance rating: high, medium, or low. This is a portfolio triage model, not a checklist. It is designed to tell a resource-constrained principal — in this case, the federal government — where to spend its attention first.",[26,867],{},[14,869,871],{"id":870},"the-core-finding-three-chokepoints-carry-the-portfolio","The core finding: three chokepoints carry the portfolio",[19,873,874],{},"RAND identified three functions as critical enablers of the entire national migration. These are the vendors and infrastructure providers who build the tools everyone else needs in order to move to post-quantum cryptography at all.",[876,877,878,891],"table",{},[879,880,881],"thead",{},[882,883,884,888],"tr",{},[885,886,887],"th",{},"Critical enabler",[885,889,890],{},"What it actually does",[892,893,894,903,911],"tbody",{},[882,895,896,900],{},[897,898,899],"td",{},"Provide Internet-Based Content, Information, and Communication Services",[897,901,902],{},"Builds the browsers, TLS implementations, and communication protocols the rest of the internet runs on",[882,904,905,908],{},[897,906,907],{},"Provide Identity Management and Associated Trust Support Services",[897,909,910],{},"Issues and manages the digital certificates that underpin authentication everywhere",[882,912,913,916],{},[897,914,915],{},"Provide Information Technology Products and Services",[897,917,918],{},"Builds the hardware and software the rest of the economy buys and deploys",[19,920,921],{},"The business logic here is straightforward: nobody else can migrate until these three groups ship PQC-capable products first. A hospital, a bank, or a pipeline operator cannot encrypt traffic with an algorithm their software vendor hasn't built yet. This is a supply chain dependency problem before it is anything else, and RAND's most important strategic recommendation was to monitor these three chokepoints closely, because a delay here delays everyone downstream.",[26,923],{},[14,925,927],{"id":926},"the-six-functions-rated-highest-priority","The six functions rated highest priority",[19,929,930],{},"Beyond the three enablers, RAND flagged six functions overall as high priority for federal assistance:",[932,933,934,937,940,943,946,949],"ol",{},[376,935,936],{},"Internet-Based Content and Communication Services (also a critical enabler)",[376,938,939],{},"Distribute Electricity",[376,941,942],{},"Protect Sensitive Information",[376,944,945],{},"Generate Electricity",[376,947,948],{},"Information Technology Products and Services (also a critical enabler)",[376,950,951],{},"Provide Materiel and Operational Support to Defense",[19,953,954],{},"Two patterns explain why electricity and defense made this list even though they are not enablers themselves.",[19,956,957,960],{},[128,958,959],{},"The grid is a special case of a broader operational technology problem."," Eighteen of the 55 functions depend heavily on industrial control systems, and most of those were rated low priority because ICS equipment tends to get replaced on a normal hardware refresh cycle anyway. Electricity generation and distribution broke from that pattern because of three compounding factors: equipment is spread across enormous geography, control systems require real-time low-latency response with little tolerance for disruption, and the regulatory and technology standards vary widely across regions and providers. In plain terms, the grid has the same underlying problem as every other OT-heavy sector, just with a materially harder cost and coordination profile layered on top.",[19,962,963,966],{},[128,964,965],{},"Defense support made the list for a different reason entirely: it is a genuine \"harvest now, decrypt later\" target."," RAND's report makes a subtle but important distinction. Most industries transmit data with a short enough shelf life — personal records, trade secrets — that an adversary capturing encrypted traffic today and cracking it in ten years gains little of value. National security data is the exception. It is exactly the kind of information a sophisticated nation-state adversary would find worth the multi-year investment to steal now and unlock later.",[26,968],{},[14,970,972],{"id":971},"the-business-takeaway-not-all-risk-is-created-equal-and-thats-good-news","The business takeaway: not all risk is created equal, and that's good news",[19,974,975],{},"The report's four cross-cutting conclusions translate directly into a prioritization framework any operator can use:",[19,977,978,981],{},[128,979,980],{},"1. Everyone has homework, but not everyone has the same amount."," Every organization, regardless of sector, should be building cryptographic agility into its technology roadmap now. But \"everyone must eventually act\" is not the same message as \"everyone must act with equal urgency,\" and conflating the two wastes budget.",[19,983,984,987],{},[128,985,986],{},"2. A small number of upstream fixes de-risk a large number of downstream dependents."," This is the single most useful sentence in the report for a capital allocation conversation: a relatively small number of critical changes by a relatively small number of stakeholders will mitigate a significant share of the nation's aggregate exposure. That is a leverage argument, and leverage arguments win budget approvals.",[19,989,990,993],{},[128,991,992],{},"3. The harvest now, decrypt later threat is real but narrow."," Running a multi-year data-harvesting campaign against encrypted traffic is expensive and logistically hard. It is only rational for an adversary to do this against a small number of very high-value targets, primarily national security data. Most organizations do not need to treat this scenario as an emergency; they need to treat it as a normal item on the modernization roadmap.",[19,995,996,999],{},[128,997,998],{},"4. This field is still young, and vendors claiming certainty should be treated with skepticism."," RAND is candid that a comprehensive inventory of what needs to change across the American technology stack did not exist at the time of the report, and still largely does not. Anyone selling a fully mapped, all-encompassing PQC solution today is getting ahead of where the underlying standards work actually is.",[26,1001],{},[14,1003,1005],{"id":1004},"why-this-matters-for-anyone-building-a-pqc-business-case","Why this matters for anyone building a PQC business case",[19,1007,1008,1009,1012],{},"This report gives operators, CISOs, and boards three things a vendor pitch deck cannot: government-validated framing, a defensible prioritization logic, and permission to ",[454,1010,1011],{},"not"," treat every system as equally urgent. The organizations best positioned to benefit are the ones that use this kind of independent risk stratification to sequence their migration spend, starting with genuine long-secrecy-lifetime data and OT environments with real cost and latency constraints, rather than migrating everything at once out of generalized anxiety.",[19,1014,1015],{},"The federal government already did the hard work of separating signal from noise. The opportunity now is operational: turn that prioritization into an actual migration program.",{"title":151,"searchDepth":152,"depth":152,"links":1017},[1018,1019,1020,1021,1022,1023,1024],{"id":16,"depth":152,"text":17},{"id":820,"depth":152,"text":821},{"id":832,"depth":152,"text":833},{"id":870,"depth":152,"text":871},{"id":926,"depth":152,"text":927},{"id":971,"depth":152,"text":972},{"id":1004,"depth":152,"text":1005},"Research","What the federal government already told us: the 2022 CISA-commissioned RAND study of quantum risk across U.S. critical infrastructure, turned into a business case.","RAND HSOAC, RR-A1367-6 (commissioned by CISA), 2022",[1029,1030,1031],"PQC risk is not uniform: RAND rated 34 of 55 National Critical Functions low priority and only 6 high priority.","Three chokepoints — internet and content services, identity and trust services, and IT products — must ship PQC before anyone downstream can migrate.","Harvest Now, Decrypt Later is real but narrow, rational mainly against long-secrecy national-security data.",{},"\u002Fresources\u002Fwhitepapers\u002Fprioritizing-pqc-migration-rand",[1035,1036,1037],"Sequence migration spend by data secrecy lifetime and OT cost and latency constraints rather than migrating everything at once.","Monitor the three critical enablers, since delays there delay everyone downstream.","Treat vendors claiming a fully mapped, all-encompassing PQC solution with skepticism.",[1039,1042,1045,1046,1047,1048,1049,1050],{"label":1040,"url":1041},"M. J. D. Vermeer, E. Parker, and A. K. Kochhar, \"Preparing for Post-Quantum Critical Infrastructure: Assessments of Quantum Computing Vulnerabilities of National Critical Functions,\" RAND Corporation, Homeland Security Operational Analysis Center, RR-A1367-6, 2022. Sponsored by CISA's National Risk Management Center.","https:\u002F\u002Fwww.rand.org\u002Fpubs\u002Fresearch_reports\u002FRRA1367-6.html",{"label":1043,"url":1044},"Cybersecurity and Infrastructure Security Agency, \"CISA Insights: Preparing Critical Infrastructure for Post-Quantum Cryptography,\" August 2022.","https:\u002F\u002Fwww.cisa.gov\u002Fsites\u002Fdefault\u002Ffiles\u002Fpublications\u002Fcisa_insight_post_quantum_cryptography_508.pdf",{"label":528,"url":529},{"label":189,"url":190},{"label":192,"url":193},{"label":195,"url":196},{"label":201,"url":202},{"label":1051,"url":1052},"Executive Office of the President, \"Presidential Policy Directive 21 (PPD-21) — Critical Infrastructure Security and Resilience,\" February 2013.","https:\u002F\u002Fwww.cisa.gov\u002Fsixteen-critical-infrastructure-sectors",{"title":795,"description":1026},"prioritizing-pqc-migration-rand","resources\u002Fwhitepapers\u002Fprioritizing-pqc-migration-rand",[534,210,790,535,1057],"federal","In 2022 CISA had RAND triage all 55 National Critical Functions for quantum risk; the finding was that a small number of upstream dependencies carry a disproportionate share of national risk.","3fz2QaPt6TELqIiR-MXsZ2jFwXpf3yX_1_O1i99G32U",{"id":1061,"title":1062,"author":7,"authorTitle":8,"authorUrl":9,"body":1063,"canonical":9,"category":493,"cover":9,"date":162,"description":1544,"draft":164,"extension":165,"faqs":9,"findingsSource":9,"image":166,"keyFindings":1545,"meta":1549,"modified":9,"navigation":172,"path":1550,"pdfUrl":9,"pullquote":9,"recommendations":1551,"references":1555,"related":9,"seo":1580,"signposts":9,"slug":1581,"stats":9,"stem":1582,"tags":1583,"tldr":1584,"__hash__":1585},"whitepapers\u002Fresources\u002Fwhitepapers\u002Fquantum-vulnerable-ai-stack.md","The Quantum-Vulnerable AI Stack",{"type":11,"value":1064,"toc":1500},[1065,1067,1070,1073,1076,1079,1081,1085,1088,1091,1097,1103,1109,1115,1118,1120,1124,1127,1131,1134,1137,1141,1144,1148,1151,1155,1158,1162,1165,1169,1172,1176,1179,1183,1186,1190,1193,1197,1200,1202,1206,1209,1213,1216,1220,1223,1227,1230,1234,1237,1241,1244,1248,1251,1253,1257,1260,1264,1267,1271,1274,1278,1281,1285,1288,1292,1295,1299,1302,1306,1309,1313,1316,1320,1323,1327,1330,1332,1336,1339,1345,1351,1357,1363,1369,1375,1378,1380,1384,1387,1391,1411,1415,1435,1439,1456,1458,1462,1465,1485,1487,1491,1494,1497],[14,1066,17],{"id":16},[19,1068,1069],{},"Enterprise adoption of artificial intelligence has outpaced the security disciplines built to protect it. Model registries, inference APIs, agent networks, vector databases, and confidential computing enclaves have become foundational infrastructure — and every layer of that infrastructure depends on classical asymmetric cryptography that a cryptographically relevant quantum computer (CRQC) will break.",[19,1071,1072],{},"The prevailing enterprise assumption is that AI systems inherit the security posture of the cloud infrastructure they run on. That assumption is wrong. AI systems have their own distinct cryptographic surface — one that spans model provenance, inference session integrity, remote attestation, agent identity, and training data lineage. Each of these layers is quantum-vulnerable today. Each of them is being targeted for Harvest Now, Decrypt Later (HNDL) collection at this moment.",[19,1074,1075],{},"This whitepaper defines the AI cryptographic stack, enumerates the ten layers where quantum-vulnerable cryptography lives in production AI systems, describes the specific threat scenarios that emerge when a CRQC becomes available, catalogs the enterprise artifacts that provide visibility into AI PQC posture, and outlines the migration path that AI-forward enterprises must begin now.",[19,1077,1078],{},"The window to act is short. NIST is developing AI-specific PQC guidance. The EU AI Act's high-risk system provisions will require cryptographic assurance. FDA premarket review for AI medical devices is moving in the same direction. And the underlying threat — that adversaries are harvesting enterprise prompt traffic, model download sessions, and agent authentication tokens today — is already in motion.",[26,1080],{},[14,1082,1084],{"id":1083},"_1-why-ai-is-a-distinct-cryptographic-environment","1. Why AI is a distinct cryptographic environment",[19,1086,1087],{},"Cloud, IT, and OT are the three environments most enterprises recognize as needing PQC migration. AI is emerging as a fourth — architecturally distinct, cryptographically dependent, and operationally consequential.",[19,1089,1090],{},"The distinction matters because AI systems have properties that traditional environments do not:",[19,1092,1093,1096],{},[128,1094,1095],{},"Model artifacts are code that behaves like data."," A poisoned foundation model does not fail loudly the way malicious code does. It performs correctly on standard benchmarks and misbehaves only on adversary-chosen inputs. This makes cryptographic provenance the primary defense — and cryptographic provenance is exactly what a CRQC breaks.",[19,1098,1099,1102],{},[128,1100,1101],{},"Inference is a session-based data flow with high-value payloads."," Enterprise prompts to LLM APIs routinely contain legal strategies, patient records, source code, engineering designs, and financial analysis. Every prompt is a TLS session, every session key is derived from a classical key exchange, and every session is a candidate for HNDL harvesting.",[19,1104,1105,1108],{},[128,1106,1107],{},"AI systems are increasingly multi-agent, multi-tenant, and multi-cloud."," The identity fabric that authenticates one agent to another, one enclave to another, one model to another, is built on classical PKI. Compromise the identity fabric and the entire architecture of trust collapses at once.",[19,1110,1111,1114],{},[128,1112,1113],{},"Regulatory pressure is arriving simultaneously with the quantum timeline."," Unlike OT, where PQC guidance is arriving before enforceable mandates, AI has both maturing at the same time — NIST AI RMF, EU AI Act, ISO\u002FIEC 42001, FDA premarket AI guidance, and the growing body of sector-specific AI governance requirements.",[19,1116,1117],{},"For these reasons, treating AI as \"just workloads that run in the cloud\" is a category error. AI is its own environment. It requires its own PQC posture assessment. And it is currently the least mature of the four in terms of quantum readiness.",[26,1119],{},[14,1121,1123],{"id":1122},"_2-where-cryptography-lives-in-the-ai-stack","2. Where cryptography lives in the AI stack",[19,1125,1126],{},"There are ten identifiable layers where classical asymmetric cryptography is embedded in production AI systems. Each is quantum-vulnerable. Each requires an independent migration path.",[269,1128,1130],{"id":1129},"_21-model-provenance-and-integrity","2.1 Model provenance and integrity",[19,1132,1133],{},"Every foundation model, fine-tuned model, and inference endpoint has cryptographic signatures proving where it came from. Hugging Face uses Sigstore for model signing. OpenAI, Anthropic, and Google sign model updates and API responses. Every model file downloaded from a registry is verified against a signature — RSA or ECDSA today, quantum-vulnerable tomorrow.",[19,1135,1136],{},"A CRQC-enabled adversary can forge a signature on a poisoned model. Every downstream consumer accepts it as legitimate. Detection is nearly impossible because the model still performs correctly on standard benchmarks — the poisoning targets specific edge cases like decision-making in critical infrastructure control loops or medical diagnosis. This is the AI equivalent of the TRITON attack on safety systems: silent, invisible, and consequential only at the moment it matters.",[269,1138,1140],{"id":1139},"_22-model-registry-and-artifact-stores","2.2 Model registry and artifact stores",[19,1142,1143],{},"MLflow, Weights and Biases, Databricks Model Registry, SageMaker Model Registry, Vertex AI Model Registry, Azure ML, and Hugging Face Enterprise all authenticate their artifact push and pull operations with TLS and OAuth. The signing keys, the API tokens, the TLS certificates — all quantum-vulnerable. An adversary with derived private keys can push malicious model versions to your registry with valid signatures, and every deployment pipeline that pulls from that registry will treat them as authorized.",[269,1145,1147],{"id":1146},"_23-inference-api-endpoints","2.3 Inference API endpoints",[19,1149,1150],{},"Every call to an LLM API — OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure OpenAI — is a TLS session. The API key, the mTLS certificate, the JWT token — all protected by classical asymmetric crypto. Enterprises are sending prompts and receiving responses over sessions that are being harvested today. For regulated industries this is a rapidly growing HNDL exposure: prompts to enterprise LLMs routinely contain PHI, PII, financial data, trade secrets, and classified reasoning. A decade of prompt history is being accumulated on adversary storage right now.",[269,1152,1154],{"id":1153},"_24-training-data-provenance","2.4 Training data provenance",[19,1156,1157],{},"Where the training data came from is increasingly cryptographically attested. The EU AI Act, NIST AI RMF, and emerging FDA guidance on AI medical devices all require attestation of training data lineage. Those attestations are signed. The signing keys are quantum-vulnerable. Forge the signing key and an adversary can attest to training data that never existed — or hide the presence of training data that did.",[269,1159,1161],{"id":1160},"_25-federated-learning-and-secure-aggregation","2.5 Federated learning and secure aggregation",[19,1163,1164],{},"Federated ML systems — TensorFlow Federated, NVIDIA FLARE, Meta federated learning, Substra — rely on cryptographic protocols including secure aggregation, differential privacy noise generation, and secure multi-party computation. Every one of these protocols uses elliptic curve pairings or RSA today. Every federated learning round has quantum-vulnerable cryptography in the aggregation step, meaning the privacy guarantees of federated learning collapse the moment a CRQC exists.",[269,1166,1168],{"id":1167},"_26-confidential-computing-enclaves","2.6 Confidential computing enclaves",[19,1170,1171],{},"AI workloads increasingly run in trusted execution environments: Intel SGX, AMD SEV-SNP, NVIDIA Confidential Computing on H100 and H200. Each of these enclaves produces remote attestation certificates that prove to a verifier that the model is running in a genuine enclave with the expected code. Those attestations are RSA or ECDSA-signed. The entire promise of confidential AI — \"your model runs in a verified enclave, your data cannot leak\" — depends on remote attestation. Break the attestation crypto and the confidential guarantee evaporates.",[269,1173,1175],{"id":1174},"_27-agent-to-agent-authentication","2.7 Agent-to-agent authentication",[19,1177,1178],{},"Multi-agent AI systems — LangChain agent networks, MCP servers, Salesforce Agentforce, Microsoft Copilot Studio agents, AWS Bedrock Agents — authenticate to each other using service identities backed by certificates. As agent architectures become the deployment pattern for enterprise AI, the identity fabric between agents becomes critical infrastructure. Forge an agent's identity certificate and an adversary can insert a malicious agent into the workflow. It authenticates correctly. It executes actions. It disappears without a trace.",[269,1180,1182],{"id":1181},"_28-vector-database-and-embedding-store-access","2.8 Vector database and embedding store access",[19,1184,1185],{},"Pinecone, Weaviate, Milvus, Qdrant, ChromaDB — all authenticated via API keys and TLS. Embeddings themselves are typically not encrypted at rest, but the access control layer is quantum-vulnerable. Forge the credentials and an adversary can read every embedding, understand every semantic relationship in the corpus, and inject malicious embeddings that steer retrieval behavior at inference time.",[269,1187,1189],{"id":1188},"_29-rag-pipeline-authentication","2.9 RAG pipeline authentication",[19,1191,1192],{},"Retrieval-Augmented Generation pipelines pull from document stores, databases, and knowledge bases using service accounts and OAuth tokens. Every connection is TLS-protected with quantum-vulnerable cryptography. RAG is the primary architecture pattern for enterprise LLM deployment — and every RAG session that touches sensitive corporate data today is a HNDL target.",[269,1194,1196],{"id":1195},"_210-guardrail-and-policy-enforcement","2.10 Guardrail and policy enforcement",[19,1198,1199],{},"Prompt injection defenses, output filters, and AI safety guardrails — NVIDIA NeMo Guardrails, Lakera Guard, Protect AI, Robust Intelligence, HiddenLayer — enforce their policies via signed policy files and TLS-protected control APIs. If an adversary forges the signature on a policy file, they can silently disable the guardrail. The AI system continues to appear compliant while its safety layer has been surgically removed.",[26,1201],{},[14,1203,1205],{"id":1204},"_3-the-ai-specific-threat-model","3. The AI-specific threat model",[19,1207,1208],{},"The threats to AI systems from quantum-vulnerable cryptography differ in character from OT or IT threats. They are more subtle, more scalable, and more difficult to detect after the fact.",[269,1210,1212],{"id":1211},"_31-model-poisoning-at-scale","3.1 Model poisoning at scale",[19,1214,1215],{},"An adversary with a CRQC can forge Hugging Face, OpenAI, or vendor signatures on poisoned foundation models. Every enterprise pulling that model accepts it as legitimate. The poisoning targets specific behaviors — an incorrect diagnosis on chest X-rays showing a specific pattern, an incorrect risk score on loan applications from specific demographics, an incorrect decision in industrial control loops when specific process conditions are present. Standard benchmarks do not detect it. Production monitoring does not detect it. Only the adversary knows which inputs trigger the poisoned behavior, and only they know when to invoke it.",[269,1217,1219],{"id":1218},"_32-prompt-harvest-and-retroactive-decryption","3.2 Prompt harvest and retroactive decryption",[19,1221,1222],{},"Enterprise prompts to LLM APIs contain the highest-value data an organization produces. Legal strategy documents. M&A analysis. Patient records queried through clinical AI. Source code shared with coding assistants. Engineering designs sent to specialized models. Every one of these prompts travels over a TLS session whose key exchange is classical. Nation-state adversaries with tap points on the internet backbone are harvesting these sessions today. When a CRQC arrives, a decade of enterprise prompt history becomes readable.",[269,1224,1226],{"id":1225},"_33-inference-response-tampering","3.3 Inference response tampering",[19,1228,1229],{},"An adversary who can forge TLS certificates can inject responses into LLM API calls. The user asked \"what does this radiology image show?\" and the response is quietly altered. The user asked \"should I approve this loan?\" and the answer is flipped. The user asked \"is this contract clause enforceable?\" and the analysis is skewed. Detection requires cryptographic verification of the response — which is exactly the defense that PQC migration provides and that classical crypto no longer will.",[269,1231,1233],{"id":1232},"_34-attestation-forgery-in-confidential-ai","3.4 Attestation forgery in confidential AI",[19,1235,1236],{},"The entire confidential AI value proposition depends on remote attestation. Enterprises deploying models in Intel SGX, AMD SEV, or NVIDIA H100 confidential computing enclaves are trusting that the attestation certificate proves the model is running where it should be, with the code it should be. If the attestation crypto is broken, the confidentiality guarantee is broken. Every confidential AI deployment built on classical attestation crypto has a defined shelf life that ends when a CRQC arrives.",[269,1238,1240],{"id":1239},"_35-agent-identity-forgery","3.5 Agent identity forgery",[19,1242,1243],{},"Multi-agent AI systems represent the fastest-growing category of enterprise AI deployment. LangGraph, CrewAI, AutoGen, MCP-based agent networks, and Agentforce all rely on service identity crypto to authenticate agent-to-agent communication. In these architectures, a single forged identity certificate compromises the entire workflow. The malicious agent authenticates correctly, participates in reasoning chains, executes tools, accesses data, and terminates its session. No trace remains beyond legitimate-looking audit logs.",[269,1245,1247],{"id":1246},"_36-federated-learning-privacy-collapse","3.6 Federated learning privacy collapse",[19,1249,1250],{},"Federated learning was designed to enable multi-party model training without centralizing data. Its privacy guarantees depend on cryptographic secure aggregation — which is quantum-vulnerable. When a CRQC exists, the privacy guarantee retroactively collapses. Every party's training contributions become derivable from the aggregated updates the adversary has been recording. Healthcare consortia running federated learning across hospitals. Financial institutions running federated fraud detection. Chip design collaborations. Every one of them is exposed.",[26,1252],{},[14,1254,1256],{"id":1255},"_4-what-enterprises-can-actually-see-the-artifact-landscape","4. What enterprises can actually see: the artifact landscape",[19,1258,1259],{},"The PQC posture of an AI stack is not invisible. It is visible in specific enterprise artifacts that most organizations already produce or can produce. Building AI PQC posture intelligence begins with inventorying these artifacts.",[269,1261,1263],{"id":1262},"_41-model-registries-and-mlops-platforms","4.1 Model registries and MLOps platforms",[19,1265,1266],{},"MLflow, Databricks Model Registry, SageMaker Model Registry, Vertex AI Model Registry, Azure ML, Hugging Face Enterprise, Kubeflow, Metaflow, ClearML, and Neptune all contain model artifact metadata, signature information, deployment history, and lineage records. These platforms are the single richest source of AI cryptographic posture data — they know what models exist, where they came from, how they were signed, and where they run.",[269,1268,1270],{"id":1269},"_42-ai-bill-of-materials-aibom","4.2 AI Bill of Materials (AIBOM)",[19,1272,1273],{},"CycloneDX has published an AIBOM extension. MITRE and NIST are actively defining AI-specific bill of materials standards. AIBOMs enumerate model components, training data provenance, fine-tuning history, embedded dependencies, and their cryptographic properties. AIBOMs are to AI what SBOMs are to software — the primary artifact for cryptographic transparency at the model level.",[269,1275,1277],{"id":1276},"_43-inference-gateway-logs","4.3 Inference gateway logs",[19,1279,1280],{},"API gateways in front of LLM endpoints — Cloudflare AI Gateway, Kong AI Gateway, Portkey, LiteLLM, Databricks AI Gateway, and IBM watsonx.governance — log every inference call including TLS session details, negotiated cipher suites, certificate metadata, and authentication token types. These logs are the AI equivalent of the network telemetry used for OT and IT PQC inventory.",[269,1282,1284],{"id":1283},"_44-ai-observability-platforms","4.4 AI observability platforms",[19,1286,1287],{},"Arize, WhyLabs, Fiddler, Truera, and IBM watsonx.governance monitor model behavior in production and have visibility into inference pipeline configuration — including the cryptographic surface of the inference stack.",[269,1289,1291],{"id":1290},"_45-prompt-guard-and-dlp-telemetry","4.5 Prompt guard and DLP telemetry",[19,1293,1294],{},"Enterprise AI security tools — Lakera, Protect AI, Robust Intelligence, HiddenLayer, Cranium, CalypsoAI — log every prompt and response and have visibility into API session cryptographic properties. Where deployed, these tools are second only to model registries as a source of AI PQC posture data.",[269,1296,1298],{"id":1297},"_46-confidential-computing-attestation-logs","4.6 Confidential computing attestation logs",[19,1300,1301],{},"Intel Trust Authority, Azure Attestation Service, AWS Nitro Enclaves attestation, and NVIDIA Confidential Compute Manager produce attestation reports that reveal the cryptographic posture of every enclave-hosted AI workload. These are the ground truth for confidential AI cryptographic state.",[269,1303,1305],{"id":1304},"_47-vector-database-access-logs","4.7 Vector database access logs",[19,1307,1308],{},"Pinecone, Weaviate Enterprise, Milvus Cloud, Qdrant Cloud, and ChromaDB Enterprise audit logs reveal TLS versions, cipher suites, and authentication tokens protecting vector stores. As RAG becomes the default enterprise AI deployment pattern, vector database access logs become foundational to AI PQC intelligence.",[269,1310,1312],{"id":1311},"_48-ai-governance-platforms","4.8 AI governance platforms",[19,1314,1315],{},"Credo AI, Holistic AI, Fairly AI, and Fiddler AI Governance track policy compliance across AI deployments and increasingly include cryptographic controls in their governance schemas. As the EU AI Act and NIST AI RMF mature, these platforms will become primary sources of PQC compliance evidence.",[269,1317,1319],{"id":1318},"_49-agent-framework-telemetry","4.9 Agent framework telemetry",[19,1321,1322],{},"LangChain, LangGraph, CrewAI, AutoGen, and MCP server implementations produce agent invocation logs that reveal the identity crypto protecting agent-to-agent authentication.",[269,1324,1326],{"id":1325},"_410-cicd-and-code-signing-for-model-deployment","4.10 CI\u002FCD and code signing for model deployment",[19,1328,1329],{},"The pipelines that promote models to production — Jenkins, GitHub Actions, GitLab CI, ArgoCD, Flux — sign artifacts and orchestrate deployments. Their signing keys and TLS configurations are AI PQC posture data.",[26,1331],{},[14,1333,1335],{"id":1334},"_5-regulatory-and-standards-trajectory","5. Regulatory and standards trajectory",[19,1337,1338],{},"AI PQC posture is not just a security question. It is becoming a compliance question, and the compliance clock is running faster than the quantum clock.",[19,1340,1341,1344],{},[128,1342,1343],{},"NIST AI RMF"," is developing sector-specific PQC guidance for AI systems, with initial drafts expected in late 2026.",[19,1346,1347,1350],{},[128,1348,1349],{},"EU AI Act"," high-risk system provisions require cryptographic assurance for provenance, integrity, and access control. PQC readiness is not yet explicitly mandated, but the current classical-crypto stack will not satisfy the assurance requirement once quantum-relevant compute arrives.",[19,1352,1353,1356],{},[128,1354,1355],{},"FDA premarket review"," for AI\u002FML-enabled medical devices increasingly requires demonstration of cryptographic integrity across training data, model artifacts, and inference. PQC readiness discussions are active in the FDA Digital Health Advisory Committee.",[19,1358,1359,1362],{},[128,1360,1361],{},"ISO\u002FIEC 42001"," (AI management systems) references cryptographic controls but is currently algorithm-agnostic; PQC-specific amendments are expected in the 2027–2028 revision cycle.",[19,1364,1365,1368],{},[128,1366,1367],{},"Financial services regulators"," — NYDFS Part 500, FFIEC AI guidance, OCC AI\u002FML risk management — are moving toward explicit cryptographic assurance requirements for high-consequence AI systems.",[19,1370,1371,1374],{},[128,1372,1373],{},"Sector-specific AI governance"," is emerging at pace: DoD Responsible AI guidance already references CNSA 2.0. Healthcare provider AI governance frameworks reference NIST PQC standards. Automotive AI standards (ISO\u002FPAS 21448, ISO\u002FSAE 21434) are being extended with AI-specific cryptographic requirements.",[19,1376,1377],{},"The pattern is clear. Every AI regulatory framework that includes cryptographic assurance requirements will eventually reference PQC. The enterprises that treat AI PQC posture as a 2028 problem will face 2028 audits with 2020s-era classical crypto embedded in their AI stack.",[26,1379],{},[14,1381,1383],{"id":1382},"_6-the-migration-path","6. The migration path",[19,1385,1386],{},"AI PQC migration follows the same phased structure as Cloud, IT, and OT migration — but with AI-specific actions in each phase.",[269,1388,1390],{"id":1389},"phase-1-discover-and-protect-20252028","Phase 1 — Discover and protect (2025–2028)",[373,1392,1393,1396,1399,1402,1405,1408],{},[376,1394,1395],{},"Inventory model registries and enumerate model signing algorithms",[376,1397,1398],{},"Generate AIBOMs for all production models using CycloneDX AIBOM extension",[376,1400,1401],{},"Audit inference gateway TLS configurations for quantum-vulnerable cipher suites",[376,1403,1404],{},"Establish baseline cryptographic posture for confidential computing attestation",[376,1406,1407],{},"Enumerate agent identity certificates across multi-agent deployments",[376,1409,1410],{},"Begin formal PQC roadmap requests to model registry vendors and confidential computing providers",[269,1412,1414],{"id":1413},"phase-2-hybrid-transition-20252031","Phase 2 — Hybrid transition (2025–2031)",[373,1416,1417,1420,1423,1426,1429,1432],{},[376,1418,1419],{},"Deploy dual-signing for model artifacts (classical + ML-DSA or SLH-DSA signatures)",[376,1421,1422],{},"Migrate inference API TLS to hybrid PQC cipher suites (X25519MLKEM768)",[376,1424,1425],{},"Rotate KMS-protected model encryption keys to PQC-capable HSMs",[376,1427,1428],{},"Migrate agent identity PKI to hybrid classical + ML-DSA certificates",[376,1430,1431],{},"Deploy PQC-capable attestation on confidential computing workloads as chip vendors ship support",[376,1433,1434],{},"Update AIBOMs to reflect hybrid cryptographic posture",[269,1436,1438],{"id":1437},"phase-3-full-migration-20312035","Phase 3 — Full migration (2031–2035)",[373,1440,1441,1444,1447,1450,1453],{},[376,1442,1443],{},"Enforce PQC-only model signing across model registries",[376,1445,1446],{},"Retire classical TLS from all inference API endpoints",[376,1448,1449],{},"Complete PQC-only agent identity infrastructure",[376,1451,1452],{},"Retire classical attestation crypto from confidential AI workloads",[376,1454,1455],{},"Establish PQC as default for all new AI system deployment",[26,1457],{},[14,1459,1461],{"id":1460},"_7-what-buyers-should-demand-of-ai-vendors-starting-now","7. What buyers should demand of AI vendors starting now",[19,1463,1464],{},"Enterprises deploying AI systems today should include the following in their vendor procurement requirements:",[373,1466,1467,1470,1473,1476,1479,1482],{},[376,1468,1469],{},"Vendor commitment to PQC-capable model signing on a defined roadmap",[376,1471,1472],{},"Cryptographic Bill of Materials (CBOM) for all AI infrastructure components",[376,1474,1475],{},"Hybrid classical + PQC support for inference API TLS by end of 2027",[376,1477,1478],{},"PQC attestation roadmap for confidential computing offerings",[376,1480,1481],{},"Certificate authority migration commitment for agent identity infrastructure",[376,1483,1484],{},"Contractual right to require escrow signing if the vendor cannot deliver PQC on schedule",[26,1486],{},[14,1488,1490],{"id":1489},"_8-conclusion","8. Conclusion",[19,1492,1493],{},"The AI cryptographic stack is real, distinct, and quantum-vulnerable at every layer. Enterprises treating AI as a subset of cloud infrastructure will miss the migration surface entirely. Enterprises treating AI PQC as a future problem will face regulatory and threat exposure simultaneously.",[19,1495,1496],{},"The right posture is to add AI as a fourth environment — alongside Cloud, IT, and OT — in every PQC migration program. To begin inventorying the AI cryptographic artifact landscape now, using the enterprise systems that already exist. To engage AI vendors on PQC roadmaps while procurement leverage still exists. And to demand cryptographic assurance for AI deployments the same way boards, auditors, and regulators demand it for financial systems, safety systems, and healthcare systems.",[19,1498,1499],{},"The harvest of enterprise prompt traffic, model artifact downloads, and agent authentication tokens is already underway. The decryption arrives when a CRQC exists. The window to migrate the AI stack closes on the same timeline as the rest of the enterprise — and it opens on a stack that is currently less mature than any of the others.",{"title":151,"searchDepth":152,"depth":152,"links":1501},[1502,1503,1504,1516,1524,1536,1537,1542,1543],{"id":16,"depth":152,"text":17},{"id":1083,"depth":152,"text":1084},{"id":1122,"depth":152,"text":1123,"children":1505},[1506,1507,1508,1509,1510,1511,1512,1513,1514,1515],{"id":1129,"depth":485,"text":1130},{"id":1139,"depth":485,"text":1140},{"id":1146,"depth":485,"text":1147},{"id":1153,"depth":485,"text":1154},{"id":1160,"depth":485,"text":1161},{"id":1167,"depth":485,"text":1168},{"id":1174,"depth":485,"text":1175},{"id":1181,"depth":485,"text":1182},{"id":1188,"depth":485,"text":1189},{"id":1195,"depth":485,"text":1196},{"id":1204,"depth":152,"text":1205,"children":1517},[1518,1519,1520,1521,1522,1523],{"id":1211,"depth":485,"text":1212},{"id":1218,"depth":485,"text":1219},{"id":1225,"depth":485,"text":1226},{"id":1232,"depth":485,"text":1233},{"id":1239,"depth":485,"text":1240},{"id":1246,"depth":485,"text":1247},{"id":1255,"depth":152,"text":1256,"children":1525},[1526,1527,1528,1529,1530,1531,1532,1533,1534,1535],{"id":1262,"depth":485,"text":1263},{"id":1269,"depth":485,"text":1270},{"id":1276,"depth":485,"text":1277},{"id":1283,"depth":485,"text":1284},{"id":1290,"depth":485,"text":1291},{"id":1297,"depth":485,"text":1298},{"id":1304,"depth":485,"text":1305},{"id":1311,"depth":485,"text":1312},{"id":1318,"depth":485,"text":1319},{"id":1325,"depth":485,"text":1326},{"id":1334,"depth":152,"text":1335},{"id":1382,"depth":152,"text":1383,"children":1538},[1539,1540,1541],{"id":1389,"depth":485,"text":1390},{"id":1413,"depth":485,"text":1414},{"id":1437,"depth":485,"text":1438},{"id":1460,"depth":152,"text":1461},{"id":1489,"depth":152,"text":1490},"A technical taxonomy of the quantum-vulnerable AI stack: ten cryptographic layers, the AI threat model, the artifacts that give visibility, and the migration path.",[1546,1547,1548],"AI systems do not inherit cloud security; they have their own cryptographic surface across ten layers, each quantum-vulnerable.","Model artifacts behave like data — poisoned models pass benchmarks and fail only on adversary-chosen inputs — making cryptographic provenance the primary defense.","AI PQC posture is visible in artifacts enterprises already produce: model registries, AIBOMs, inference-gateway logs, and attestation logs.",{},"\u002Fresources\u002Fwhitepapers\u002Fquantum-vulnerable-ai-stack",[1552,1553,1554],"Add AI as a fourth environment in every PQC program and inventory the ten layers now.","Deploy dual-signing, hybrid PQC inference TLS, and PQC attestation on the phased 2025 to 2035 path.","Demand PQC roadmaps and cryptographic bills of materials from AI vendors while procurement leverage still exists.",[1556,1557,1558,1559,1560,1561,1562,1563,1566,1569,1572,1575,1578,1579],{"label":189,"url":190},{"label":192,"url":193},{"label":195,"url":196},{"label":509,"url":510},{"label":180,"url":181},{"label":183,"url":184},{"label":198,"url":199},{"label":1564,"url":1565},"OWASP Foundation, \"CycloneDX Machine Learning Bill of Materials (ML-BOM) Specification,\" 2024.","https:\u002F\u002Fcyclonedx.org\u002Fcapabilities\u002Fmlbom\u002F",{"label":1567,"url":1568},"The Linux Foundation, \"Sigstore Project — Software Signing for the Modern Age,\" 2024.","https:\u002F\u002Fwww.sigstore.dev\u002F",{"label":1570,"url":1571},"Intel Corporation, \"Intel Software Guard Extensions (SGX) — Developer Reference,\" 2024.","https:\u002F\u002Fwww.intel.com\u002Fcontent\u002Fwww\u002Fus\u002Fen\u002Fdeveloper\u002Ftools\u002Fsoftware-guard-extensions\u002Foverview.html",{"label":1573,"url":1574},"Advanced Micro Devices, \"AMD Secure Encrypted Virtualization — Secure Nested Paging (SEV-SNP),\" Technical Reference, 2024.","https:\u002F\u002Fwww.amd.com\u002Fen\u002Fdeveloper\u002Fsev.html",{"label":1576,"url":1577},"NVIDIA Corporation, \"NVIDIA Confidential Computing on H100 and H200,\" Technical Documentation, 2024.","https:\u002F\u002Fwww.nvidia.com\u002Fen-us\u002Fdata-center\u002Fsolutions\u002Fconfidential-computing\u002F",{"label":201,"url":202},{"label":186,"url":187},{"title":1062,"description":1544},"quantum-vulnerable-ai-stack","resources\u002Fwhitepapers\u002Fquantum-vulnerable-ai-stack",[207,208,534,788],"AI is a distinct, quantum-vulnerable cryptographic environment — ten layers from model provenance to guardrails — and it is the least mature of the four surfaces to migrate.","EQwW_d-oUIT2IXBcjqRMn8C38pTikJMStFY9oyrdAl8",{"id":1587,"title":1588,"author":7,"authorTitle":8,"authorUrl":9,"body":1589,"canonical":9,"category":161,"cover":9,"date":162,"description":1876,"draft":164,"extension":165,"faqs":9,"findingsSource":9,"image":166,"keyFindings":1877,"meta":1881,"modified":9,"navigation":172,"path":1882,"pdfUrl":9,"pullquote":9,"recommendations":1883,"references":1887,"related":9,"seo":1901,"signposts":9,"slug":1902,"stats":9,"stem":1903,"tags":1904,"tldr":1905,"__hash__":1906},"whitepapers\u002Fresources\u002Fwhitepapers\u002Fthe-three-clocks.md","The Three Clocks: Why Post-Quantum Migration Is the Defining Infrastructure Challenge of the Decade",{"type":11,"value":1590,"toc":1863},[1591,1593,1596,1599,1602,1605,1608,1611,1613,1617,1621,1624,1627,1630,1633,1637,1640,1654,1657,1660,1664,1667,1670,1673,1676,1679,1681,1685,1688,1694,1700,1706,1712,1715,1718,1720,1724,1727,1730,1736,1742,1748,1754,1757,1759,1763,1766,1772,1778,1784,1790,1796,1799,1802,1804,1808,1811,1814,1820,1826,1832,1835,1837,1841,1844,1851,1854,1857,1860],[14,1592,17],{"id":16},[19,1594,1595],{},"Three clocks are running simultaneously in every critical infrastructure enterprise today.",[19,1597,1598],{},"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.",[19,1600,1601],{},"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.",[19,1603,1604],{},"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.",[19,1606,1607],{},"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.",[19,1609,1610],{},"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.",[26,1612],{},[14,1614,1616],{"id":1615},"act-1-the-three-clocks","Act 1: The three clocks",[269,1618,1620],{"id":1619},"the-adversary-clock","The adversary clock",[19,1622,1623],{},"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.",[19,1625,1626],{},"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.",[19,1628,1629],{},"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.",[19,1631,1632],{},"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.",[269,1634,1636],{"id":1635},"the-crqc-clock","The CRQC clock",[19,1638,1639],{},"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:",[373,1641,1642,1645,1648,1651],{},[376,1643,1644],{},"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.",[376,1646,1647],{},"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.",[376,1649,1650],{},"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.",[376,1652,1653],{},"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.",[19,1655,1656],{},"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.",[19,1658,1659],{},"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.",[269,1661,1663],{"id":1662},"the-enterprise-clock","The enterprise clock",[19,1665,1666],{},"The third clock is different from the first two in one critical way: the enterprise controls when it starts and how fast it runs.",[19,1668,1669],{},"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.",[19,1671,1672],{},"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.",[19,1674,1675],{},"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.",[19,1677,1678],{},"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.",[26,1680],{},[14,1682,1684],{"id":1683},"act-2-the-four-surfaces","Act 2: The four surfaces",[19,1686,1687],{},"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.",[19,1689,1690,1693],{},[128,1691,1692],{},"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.",[19,1695,1696,1699],{},[128,1697,1698],{},"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\u002F204\u002F205 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.",[19,1701,1702,1705],{},[128,1703,1704],{},"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.",[19,1707,1708,1711],{},[128,1709,1710],{},"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.",[19,1713,1714],{},"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.",[19,1716,1717],{},"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.",[26,1719],{},[14,1721,1723],{"id":1722},"act-3-why-this-is-different-from-every-prior-security-migration","Act 3: Why this is different from every prior security migration",[19,1725,1726],{},"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.",[19,1728,1729],{},"Post-quantum cryptographic migration is not like any of them.",[19,1731,1732,1735],{},[128,1733,1734],{},"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.",[19,1737,1738,1741],{},[128,1739,1740],{},"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.",[19,1743,1744,1747],{},[128,1745,1746],{},"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.",[19,1749,1750,1753],{},[128,1751,1752],{},"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.",[19,1755,1756],{},"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.",[26,1758],{},[14,1760,1762],{"id":1761},"act-4-the-regulatory-arc","Act 4: The regulatory arc",[19,1764,1765],{},"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.",[19,1767,1768,1771],{},[128,1769,1770],{},"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.",[19,1773,1774,1777],{},[128,1775,1776],{},"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.",[19,1779,1780,1783],{},[128,1781,1782],{},"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.",[19,1785,1786,1789],{},[128,1787,1788],{},"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.",[19,1791,1792,1795],{},[128,1793,1794],{},"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.",[19,1797,1798],{},"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.",[19,1800,1801],{},"The regulatory clock is now aligned with the adversary clock and the CRQC clock. All three are running toward the same horizon.",[26,1803],{},[14,1805,1807],{"id":1806},"act-5-what-the-enterprise-must-build","Act 5: What the enterprise must build",[19,1809,1810],{},"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.",[19,1812,1813],{},"Three capabilities define the Full Stack approach.",[19,1815,1816,1819],{},[128,1817,1818],{},"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.",[19,1821,1822,1825],{},[128,1823,1824],{},"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.",[19,1827,1828,1831],{},[128,1829,1830],{},"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.",[19,1833,1834],{},"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.",[26,1836],{},[14,1838,1840],{"id":1839},"coda-the-one-question","Coda: The one question",[19,1842,1843],{},"Every critical infrastructure enterprise should be able to answer one question about its post-quantum cryptographic posture at any moment on any Monday morning:",[449,1845,1846],{},[19,1847,1848],{},[454,1849,1850],{},"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?",[19,1852,1853],{},"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.",[19,1855,1856],{},"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.",[19,1858,1859],{},"The enterprise that cannot answer that question is not late. It has not yet started.",[19,1861,1862],{},"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.",{"title":151,"searchDepth":152,"depth":152,"links":1864},[1865,1866,1871,1872,1873,1874,1875],{"id":16,"depth":152,"text":17},{"id":1615,"depth":152,"text":1616,"children":1867},[1868,1869,1870],{"id":1619,"depth":485,"text":1620},{"id":1635,"depth":485,"text":1636},{"id":1662,"depth":485,"text":1663},{"id":1683,"depth":152,"text":1684},{"id":1722,"depth":152,"text":1723},{"id":1761,"depth":152,"text":1762},{"id":1806,"depth":152,"text":1807},{"id":1839,"depth":152,"text":1840},"Why post-quantum migration is the defining infrastructure challenge of the decade: the three clocks running in parallel and why your migration clock decides the outcome.",[1878,1879,1880],"Harvest Now, Decrypt Later is already running: adversaries are storing encrypted enterprise traffic today to decrypt once a quantum computer arrives.","Credible CRQC arrival estimates have moved earlier every cycle and now converge on the late 2020s to early 2030s.","The enterprise migration clock spans four surfaces — Cloud, IT, OT, and AI — each at a different maximum speed, and is set by the slowest (usually OT, then AI).",{},"\u002Fresources\u002Fwhitepapers\u002Fthe-three-clocks",[1884,1885,1886],"Start the enterprise clock now; its speed is fixed by the environments being migrated, not by willingness to hurry later.","Run Full Stack visibility, a living migration roadmap, and continuous governance across all four surfaces as one program.","Be able to answer on any Monday what percentage of your cryptographic surface is PQC-ready across Cloud, IT, OT, and AI, and when you finish.",[1888,1889,1890,1891,1892,1893,1894,1895,1896,1899],{"label":189,"url":190},{"label":192,"url":193},{"label":195,"url":196},{"label":509,"url":510},{"label":781,"url":782},{"label":528,"url":529},{"label":201,"url":202},{"label":183,"url":184},{"label":1897,"url":1898},"UK National Cyber Security Centre, \"Next Steps in Preparing for Post-Quantum Cryptography,\" Guidance, March 2025.","https:\u002F\u002Fwww.ncsc.gov.uk\u002Fguidance\u002Fpqc-migration",{"label":1900,"url":1052},"Federal Register, \"Presidential Directive on Critical Infrastructure Security and Resilience,\" PPD-21, February 2013.",{"title":1588,"description":1876},"the-three-clocks","resources\u002Fwhitepapers\u002Fthe-three-clocks",[534,210,789,790,535],"Three clocks run in parallel in every critical-infrastructure enterprise — the adversary’s, the quantum computer’s, and your own migration clock — and only the last one is yours to control.","d47gkI8mjjbeftlGIqQOdZG5KRcXmKhFlJ8XipPWtvM",1784747239675]