For most of the last decade, post-quantum cryptography lived in a particular kind of conversation. It came up at security conferences. It appeared in NIST press releases. CISOs nodded politely when it surfaced in briefings, filed it under “things to deal with eventually,” and moved on to the quarter’s actual fires.
That conversation is over. It ended this week.
In the span of a few days, five separate signals landed. Each on its own is significant. Together, they are impossible to ignore. Western Digital announced PQC support in its product line. CNN ran a primetime segment on the quantum threat. The U.S. government committed roughly two billion dollars toward quantum computing initiatives.
Reports surfaced of an executive order accelerating federal PQC adoption. And Apple publicly endorsed ML-KEM and ML-DSA, the NIST-finalized post-quantum algorithms, for protecting iMessage.
Pick any one of those in isolation, and it’s notable. Stack them on the same week, and they’re a pattern. The companies, governments, and infrastructure providers who actually run the world’s encryption are not waiting anymore. They are building, shipping, and deploying.
The question for everyone reading this is no longer whether post-quantum cryptography matters. It’s whether your organization is moving with the industry or quietly drifting behind it.
The two threats that don’t need a quantum computer
The most expensive misconception in PQC strategy is the assumption that nothing bad happens until a cryptographically relevant quantum computer exists. That framing makes the threat feel distant, which makes it easy to defer, which is exactly why so many programs are still in planning instead of execution.
Two threats are already active today, and neither one requires a working quantum computer to do damage.
The first is Harvest Now, Decrypt Later, or HNDL. Adversaries, nation-states in particular, are intercepting and storing encrypted traffic right now. They don’t need to read it today. They need to read it in 2030, or 2035, or whenever a sufficiently powerful quantum computer comes online. Storage is cheap. Patience is free.
The encryption protecting your VPN traffic, your TLS-secured APIs, and your long-lived sensitive communications becomes retroactively breakable the moment that hardware exists. For any data that needs to stay confidential for ten years or more (healthcare records, financial archives, intellectual property, government communications), the exposure window has already opened.
The second is Trust Now, Forge Later, or TNFL. This is the integrity side of the same problem. Digital signatures that establish trust today, including root CA keys, code-signing keys, firmware signatures, and certificate hierarchies, can be forged retroactively once quantum capability arrives.
The thing being attacked isn’t confidentiality. Its authenticity. Software supply chains, identity systems, secure boot, legal signatures, all of it depends on signatures whose security assumptions are quietly aging.
Neither threat is theoretical. Both are operational right now. And both are why the organizations leading on PQC are not waiting for hardware to exist before they act.
The visibility problem nobody is talking about
Here is the part that doesn’t make it into the headlines.
When organizations finally do start their PQC programs, they almost always run into the same wall. Not algorithm selection. Not vendor support. Not budget. The wall is visible.
Cryptography in a modern enterprise lives in six places at once, and most of them are not on anyone’s map. There is the application layer, where legacy systems hardcode RSA and ECC implementations that nobody on the current team built. There is the infrastructure layer (load balancers, VPN gateways, SSH endpoints), where deprecated cipher suites and long-lived keys often have no documented owner.
There is cloud and SaaS, where the cryptographic boundary frequently lives outside the customer’s direct control. There is OT and IoT, where firmware-level cryptography can be operational for fifteen or twenty years without ever being upgraded.
There is the PKI layer, where root and issuing CAs anchor trust for the entire organization. And there is the third-party and supply-chain layer, where vendors choose algorithms on your behalf and rarely tell you what they picked.
When you actually run discovery against an enterprise environment, the findings are almost always the same. RSA-1024 running in production on services nobody maintains. Certificates with ten-year validity periods were issued before the current governance existed. Cryptographic keys hardcoded into application configs and CI/CD pipelines, with no rotation history and no dependency map. Third-party integrations using algorithms that the security team has no contractual right to audit.
You cannot migrate cryptography you cannot see. You cannot prioritize what you have not inventoried. And you cannot defend a posture you cannot describe to your board.
The sequence that actually works
The most consistent pattern across industries and organization sizes is that PQC programs fail in roughly the same way. They start with algorithm selection. They pick a pilot system. They get a small proof of concept working. And then they hit the wall of trying to scale that pilot across thousands of systems, they don’t have a complete inventory of.
The sequence that works runs in the opposite direction.
It starts with a Cryptography Bill of Materials, or CBOM. This is a live, continuously updated inventory of every cryptographic asset across the enterprise: algorithms, key lengths, certificates, libraries, protocols, ownership, business criticality. Not a one-time spreadsheet that goes stale within weeks. Operational infrastructure that stays current as your environment changes.
With a CBOM in place, the second phase becomes possible: crypto-agility. This is the architectural property that lets you swap algorithms without rebuilding systems, deploy hybrid classical-plus-PQC key exchange without breaking compatibility, automate certificate lifecycle operations at enterprise scale, and migrate in phases instead of all at once. Crypto-agility does not replace your infrastructure. It is a capability layered on top of it.
Once both are in place, the third phase, prioritization, becomes a rational exercise instead of a guessing game. Score every asset on three axes: algorithm vulnerability, data longevity, and business criticality. The intersection tells you what migrates immediately, what migrates in the next twelve to eighteen months, and what stays under continuous monitoring.
Skip the inventory step, and everything downstream becomes guesswork. You make architectural decisions on incomplete information. You execute migration waves and discover dependencies mid-deployment. You spend resources on the wrong assets in the wrong order. The sequence is non-negotiable: inventory first, then agility, then prioritization.
Why this matters now, specifically
NIST finalized the first three PQC standards in August 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). That moment changed PQC from research to deployable engineering. Within months, organizations like Cloudflare, Google, Apple, Akamai, AWS, and Microsoft began shipping production deployments.
Chrome made ML-KEM the default key exchange. Apple’s PQ3 protocol moved iMessage to hybrid ML-KEM ratcheting. Google set an internal target to complete its PQC migration by 2029. Cloudflare reports that over half of human internet traffic now runs through post-quantum key agreement.
Behind those deployments, the regulatory floor is rising. CNSA 2.0 enforces PQC signing requirements for new National Security Systems acquisitions starting in 2027. NIST has signalled the deprecation of RSA and ECC after 2030.
The September 2026 transition of legacy FIPS 140-2 validations to the historical list creates a convergence point: organizations modernizing to FIPS 140-3 are doing it under the same engineering load as the PQC migration itself.
What this means in practice: organizations that started foundational work (the CBOM, the vendor conversations, the hardware assessments) in 2024 and 2025 are now executing migrations. Organizations starting that work today are still on the bridge. Both can get to the other side. The runway is different.
What the visibility layer actually looks like
This is where CBOM Secure fits into the conversation. It is the cryptographic posture management platform Encryption Consulting built specifically for this problem: the visibility gap that sits underneath every PQC program, every compliance audit, and every certificate lifecycle automation initiative.
The platform runs nineteen production discovery sensors across the layers where cryptography actually lives. Cloud KMS (AWS, Azure, GCP). HSM APIs including Entrust nCipher, Thales Luna, IBM 4767/4768/4769, Yubico YubiHSM 2, and Fortanix DSM. KMIP servers, versions 1.0 through 2.1. Database TDE. Source code across seven languages.
OS trust stores. Active Directory, LDAP, HashiCorp Vault, and the major filesystem formats. Everything normalizes into a single CBOM-compliant inventory exported in CycloneDX format. Every asset gets a risk score. Quantum-vulnerable cryptography is flagged automatically. Audit evidence for NIST SP 800-131A, FIPS 140-3, CNSA 2.0, CMMC 2.0, PCI DSS 4.0, and FedRAMP comes out of the same dataset, on demand.
The pattern most organizations adopt: start with the CBOM, because without visibility, everything downstream is guesswork, and build from what the inventory reveals. The certificate automation, the PQC migration planning, and the compliance reporting all run off the same source of truth.
What path is your organization on?
This is the question worth taking back to your team this week.
The headlines aren’t going to slow down. Western Digital, CNN, the U.S. government, the executive branch, and Apple. That was one week. There will be another week like it, and another after that. Every one of those announcements compresses the timeline for organizations that haven’t started, and widens the gap for organizations that have.
There are roughly three paths from here. The first is to start the foundational work now. Build the CBOM. Identify the assets with the longest lead times. Begin the hybrid deployment conversations with vendors. Treat crypto-agility as an operating model rather than a project.
The second is to wait one more quarter, one more budget cycle, one more strategic planning meeting, and start the same work later under more pressure. The third is to do nothing and discover, somewhere around 2028 or 2029, that the migration window has narrowed faster than the program can execute.
Organizations on path one are building cryptographic agility by the way they push configuration updates. Organizations on path two are still buying themselves time. Organizations on path three are building a gap that compounds every quarter.
The technology is ready. The standards are finalized. The deployments are happening at scale, in production, this week.
What path is your organization on?
Encryption Consulting builds CBOM Secure, the cryptographic posture management platform behind the inventory layer described in this article. To see how a continuously updated CBOM maps against your environment, visit www.encryptionconsulting.com or reach out at info@encryptionconsulting.com.
