US order accelerates the move to post‑quantum cryptography: what changed and how to prepare

If you work with US government systems or sell to agencies, the deadline to replace quantum‑vulnerable cryptography just moved up. A new executive order accelerates transition dates, expands reporting, and tightens procurement rules so RSA, Diffie–Hellman, and elliptic‑curve algorithms are phased out sooner in favor of NIST‑approved post‑quantum cryptography (PQC).

In practical terms, that means federal agencies—and most contractors that connect to or process federal data—must complete cryptographic inventories faster, begin using PQC in new deployments earlier, and demonstrate crypto‑agile architectures. Expect near‑term changes to RFP language, authority‑to‑operate (ATO) requirements, software supply‑chain attestations, and FedRAMP packages. If you haven’t started a PQC migration, you’re already behind schedule.

What changed in the new directive

While agencies were already on a multiyear path to PQC, the order shortens key milestones and adds governance teeth. The specific dates vary by system category, but the practical shifts are consistent across government:

• Faster cutover windows: Previously published transition targets are pulled forward—especially for systems that protect long‑lived secrets. Expect “new systems must support PQC” to become an immediate or near‑term requirement.
• Stricter inventories and reporting: Agencies must complete cryptographic system inventories sooner and update them more frequently. Reports flow to OMB and cybersecurity leadership bodies, with fewer waivers and tighter justifications.
• Procurement pressure: New contracts, renewals, and major upgrades are expected to include PQC support (and crypto‑agility) by default. Vendors will be asked to prove readiness, not just to submit roadmaps.
• Reduced waivers and shorter sunset periods: Temporary exceptions for legacy algorithms expire more quickly, especially where the “harvest‑now, decrypt‑later” risk applies.
• Interagency alignment: The order harmonizes expectations across civilian and national‑security communities, pressing for compatibility with NIST standards and, where applicable, NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).

Bottom line: the window to plan is closing; the window to implement is opening.

Who must act now

• Federal civilian agencies (CFO‑Act and beyond): CIOs, CISOs, and acquisition leads must inventory, budget, and deploy PQC per the accelerated milestones.
• National security systems owners: Align transitions with CNSA 2.0 and the order’s earlier dates for high‑impact systems.
• Contractors and service providers: If you connect to, process, or store federal data—or provide software/hardware used by agencies—PQC support and crypto‑agility will be gating factors in awards and ATOs.
• Cloud and SaaS platforms: FedRAMP and agency ATO packages will expect PQC roadmaps, evidence of pilots, and plans for tenant‑level controls.
• Certificate authorities, PKI operators, and trust service providers: Prepare for hybrid or PQC‑native certificates, updated OIDs, path validation logic, and larger artifacts.
• Device, telecom, and OT/IoT vendors: Firmware update signing, secure boot, VPNs, and management protocols must move to PQC or PQC‑hybrid, with careful attention to constrained environments.

Why this matters: the durable “harvest‑now, decrypt‑later” problem

Adversaries can eavesdrop today and stockpile encrypted traffic for decryption once large‑scale quantum computers arrive. Any secret that must remain confidential for years—personnel data, health records, legal evidence, trade secrets, and classified information—faces this time‑shifted risk. Accelerating the transition reduces the window during which today’s recordings can be decrypted tomorrow.

What counts as “quantum‑vulnerable”

• Vulnerable to quantum attacks:
  • RSA (all key sizes) used for key establishment and signatures
  • Diffie–Hellman (finite‑field DH) and elliptic‑curve Diffie–Hellman (ECDH)
  • Elliptic‑curve signatures (ECDSA/EdDSA) for long‑term assurances
• Largely resilient with adjustments:
  • Symmetric cryptography (e.g., AES): increase key sizes (AES‑256 is preferred) to offset Grover’s algorithm
  • Hash functions (e.g., SHA‑2/SHA‑3): maintain robust output sizes; 256 bits and above remain sound for most uses

The migration is primarily about replacing public‑key building blocks used in TLS, VPNs, SSH, PKI, code signing, email, and software update systems.

What to adopt: NIST‑approved post‑quantum cryptography

NIST has selected and published standards for general‑purpose PQC:

• Key establishment: ML‑KEM (derived from CRYSTALS‑Kyber)
• Digital signatures: ML‑DSA (derived from CRYSTALS‑Dilithium) and SLH‑DSA (derived from SPHINCS+)
• Additional signature options: NIST has indicated further signature algorithms may be standardized for specialized needs; consult the current NIST list.

For national security systems, follow NSA’s CNSA 2.0 guidance, which aligns with NIST’s choices and sets specific adoption timelines.

Many deployments will start with hybrid modes that combine classical (e.g., X25519) and PQC (e.g., ML‑KEM) key exchanges or dual signatures. Hybrids provide continuity while ecosystems upgrade, though they increase complexity and artifact sizes.

