compliance

PQC Readiness: What It Means, How to Measure It, and Where Most Organisations Stand

Most organisations that have discussed post-quantum cryptography at the board level believe they are ahead of the curve. The available evidence suggests the opposite. A 2024 ISACA poll found that 63% of security professionals believe quantum computing will materially increase or shift cybersecurity risk, yet the same data shows that the majority of organisations have not completed even a basic cryptographic inventory.^[^ISACA^] The U.S. Office of the Comptroller of the Currency reinforced this concern in its July 2025 Semiannual Risk Perspective, explicitly advising banks to monitor quantum risks and begin building crypto-agile architectures - language that signals a shift from awareness to examiner expectation.^[^OCC^] Enterprise quantum migration typically takes three to five years end-to-end. Organisations that have not begun cryptographic discovery work are already at risk of missing mid-decade compliance thresholds - not 2033 ones.

What "PQC Readiness" Actually Means - And What It Doesn't

Readiness is not a binary state. Describing an organisation as either "quantum-ready" or "not quantum-ready" collapses a multi-year, multi-phase programme into a label that obscures the actual work remaining. True PQC readiness spans five distinct and observable stages: awareness, cryptographic inventory, risk assessment and algorithm selection, migration roadmapping, and verified deployment. An organisation that has attended a vendor briefing and produced a board slide sits at stage one. An organisation with a validated CBOM, completed risk-tiering by data sensitivity lifetime, and a funded migration roadmap sits at stage four. These are not equivalent positions, and regulators are beginning to distinguish between them.

NIST finalised three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme).^[^{NIST PQC}^] The existence of finalised standards removes the last legitimate technical justification for deferring migration planning. Algorithm selection is no longer a blocker. What remains - and what most organisations have not yet completed - is the foundational inventory and risk-prioritisation work that must precede any migration decision. Understanding how a cryptographic bill of materials enables systematic asset discovery is the necessary first step before any of the five readiness stages can be advanced.

The Regulatory Clock - Deadlines, Expectations, and What Examiners Are Starting to Ask

The regulatory landscape for PQC is no longer limited to federal agency mandates. It now spans financial services supervision, critical infrastructure guidance, and international frameworks - and the language has shifted from advisory to expectational across all of them.

NIST and Federal Migration Milestones

NIST IR 8547, currently in draft, establishes 2030 as the target date for federal agencies to deprecate RSA and elliptic curve cryptography in most contexts, with 2035 as the hard disallow date.^[^NIST^] These milestones govern federal systems directly and set the de facto benchmark against which auditors and regulators in adjacent sectors are calibrating their own expectations. The 2030 and 2035 deprecation deadlines in NIST IR 8547 are not aspirational targets - they represent the outer boundary of what NIST considers a manageable transition window for organisations that begin work immediately.

NSA CNSA 2.0

The NSA's Commercial National Security Algorithm Suite 2.0, published in October 2022, sets a 2033 adoption deadline for national security systems across software applications, networking equipment, and operating platforms.^[^{NSA CNSA 2.0}^] For defence contractors and government suppliers, CNSA 2.0 compliance is not optional - it is a condition of continued system accreditation. Given that enterprise migration takes three to five years, a 2033 deadline requires organisations subject to CNSA 2.0 to be in active migration no later than 2028-2029, which means roadmapping must be complete significantly earlier.

OCC and Financial Sector Expectations

The OCC's July 2025 Semiannual Risk Perspective explicitly identifies quantum computing as an emerging operational risk and advises supervised institutions to monitor developments, assess cryptographic dependencies, and plan for crypto-agile architecture.^[^OCC^] This is examiner-facing language. When the OCC describes a risk category in its risk perspective, examiners use that framing in subsequent supervisory cycles. Financial institutions that cannot demonstrate active monitoring and planning posture in response to this guidance face increasing examination scrutiny - not at some future date, but in the next examination cycle.

CISA and Critical Infrastructure

CISA's Post-Quantum Cryptography Initiative explicitly addresses the harvest-now-decrypt-later threat and provides sector-specific readiness resources for critical infrastructure operators.^[^CISA^] CISA guidance does not carry the force of law for private sector entities, but it informs the risk expectations of sector-specific regulators - including FERC, HHS, and the TSA - who increasingly reference CISA frameworks in their own supervisory communications.

ENISA and EU Expectations

ENISA's post-quantum cryptography guidance advises EU member states and regulated entities to begin migration planning immediately, citing the same harvest-now-decrypt-later risk vector that underpins U.S. federal guidance.^[^ENISA^] For organisations subject to NIS2 or DORA, PQC readiness intersects directly with existing cryptographic risk management obligations under those frameworks.

A Practical Readiness Maturity Model - Five Levels Every CISO Should Know

The following five-level model gives security teams a structured self-assessment scaffold. It is organised around observable, verifiable indicators - not intentions or plans that have not yet produced artefacts.

Level 1 - Unaware

