Blog
/
Post-Quantum Cryptography

Trust Now, Exploit Later: PQC Is an Identity Problem

Colin White
October 5, 2026

For years, the case for post-quantum cryptography (PQC) has rested on one phrase: harvest now, decrypt later. Adversaries steal encrypted data today and wait for a quantum computer to unlock it.

On October 1, the National Security Agency put a second phrase front and center. In announcing new PQC measures for national security systems, NSA warned that today's architectures also need protection from "trust now, exploit later" threats.

That second phrase deserves more attention than it's getting. Harvest now, decrypt later is about confidentiality. Trust now, exploit later is about authentication. And authentication is identity.

In plain terms, trust now, exploit later is the risk that a future quantum computer will let attackers forge the digital signatures and certificates your systems trust today.

What NSA announced

NSA's announcement sets firm expectations for national security systems (NSS):

  • Starting in 2027, all new commercial NSS must be capable of supporting quantum-resistant algorithms, as required by CNSSP 15.
  • Legacy systems that can't run quantum-resistant algorithms face phaseout by 2030.
  • NSA is publishing a library of PQC resources to guide the transition, including guidance that quantum key distribution is no substitute for quantum-resistant algorithms.

The dates won't surprise anyone tracking CNSA 2.0, the set of quantum-resistant algorithms NSA requires for national security systems. The framing is what's new. NSA is saying the threat isn't only about data someone might decrypt years from now. It's also about the trust decisions your systems are making today. Among the reasons to adopt quantum-resistant algorithms, NSA lists keeping authentication systems intact and protecting user identities.

Why trust now, exploit later is an identity problem

Every time a user signs in with a smart card, a laptop joins Wi-Fi with a certificate, or a server proves who it is over TLS, a digital signature is doing the work. Most of those signatures rely on RSA or elliptic curve cryptography. Those are the algorithms a large enough quantum computer is expected to break. NIST's main replacement for them is ML-DSA, the post-quantum signature standard published as FIPS 204.

When that happens, an attacker doesn't need to steal your data. They can forge the credentials that grant access to it. A forged certificate looks legitimate. A forged signature on a firmware update installs cleanly. A compromised certificate authority can vouch for anything.

The "trust now" part is what makes this urgent today. Root CAs, smart card fleets, and hardware tokens are built to last years, sometimes more than a decade. A root CA stood up on RSA this year may still be anchoring trust when quantum attacks become practical.

That's why PQC readiness and identity security are really the same project. You can't migrate what you can't see. For most organizations, the biggest blind spot is the sprawl of certificates, keys, and credentials spread across users, machines, and devices.

The federal clock is running

