Now Here Come the Hot Takes
Executive Orders 14409 and 14411 dropped yesterday. I want to give credit where it is due before I get into what is missing, because it would be easy to read this order and only see the gaps.
This is the right call. The National Security Agency (NSA) and the intelligence community have been raising the post-quantum cryptography (PQC) alarm for years. National Security Memorandum 10, issued in 2022, told agencies to start preparing. NIST finalized its PQC standards in 2024. The cryptographic community did the work. The algorithms exist.
And yet the internet is still running on RSA and elliptic curve cryptography, and most organizations have no idea where those algorithms live in their stack.
Quantum computing is not a hypothetical threat in a white paper. It is a threat that could break the foundational assumptions of online privacy and encrypted communication at scale. If a large enough quantum computer becomes operational, most of the cryptographic infrastructure the internet runs on becomes effectively useless. Everything you assumed was encrypted and private becomes readable by whoever gets there first.
That is not a niche security problem, it’s literally going to break the internet.
So yes: federal action is appropriate. The direction in the order is clear and prescriptive. Agencies must inventory their cryptographic assets, NIST must define the minimum elements of a cryptographic bill of materials (CBOM), and federal systems and contractors must migrate to quantum-resistant algorithms. That structure is sound.
Now the hot takes.
Is 2030 Too Late?
The migration deadline for high value assets is December 31, 2030. For digital signatures, it is December 31, 2031. That is four to five years from today.
I understand why those timelines exist. Migration at this scale is genuinely hard. Federal procurement cycles are slow. Legacy systems are deeply embedded. Contractors need time to update their stacks. All true.
But here is the problem: adversaries are not waiting for 2030. The "harvest now, decrypt later" threat, which the executive order itself names, means that data being collected today can be decrypted the moment a large-scale quantum computer becomes operational. Every day spent on the current cryptographic infrastructure is another day of exposure that no future migration deadline can retroactively close.
The organizations with the most sensitive data, the ones this order is most trying to protect, are probably already harvested. The question is whether decryption is possible before or after the migration is complete. A 2030 deadline is a bet that quantum capability at operational scale is still years beyond that. That may be right. But it is a bet, not a guarantee, and the order does not name what happens if that bet is wrong.
The Procurement Gap
The order mandates that covered contractors comply with NIST standards by December 31, 2030, with the FAR Council publishing a proposed rule within 180 days. That is progress.
What is missing is any specification of consequences for vendors selling cryptographic technology that does not meet the standard. The order tells agencies and contractors to migrate. It does not tell them what to do when the vendor they are buying from has not migrated.
This matters because a significant portion of the cryptography that needs to migrate is not owned by the agency or the contractor. It lives in commercial products, software libraries, network equipment, and hardware security modules supplied by third parties. Telling the buyer to comply while leaving the seller's obligation vague creates a compliance gap that will be exploited by every vendor that finds migration inconvenient.
We have seen this pattern before. The Cybersecurity Maturity Model Certification (CMMC) framework put requirements on prime contractors without initially specifying how those requirements flow to subcontractors and software suppliers. The result was years of confusion, renegotiated contracts, and DIB organizations scrambling to figure out what their vendors actually owed them. The PQC procurement rule is heading down the same road.
Procurement requirements with teeth, tied to contract awards and specifying what vendors must demonstrate about their cryptographic posture, would change the incentive structure. What is in this order is not that.
The CBOM Problem Is an SBOM Problem. We Should Say So.
This is the one that will generate the most debate, so let me be direct.
A CBOM is not a new category of artifact. It is a component of a software bill of materials (SBOM). CycloneDX, one of the two dominant SBOM formats, has supported cryptographic asset declarations since version 1.6. The data model exists. The tooling is being built. A cryptographic inventory is, structurally, an extension of the software inventory organizations should already have.
So here is my question: if this administration is effectively mandating CBOMs, why have previous memos and orders stopped short of mandating SBOMs or AI bills of materials (AIBOMs)?
I wrote about this after last year's cybersecurity executive order. That order loosened SBOM requirements rather than strengthened them, removing the requirement for secure software development framework attestations without replacing them with anything more substantive. And now we are layering a new acronym on top of an infrastructure problem that was never fully addressed.
Treating CBOMs as a separate initiative from SBOMs creates real confusion in the field. Program managers, procurement officers, and security teams are going to ask whether they need both, how they relate, which tools support which format, and who is responsible for what. None of those are hypothetical questions. They are the questions I get from customers every week.
The cleaner, more defensible position would have been to say: agencies must collect and maintain comprehensive software inventories, including cryptographic assets, using established SBOM standards. Full stop. That would have unified the policy direction, leveraged the tooling ecosystem that already exists, and avoided inventing a new acronym for something that SBOM infrastructure can already represent.
Instead we have SBOM, AIBOM, and now CBOM: three overlapping mandates, varying levels of enforcement, and a growing list of compliance obligations that organizations are expected to satisfy with tools that were built for a narrower question.
You cannot secure what you do not know about. That principle does not change based on whether you are looking for vulnerable libraries, risky AI models, or deprecated cryptographic algorithms. The inventory problem is the same problem. The policy should reflect that.
What to Do Right Now
If you are a CISO, a program manager, or a contractor trying to figure out what Monday looks like after this order, here is my honest read:
Do not wait for the CBOM guidance. You already know the question: where does classical cryptography live in my software and hardware stack? Start answering it. SBOM tooling with cryptographic asset support exists today. The standard will mature, but the underlying data problem is solvable now.
Treat the contractor deadline as real. The CMMC experience taught the defense industrial base what happens when you wait for the last mile. The organizations that started building compliance infrastructure early were the ones that closed contracts on schedule. The ones that waited scrambled. The PQC procurement rule will follow the same pattern.
Ask your vendors the hard question now. Do not wait for the FAR rule. What cryptographic algorithms are you using? Are they NIST-approved? What is your migration timeline? If they cannot answer, that is a risk you are already carrying, and the 2030 deadline will not protect you from it.
Build inventory infrastructure, not just a migration plan. The order requires agencies to submit a migration plan within 90 days. A plan is not the same as progress. What you actually need is the infrastructure to know your cryptographic posture continuously, because the threat environment will keep moving long after the 2030 deadline passes. Point-in-time compliance is compliance theater.
The Bottom Line
This is a serious executive order addressing a serious threat. The administration deserves credit for acting. The direction is right, the structure is sound, and the CBOM requirement in particular is a meaningful forcing function for organizations that have been deferring the inventory question.
The timeline may be too generous. The procurement leverage is not there yet. And the decision to treat CBOMs as a standalone mandate rather than as part of a unified SBOM requirement adds complexity to a field that is already drowning in overlapping acronyms and inconsistent enforcement.
But the core signal is correct: quantum is a big deal, cryptographic inventory is the prerequisite for everything else, and the clock is running.
