Washington just set a hard deadline for finding cryptography most agencies can't locate yet.
On June 22, 2026, the White House issued the Executive Order Securing the Nation Against Advanced Cryptographic Attacks. It directs federal agencies to migrate high value assets and high impact systems to NIST-approved post-quantum cryptography: key establishment by December 31, 2030, and digital signatures by December 31, 2031. It names a PQC migration lead in every agency, and it makes that person responsible for agency-wide cryptographic inventory management. It also directs CISA and NIST to develop the minimum elements of a cryptographic bill of materials (CBOM) within 270 days.
These requirements take seriously the threat of adversaries harvesting encrypted data now to decrypt it later, once large-scale quantum computers exist, a Harvest Now, Decrypt Later (HNDL) strategy. And they recognize something most coverage of the order glosses over: a migration deadline means nothing until you know which systems are actually running quantum-vulnerable cryptography. The order goes beyond implying that; it assigns someone to own it.
But there is a gap between what the order sets in motion and what most agencies, and the scanning tools they rely on, can currently deliver. To migrate cryptography by 2030, you first have to find it. And finding it is the part almost no one is set up to do.
First you have to find the cryptography
The order's deadlines all rest on a single prerequisite, and the order knows it. Section 2 defines the PQC migration lead as the person responsible for cryptographic inventory management. Section 4 requires each agency to review its inventory of high value assets and high impact systems before it can submit a migration plan. The cryptographic bill of materials in Section 5 and the procurement rules in Section 6 don't work without that inventory either. Everything the order asks for traces back to one question: What cryptography is actually in the software we run?
That question is exactly what traditional approaches can't answer. Cryptographic libraries, certificates, embedded keys, and the algorithms protecting data in transit and at rest are compiled into the firmware, operating systems, containers, and applications agencies deploy. Much of it was built in by a third party and never written down anywhere an agency can see. A documentation review, a source scan, or a vendor questionnaire only tells you what someone meant to ship, not what's actually running once everything is compiled together.
You can't migrate cryptography you haven't found. You can't build a cryptographic bill of materials from a manifest that never listed the cryptography to begin with.
This is where the order's hardest requirements live. Section 5(d) directs CISA, with NIST, to publish guidance within 270 days on the minimum elements of a cryptographic bill of materials, elements meant to enable automated assessment of the cryptographic assets used by a hardware or software element. The order stops there; it doesn't say how that inventory should be produced. But automated assessment of what's used by an element is hard to satisfy from a vendor's declaration alone.
It points toward evidence drawn from the artifact, and depends on an accurate account of what cryptography is genuinely present and running, including the expired certificates, weak keys, and legacy algorithms that ship inside vendor products without disclosure. In our own analysis of commercial firmware and appliances, we find this kind of stale, quantum-vulnerable cryptography all the time. Nobody deployed it on purpose, the vendor never documented it, and the tools agencies run today don't catch it.
The deadline you're not thinking about is the signatures one
And finding it matters for more than confidentiality. Most PQC urgency centers on confidentiality: the Harvest Now, Decrypt Later problem, where an adversary stores encrypted data today and decrypts it once quantum computers mature. The order's 2030 key-establishment deadline speaks to that. But the second deadline, PQC digital signatures by the end of 2031, addresses a threat that may matter more for operational systems, and it gets far less attention.
Call it Trust Now, Forge Later, or harvest now, forge later. The idea is that the digital signatures verifying your software updates, firmware, and certificates today become forgeable once an adversary can break the signing algorithm. And forging a signature doesn't require stealing anything first. Recovering a signing key from its public counterpart is enough to mint updates that every device still trusts. A quantum-capable adversary who can forge a vendor's code-signing key doesn't break into the network. It signs a malicious update, and every system that hasn't migrated installs it as legitimate.
That makes this an integrity problem, not a confidentiality one, and integrity is where operational technology and critical infrastructure live. A forged control command to a power grid or a forged firmware update to a medical device is a different category of consequence than a decrypted log file. For these systems, the question isn't only what cryptography protects your data. It's which keys and certificates establish trust, where they live across your fleet, and which ones rest on algorithms a quantum computer will break.
This is the part of PQC readiness that a CBOM alone won't solve. A bill of materials tells you which cryptographic elements are present. Defending against forgery means knowing your signing keys and certificates specifically: the quantum-vulnerable ones, and the expired and soon-to-expire ones. That inventory has to come from the artifact, because the keys and certificates that matter are compiled into firmware and software, not listed in a manifest. It's the same finding problem the rest of this post describes, pointed at the trust layer instead of the data layer.
Why everything depends on the cryptographic inventory
A binary-derived cryptographic inventory is where the work starts, not where it ends. Almost everything else in the order depends on getting it right first.
Start with prioritization, which the order builds in deliberately: agencies migrate high value assets and high impact systems first. Deciding which systems move first means knowing which ones carry quantum-vulnerable key establishment and digital signatures, which protect long-retention data, and which are simply running stale cryptography that should be retired regardless of the quantum timeline. That triage is impossible against an inventory that stops at the declaration layer.
Then there's the cryptographic bill of materials. A CBOM is only as trustworthy as the analysis behind it. Assemble it from vendor attestations and source repositories and it inherits every blind spot those sources already have, reproducing the exact problem the order is trying to solve. A CBOM grounded in the compiled artifact reflects the cryptography that actually executes, which is the only version a program office, an auditor, or a contracting officer can stand behind.
And then procurement, where the order gets specific in a way that matters for software. Section 6 moves toward FAR rules requiring covered contractors to comply with FIPS, including PQC-compliant algorithms, by the end of 2030. Section 6(d) goes further: it directs that contractor vulnerability disclosure programs incorporate reports of cryptographic vulnerabilities, including testing for lack of encryption and the use of non-FIPS approved algorithms. Enforcing that at intake means independently verifying what a vendor actually delivered — detecting missing encryption and unapproved algorithms in the shipped software, not reading what the vendor claimed. All of it traces back to the inventory. If that inventory is wrong, the migration plan goes after the wrong systems, the CBOM is built on bad data, and procurement has nothing solid to hold contractors to.
Seeing the cryptography that's actually running — NetRise Turbine®
NetRise Turbine analyzes compiled artifacts across firmware, containers, kernels, operating systems, applications, and embedded systems, with no agents, no source code, and no vendor cooperation required. It identifies the cryptography present in the artifact and maps it to the assets carrying it: certificates, public and private keys, and the algorithms protecting data, classified so teams can separate classical quantum-vulnerable cryptography from quantum-resistant PQC and flag the systems in scope for migration first.
Turbine also surfaces the conditions Section 6(d) points to — missing encryption, non-FIPS algorithms, weak or exposed keys, and expired or soon-to-expire certificates. These are the stale artifacts that signal no one has been looking, and that often become an attacker's path long before any quantum computer exists. Those same certificates and signing keys are what the forge-later threat targets, so the inventory that flags a soon-to-expire certificate also tells you which signing keys rest on algorithms a quantum computer will break.
Because each finding links back to the asset it came from, with remediation status and analyst notes preserved, a cryptographic inventory becomes something a team can put on a Plan of Action and Milestones and report against cycle after cycle.
And Turbine produces a CBOM export aligned to CycloneDX 1.6 — a machine-readable inventory of cryptographic elements with algorithm identifiers and key sizes. The cryptographic bill of materials CISA and NIST will develop is still 270 days out, but agencies that begin from a binary-derived CBOM today get a head start on exactly the artifact the order is describing.
What this means beyond the federal government
The order's obligations fall on federal agencies. Critical infrastructure owners and operators are beneficiaries here, not mandated parties — the order directs Sector Risk Management Agencies and CISA to assist them with migration planning, not to require it. But the operational reality the order exposes is universal. Any organization sitting on long-retention sensitive data faces the same exposure to adversaries who collect now and decrypt later, and financial services and healthcare organizations holding PII and protected health information have their own reasons to start now. The starting point is identical: a cryptographic inventory derived from the artifact, not the declaration.
The right deadline needs the right foundation
The White House got the framing right. Quantum-vulnerable cryptography is embedded in compiled software, in vendor products shipped without disclosure, and in certificates and keys no one has looked at in years. The order sets the deadline. It can't hand agencies the inventory they'll need to hit it — that has to come out of the software itself. For a program still built on vendor attestations and source-level intent, this order is the reason to rebuild on a foundation that can carry the weight of a 2030 migration.
NetRise analyzes compiled software artifacts across firmware, containers, applications, and embedded systems: finding the cryptography scanners miss, classifying what's quantum-vulnerable, producing a CycloneDX CBOM teams can report against.
