What EO 14412 Actually Requires You to Inventory (And Why Your Certificate Manager Won’t Find It)
On June 22, 2026, the White House issued Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. Three dates matter:
- December 31, 2030. Federal agencies must transition high value assets and high impact systems to post-quantum cryptography for key establishment.
- December 31, 2031. The same systems must transition to post-quantum digital signatures.
- End of 2030. Federal contractors must comply with post-quantum FIPS standards.
What makes this different from NSM-10, CNSA 2.0, and the guidance stack that preceded it is enforceability. Previous federal direction on post-quantum cryptography was advisory in tone and aspirational in timeline. EO 14412 attaches obligations to contractors and directs OMB and the National Cyber Director to run oversight. Some of its reporting requirements landed in late July, weeks after signing.
If you are a federal agency, this is your program now. If you are a federal contractor, it is your procurement gate. And if you are neither, you should still be reading, because the commercial flow-through mechanism here is not regulation. It is purchasing. Federal buyers will require post-quantum capable products from their vendors, those vendors will require it from their suppliers, and the requirement will reach you through a security questionnaire long before it reaches you through a regulator. Sector regulators in healthcare, financial services, and critical infrastructure have a consistent history of converging on federal cryptographic baselines, and there is no reason to expect this transition to break the pattern.
The 2030 deadline is really a 2027 deadline
Here is the arithmetic nobody puts on a slide.
Organizations with a mature cryptographic asset inventory and a crypto-agile architecture take two to three years to complete a comprehensive migration. Organizations with cryptography hardcoded into legacy applications take four to six years, and often longer. The effort is heavily front-loaded: discovery and architecture consume the majority of the calendar, and remediation only starts once you know what you have.
Work backward from December 31, 2030. If you are in the four to six year category, and most enterprises with any meaningful legacy footprint are, you needed to start somewhere between 2024 and 2026. If you are in the two to three year category, you have until roughly late 2027, and you only qualify for that category if your inventory already exists.
Which raises the obvious question. Does it?
For most organizations the honest answer is that a partial inventory exists, it covers public-facing TLS certificates, it is maintained in a spreadsheet or a certificate lifecycle tool, and it represents a fraction of the cryptographic surface area that EO 14412 puts in scope. The gap between “we have a certificate manager” and “we have a cryptographic inventory” is the single largest source of schedule risk in this entire migration.
What a real cryptographic inventory covers
Scope this correctly on the first pass and you save a year. Here is what belongs in the inventory, and why each category resists the tooling most teams already own.
Public TLS certificates. The part everyone has. Your certificate lifecycle manager tracks issuance, expiry, and issuing CA for externally facing endpoints. Necessary and well understood. Treat it as the starting point, not the deliverable.
Internal PKI and the CA hierarchy itself. Internal certificates typically outnumber public ones by a wide margin, and they are frequently issued by CAs nobody has audited in years. More important: the signing algorithms and key sizes of the CA hierarchy itself are in scope. A quantum-vulnerable root signing quantum-vulnerable intermediates invalidates every certificate beneath it, and rebuilding a hierarchy is a multi-quarter project with change-control consequences across every system that trusts it.
SSH host and user keys. This is the category most consistently missing. SSH keys are provisioned by engineers, distributed through configuration management, accumulated in authorized_keys files across build agents, bastion hosts, and long-lived VMs, and almost never inventoried centrally. They have no expiry, so nothing forces a review. RSA and ECDSA host keys are quantum-vulnerable, and the sprawl means you cannot rotate what you cannot find.
Code signing and firmware signing keys. The hardest category to remediate and among the most exposed. A firmware signing key protects artifacts with service lifetimes measured in decades. If an adversary can derive that private key in 2035, they can sign malicious firmware that every device still trusting the corresponding public key will accept as authentic. Rotation requires coordinated updates to verification logic in the field, which for embedded fleets may not be possible at all. Start here on planning even though you will finish here on execution.
Embedded and hardcoded cryptography in application code. Algorithm choices baked into source, pinned in configuration files, or frozen inside container images. These do not appear in any certificate inventory because they are not certificates. Finding them requires scanning code, config, and image layers, and the results determine whether your migration is a configuration change or a development project. This category alone is usually the difference between the two to three year path and the four to six year path.
HSM and KMS-backed keys. Inventory not just the keys but the hardware and service capability underneath them. Does the module support ML-KEM and ML-DSA? Is it FIPS 140-3 validated? Note that all remaining FIPS 140-2 module validations move to the CMVP historical list on September 21, 2026, after which only FIPS 140-3 validated modules may be used for new procurement. That constrains your hardware options independently of anything post-quantum. If your HSM cannot do post-quantum algorithms, your migration includes a hardware refresh with lead times you do not control.
Third-party and SaaS dependencies. You inherit the algorithm choices of every service you integrate with. Their migration timeline becomes yours. Inventory which vendors terminate TLS on your behalf, which sign assertions you rely on, and which have published a post-quantum roadmap. The ones that have not published a roadmap are the finding.
Service account and workload identity credentials. Machine-to-machine authentication material: mutual TLS client certificates, signed JWTs, API keys backed by asymmetric crypto, workload identity federation. This is the fastest-growing identity population in most enterprises and the least governed.
Read that list again and notice the pattern. X.509 certificates are the only category with a built-in forcing function, because they expire. Everything else persists silently until someone goes looking. That is precisely why certificate-centric tooling produces a comfortable and badly incomplete picture.
Sequencing: what actually goes first
Once the inventory exists, the temptation is to remediate in order of ease. Resist it. Sequence by data confidentiality lifetime.
The threat that governs urgency is harvest now, decrypt later. An adversary capturing encrypted traffic today can store it and decrypt it once a cryptographically relevant quantum computer exists. Current projections place that window somewhere between 2033 and 2037, with wide error bars in both directions.
So the rule is simple. If the data protected by a key must remain confidential past roughly 2033, that key is already exposed and goes to the front of the queue. Fifteen-year medical records, long-lived PII, trade secrets, classified material, legal holds, and anything with a statutory retention period reaching into the 2030s all qualify. The protection on that data does not end when your retention policy ends. It ends when the math breaks.
Signatures follow a different risk model and can be sequenced second, which is consistent with the EO placing key establishment a year ahead of digital signatures. A signature forged in 2035 cannot retroactively compromise a document verified in 2026. The exception is signatures on long-lived artifacts that will still be verified in the future, which is why code signing and firmware signing sit uncomfortably in both categories.
Notice what this rule does not consider: how easy the system is to change. Difficulty determines how long a remediation takes, not whether it should start. Sequence by exposure, then staff by difficulty.
The deliverable is agility, not a completed migration
There is a version of this project that ends with a report, a signed-off remediation plan, and a closed ticket. That version fails.
FIPS 203, 204, and 205 were finalized in August 2024. FIPS 206, the FALCON-based FN-DSA signature scheme, is still a draft and is not expected to be final before late 2026 at the earliest. NIST IR 8547 deprecates RSA-2048 and ECC P-256 by 2030 and removes quantum-vulnerable algorithms from NIST standards entirely by 2035. And the lattice assumptions underneath ML-KEM and ML-DSA are younger than the factoring and discrete log problems they replace, with correspondingly less time under adversarial scrutiny. SLH-DSA sits in the standard set as the conservative hedge against exactly that: hash-based, slower, larger signatures, and resting on assumptions that have been studied for decades.
That is not an argument for waiting. NIST shipping a backup signature scheme is a statement about how the next ten years will go, not a reason to sit out the first five. The correct response to algorithm churn is the ability to change algorithms on demand, and you cannot build that capability during the transition that requires it.
The organizations that handle this well will not be the ones that complete the migration fastest. They will be the ones that come out of it with continuous visibility into where cryptography lives, what algorithms are in use, and which systems can have those algorithms changed without a development cycle. That capability is the asset. The 2030 deadline is just the first time you need it.
Which reframes the inventory. It is not a project artifact you produce once and archive. It is a live system of record for machine identity and cryptographic posture, and it has to survive the migration it enables.
A 90-day starting plan
If you have no program today, this is a defensible way to have one by early November.
Days 1 to 30: scope and instrument. Define the asset boundary, including subsidiaries, cloud accounts, and OT or embedded estates that sit outside normal IT governance. Select discovery tooling that covers certificates, SSH keys, code and config, and cloud key stores rather than certificates alone. Identify the system owners you will need and get them on notice now, because their availability is the schedule.
Days 31 to 60: run discovery and classify. Execute scanning across the full boundary. Classify every finding by algorithm, key size, owner, and confidentiality lifetime of the protected data. Expect the raw count to be several multiples of what your team estimated. Flag the categories where discovery came back empty, because empty usually means blind spot rather than absent.
Days 61 to 90: sequence and cost it. Produce a remediation queue ordered by confidentiality lifetime. Separate configuration changes from development work from hardware refresh, since those three have completely different cost and lead-time profiles. Convert that into a multi-year budget request. Take it to your board with the EO deadline attached, because the deadline is the thing that makes the budget conversation short.
Ninety days does not migrate anything. It tells you the size of the problem, which is what you need before the 2027 budget cycle closes.
Asparz covers certificates across public and internal PKI, SSH keys, and cryptography embedded in code and configuration, with post-quantum readiness classification built into the output. It does not inventory HSM firmware capability or audit your vendors’ roadmaps, and those categories still belong in your program.
Get Your Free Discovery Scan
Gain immediate visibility into your TLS certificate and SSH key estate at no cost, no contracts, and no obligations.Frequently asked questions
Not directly. It binds federal agencies and, through FIPS compliance requirements, federal contractors. Commercial organizations encounter it through procurement: federal buyers and prime contractors pass the requirement down their supply chains via contract terms and security questionnaires. Regulated sectors should also expect sector regulators to publish comparable timelines well before the federal endpoint.
The recommended approach is hybrid for key establishment, given the maturity gap and client compatibility, with a stated migration path off the classical component. Hybrid combines a classical key exchange with ML-KEM so that a break in either one alone does not expose the session, which is a reasonable hedge while lattice assumptions accumulate scrutiny. It is also where the industry has landed in practice: X25519MLKEM768 is what major browsers and CDNs have deployed, so hybrid is the interoperable choice today.
Be aware that this is a genuine split. NSA's CNSA 2.0 does not require hybrid for national security systems and treats the added complexity as a cost rather than a benefit. If you are building to CNSA 2.0, follow CNSA 2.0. For most commercial deployments the compatibility argument wins.
Signatures are a different question. There is no harvest-now-decrypt-later exposure on a signature, so the defense-in-depth case for hybrid is weaker and the size and performance cost is real. Treat the two decisions separately rather than adopting one posture across the board.
Whichever you choose, write down the condition that ends it. Hybrid without a stated exit becomes permanent by default, and you carry the classical algorithm and its cost long past the point it was protecting anything. .
Discovery itself runs weeks, not months, if the tooling covers the full asset classes. What extends the timeline is boundary definition and system owner engagement, particularly for cloud accounts and embedded estates outside central IT governance. Organizations that scope narrowly finish quickly and then repeat the exercise a year later with the correct scope.