up:: Quantum Risk Models MOC

PKI Collapse

PKI collapse is the failure condition where a public key infrastructure stops being able to prove who anyone or anything is, because the signature keys underneath it have become forgeable. In a quantum context, it happens when a cryptographically relevant quantum computer runs Shor’s algorithm against a certificate authority’s public signing key and recovers the matching private key. From that instant, every certificate that CA ever signed, and every certificate it could sign in the future, is forgeable. This is the highest-blast-radius scenario in the whole quantum threat, because a single broken key can invalidate trust for millions of systems and billions of users at once.

The short version:

• PKI collapse is a trust failure, not a secrecy failure. It forges identity across an entire certificate hierarchy rather than stealing any one secret.
• It comes from breaking one high-value key. Recover a CA’s private signing key with Shor’s algorithm, and every certificate chained to that CA is compromised simultaneously.
• It is a Non-HNDL threat. The attacker needs a live quantum computer at the moment of attack, and the target key is already public, so there is nothing to harvest and no vault to breach.
• Recovery is brutal and slow. It means revoking the CA, reissuing everything under it, and pushing new trust anchors out through operating-system and browser update cycles, while already-signed code and firmware keep verifying as valid.
• The fix is to migrate CA signing keys to ML-DSA or SLH-DSA before the machine exists, because there is no clean way to recover after.

An everyday analogy

Think of a certificate authority as the passport office for the internet. It does not check your identity every time you cross a border; it issued a document, and every border guard in the world trusts that document because they trust the office’s official seal. PKI collapse is what happens when someone forges the seal itself. Now they can print a genuine-looking passport for anyone, in anyone’s name, and every guard on the planet waves them through, because the seal is real as far as the guard can tell. You do not fix that by reissuing one traveler’s passport. You have to convince every border guard, all at once, to stop trusting the old seal and start trusting a new one, and until they all do, the forger walks through freely.

What kind of threat is PKI collapse?

PKI collapse is an integrity and authentication threat, not a confidentiality threat. Its damage is to trust, meaning the ability to tell a genuine identity from a forged one, rather than to the secrecy of any stored data. That places it in a specific box on the quantum threat map:

1. Temporal class: real-time. It is a Non-HNDL threat. Unlike harvest-now-decrypt-later, which lets an attacker collect encrypted traffic today and open it years later, PKI collapse cannot be staged in advance. The attacker has to be holding a working quantum computer at the moment of the forgery.
2. Enabling algorithm: Shor’s. The break comes from Shor’s algorithm, which recovers a private key from a public one for RSA and ECDSA signatures. Grover’s algorithm is not the relevant tool here; this is a public-key signature break, not a symmetric-key search.
3. Dependency: a CRQC. It needs a CRQC large enough to factor or solve discrete logs at real key sizes. No such machine exists today, which is why this is a migration problem rather than an active incident.
4. The catch that makes it urgent: the target key is already public. A CA’s signing key lives inside its certificate, published in every trust store and served on every handshake. The attacker already has the input to Shor’s algorithm. They are waiting only on the hardware.

How does a quantum PKI collapse actually happen?

The mechanism is short, which is part of what makes it so dangerous. PKI works because trust flows down a chain of signatures: a root CA signs an intermediate CA, the intermediate signs an end-entity certificate, and a relying party believes the end-entity’s identity because it can verify that chain of signatures back up to a trusted root. Break the signature at any level and everything below it becomes forgeable. The quantum attack runs in five moves:

1. Pick the CA key. Root and intermediate CA keys are the prize, because they sit at the top of the chain and vouch for everything beneath them. They are public information, listed in trust stores and served in certificate chains.
2. Derive the private key. Run Shor’s algorithm on a large enough quantum computer to recover the CA’s private signing key from its published public key.
3. Forge certificates at will. With the CA’s private key, the attacker can issue certificates that are cryptographically valid for any name they choose, including domains, services, users, and devices they do not control.
4. Present the forgery. A relying party validates a forged certificate and it passes, because the signature is mathematically correct and chains to a trusted root. There is no defect to detect; the forgery is indistinguishable from a genuine certificate without out-of-band information the relying party does not have.
5. Impersonate and sign anything in scope. The attacker can now stand up fake versions of any site or service, forge authentication, and sign code and firmware that verifies as legitimate on every device that trusts the compromised root.

The critical difference from a classical CA breach is that the attacker never touches the CA. The break needs neither an intrusion nor a stolen hardware security module nor an insider, because the private key is computed from public data. That means the CA’s own defenses, its physical security, its HSMs, and its access controls, are all irrelevant to the break.

