President Trump signed Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” on June 22, 2026, giving federal agencies until Dec. 31, 2030, to migrate their most sensitive systems to post-quantum encryption and until Dec. 31, 2031, to complete the switch for authentication.
Federal contractors face the same 2030 deadline. Because maintaining separate cryptographic codebases for government and commercial customers is rarely worth the engineering cost, vendors serving both markets are likely to apply that timeline across their entire product lines — meaning the deadline pressure now bearing down on Washington will reach ordinary businesses whether or not they hold a single federal contract.
For most companies, that transition won’t happen inside their own data centers, but will happen inside someone else’s — a cloud platform, a managed security provider, a hardware maker, a piece of enterprise software renewed every year without much scrutiny. That dependency is what makes vendor conversations the most important part of a company’s post-quantum preparation, and also the easiest part to get wrong. NIST finalized its first three post-quantum standards — ML-KEM, ML-DSA and SLH-DSA — in August 2024; a fourth, FN-DSA, remains in draft. But a vendor can invoke those standards, or the word “post-quantum” generally, without saying anything specific about what its product actually does, when, or at what cost to a customer’s existing systems.
A business that walks into that conversation without its own specific questions will get whatever answer the vendor finds easiest to give — and cryptographic migrations, which have historically taken 10 to 20 years to complete, don’t leave much room to discover the gap later. Being ready to ask precise questions, and knowing what a credible answer sounds like, is what separates a company that controls its own migration timeline from one that is simply told what to do.
Why the Post-Quantum Deadline Suddenly Matters to the Private Sector
Washington’s June 2026 executive order was written for federal agencies and their contractors, but its effects won’t stay contained to government. The order accelerates timelines set out in 2024 NIST guidance, which called for retiring RSA and elliptic-curve cryptography — the math underpinning most of today’s internet security — by 2030 and disallowing it outright by 2035. Cloudflare, one of the larger infrastructure providers already deploying post-quantum protections, has called the compressed federal timeline a likely reference point for private-sector expectations, not just a government mandate.
That matters because most companies don’t write their own cryptography. They buy it — embedded in cloud services, VPNs, identity platforms, point-of-sale systems and industrial control equipment. When a vendor’s federal customers require post-quantum support by a hard deadline, that requirement tends to flow into the commercial product too, since maintaining two separate cryptographic codebases is rarely worth the engineering cost. The practical result: even companies with no federal contracts at all are likely to see the pace of this transition set, in large part, by decisions being made in Washington right now.
The Trouble With Asking “Is This Product Post-Quantum?”
The obvious question to ask a vendor is whether its product is “post-quantum ready.” It’s also the least useful one. A vendor can answer yes in good faith while describing a dozen different situations — a fully implemented, standards-based upgrade; a roadmap item still in engineering review; or a single feature, buried deep in the product, that has nothing to do with the systems actually protecting customer data.
The more useful approach treats a vendor conversation less like a yes-or-no compliance check and more like an audit. Cryptography is rarely one thing inside a product — it’s dozens of components (session encryption, digital certificates, firmware signing, API authentication) that may each be on a different upgrade schedule. A vendor that hasn’t broken the conversation down to that level probably hasn’t done the internal work either.
Ten Questions to Ask — and What a Good Answer Sounds Like
1. Which components of the product use public-key cryptography? A vendor with a genuine handle on its own product can name the specific components — TLS connections, code-signing, certificate-based device authentication, API key exchange — rather than answering at the level of the whole product. A vague answer, or one that treats the product as a single monolithic thing, suggests the vendor hasn’t done its own cryptographic inventory yet.
2. Does the product use RSA, ECC, Diffie-Hellman, ECDH or ECDSA? These are the exact algorithms quantum computers are expected to eventually break. A good vendor answer names which of these are in use, where, and for what purpose — not just “industry-standard encryption.” If a vendor can’t identify its underlying algorithms by name, it likely can’t tell you when or how they’ll be replaced, either.
3. Is there a roadmap for PQC or hybrid cryptography support? Look for a specific document with dates, not a verbal assurance. “Hybrid” cryptography — running a classical algorithm and a post-quantum algorithm together, so both would need to be broken to compromise security — is the industry’s preferred bridge during the transition, and a credible roadmap should mention it by name along with a target quarter or year, not just “when NIST finalizes everything.”
4. Will PQC support require software updates, configuration changes, licence changes or hardware replacement? This is a budgeting question as much as a technical one. Post-quantum keys and signatures are substantially larger than their classical counterparts — an ML-KEM public key runs roughly 37 times the size of a comparable ECC key — which can strain memory-constrained hardware such as smart cards, industrial sensors and older network appliances. A vendor should be able to say plainly whether your existing hardware can handle the new key sizes or whether it’s approaching end of life.
5. Will the product support standardized algorithms such as ML-KEM, ML-DSA or SLH-DSA where appropriate? Standardized means finalized by NIST as FIPS 203, 204 and 205 — not a proprietary alternative a vendor built in-house. A good answer commits to the NIST standards specifically, explains which one applies to which function (ML-KEM for key exchange, ML-DSA for most signatures, SLH-DSA as a hash-based backup), and is candid that FN-DSA, the fourth standard, is still in draft and not yet appropriate for production deployment.
6. How will interoperability with older clients, browsers, devices or applications be handled? Not every customer, partner or device on the other end of a connection will upgrade on the same schedule. A vendor should describe a specific fallback or negotiation mechanism — not just promise that “everything will keep working.”
7. Will certificate types, trust stores or PKI integrations need to change? Public key infrastructure, or PKI — the system of digital certificates that lets systems verify each other’s identity — is where post-quantum migration tends to surface the most hidden work. A thorough vendor will flag whether new certificate authorities, updated trust stores, or reissued certificates across a customer’s environment will be required, rather than treating this as a detail to be worked out later.
8. What testing guidance will be provided before production deployment? Post-quantum algorithms can behave differently under load — larger payloads, different latency characteristics — than the cryptography they replace. A vendor should offer a testing environment, sample configurations, or a documented rollback path, not simply tell customers to deploy and monitor.
9. Will performance, bandwidth, storage or hardware requirements change? Larger keys and signatures mean more data moving across networks and more storage consumed by certificates and logs. Reasonable vendors quantify this — in percentage terms, in specific numbers — rather than describing the impact as negligible without evidence.
10. What is the vendor’s long-term support plan for cryptographic updates? Post-quantum cryptography isn’t a one-time swap. NIST’s own guidance anticipates further rounds of algorithm review, and a fourth signature standard is still being finalized. A vendor should be able to describe how future cryptographic updates will be delivered — through routine patches, a defined support window, or a formal crypto-agility framework — rather than treating this migration as a single, closed project.
What This Should Look Like in Practice
None of these questions require a technical background to ask, and a vendor’s willingness to answer them specifically is itself useful information. A supplier that responds with dates, named algorithms and identified components is one that has already done its own cryptographic inventory. A supplier that responds only with reassurance is one that hasn’t — and that gap tends to surface at the worst possible time, once a deadline is close and options have narrowed.
The starting point inside most organizations is the same regardless of industry: a cryptographic inventory of where encryption is used, which vendors and products are involved, and how long the data those systems protect needs to stay confidential. That inventory is what turns a vendor’s answers from a compliance exercise into an actual migration plan — and it’s the one piece of this transition no outside supplier can do for you.
