The Quantum Clock Is Already Running: PQC Through a CDM Lens

Post-quantum cryptography migration is not a future problem. It became a present one in August 2024 when NIST finalized the first three post-quantum cryptography standards: FIPS 203, 204, and 205. The regulatory clock is running. The migration is long. And one category of threat doesn’t wait for quantum computers to arrive at all.

Harvest now, decrypt later (HNDL) is exactly what it sounds like. Adversaries are collecting encrypted data today, storing it, and planning to decrypt it when a cryptographically relevant quantum computer (CRQC) becomes available. Estimates on when that is range from 10 to 20+ years, but for any data with a confidentiality requirement extending that long — financial records, health data, intellectual property, long-term contracts — the exposure is current. CISA, NSA, and NIST published a joint advisory in 2022 saying so explicitly.

Migration takes 5 to 10 years in large enterprise environments when you account for legacy systems, vendor dependencies, and organizational coordination. That math is why every major Western security agency is telling organizations to start now.

Where cryptographic risk lives in the CDM

Cryptography isn’t a single-cell problem. It runs across the matrix.

Data/Protect is the most obvious cell: TLS protecting data in transit, encryption protecting data at rest. Every HTTPS connection using RSA or elliptic curve key exchange is producing ciphertext vulnerable to HNDL. This is the right place to start migration, and hybrid key exchange (classical plus post-quantum, simultaneously) is available in production TLS libraries today.

Devices/Identify and Networks/Identify are where PKI lives. Certificates establish the trustworthiness of devices and network endpoints. Those certificates are signed with RSA or ECC. A CRQC can forge those signatures, which means the entire identity layer of a Zero Trust architecture built on classical PKI becomes unreliable. Post-quantum certificates, signed with FIPS 204 (ML-DSA), are the fix. The operational challenge is scale: large PKI deployments have tens of thousands of certificates and require a new CA hierarchy.

Applications/Protect is code signing: the mechanism that verifies software is authentic before installation or execution. OS updates, firmware, application delivery — all depend on digital signatures that are currently quantum-vulnerable. This cell’s migration is externally gated on vendor and standards-body timelines.

Users/Protect is authentication. FIDO2/WebAuthn uses ECC. Smart card authentication (standard in Japanese enterprise and government environments) uses RSA or ECC. The FIDO Alliance published a PQC roadmap in 2023; hardware token vendors are working through their own timelines.

Networks/Protect is VPN key exchange. IPsec, OpenVPN, WireGuard: all use asymmetric cryptography for key negotiation. Hybrid key exchange is the near-term path here too, with full PQ key exchange following as vendor implementations mature.

The cell that’s most commonly overlooked: Data/Identify. Before you can migrate any of the above, you need to know what cryptographic dependencies you have and where they are. That’s a discovery problem. And most organizations don’t have that inventory.

The CBOM problem

A Cryptographic Bill of Materials (CBOM) is a structured inventory of all cryptographic algorithms, key sizes, protocols, and certificate dependencies across the enterprise. It’s the foundation everything else is built on. You cannot prioritize PQC migration without knowing what you’re migrating from.

Most organizations don’t have one. They have fragments: a certificate management system covering some certificates, network monitoring logging some TLS handshakes, application security tooling surfacing some library usage. Assembling those fragments into a complete picture is the first task of any serious PQC migration program.

OmniTrust ILM and CBOM-Lens

McPhail Security’s QSRP (Quantum Security Readiness Program) addresses the CDM gap most critical to PQC migration: the Identify column across all rows where cryptographic inventory lives.

CBOM-Lens performs cryptographic asset discovery through network-layer inspection and certificate inventory integration. The output is a structured CBOM mapped to the CDM’s asset classes, with risk prioritization based on data sensitivity, certificate role in the trust chain, and application criticality.

OmniTrust ILM manages what CBOM-Lens discovers. It handles certificate lifecycle across the transition period: hybrid PKI operation (classical and PQ simultaneously), migration sequencing, and ongoing certificate management as the estate moves to PQ-signed certificates. The platform is built on CZERTAINLY, an open-source PKI core, which means algorithm updates as FIPS implementations mature don’t require a platform replacement.

In CDM terms: CBOM-Lens populates the Identify column. OmniTrust ILM operates the Protect column. A third function — continuous CBOM monitoring to detect regression as the migration progresses — covers the Detect column. That’s the full left-to-right program in a single integrated engagement.

The migration sequence

The phased approach follows CDM logic:

Phase 0 (Identify): CBOM discovery. Know what you have before touching anything. Output is a prioritized migration roadmap anchored in the actual inventory, not a generic template.

Phase 1 (Protect, Data and Networks first): Hybrid TLS and VPN key exchange for highest-priority data flows. Achievable today without waiting for full PQ certificate chain support.

Phase 2 (Protect, PKI): New post-quantum root and intermediate CA hierarchy. Hybrid PKI during transition. Certificate reissuance sequenced by priority from the Phase 0 CBOM.

Phase 3 (Protect, Users): FIDO2 and smart card migration as PQ-capable implementations become available from hardware vendors.

Phase 4 (Detect): Continuous CBOM monitoring to verify migration completion and catch regression. The migration isn’t done when you’ve replaced the certificates; it’s done when you’re detecting and alerting on any reappearance of deprecated algorithms.

Each phase is designed to fit below standard Japanese enterprise procurement approval thresholds, which matters: large security program procurement cycles at Japanese financial institutions typically run 12 to 18 months. A bounded phased model that produces value at each step moves faster.

The regulatory position in APJ

NISC published quantum security guidance in 2023. MAS has flagged PQC as an emerging priority in technology risk management. APRA CPS 234’s risk-proportionate requirements encompass emerging cryptographic risks. FISC has not yet published PQC-specific guidance but the 14th edition’s cryptographic requirements establish the baseline that PQ migration will need to supersede.

The direction across all four major APJ regulatory environments is consistent: start now, document the plan, demonstrate progress. Organizations that begin structured PQC migration programs in 2025-2026 will be ahead of regulatory expectations. Organizations that wait for specific regulatory mandates will be managing crisis migration on someone else’s timeline.

The CDM doesn’t make the migration easy. Nothing does. But it makes the problem legible: specific cells, specific dependencies, specific migration sequence, specific ownership. That’s enough to start.

McPhail Security delivers PQC advisory engagements through the QSRP program, using OmniTrust ILM and CBOM-Lens as the primary delivery platform. Structured as bounded phases for APJ enterprise procurement cycles. Contact: mcphail.pro

The Cyber Defense Matrix framework was created by Sounil Yu — cyberdefensematrix.com