What’s at risk when PKI collapses?

Essentially every system that uses certificates to establish trust, which in a modern enterprise is nearly everything. The trust surfaces fall into distinct buckets, and scoping to only the first one is the most common way teams underestimate the exposure:

1. Public and internal TLS identity. Every website, customer portal, public API, partner API, and internal service that proves its identity with a certificate. Mutual TLS, service-mesh identity, and east-west workload authentication all rest on the same certificate trust.
2. Administrative and privileged access. Certificate-based admin authentication, privileged-access infrastructure, VPN certificate auth, and management-plane trust. These are the highest-value targets because they gate control of the estate.
3. Code and software supply chains. Release signing, package-manager trust, and update-channel verification. A forged code-signing certificate produces signed malware that passes verification on every device trusting the CA.
4. Firmware and device trust. Secure boot, firmware validation, device identity, and hardware provisioning, much of it embedded in devices with long field lifetimes and slow or no update paths.
5. Enterprise user and machine certificates. Smart cards, device certificates, and internal user certificates issued from private enterprise PKI, which is usually broader and more fragile than the public web PKI most people picture.

The protocols in scope run across the whole stack: TLS certificate validation, code and firmware signing, mutual-TLS service identity, VPN and IPsec peer authentication, and certificate-based smart-card login. A cryptographic inventory scoped to “public TLS endpoints” misses most of the real trust surface, which is why all of it belongs in a CBOM.

Why is this a problem today if the quantum computer is years away?

Because migrating a PKI takes years, and it has to finish before the machine exists. The exploitation is instantaneous once a CRQC arrives, but the defense is slow, and that asymmetry is the whole problem.

1. PKI migration is a multi-year program. Re-rooting trust means rebuilding certificate hierarchies, reissuing certificates, updating validators, and pushing new trust anchors to every relying party. For a large enterprise with embedded devices and vendor dependencies, this commonly runs on the order of several years.
2. Vendor-controlled surfaces cannot move on your schedule. Operating-system trust stores, public-CA root programs, and identity-platform migrations all carry external dependencies that stretch the timeline well past what an internal team controls.
3. The timeline is a race you can lose by starting late. This is a straight Mosca’s theorem argument. For a root CA key, the security lifespan you need is effectively “until the whole migration is done,” so the migration time is the exposure window. U.S. national-security policy sets 2035 as the outer date for completing the transition, and with multi-year migrations, an organization that starts late can still be mid-migration when a capable machine appears.

Source: NSA, “CNSA 2.0 FAQ” (PP-24-4014, December 2024 update), which sets 2035 as the completion date for the National Security Systems transition, CNSA 2.0 FAQ.

How much damage would PKI collapse cause?

More than any other single cryptographic failure, because PKI is a trust multiplier. One root or intermediate CA vouches for a huge population of certificates, so breaking one key does not compromise one system, it compromises everything that key underwrites. The severity comes from five dimensions of blast radius:

Blast-radius dimension	Why PKI collapse maxes it out
Population	Potentially every user, device, service, and application that trusts the compromised CA, up to millions of relying parties and billions of users under a widely-trusted root
Privilege	Extremely high, because PKI underpins administrative access, production service identity, code signing, and firmware trust
Reachability	Internet-facing, internal, partner-facing, and embedded systems are all reachable through the same broken trust anchor
Propagation	Once chain validation can be forged, every downstream system that depends on those certificates is unsafe at the same time
Recovery complexity	Very high, because recovery requires root changes, mass reissuance, validator upgrades, device updates, and cross-vendor coordination

Recovery is the part that turns a bad day into a bad year. It is not one action, it is a sequence, each step slow on its own:

1. Revoke the CA and everything it issued. Revocation only helps if relying parties check it and the attacker cannot simply mint fresh believable certificates, which against a broken CA key they can.
2. Reissue every affected certificate from a new, trustworthy anchor. For a large estate that is an enormous inventory of leaf, intermediate, and device certificates.
3. Distribute the new trust anchors to every relying party. This moves at the speed of operating-system and browser update cycles, and old or embedded clients may never update at all, leaving split-brain trust across the environment.
4. Deal with artifacts already signed under the old keys. Software and firmware signed before the break keep verifying as valid indefinitely, so a key revocation after the fact does not undo signatures that already passed.

No organization can do this alone, and there is no after-the-fact recovery path worth the name. That is exactly why the migration has to be pre-emptive.

What does the research say about the quantum threat to PKI?

The threat rests on published, peer-reviewed resource estimates for how large a quantum computer would need to be to break the specific keys PKI relies on. Those estimates are why the industry treats this as a “when,” not an “if.”