Practical consequences across your stack

Expect change in nearly every place you rely on public‑key crypto:

• TLS/QUIC for web and APIs
  • Adopt libraries that offer PQC or hybrid key exchange support
  • Validate performance impacts on high‑traffic services
  • Ensure load balancers, proxies, and observability tooling can handle larger keys and messages
• VPN and network security
  • Upgrade IPsec and TLS VPNs to PQC/hybrid suites; test client interoperability on managed and BYOD fleets
• SSH and administrative access
  • Plan for PQC‑capable key exchange and signatures as providers add support; evaluate jump‑host and bastion impacts
• Email (S/MIME) and messaging
  • Pilot PQC/hybrid signing and encryption for high‑sensitivity mailboxes; plan for mixed‑mode address books and gateway compatibility
• Code signing and software supply chain
  • Introduce dual‑signing (classical + PQC) for build artifacts, containers, and firmware during transition
  • Confirm package managers and verifiers accept larger signatures and new OIDs
• PKI, certificates, and trust stores
  • Prepare CAs and RAs for PQC/hybrid certificates and updated validation rules
  • Review certificate lifetimes and path length constraints; artifact sizes will grow
• Data at rest and backups
  • Re‑wrap keys under PQC‑protected KEKs; favor AES‑256 for bulk encryption
  • Ensure backup catalogs and key escrow solutions are crypto‑agile
• Devices, OT/IoT, and constrained systems
  • Evaluate footprint and timing: ML‑DSA is fast with moderate sizes; SLH‑DSA offers strong conservatism at larger sizes
  • Budget for firmware and bootloader updates, secure element/HSM refreshes, and longer update windows

A practical migration plan

Here’s a staged plan you can adapt to your risk profile and the order’s timelines.

Days 0–90: establish facts and governance

• Build (or refresh) your cryptographic inventory: protocols, libraries, key lengths, certificate types, and where secrets live
• Classify systems by data sensitivity and confidentiality lifetime (e.g., needs secrecy for 2, 5, 10+ years)
• Appoint crypto owners: architecture, engineering, procurement, and compliance leads with clear roles
• Freeze new tech debt: require that any new system be crypto‑agile and capable of PQC or hybrid by design
• Engage vendors: request PQC roadmaps, FIPS validation status, and target dates for PQC support in your products

Months 3–6: prove feasibility

• Stand up test environments with PQC‑capable libraries and ciphersuites; run interoperability tests
• Pilot PQC/hybrid TLS for internal services and management planes
• Begin dual‑signing for internal build artifacts where supported
• Draft updated PKI policies (CP/CPS) and certificate profiles for PQC/hybrid issuance
• Align with compliance: incorporate PQC controls into SSPs, POA&Ms, and FedRAMP/FISMA documentation

Months 6–12: production footholds

• Require PQC/hybrid for new high‑sensitivity systems and greenfield deployments
• Roll out PQC/hybrid in front‑door services exposed to harvesting risk (public APIs, email gateways, VPN concentrators)
• Refresh RFPs and contracts: mandate PQC support, crypto‑agility, and vendor attestation timelines
• Train teams: secure coding for PQC, side‑channel awareness, certificate handling with larger artifacts

Year 1–2: broad adoption and deprecation

• Migrate administrative access, internal service mesh, and inter‑service TLS to PQC/hybrid
• Transition PKI to issue PQC/hybrid certificates at volume; monitor path validation success and revocation behavior
• Replace or upgrade HSMs, TPMs, and secure elements as needed; verify FIPS validations for PQC primitives
• Shorten lifetimes of classical‑only certificates; stop issuing RSA/ECC‑only for protected contexts
• Update incident response: include PQC‑specific failure modes and rollback strategies

Decision criteria and prioritization

• Confidentiality lifetime: If data must remain secret beyond a few years, prioritize PQC now
• Updatability: If a component is hard to patch (embedded, fielded, safety‑critical), upgrade earlier
• Exposure: Public endpoints and high‑volume channels are prime targets for harvesting
• Dependency chains: Core libraries (OpenSSL, BoringSSL, Java, .NET) and shared infrastructure (load balancers, proxies) are leverage points
• Compliance and customer commitments: Align with contract and regulatory expectations to avoid delays in ATOs and renewals
• Performance and footprint: Choose signature and KEM variants that meet your throughput and size constraints; benchmark before committing

Risks and pitfalls to avoid