The organisation has not formally assessed PQC as a risk category. No cryptographic inventory exists. No budget has been allocated. PQC has not appeared in a risk register or board report. This is not an uncommon position for mid-market enterprises and smaller regulated entities as of 2025.

Level 2 - Aware but Uninventoried

Leadership is aware that PQC represents a compliance obligation. A board presentation or internal briefing has occurred. However, no systematic cryptographic asset discovery has been completed. The organisation does not know where RSA, ECDH, or ECDSA are deployed across its estate. This is where the majority of enterprises currently sit, including a significant share of large financial institutions.

Level 3 - Inventoried and Assessed

A cryptographic bill of materials has been produced, covering at minimum the organisation's highest-risk systems - those handling data with long sensitivity lifetimes or supporting regulated functions. Each cryptographic dependency has been tiered by risk: sensitivity of data protected, exposure to harvest-now-decrypt-later risk, and remediation complexity. Algorithm selection decisions have been made against NIST FIPS 203, 204, and 205.

Level 4 - Roadmapped

A funded migration roadmap exists, prioritised by risk tier. Executive ownership has been assigned. Vendor dependencies and third-party interoperability requirements have been assessed. The roadmap has been integrated into the organisation's IT investment planning cycle. NIST's NCCoE migration guidance has been reviewed and applied where relevant.^[^{NIST NCCoE}^]

Level 5 - Migrating or Validated

Active migration is underway on at least the highest-risk systems. Hybrid cryptographic deployments - combining classical and post-quantum algorithms - are in production for sensitive communications and key exchange. Validation against FIPS 203/204/205 is in progress or complete for priority systems. Ongoing monitoring processes exist to track cryptographic posture as the estate evolves. The Trusted Computing Group predicted in November 2025 that at least one PQC algorithm would be in place across a meaningful share of enterprises by end-2026 - Level 5 organisations are those positioned to meet that benchmark.^[^TCG^]

Where Most Organisations Actually Stand Right Now

The honest picture is that most organisations remain at Level 1 or Level 2. An ISACA poll found 62% of security professionals are concerned that quantum computing will break current encryption before PQC is fully implemented - a concern that implies awareness without action, which is the defining characteristic of Level 2.^[^ISACA^] The same data set shows the executive-resource disconnect that underlies this stagnation: over 50% of surveyed organisations cite lack of executive support as a primary barrier to PQC readiness, even among organisations whose security teams understand the urgency.^[^ISACA^]

Sector-level variation is real but should not be overstated. Financial institutions subject to OCC oversight are, on average, more advanced than mid-market enterprises - but "more advanced" in this context often means "has a project charter" rather than "has completed inventory." Healthcare organisations face particular exposure because of the long sensitivity lifetime of patient records; PHI protected today under AES-256 key exchange using RSA-2048 remains vulnerable to harvest-now-decrypt-later attacks if the RSA layer is compromised before migration is complete. Critical infrastructure operators - energy, water, transport - remain predominantly at Level 1 or 2, with some sectors only beginning to receive explicit regulatory signals from their sector-specific authorities.

For organisations whose data carries sensitivity lifetimes extending beyond five years, the threat window is not a future consideration. The harvest-now-decrypt-later exposure is active today, and every month of delay on cryptographic inventory represents an irreversible expansion of the data set at risk. This is particularly acute for financial records, legal communications, health data, and intellectual property - precisely the categories that attract the most aggressive adversarial collection activity.

The Four Barriers Blocking Progress - And How Leading Teams Are Clearing Them

Barrier 1: Lack of Executive Support

Over 50% of organisations identify executive support as a primary barrier.^[^ISACA^] The most effective framing for closing this gap is regulatory consequence, not technical threat. Executives respond to examiner expectations and compliance deadlines more reliably than to abstract risk narratives. The OCC's July 2025 language on crypto-agile architecture, CNSA 2.0's 2033 hard deadline for national security systems, and NIST IR 8547's 2030 deprecation milestone all provide the concrete regulatory anchors that convert security team concern into budget conversations. Security architects broadly recommend leading executive briefings with the regulatory timeline rather than the technical threat model - this is the approach most consistently reported to produce resource allocation decisions.

Barrier 2: Absence of Cryptographic Inventory Tooling

Many organisations lack tooling capable of producing a comprehensive cryptographic bill of materials across heterogeneous environments - on-premises infrastructure, cloud workloads, third-party integrations, and embedded systems. NIST's NCCoE Migration to Post-Quantum Cryptography project provides practical guidance on crypto-agility frameworks and discovery approaches that do not require full commercial tooling investment at the outset.^[^{NIST NCCoE}^] Leading teams begin with manual or semi-automated inventory of the highest-risk asset classes - TLS termination points, PKI infrastructure, data-at-rest encryption for long-lifetime records - rather than waiting for a complete tooling solution before starting.

Barrier 3: Vendor Dependency and Interoperability Uncertainty

