July 31, 2026
Mandated Is Not Verified
The federal government just put hard dates on the end of public-key cryptography. Meeting them will not make the supply chain trustworthy.

By KALEO-AZRAEL LANE
11 min read
The federal government just put hard dates on the end of public-key cryptography. Meeting them will not make the supply chain trustworthy.
Somewhere right now, an adversary is copying encrypted defense traffic it cannot read.
That is not speculation and it is not new. The strategy is called harvest now, decrypt later, and it works on simple arithmetic: a great deal of the data moving through the defense industrial base stays sensitive for 20 years, and the encryption protecting it has a shorter shelf life than that. You do not need a quantum computer today. You need storage today and a quantum computer eventually.
The government's answer has been in motion since 2022, and in June 2026 it stopped being guidance.
What actually changed
Executive Order 14412 put dated obligations on federal agencies: post-quantum key establishment by the end of 2030, post-quantum signatures by the end of 2031. More consequentially for anyone with a contract, it directed the Federal Acquisition Regulatory Council to publish a proposed rule within 180 days requiring covered contractors to comply with NIST cryptographic standards, including the post-quantum ones, by December 31, 2030. A second rule, due within 270 days, would require vulnerability disclosure policies that explicitly cover cryptographic vulnerabilities, including the use of algorithms that are not FIPS approved.
One day later, the Department of War published its Post Quantum Cryptography Strategy. Departmental systems support post-quantum cryptography by the end of 2030 and use it by the end of 2031. It commits to ensuring the defense industrial base migrates across the enterprise, and it states that the Cybersecurity Maturity Model Certification program will be updated with post-quantum requirements.
Read those together and the mechanism has changed. For 4 years, the reach into the supply chain ran through interpretation of contract language. It now runs through acquisition regulation, on a published schedule, backed by a certification program that became enforceable in November 2025.
So the deadlines are real. The work is necessary. Everybody should do it.
And when it is finished, the supply chain still will not be trustworthy. Here is why.
Everyone clears the same floor
Every organization subject to this will implement the same 2 or 3 primitives, on the same schedule, to the same parameter sets. Nobody will be differentiated by having done it, because differentiation requires that some parties do something others did not.
That is fine. Floors are supposed to work that way. The problem is that a floor is being discussed as though it were a destination.
Not broken. Unproven. The difference matters.
ML-KEM and ML-DSA rest on lattice hardness assumptions. No proof exists that those assumptions hold, against a quantum adversary or a classical one. Their security is a reduction to a problem believed to be hard, and the belief rests on the absence of a published break rather than the presence of a proof.
That is a normal condition in cryptography and it is not by itself an indictment. It becomes one when the belief is treated as settled fact and then made the only load-bearing element of national infrastructure on a fixed timetable.
There is a meaningful difference between this has been proven secure and nobody has told us otherwise yet. The mandate is built on the second and is being communicated as though it were the first.
We have already watched what that costs, inside this same standardization process.
Rainbow, a multivariate signature scheme, reached the third round of the NIST competition as a finalist and was broken in February 2022 after years of confident security claims. Six months later, SIKE, which had survived 3 rounds of scrutiny and advanced to the fourth, was broken by Wouter Castryck and Thomas Decru. The attack recovered the secret key at NIST security level 1 in roughly 62 minutes, on a single core of a processor released in 2013, using a mathematical theorem published in 1997. NIST posted a note on the submission page stating plainly that SIKE and SIDH are insecure and should not be used.
The usual response is that the process worked, because both breaks came before deployment. That is true and it is the wrong lesson. What the record actually shows is that multi-year review by the international cryptographic community can certify, to the threshold of late-round finalist, constructions that one researcher then dismantles on a decade-old desktop in about an hour. The process caught those two. Nothing in it guarantees the next one.
Then there is the monoculture. The transition does not merely publish the algorithms. It compels the entire national security inventory, every prime, every subcontractor, every supplier, onto the same narrow set of primitives, converging in 2033. After that, a single mathematical discovery is no longer a local failure at one vendor. It is a simultaneous systemic failure across the whole defense industrial base, arrived at deliberately, on a published timetable, with no diversity left to limit the blast radius.
The standards bodies know this. CNSA 2.0 includes SLH-DSA, a hash-based signature scheme resting on entirely different mathematics, recommended for diversity in high-assurance environments. That is a backup, installed by the same authority that wrote the mandate, against the specific possibility that the primary bet does not hold.
No accusation required. The seatbelt is in the car. The question is what the people who installed it were expecting.
Here is the shortest version of the whole argument: the transition retires algorithms with a known failure mode and a datable expiration, and replaces them with algorithms whose failure mode is unknown and whose expiration cannot be read. It does not remove the expiration date. It removes our ability to see it.
AES-256 will survive, and it will not save you
AES-256 is sound. It has no practical break, it is correctly retained in CNSA 2.0, and symmetric constructions at that key length hold up against quantum attack because the available speedup is quadratic rather than exponential. I am not going to argue otherwise, and anyone who does should be ignored.
That is exactly the point worth sitting with.
AES-256's security is entirely contingent on the key it is handed. That key has to be established, and key establishment is the quantum-vulnerable layer. It is the entire reason ML-KEM exists. Which means the strongest algorithm in the mandated suite is protected by the weakest link in it, and an adversary who defeats key establishment never touches AES at all. They are handed the key.
The same contingency runs through implementation. KyberSlash1 and KyberSlash2 were timing vulnerabilities found in several ML-KEM implementations, including the official reference code, exploiting secret-dependent division timings. Demonstrated on a Raspberry Pi 2 and an Arm Cortex-M4, they recovered secret keys within minutes for one variant and a few hours for the other. A separate proof of concept pulled a full ML-KEM 512 secret key from decapsulation timing in 5 to 10 minutes on a commodity Intel processor. Follow-on work showed that patching the timing leak can push the leakage into power consumption instead. One of the teams that found this class of defect independently noted that any implementation directly encoding the pseudocode as published is likely to be insecure, and remarked on how many expert developers fell into it.
Read that sequence again. The algorithm was standardized. The reference implementation leaked keys. Expert teams building from the specification reproduced the defect. The patch relocated the leak. And the deployment schedule did not move.
Ciphers are not what fails. Keys are what get taken.
The gap nobody has an instrument for
Every one of these federal instruments measures the same thing: which algorithms you have, and when you will replace them. That measurement is necessary and it is entirely internal.
The defense industrial base is not an internal system. It is a hierarchy of organizations that cannot inspect one another.
Three things get conflated constantly, and separating them is most of the problem.
Attestation is a claim a party makes about itself. It is a promise, and its weight is exactly the credibility of whoever made it.
Assessment is a periodic third-party examination. Stronger, and sampled and dated. It establishes that a condition held during a window. It says nothing about any particular day afterward and nothing at all about any particular transaction.
Evidence is an artifact tied to a specific event, which the recipient can check independently, without trusting the party that produced it.
The federal regime now demands the third and is equipped to collect the first two. Nothing in CNSA 2.0, in the executive order, in the CMMC model, or in any DFARS clause produces a per-transaction artifact at a boundary between 2 organizations.
Consider what a prime contractor actually holds today when it certifies the cryptographic integrity of its supply chain.
It holds a questionnaire. The questionnaire was completed by someone at the subcontractor who was asked to describe a system they may not administer, against a standard they were not given time to read, and returned by a deadline that had nothing to do with when the answer became true. That document is then filed as evidence of supply chain cryptographic governance.
It is not evidence. It is a record that a question was asked.
That is not a criticism of the people filling out the forms. It is a description of the only instrument anyone gave them.
Agility is not the answer either, and I say that as someone who thinks you should build it
The prevailing response to unproven primitives is crypto-agility: architect so algorithms can be swapped without redesign. This is correct doctrine. Given everything above, an organization that cannot change algorithms is betting everything on an assumption it cannot evaluate. Build the agility.
It is still insufficient, for reasons that are structural rather than fixable.
Agility converts your cryptographic posture into a subscription with no terminal date, where security becomes a function of patch cadence. Every organization in the chain has to sustain that indefinitely, including the ones with no security staff. The tail is not the prime. It is the 40-person machine shop with a legacy controller and one part-time sysadmin, and that shop is inside the program boundary.
Agility also creates surface. A system that can run several algorithms has to decide at runtime which one it is running, and that decision is a negotiation. The history of downgrade attacks is not a history of exotic mathematics. It is a history of implementations agreeing to something weaker than both sides could have supported.
And agility depends on supply nobody controls. Swapping in a validated module requires the module to exist. The validation queue runs 12 to 18 months from submission to certificate. You can be perfectly agile in architecture and completely unable to act.
None of that is the deepest problem. The deepest problem is that agility answers can I change this when it breaks. The boundary question is can I prove what happened here. A system can be perfectly agile and produce no evidence whatsoever.
Agility is how you survive being wrong. It is not how you demonstrate being right, and the federal regime is now asking for the second one.
Determinism is what produces evidence
There is a property class that closes this, and it is not a cryptographic primitive.
A deterministic system produces identical output from identical input, everywhere, every time, on every implementation. That sounds like an engineering convenience. It is the entire evidentiary case.
A claim about a probabilistic or environment-dependent system can only be accepted, because the recipient cannot reproduce the conditions and therefore cannot test the claim. A claim about a deterministic system can be checked. Run the same input, compare. If the results diverge, something is wrong, and the divergence is the finding. No trust in the counterparty is required for the check to mean something, which is precisely the condition at a supply chain boundary.
This is not novel. It is the basis of every serious qualification regime in aerospace and manufacturing. A component is not accepted because its manufacturer assures you of its intent. It is accepted because it produced measurable behavior against a known standard, the measurement repeats, and a second party with the same gauge gets the same number.
I came into this work from Air Force aerospace propulsion and quality engineering, and that background is the reason I find the current approach so difficult to accept. In propulsion, a part that fails intermittently is worse than one that fails every time, because a consistent failure can be characterized and designed around and an intermittent one cannot. You do not qualify a component by asserting it should work. You qualify it by measuring what it does.
We are about to run national infrastructure on primitives whose central security property has never been proven, only assumed, and we are calling that compliance.
What we built
DOR Advanced Technologies builds DORCOR 0™, a sealed deterministic cryptographic trust fabric, delivered as ANCHOR™.
The scope statement first, because it matters and because I would rather say it than have someone catch it: DORCOR 0™ is not a NIST-standardized post-quantum algorithm and is not offered as compliance with CNSA 2.0. If you are subject to those mandates, implement them on schedule. Nothing we make substitutes for that. DORCOR 0™ addresses the layer the mandates do not reach.
What it stakes is a different question than most security architecture asks. Nearly everything in service today is built to establish that something is authentic, which is a claim about origin. That was the right question while forgery was expensive. It is no longer. When content, credentials, telemetry, and sensor output can all be generated convincingly and at scale, an adversary who produces a well-formed artifact with correct provenance has satisfied every authenticity check in the chain. Authentic means genuine. Real means true. We built for the second one.
The properties follow from that.
Nothing is stored, so there is nothing to harvest. State is reproducible from a seed rather than retained: no key material at rest, no key schedule to recover, no runtime entropy source to starve or manipulate. Against harvest now, decrypt later, that is a structurally different answer than a longer key, because the adversary is collecting against a key that was never sitting anywhere.
The system is sealed, and the integrator does not need to trust its internals for the guarantee to hold. That maps exactly onto the boundary condition above: 2 organizations that do not trust each other, and will not open their systems to each other, can still establish something verifiable between them.
There is no negotiation phase, so there is no negotiation surface. Nothing decides at runtime which construction is in use, and the downgrade class has nowhere to attach.
Behavior reproduces identically across independent implementations, bit for bit, in software or in hardware. That is what makes a claim about the system checkable instead of acceptable.
Notice what that list is and is not. It is not a claim to have scored better at the same game. Every line is a class of failure that does not exist in the architecture, and no revision to a standard removes those from a key-based, negotiated, agility-dependent model, because they are what the model is made of. A standard can specify a different algorithm. It cannot specify away the requirement to hold a key.
The part where we hold ourselves to it
DORCOR 0™ has been examined on both surfaces an attacker actually has: the output it produces and the construction that produces it.
On output, it passed TestU01 BigCrush across more than 160 statistics and the full NIST SP 800–22 suite, and ran clean through a full 1 TiB PractRand evaluation across 401 tests with zero anomalies. Depth is the point. Weak constructions do not fail immediately, they fail progressively as volume grows, which is why most published claims stop where the evidence is still flattering. At 2 to the 40th bytes, structure that hides at smaller volumes has room to surface. It did not.
On construction, it has been through independent adversarial cryptanalytic review carried from black-box access through full white-box access, with all documented findings remediated and the most significant remediation measured rather than assumed. The white-box progression is what carries weight. Surviving analysis by someone who cannot see the construction is a statement about their access, not about your system.
And every result above regenerates from a documented seed and a documented fingerprint.
That last sentence is not a detail. I have spent this entire article arguing that evidence beats attestation, and that the difference is whether you can check a claim without trusting whoever made it. A reported pass is an attestation. A result that regenerates on demand for anyone who runs it is evidence. It would be incoherent to make that argument and then ask you to take our measurements on faith.
A trust technology that asks to be believed has misunderstood its own category.
Where this leaves you
The deadlines are real, they are closer than most contractors think, and the work is not optional. Do it.
Then ask the question the mandate does not: for your most critical supplier, what artifact do you currently hold that establishes their cryptographic posture, who produced it, and could you verify a single claim in it without their cooperation?
If a contracting officer asked you today how you know your program's cryptographic integrity holds end to end, what would you hand them?
Most organizations can answer that with a folder. Very few can answer it with evidence.
The full technical treatment, including the corrected CNSA 2.0 timeline by category, the June 2026 instruments, and the architecture and evidence record in detail, is in the white paper "The Verification Gap," available from DOR Advanced Technologies.
Kaleo-Azrael Lane is Founder and Principal Architect of DOR Advanced Technologies, Inc., where he built DORCOR 0™. His background is in United States Air Force aerospace propulsion and quality engineering.
doradvancedtech.com kaleoazraellane.com