For federal agencies and the companies that sell to them, the next few months are packed:

  • Around October 22, 2026: Civilian agencies submit PQC migration plans to OMB and the Office of the National Cyber Director. OMB M-26-15, the memo implementing Executive Order 14412, requires them. OMB calls a continuously updated cryptographic inventory, built with automated tools wherever possible, the foundation of those plans.
  • Expected by mid-December 2026: EO 14412 gives the FAR Council 180 days, or until about December 19, to propose a rule requiring covered contractors to comply with NIST's FIPS standards, including PQC, by December 31, 2030. That's how quantum-safe requirements will start showing up in federal contracts.
  • 2027: Under CNSSP 15, new commercial national security systems must be capable of supporting quantum-resistant algorithms (NSA's CNSA 2.0 suite). This is the same requirement NSA restated on October 1.
  • End of 2030 and 2031: EO 14412 deadlines for agencies to move their high value assets and high impact systems to PQC for key establishment (December 31, 2030) and digital signatures (December 31, 2031). National security systems follow a separate track.

Notice that signatures get their own deadline. Contractors should expect agencies to start asking about their cryptographic readiness as these plans take shape.

Outside government, the timeline keeps shrinking

If you don't sell to the government, it's tempting to file all this under "federal problem." Recent news says otherwise:

  • Google and Cloudflare have each set 2029 as the target to finish their own post-quantum migrations, and both explicitly include authentication and signatures, not just encryption (Google, Cloudflare).
  • On September 29, Cloudflare announced plans to become a public certificate authority that issues post-quantum Merkle Tree Certificates, with production issuance targeted for early 2027 (Cloudflare). That covers the web's public certificates. The certificates inside your organization, for users, devices, and internal services, are still yours to migrate.
  • At Bitkom's AI, Data & Quantum Summit in Berlin, Germany's Bundesdruckerei presented research suggesting AI could cut in half the quantum resources needed to break ECDSA, one of the most widely used signature algorithms. It's an early result from a conference talk, so treat it as a signal rather than a settled finding.
  • On October 5, the Dutch cabinet sent parliament a quantum strategy that targets the end of 2030 for central government to finish migrating high-risk use cases. It also names a forgery risk it calls "harvest now, forge later," and says organizations covered by the Dutch NIS2 law, more than 8,000 of them, can use that law to take steps toward quantum-safe cryptography.

The direction is consistent. Estimates of when quantum attacks become practical keep moving earlier, and regulators keep landing on 2030.

What to do now

You don't need a finished migration this quarter. You do need to start, and identity is the right place to start.

  1. Inventory your certificates, keys, and credentials. Cover users, machines, devices, and services. Spreadsheets won't keep up, which is why OMB tells agencies to automate it wherever possible. Most organizations also think they're further along than they are. In Axiad's PQC Confidence Gap report, a survey of 315 U.S. security and IT leaders, 90% of CISOs and CIOs said they keep a continuously updated crypto inventory, but only 33% of the architects and PKI engineers who manage those assets agreed. And a list of certificates isn't the whole picture. You need to see every cryptographic dependency tied to the human and machine identities that rely on it, ranked by risk, which is the view Axiad Mesh is built to give you.
  2. Find your long-lived trust anchors. Root and issuing CAs, smart card and token fleets, and code-signing keys live the longest, so they carry the most trust now, exploit later risk.
  3. Build for crypto-agility. Choose tools and architectures that let you swap algorithms without reissuing everything by hand. Expect to run classical and post-quantum certificates side by side for years.
  4. Ask your vendors for their roadmaps. Your PKI, HSMs, authenticators, and identity providers all need a PQC plan. Get it in writing.
  5. Start with a quick outside-in check. See what your public-facing services reveal about your cryptography today, then work inward.

The bottom line

Harvest now, decrypt later made PQC a data problem. Trust now, exploit later makes it an identity problem. Organizations that treat it that way, starting with a clear view of every credential they've issued, will have a much easier time with 2027, 2030, and whatever deadline comes next.

Want a quick read on where you stand? Run the free Axiad PQC Readiness Tester to see how your public-facing TLS holds up. Then talk to our team about building an identity-first PQC roadmap.

Frequently asked questions

What's the difference between harvest now, decrypt later and trust now, exploit later? Harvest now, decrypt later targets confidentiality: attackers store encrypted data and decrypt it once quantum computers can. Trust now, exploit later targets authentication: attackers forge the signatures and certificates that systems use to decide who and what to trust.

When are federal agencies' PQC migration plans due? Around October 22, 2026. OMB M-26-15 gives civilian agencies 120 days from its June 24 release to submit plans to OMB and the Office of the National Cyber Director.

Where should an organization start with PQC readiness? With an inventory of certificates, keys, and credentials across users, machines, and devices. Prioritize long-lived trust anchors like root CAs, smart cards, and code-signing keys.

What do federal contractors need to do about PQC? Executive Order 14412 directs the FAR Council to propose a rule, expected by mid-December 2026, requiring covered contractors to comply with NIST's FIPS standards, including PQC, by December 31, 2030. Agencies are building their migration plans now, and OMB tells them to prioritize PKI-based access control systems, so expect questions about your cryptography and your PQC roadmap. Start with a cryptographic inventory and a written plan for moving to ML-KEM and ML-DSA.

About the author

Colin White is Director of Demand Generation at Axiad. He has spent more than 20 years in B2B marketing at cybersecurity and SaaS companies.

Sources

AXIAD DEMO
See How Axiad Works

See a comprehensive demo of Axiad and envision how it will revolutionize authentication for you!

Request Now
NEWSLETTER
Axiad's Monthly Newsletter