• Interoperability gaps: Hybrid modes and new certificate profiles can fail in middleboxes, legacy clients, and monitoring tools
• Side‑channel vulnerabilities: PQC implementations must be hardened; prefer vetted, constant‑time libraries and FIPS‑validated modules
• Premature optimization: Don’t lock into niche algorithms; stick to NIST‑approved options and widely adopted profiles
• Artifact bloat: Certificates, signatures, and handshake messages are larger; monitor MTU, handshake retries, and storage impacts
• Governance gaps: Without inventory and ownership, migrations stall; tie milestones to budgets and procurement gates
• Supply‑chain surprises: Third‑party SDKs and agents may use hidden crypto; require SBOMs and cryptography disclosures

Tooling and standards to watch

• NIST PQC standards and FIPS validations for ML‑KEM, ML‑DSA, and SLH‑DSA; track updates for additional signature algorithms
• NSA CNSA 2.0 timelines for national security systems
• IETF work on PQC and hybrid modes for TLS/QUIC, IPsec, S/MIME, JOSE/COSE, and ACME
• PKI profiles for PQC/hybrid certificates and updated X.509 object identifiers (OIDs)
• Library and platform support roadmaps: OpenSSL, BoringSSL, wolfSSL, liboqs, Java, .NET, Go, Rust, Python
• Hardware support: HSMs, smartcards, TPMs, and secure enclaves adding PQC primitives
• Cloud provider features: managed certificates, load balancers, KMS/HSM services, and service‑mesh PQC options

For organizations outside the US public sector

Even if you’re not legally bound by the order, there are strong incentives to align:

• Customer demand: Regulated industries and global enterprises will ask for PQC readiness in security questionnaires and contracts
• Cross‑border alignment: EU, UK, and other jurisdictions are publishing PQC guidance; harmonization favors early movers
• Insurance and liability: Demonstrable PQC planning can support underwriting and due‑diligence narratives
• Competitive signaling: PQC support in your platform becomes a differentiator in long‑term data protection guarantees

Pragmatically, mirror the government’s approach: inventory, hybrid pilots, crypto‑agility, and staged rollouts tied to data‑lifetime risk.

Budget and contract language you can reuse

When refreshing procurements and supplier terms, consider clauses such as:

• “The solution must implement NIST‑approved post‑quantum cryptography (ML‑KEM for key establishment; ML‑DSA or SLH‑DSA for signatures) or approved hybrid modes, with configuration documented.”
• “Vendor will provide a PQC migration plan, including supported versions, timelines, and FIPS validation status for cryptographic modules.”
• “All new deployments must be crypto‑agile, allowing algorithm and parameter changes without code rewrites.”
• “Artifacts (certificates, CSRs, signed packages) must support PQC or dual‑signing within 12 months of contract award.”

Key takeaways

• The US has accelerated the timeline to retire quantum‑vulnerable public‑key cryptography in government systems.
• Agencies and contractors must complete inventories sooner, adopt PQC in new systems, and show crypto‑agility.
• Start with high‑risk areas: public endpoints, long‑lived secrets, hard‑to‑update devices, and software supply chains.
• Stick to NIST‑approved algorithms and monitor FIPS validations and IETF profiles.
• Expect procurement and compliance pressure: PQC support will increasingly decide awards and ATOs.

FAQ

Q: Do I need to rip out RSA/ECC everywhere immediately?
A: No. Prioritize systems that protect data with multi‑year confidentiality needs and external exposure. Use hybrid modes during transition and phase out classical‑only over time.

Q: Which algorithms should I standardize on first?
A: For key establishment, ML‑KEM. For signatures, ML‑DSA for general use; SLH‑DSA where conservative, hash‑based assurance is preferred. Verify current NIST guidance for any updates.

Q: Are symmetric ciphers like AES broken by quantum computing?
A: No. Quantum speedups are limited; use AES‑256 to maintain strong margins. Hash functions like SHA‑256/384 remain appropriate for most uses.

Q: What about performance and size overheads?
A: Expect larger keys, signatures, and handshakes. Benchmark in your environment; tune certificate chains, MTUs, and handshake retries. Many workloads will see manageable overhead with careful engineering.

Q: How do I know a library is safe to use?
A: Favor widely reviewed implementations with side‑channel hardening and, where required, FIPS‑validated modules. Monitor vendor advisories and adopt stable releases.

Q: Can I wait for the ecosystem to settle?
A: Waiting increases exposure to harvest‑now, decrypt‑later risk and may jeopardize compliance and contract renewals. Begin pilots and crypto‑agility work now to avoid a cliff later.

Q: We operate globally. Will PQC break cross‑border interoperability?
A: Transition periods can be bumpy. Use hybrids and maintain classical fallback where allowed, but plan to converge on NIST‑aligned PQC as international standards mature.

—

Source & original reading: https://arstechnica.com/information-technology/2026/06/executive-order-bumps-up-deadline-to-move-off-quantum-vulnerable-crypto/