Non-HNDL
Non-HNDL is the class of quantum attacks that need a working quantum computer at the moment of attack, and that target trust rather than secrecy: forged signatures, fake certificates, impersonated identities, and malicious code that verifies as legitimate. Where HNDL threatens the confidentiality of data collected in the past, Non-HNDL threatens integrity and authentication in real time. The moment a cryptographically relevant quantum computer can break ECDSA or RSA signatures, everything that trusts those signatures is compromised at once.
The short version:
- Non-HNDL is a trust problem: it forges identity, it doesn’t steal secrets.
- It can’t be staged in advance. It needs a live quantum computer, so its clock is the arrival of the machine, not today’s harvesting.
- Its worst case is PKI collapse: breaking a Certificate Authority’s signing key makes every certificate under it untrustworthy simultaneously.
- The fix is replacing signature algorithms (ECDSA, RSA) with ML-DSA or SLH-DSA, and it has to finish before the machine arrives, because after is too late.
The catch that makes it urgent despite the later clock: the public keys are already public. Every signing key an attacker would target sits in a certificate or a token in the open, so there’s no traffic to intercept and no vault to breach. They need the public key, which they already have, and the machine, which they’re waiting for.
How does an attacker forge a signature from a public key?
A digital signature is trustworthy because only the holder of the private key can produce it, and anyone can check it against the matching public key. Quantum computing breaks that one-way relationship. Shor’s algorithm can compute the private key from the public key, and public keys are, by design, published everywhere: in X.509 certificates, in JWT signing keys, in code-signing certificates. The attack runs in four moves:
- Pick a target key. Root CA keys, intermediate CA keys, identity-provider signing keys, code-signing certificates. All public information.
- Derive the private key. Run Shor’s on a large enough quantum computer to recover the private signing key from the public one. For ECDSA P-256 that means a machine on the order of a few thousand logical qubits, far beyond anything that exists today.
- Forge. With the private key in hand, the attacker can issue fraudulent certificates, forge authentication tokens, sign malware and firmware, and sign fraudulent transactions.
- Present the forgery. A relying party validates the forged artifact and it passes, because the signature is mathematically correct. The key is real, the math checks out, and there’s no way to tell the forgery from the genuine article without out-of-band trust.
No internal access to the victim is needed for the key-derivation step. That’s what makes Non-HNDL so dangerous: the attacker works entirely from public information plus the machine.
What’s at risk from Non-HNDL?
Non-HNDL scope is essentially every system that relies on classical digital signatures for trust:
- PKI and certificates. Every X.509 certificate signed by a quantum-vulnerable CA key, which is the entire public TLS certificate ecosystem, plus enterprise, government, and code-signing PKI. A compromised root undermines everything beneath it.
- Identity and authentication. SAML assertions, JWT access tokens, and OAuth codes signed with vulnerable keys can be forged, and with them every SSO session and federated identity that depends on them.
- Software supply chains. Code-signing and firmware-signing keys. A compromised key produces signed malware that passes verification on every device that trusts the certificate.
- Financial and government systems. Transaction signing, payment authorization, non-repudiation, document signing, and legal instruments built on classical signatures.
The protocols in scope run across the whole stack: TLS certificate validation, IPsec peer authentication, JWT and SAML token signing, SSH host keys, MIME and OpenPGP email signing, and code-signing everywhere.
Why is Non-HNDL a present-day problem if the machine is years away?
Non-HNDL exploitation is instantaneous once a quantum computer arrives, but the planning problem is live now, for one reason: migration takes years, and it has to be done before the machine exists.
- Migration lead time is the binding constraint. PKI migration means updating trust stores, distributing new roots, rebuilding certificate hierarchies, and getting vendor-controlled signing services onto post-quantum algorithms. For a large enterprise, that runs 3 to 7 years.
- Vendor surfaces can’t move unilaterally. Operating-system trust stores, public CA root programs, and identity-platform migrations all carry external dependencies that stretch the timeline beyond what internal teams expect.
- The timeline uncertainty cuts against you. Credible assessments put a capable quantum computer plausibly in the 2030–2040 range, and U.S. federal policy targets 2035 for migration completion. With 3-to-7-year migrations, an organization starting in 2026 could easily still be mid-migration when the machine arrives.
This is a straight Mosca’s theorem argument: for a root CA key, the security lifespan is effectively “until migration is done,” so the migration time is the exposure window. Start late and the window never closes in time.
What does the worst case look like? PKI collapse
Non-HNDL attacks on trust infrastructure carry the highest blast radius of any cryptographic threat, and PKI collapse is the specific catastrophe. A compromised root CA key undermines every certificate in its hierarchy, potentially millions of relying-party systems and billions of users. It grants the attacker the ability to impersonate any identity, sign any code, and authenticate to anything that trusts the compromised key, which is effectively arbitrary privilege across the whole trust domain.
Recovery is brutal. It means revoking the CA and everything it issued, distributing updated trust stores to every relying party through operating-system and browser update cycles, reissuing all affected certificates from a new anchor, and dealing with signed binaries and firmware that stay in circulation and keep verifying as valid. That’s measured in months to years, and no organization can do it alone. There’s no after-the-fact recovery path worth the name, which is exactly why the migration has to be pre-emptive.
How do you close the exposure?
| Replace | With | Best for |
|---|---|---|
| ECDSA / RSA signatures | ML-DSA | General-purpose signing (primary choice) |
| ECDSA / RSA signatures | SLH-DSA | Stateless or very long-lived signatures (conservative) |
| ECDSA / RSA signatures | FN-DSA | Constrained signature size and speed |
- Replace the signing algorithms. Move ECDSA and RSA signing to ML-DSA as the primary choice, with SLH-DSA for stateless or very long-lived signatures and FN-DSA where signature size and speed are constrained.
- Bridge with transitional structures. Composite certificates carry both a classical and a post-quantum algorithm in one certificate, so post-quantum-aware verifiers get post-quantum security while older ones still work. Dual signatures run two independent hierarchies in parallel for defense in depth. Cross-certification lets an existing CA vouch for a new post-quantum CA before trust stores update everywhere.
- Build crypto-agility first. PKI that hardcodes its signing algorithm faces the longest migration. Design so the algorithm can change without replacing the whole infrastructure.
Some things that look like fixes aren’t. Reissuing end-entity certificates without migrating the CA’s own signing key leaves the real vulnerability untouched. Certificate pinning pins a still-vulnerable classical certificate. And bumping RSA key sizes to 4096 buys almost nothing against Shor’s algorithm. For artifacts already signed and in the field, plan for re-signing and for timestamp-authority records (RFC 3161) that lock in a signature’s validity at a point in time before the break.
Where do teams miss Non-HNDL exposure?
Three gaps recur when organizations scope this work:
- Identity infrastructure. JWT and SAML signing keys are often owned by a different team than PKI, and they get left out of the inventory despite being high-blast-radius targets.
- Code signing. Operating-system update signing, package-manager signing, and CI/CD pipeline signing are vendor-controlled surfaces that a perimeter TLS scan never sees.
- Field artifacts. Software and firmware already signed under classical keys stay vulnerable indefinitely, and revoking a key after the fact doesn’t undo signatures that already validated.
Scoping a cryptographic inventory to “TLS endpoints” misses most of an organization’s Non-HNDL exposure. All signing infrastructure belongs in a CBOM, reaching well beyond the transport layer.
How does Non-HNDL relate to HNDL?
The two quantum risk categories cover different halves of cryptography, and a complete migration needs both. Move key establishment to ML-KEM and you’ve closed HNDL while leaving every signing key exposed. They’re governed by the same NIST standards but they’re different programs: HNDL is a key-establishment replacement, Non-HNDL is a signing and PKI replacement. Separating them cleanly lets a team sequence the more urgent one first, and blast radius is how you decide which that is.
Everything here is the map, given freely. When your team needs the version built for your own trust infrastructure, defensible to your own regulator, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.