Many organisations are dependent on vendor-managed cryptographic implementations in ERP systems, cloud platforms, networking equipment, and SaaS applications. Where vendors have not yet published PQC migration roadmaps, organisations face genuine uncertainty about when compliant options will be available. The practical mitigation is to make PQC migration timelines a contractual and procurement requirement in new or renewing vendor agreements - a step that also creates internal documentation of due diligence if regulatory scrutiny increases. Building crypto-agile architecture into system design reduces dependency on any single vendor's migration timeline by ensuring that cryptographic primitives can be swapped without system redesign.

Barrier 4: Undefined ROI for Migration Investment

PQC migration does not produce measurable short-term security improvements that map easily onto standard ROI frameworks - the benefit is the avoidance of a future compliance failure and the protection of data that is being collected now. Security architects broadly recommend framing migration investment as a compliance cost rather than a security investment: the question is not whether migration will be required, but whether it will be completed on a planned timeline or under regulatory pressure. The cost differential between planned migration and reactive migration - driven by an examiner finding or a compliance deadline - is substantial and is the most credible financial argument for early resource allocation.

Building Your 90-Day PQC Readiness Sprint - A Starting Framework

The following 90-day framework is designed to advance an organisation from Level 1 or 2 to the threshold of Level 3 - not to complete migration, but to produce the foundational artefacts that make migration planning possible. It is calibrated for organisations that are beginning this work in 2025 or early 2026.

Days 1-30: Cryptographic Asset Discovery

Scope the initial inventory to the highest-risk asset classes: all systems performing asymmetric key exchange (TLS, SSH, VPN), PKI infrastructure (certificate authorities, certificate issuance systems), and data-at-rest encryption for records with sensitivity lifetimes exceeding five years. For each asset, document the algorithm in use, the key size, the owning team, and the vendor or library dependency. Do not attempt to inventory the entire estate in this phase - completeness is the enemy of a useful first sprint. The objective is a working CBOM for tier-one systems, not a comprehensive enterprise map.

Days 31-60: Risk Prioritisation by Data Sensitivity Lifetime

Apply a risk-tiering framework to the inventory produced in phase one. The primary variable is data sensitivity lifetime: data that must remain confidential for more than five years represents the highest harvest-now-decrypt-later exposure and should be prioritised for migration regardless of other factors. Secondary variables include regulatory classification (PHI, PII, classified), system criticality, and remediation complexity. Produce a prioritised migration candidate list with estimated complexity ratings. This document becomes the foundation for the migration roadmap and the primary input for executive budget discussions.

Days 61-90: Governance Documentation and Executive Reporting

Produce three artefacts: a PQC risk register entry with current maturity level, identified gaps, and regulatory exposure; an executive summary mapping organisational posture against the OCC July 2025 expectations, NIST IR 8547 milestones, and any sector-specific obligations; and a draft migration roadmap covering at minimum the tier-one systems identified in phase one, with resource requirements and timeline estimates. These artefacts serve two purposes - they drive internal resource allocation decisions and they constitute the documentation of active risk management posture that examiners and auditors will increasingly expect to see.

Before closing this sprint, review the NIST NCCoE's migration guidance directly.^[^{NIST NCCoE}^] It provides practical checklists and decision frameworks that map directly onto the inventory and prioritisation work described above, and it is the reference document most likely to be cited by examiners assessing the rigour of your migration approach.

The single most important step any CISO can take after reading this article is to open the NIST NCCoE's Migration to Post-Quantum Cryptography project page and assign ownership of the cryptographic discovery phase to a named individual with a 30-day deliverable. Without that assignment, 90-day sprints remain planning artefacts rather than executed programmes.

Key Takeaways

PQC readiness is a five-stage spectrum - awareness, inventory, assessment, roadmapping, and validated deployment - not a binary state. Most organisations remain at Level 1 or 2 as of 2025.
NIST IR 8547 sets 2030 as the federal deprecation target and 2035 as the hard disallow date for RSA and ECC. NSA CNSA 2.0 sets a 2033 adoption deadline for national security systems. These are not aspirational - they are the outer boundary of a manageable transition for organisations that begin immediately.
The OCC's July 2025 Semiannual Risk Perspective explicitly identifies quantum risk and crypto-agile architecture as supervisory expectations for supervised financial institutions - examiner-facing language that will appear in examination cycles.
Enterprise PQC migration takes three to five years end-to-end. Organisations that have not begun cryptographic inventory work are already at risk of missing mid-decade compliance thresholds.
Over 50% of organisations cite lack of executive support as the primary barrier. The most effective framing for executives is regulatory consequence and examiner expectation - not abstract threat narratives.
A 90-day sprint covering cryptographic discovery, risk prioritisation, and governance documentation can advance an organisation from Level 1-2 to the threshold of Level 3 and produce the artefacts required for examiner scrutiny.
NIST's NCCoE Migration to Post-Quantum Cryptography project is the authoritative reference for practical migration guidance and should be the first external document assigned to the team leading this work.