1. Breaking ECDSA signing keys. A 256-bit elliptic curve, the P-256 curve behind a great deal of certificate signing, is estimated to need on the order of 2,330 logical qubits to solve via Shor’s algorithm. Elliptic-curve keys fall first because they are short relative to their classical security level.
2. Breaking RSA signing keys. Factoring a 2048-bit RSA key, still common in root and intermediate CAs, was estimated in 2019 at roughly 20 million noisy physical qubits (about 6,100 logical qubits), and a 2025 optimization brought the physical-qubit figure under one million. Larger RSA keys raise the cost, but only modestly, because Shor’s runtime grows as a polynomial in key length rather than hitting the exponential wall that stops classical factoring.
3. The gap to today’s hardware. No current quantum computer is within orders of magnitude of these figures. The research does not say the machine is here; it says the target is a fixed, known number of error-corrected qubits, and the field is moving toward it.

Sources: Martin Roetteler, Michael Naehrig, Krysta M. Svore, Kristin Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.

Craig Gidney and Martin Ekerå, “How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits,” Quantum 5, 433, 2021, arXiv:1905.09749.

Craig Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits,” 2025, arXiv:2505.15917.

What replaces the cryptography PKI depends on?

The fix is to move the signatures inside the certificate ecosystem off RSA and ECDSA and onto NIST’s standardized post-quantum signature algorithms, starting with the CA signing keys themselves, because those are the highest-blast-radius keys in the estate.

Replace	With	Best for
RSA / ECDSA CA and certificate signatures	ML-DSA	General-purpose certificate and CA signing, the primary choice
RSA / ECDSA long-lived signatures	SLH-DSA	Conservative, hash-based backstop for very long-lived or high-assurance roots
RSA / ECDSA key establishment in TLS	ML-KEM	The confidentiality half of the transition, adjacent to PKI but a separate program

Because a PKI is an ecosystem that cannot flip all at once, the transition usually runs through bridging structures rather than a single cutover:

1. Composite certificates carry both a classical and a post-quantum signature in one certificate, so post-quantum-aware verifiers get post-quantum security while older clients still validate the classical part.
2. Dual signatures and parallel trust chains run a classical and a post-quantum hierarchy side by side, letting relying parties upgrade in stages instead of in lockstep.
3. Cross-certification lets an existing CA vouch for a new post-quantum CA before every trust store has been updated, smoothing the root-distribution problem.
4. Crypto-agility first. A PKI that hardcodes its signing algorithm faces the longest and most painful migration. Designing so the algorithm can change without rebuilding the whole infrastructure is the precondition for every step above.

Sources: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, FIPS 204.

NIST, “Stateless Hash-Based Digital Signature Standard,” FIPS 205, August 2024, FIPS 205.

What looks like a fix but isn’t?

Several plausible-sounding moves leave the actual vulnerability untouched, and they are worth naming because teams reach for them first:

1. Reissuing leaf certificates without migrating the CA key. Rotating all the end-entity certificates feels like progress, but if the CA’s own signing key is still classical, the attacker forges from the CA and every fresh leaf certificate is just as forgeable. The vulnerable key is the one at the top, not the ones at the bottom.
2. Bumping RSA to 4096 bits. A larger RSA key raises the quantum cost only modestly, because Shor’s algorithm scales polynomially in key length. It buys almost nothing against a CRQC while adding classical overhead, so it is a delay tactic at best.
3. Certificate pinning. Pinning a certificate or public key hardens against a rogue-CA-issuance attack, but it pins a still-classical, still-forgeable key. Once the underlying signature is breakable, pinning the broken thing does not help.
4. Assuming vendors will handle it. Operating-system trust stores, public-CA root programs, and appliance firmware are vendor-controlled surfaces. Waiting for them is reasonable for the parts they own, but it is not a migration for the private PKI, code signing, and device identity an organization owns itself.

How does PKI collapse relate to the other quantum threats?

PKI collapse is the worst-case instance of the Non-HNDL threat class. Non-HNDL is the general category of quantum attacks on trust, forged signatures, fake certificates, impersonated identity, and PKI collapse is the specific catastrophe where the forged signature is a certificate authority’s, so the forgery propagates across an entire trust hierarchy at once.

It sits opposite HNDL on the threat map. HNDL is a confidentiality problem you close by migrating key establishment to ML-KEM, while PKI collapse is a trust problem you close by migrating signatures to ML-DSA and SLH-DSA. A migration that handles only one of the two is half finished. Blast radius is the tool that tells you PKI collapse belongs at the front of the signature-migration queue, because no other broken key takes so much down with it.

