NIST finalised its first post-quantum algorithm standards on 13 August 2024 . FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The algorithm selection phase of the post-quantum transition is, for practical purposes, settled. The question for most enterprise security teams is now structural: how do you build a programme that covers a distributed cryptographic estate without breaking what is already running?
Most organisations that describe themselves as "working on PQC" have attended a vendor briefing, stood up a proof-of-concept TLS endpoint, and perhaps completed a workshop. That is awareness. It is not a programme. A programme requires a scoped inventory, a risk-based migration roadmap, a governance model with named owners, and a sequenced execution plan. This article gives you that structure.
Before the programme scope can be set, the urgency context matters. QSECDEF's Post-Quantum Risk Assessment produces a directional score across five exposure factors: sector, data longevity, sensitivity, regulatory obligation, and legacy complexity. It does not replace the inventory . but it establishes the prioritisation argument that gets the programme funded.
Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.
Start With the Inventory, Not the Algorithm
Every vendor in this space opens the conversation with algorithm selection. That is understandable . algorithm selection is the part they have a product for. It is also the wrong starting point for a migration programme.
Without a cryptographic inventory, you do not know which algorithms are in use, on which systems, protecting which data. You cannot build a risk-prioritised roadmap for systems you have not catalogued. You cannot assess vendor readiness against requirements you have not defined. Algorithm selection without inventory produces a technically correct answer to the wrong question.
NIST IR 8547 (Initial Public Draft, November 2024) and NIST SP 1800-38A (NCCoE PQC Migration Project, 2024) are both explicit on this point: the cryptographic inventory is the mandatory prerequisite for every subsequent phase of migration. See our detailed treatment of the cryptographic inventory process for the full rationale and methodology. What follows here is the programme dimension: how to scope it, how long it takes, and what it produces.
The four discovery layers
Cryptographic discovery must operate at four distinct layers. Each requires different tooling and different organisational access.
Network layer. TLS/HTTPS traffic inspection, certificate transparency log scanning, and SSH banner analysis. This is the most accessible layer . automated scanning tools can cover most of it within days. Do not mistake completeness here for programme completeness.
PKI layer. Certificate management systems, intermediate CAs, root CAs, and code-signing certificates. The critical distinction here is validity period. Short-lived TLS certificates auto-rotate; long-lived certificates . intermediate CAs and root CAs may carry five-to-fifteen-year validity periods . require explicit inventory. They will not surface in a scan designed for short-lived certificate rotation.
Application layer. Database-level encryption (TDE), API signing workflows, JWT signatures, S/MIME and PGP email infrastructure, HSM-managed keys. This layer requires code analysis, vendor attestation, or application-layer scanning. It is where most organisations underestimate the scope of their estate. In every programme I have worked on, the application layer surfaces a larger inventory than the initial network scan suggested.
OT/ICS layer. Operational technology environments require a separate discovery workstream. Standard IT scanning tools cannot safely interrogate live ICS/SCADA environments. NIST SP 800-82 Rev. 3 (2023) defines the safe boundary for OT assessment. Vendor coordination is typically necessary. This layer extends timelines significantly . factor it into programme scope from the outset.
What the inventory produces: the CBOM
The structured output of a cryptographic inventory is a Cryptographic Bill of Materials (CBOM) . modelled on the Software Bill of Materials (SBOM) concept and based on extensions to the CycloneDX schema. A CBOM records each cryptographic algorithm in use, the system or component that runs it, the associated key material and certificate, and the data asset or process it protects. NIST and CISA both reference CBOM in recent guidance as the emerging standard for managing cryptographic inventories.
Realistic timelines: a complete first pass of a complex enterprise estate typically takes six to eighteen months, depending on organisational size, estate complexity, OT scope, vendor cooperation timelines, and internal resource availability. This is not an estimate designed to alarm . it is the documented range from NIST NCCoE pilot programme observations and from the CISA/NSA/NIST joint advisory on quantum readiness (August 2023). For organisations targeting priority system migration by the 2030 deadline established in NSM-10 (May 2022) and referenced in NIST IR 8547, an inventory that begins in 2028 leaves no programme margin. None.
Phase 2: Risk Prioritisation and the Migration Roadmap
The inventory tells you what you have. The Mosca inequality tells you what migrates first.
Dr Michele Mosca's framework (IEEE Security and Privacy, 2018) is the right analytical tool here: an asset requires migration before Q-Day . the arrival of a cryptographically relevant quantum computer (CRQC) capable of running Shor's algorithm against RSA-2048 . if its confidentiality requirement (Y, years) plus the migration time required (X, years) exceeds the expected CRQC arrival window (Z, years). Apply this calculation to your CBOM and it produces a natural priority structure.
Tier 1 . immediate action. Data with secrecy requirements of ten or more years: medical records, financial records, legal privilege material, national security communications. The HNDL threat . Harvest Now, Decrypt Later . means this data is already at exposure risk regardless of when a CRQC arrives. Adversaries collecting encrypted traffic today are banking it for decryption once the hardware exists. Migration start date does not retroactively protect data already captured. This is the most urgent tier because the window has already opened.
Tier 2 . near-term action. PKI trust infrastructure, CA hierarchies, and long-lived certificates. These require long lead times to replace because of certificate chain dependencies. A root CA that needs to migrate to ML-DSA (FIPS 204) requires a carefully sequenced re-issuance programme before the legacy CA can be retired. Start later than necessary and you will be managing parallel CA hierarchies under time pressure.
Tier 3 . planned action. Session encryption (TLS, SSH, IPsec) on standard enterprise workloads with shorter data longevity. Important, but sequenced after Tier 1 and 2 work.
NIST IR 8547 provides the federal transition taxonomy that maps onto this tiering: algorithms categorised as "Acceptable," "Deprecated after 2030" (new system use to cease; legacy use permissible under conditions) and "Disallowed after 2035" (full prohibition). Map each CBOM entry against this taxonomy. Deprecated algorithms currently in use are the primary migration targets. Any system running a "Disallowed" algorithm is already in remediation territory.
Once the inventory is complete and risk tiers are established, the sequencing question is which system migrates first. The PQC Migration Decision Tree routes CBOM output through the key sequencing variables . data longevity, regulatory obligation, system criticality, and migration complexity . and returns a recommended starting workload.
Three parallel work tracks, not one
The migration roadmap should separate three work tracks that run in parallel rather than sequentially. Treating them as a single track creates artificial sequencing constraints that slow every phase.
Track A is the cryptographic algorithm migration track: replacing RSA and ECC with ML-KEM, ML-DSA, and SLH-DSA across protocol stacks and applications. Track B is the PKI and certificate management track: issuing new post-quantum certificates, updating CA hierarchies, managing certificate validity periods. Track C is the vendor and procurement track: assessing whether current vendor products support post-quantum migration on timelines that match your programme, and managing contracts accordingly. These three tracks have dependencies between them, but they are not sequential. Running them in parallel is the difference between a three-year programme and a five-year programme.
Phase 3: Algorithm Selection and the Hybrid Approach
NIST FIPS 203, 204, and 205 are the standardised algorithm suite. For enterprise migration, the decision framework is straightforward:
- Key exchange: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) . previously known as Kyber during the NIST competition. ML-KEM-768 is the standard enterprise starting point; ML-KEM-1024 for CNSA 2.0-compliant national security applications per NSA's Commercial National Security Algorithm Suite 2.0 (September 2022).
- Digital signatures (general use): ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) . previously known as Dilithium. ML-DSA-65 for general enterprise; ML-DSA-87 for CNSA 2.0 requirements.
- Digital signatures (long-term anchors and algorithm diversity): SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) as a secondary signature algorithm for root CAs and long-term archive signing. Hash-based security provides algorithm diversity from the lattice-based ML-KEM and ML-DSA . relevant for organisations managing tail risk on lattice cryptography.
For parameter set detail and byte sizes, the NIST FIPS 203/204/205 article linked above covers this specifically. Do not reproduce that detail here . cross-reference it.
The hybrid transition mechanism
Hybrid classical/post-quantum schemes are the recommended transition mechanism. A hybrid scheme runs a classical algorithm . ECDH-P256, for example . and a post-quantum algorithm (ML-KEM-768) in parallel, combining their outputs to establish a shared key. Security is guaranteed as long as either component remains unbroken. Before Q-Day, the scheme is at least as secure as the classical component alone. After Q-Day, at least as secure as the post-quantum component alone. NIST, ETSI (TS 103 744 V1.1.1, 2020), and the IETF (draft-ietf-tls-hybrid-design, 2024) all recommend hybrid approaches for the transition period.
One clarification that matters for programme planning: hybrid is a transition mechanism, not a resting state. The classical ECDH or RSA component in a hybrid scheme still requires eventual replacement. Deploying hybrid schemes without a migration roadmap for the classical component creates a false sense of completion. The programme is not finished when hybrid is deployed . it is started.
The performance overhead is manageable but worth accounting for. A hybrid TLS 1.3 handshake with ML-KEM-768 combined with X25519 carries larger key shares than a classical X25519 handshake. In practice, TLS handshake overhead is tolerable on modern infrastructure. The more significant constraint is PKI certificate chain sizes when ML-DSA signatures replace ECDSA signatures in certificate hierarchies . something to test explicitly in the hybrid scheme design phase.
Phase 4: Governance . Who Owns This Programme
The most common reason PQC migration programmes stall is not technical. It is ownership. PQC migration is not an infrastructure project that the network team runs. It crosses cryptographic engineering, PKI management, application development, vendor management, and executive governance. Without explicit ownership at each boundary, territory disputes will consume the programme.
NIST SP 1800-38A recommends that organisations establish a dedicated cryptographic migration steering committee with cross-functional representation. The CISO or delegate serves as programme sponsor. The committee includes: cryptographic engineering lead, PKI and certificate management, application security, procurement and vendor management, and compliance and regulatory mapping. Without this committee, inventory work stalls when it crosses team boundaries, migration tracks diverge, and vendor assessments are duplicated . I have watched this happen in enough programmes to say with confidence it is the single most common failure mode beyond the inventory phase.
The vendor lock-in risk
Vendor lock-in is a governance risk specific to PQC migration and tends to be underweighted in early programme planning. Organisations that migrate to a post-quantum algorithm implemented only by a single vendor . or that rely on a vendor's proprietary hybrid scheme rather than the IETF and ETSI standards . create a dependency that will impede future migration when standards evolve.
The vendor assessment should explicitly cover: which FIPS 203/204/205 algorithms are supported; which interoperability standards are implemented (IETF hybrid drafts, ETSI TS 103 744); and the vendor's published update timeline for post-quantum support. A vendor that supports ML-KEM-768 via its own proprietary hybrid construction, without IETF-specified hybrid KEM compliance, is selling lock-in alongside the algorithm.
The PQC Readiness Checklist provides a 40-point assessment mapping directly to the five migration phases . inventory completeness, governance structure, vendor assessment status, regulatory mapping, and migration planning. It is designed for regular programme status reviews as the migration progresses, not as a substitute for programme execution.
Phase 5: Timeline . What Realistic Looks Like
The following timeline is a planning reference for a complex enterprise estate, not a contractual commitment. Simpler estates move faster. OT-heavy estates move slower. The point is not the specific months . it is the scale. A programme that begins in 2028 and expects to complete Tier 1 migration by 2030 has not done the arithmetic.
- Months 0–3: Steering committee formation, scope definition, tooling procurement for cryptographic discovery.
- Months 3–12: Cryptographic inventory, first pass. OT environments run as a separate track.
- Months 9–18: Risk prioritisation, CBOM production, Tier 1/2/3 migration sequencing. Overlap with inventory is intentional . do not wait for full inventory completion before starting prioritisation.
- Months 12–24: Algorithm selection confirmed, hybrid scheme design and testing for priority workloads, vendor roadmap assessments complete.
- Months 18–36: Migration execution for Tier 1 workloads . long-lived data systems and PKI anchors.
- Year 3 and beyond: Tier 2 and Tier 3 migration, certificate rotation, continuous monitoring.
The regulatory clock is set. NSM-10 (The White House, May 2022) established federal transition targets for priority systems by 2030. NCSC guidance (2024) sets comparable urgency for UK organisations. The question is not whether to start . it is whether the programme start date leaves enough margin to reach the transition deadline.
What to communicate upward
Board communication for PQC migration needs to address four questions clearly. First: what are we protecting, and for how long? Second: what is the HNDL exposure . are adversaries already collecting our encrypted data? The evidence base for that question lives in the HNDL in Motion article; the answer, for most organisations holding long-lived sensitive data, is that the collection phase has already started. Third: what does the regulatory compliance obligation require, by when? Fourth: what does the programme cost, and what is the cost of delay?
That last question has a specific answer most boards do not expect. The cost of delay is not zero . it compounds. A migration programme that begins in 2024 has twelve to eighteen months of inventory time before the 2030 deadline becomes a real constraint. The same programme begun in 2027 is already in crisis management mode. The programme cost is fixed. The delay penalty is not.
Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.