Has this happened before?

Yes, without any quantum computer at all, and the wreckage is a preview of the quantum version at smaller scale. In 2011 the Dutch certificate authority DigiNotar was breached, and the attacker used its issuance systems to mint at least 531 fraudulent certificates, including a wildcard certificate for *.google.com. Those forged certificates were used in man-in-the-middle attacks against roughly 300,000 Iranian Gmail users, who saw a padlock and a valid-looking certificate while their traffic was being intercepted. The relying parties could not tell the forgeries from the real thing, because the certificates chained to a trusted root, which is the exact failure mode of PKI collapse.

The recovery is the part that rhymes with the quantum scenario. All major browsers removed DigiNotar’s roots from their trust stores in late August 2011, and once the world stopped trusting the seal, the company was worthless; DigiNotar was declared bankrupt within weeks, on September 20, 2011. That was a single compromised CA, contained by yanking its roots. A quantum PKI collapse is the same shape with two differences that make it far worse: the attacker forges from the CA key by computation, without ever breaching the CA, and the break can hit many CAs at once, because they all rely on the same quantum-vulnerable math.

Source: Fox-IT, “Black Tulip, Report of the investigation into the DigiNotar Certificate Authority breach,” 2012, Fox-IT Black Tulip report, as hosted by ENISA.

Common misconceptions

1. “PKI collapse means my old encrypted data gets decrypted.” That is HNDL, a separate confidentiality threat. PKI collapse is about losing the ability to trust identities and signatures in real time, not about retroactive decryption.
2. “If I rotate all my certificates, I’m covered.” Rotating leaf certificates while the CA signing key stays classical leaves the real vulnerability in place. The key that has to move first is the CA’s own.
3. “It’s just the public web PKI.” Private enterprise PKI, code signing, firmware, device identity, and internal machine certificates are usually a larger and more fragile trust surface than the public certificates people picture.
4. “A bigger RSA key fixes it.” Shor’s algorithm scales polynomially in key length, so RSA-4096 raises the cost only slightly. It is not a durable defense.
5. “We can just revoke and reissue if it happens.” Revocation assumes you can distribute new trust anchors faster than the attacker can forge, and against a broken CA key you cannot. Already-signed code and firmware also keep verifying regardless of revocation.
6. “This is a confidentiality thing, so it can wait behind HNDL.” For long-lived signing infrastructure, the migration window is measured in years, and the completion deadline is fixed, so the planning problem is live now.

Questions people ask

Is PKI collapse a threat today, or only after quantum computers exist? The forgery itself only happens once a CRQC exists, which is years out. The migration to prevent it is a present problem, because re-rooting a large PKI takes years and has to finish before the machine arrives.

Which key actually has to be replaced first? The certificate authority signing keys, especially roots and intermediates. They sit at the top of the trust chain and vouch for everything beneath them, so they carry the largest blast radius and are the highest priority in a signature migration.

Does the attacker have to break into the certificate authority? No, and that is what makes the quantum version so dangerous. The CA’s public key is already published, so Shor’s algorithm computes the private key from public data. The CA’s physical security, HSMs, and access controls are irrelevant to that step.

What replaces the vulnerable signatures? ML-DSA is the general-purpose replacement for certificate and CA signing, with SLH-DSA as a conservative hash-based option for very long-lived or high-assurance roots. Both are finalized NIST standards published in August 2024.

Can I just revoke certificates if a collapse happens? Not effectively. Revocation only works if relying parties learn the new trust state faster than the attacker can forge new certificates, and against a broken CA key the attacker can always mint believable ones. Artifacts already signed under the old key also keep verifying.

How is this different from the DigiNotar breach in 2011? DigiNotar was an intrusion, someone broke into the CA and abused its issuance systems. A quantum PKI collapse needs no intrusion at all, because the private key is computed from the public key, and it can affect many CAs at once rather than one.

How long does a PKI migration take? For a large enterprise with embedded devices and vendor dependencies, re-rooting trust and reissuing across the estate commonly runs on the order of several years. That lead time, against a fixed completion deadline, is why teams start well before a quantum computer exists.

Is this the same as harvest-now-decrypt-later? No. HNDL is a confidentiality threat closed by migrating key establishment to ML-KEM. PKI collapse is a trust threat closed by migrating signatures to ML-DSA and SLH-DSA. A complete migration handles both.

---

Everything here is the map, given freely. When your team needs its own trust infrastructure found, sized, and sequenced onto a post-quantum path before the machine arrives, that is the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.