compliance

PQC Readiness Assessment: A Step-by-Step Framework for Security and Compliance Teams

CISA's quantum-readiness guidance, published jointly with NIST and NSA, identifies completing a cryptographic inventory as the single most urgent action organizations can take - not a future milestone, but an immediate operational requirement.^[^CISA^] That framing matters to compliance teams: it converts PQC readiness from a research exercise into a defensible audit artifact. Organizations that complete a structured assessment today have documented evidence of due diligence when sector-specific mandates - already visible in federal contracting and financial services - arrive with enforcement teeth.

This article provides a four-step assessment framework anchored to NIST, CISA, and NSA primary guidance. Each step produces a concrete output that maps to audit evidence, board reporting, or regulatory response.

What a PQC Readiness Assessment Is - and Why Compliance Teams Own It

A PQC readiness assessment is a structured evaluation of an organization's current cryptographic posture against the requirements established by finalized post-quantum standards and agency migration guidance. Its scope covers three dimensions: the cryptographic algorithms in active use, the data those algorithms protect, and the vendors and suppliers whose cryptographic choices affect the organization's exposure.

Compliance teams - not just security engineering - own this process for a specific reason: regulatory accountability. NIST's NCCoE Migration to Post-Quantum Cryptography project frames cryptographic discovery and prioritization as governance activities, not purely technical ones.^[^{NIST NCCoE}^] When an auditor, regulator, or board asks whether the organization has assessed its quantum exposure, the answer must be traceable to a dated, scoped, and assigned work product - not a verbal assurance from the security team.

The compliance trigger is concrete. NIST finalized three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).^[^{NIST FIPS 203}^] Organizations now have finalized standards to migrate toward. Continuing to operate RSA or ECC without a documented migration plan is no longer a position that can be defended as prudent waiting - it is a documented risk acceptance decision that compliance teams must own explicitly.

Step 1: Conducting a Cryptographic Inventory Across Systems and Vendors

The cryptographic inventory is the foundation of every subsequent assessment step. Without a complete picture of where quantum-vulnerable algorithms are deployed, risk classification and remediation planning are both unreliable. CISA's quantum-readiness guidance identifies this inventory as the first required action for critical infrastructure operators.^[^CISA^]

What to Inventory

The inventory must capture every instance of asymmetric cryptography in use - specifically RSA, elliptic curve cryptography (ECC), and Diffie-Hellman key exchange in all variants. These are the algorithm families that finalized post-quantum standards are designed to replace. Symmetric algorithms such as AES-256 are not the target of this inventory phase, as they do not carry the same exposure profile under current NIST analysis.^[^{NIST FIPS 203}^] The inventory should cover:

Infrastructure layer: TLS configurations on web servers, load balancers, API gateways, and VPN endpoints; certificate authorities and certificate stores; SSH key types; IPsec configurations.
Application layer: Code libraries implementing cryptographic functions (OpenSSL, BouncyCastle, native language libraries); signing and verification routines; key management service integrations.
Data at rest: Encrypted storage systems, database encryption modules, backup encryption, and document-level encryption tools.
Third-party and SaaS integrations: Any API, data feed, or identity provider where the cryptographic negotiation is controlled by a vendor rather than internally.

Inventory Methodology

The NCCoE practice guide volumes for the Migration to Post-Quantum Cryptography project provide a structured discovery methodology, including tooling categories and data collection templates that compliance teams can adopt directly.^[^{NIST NCCoE}^] In practice, a first-pass inventory should be scoped to the five to ten systems handling regulated data or long-retention records - these represent both the highest compliance risk and the most defensible starting boundary for an audit artifact. A cryptographic bill of materials is the structured output format that makes inventory findings reusable across audit cycles and vendor assessments.

Assign a named individual - typically a security architect or lead engineer - formal ownership of the inventory output. Document the scope boundary, the date completed, and the methodology used. These three metadata fields are what convert an inventory spreadsheet into an audit artifact.

Step 2: Classifying Risk by Data Sensitivity and Longevity

Not all quantum-vulnerable cryptography carries equal compliance risk. The prioritization model must account for two variables: the sensitivity classification of the data being protected, and the minimum period over which that data must remain confidential.

The Data Longevity Factor

The "harvest now, decrypt later" threat model is the specific mechanism that makes data longevity a compliance concern today rather than a future planning consideration. Adversaries collecting encrypted data now against the possibility of decrypting it later is a documented intelligence concern referenced in joint CISA, NSA, and NIST guidance.^[^CISA^] For compliance teams, this translates directly: any data encrypted with RSA or ECC today that must remain confidential for five or more years represents a current risk exposure, not a future one. The irreversibility of harvest-now attacks means that migration delay compounds the exposure - data already collected cannot be retroactively re-encrypted with post-quantum algorithms.

Risk Classification Matrix

Apply a two-axis classification to each cryptographic asset identified in the inventory:

Axis 1 - Data sensitivity: Regulated (PHI, PII, financial records, classified), business-critical (IP, contracts, strategic communications), or general operational.
Axis 2 - Required confidentiality horizon: Less than three years (low longevity), three to ten years (medium longevity), or more than ten years (high longevity).

Assets in the high-sensitivity, high-longevity quadrant warrant immediate remediation planning regardless of whether a hard regulatory deadline has been published for the sector. Assets in the low-sensitivity, low-longevity quadrant can be scheduled for later migration phases without material compliance risk - provided that determination is documented.

Regulatory Overlay

Layer sector-specific obligations onto the matrix as they apply. Federal contractors operating National Security Systems face adoption timelines beginning in 2025 under NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).^[^{NSA CNSA 2.0}^] NIST IR 8547 establishes deprecation timelines for RSA and ECC in federal use cases, with the 2030 and 2035 milestones representing the outer boundary of acceptable migration timelines for federal-adjacent organizations. Document which regulatory framework governs each asset class - this mapping is the input to the remediation roadmap in Step 4.

Step 3: Evaluating Vendor and Supply Chain PQC Readiness

An organization's own migration progress is only part of its compliance posture. Where cryptographic operations are performed by or mediated through third parties - cloud providers, SaaS platforms, hardware security module vendors, PKI providers, and network equipment manufacturers - the vendor's migration timeline becomes part of the organization's risk profile.

Vendor Questionnaire Framework

Direct vendor inquiries to four specific questions, structured to elicit verifiable commitments rather than marketing language:

Algorithm inventory disclosure: Which asymmetric algorithms does your platform currently use for key exchange, authentication, and data encryption in the services we consume? Can you provide documentation?
FIPS alignment commitment: Do you have a published commitment to support NIST FIPS 203, 204, or 205? If so, what is the target date, and is it contractually binding?^[^{NIST FIPS 204}^]
Hybrid transition support: Will your platform support hybrid classical/post-quantum cipher suites during the transition period? What is your deprecation schedule for legacy algorithm support?
Cryptographic agility architecture: Is your cryptographic implementation modular enough to allow algorithm updates without service interruption or contract renegotiation?

Red-Flag Indicators

Treat the following vendor responses as material risk indicators requiring escalation in the assessment output:

No published PQC roadmap or internal commitment to FIPS 203/204/205 alignment as of 2025.
Inability to disclose which algorithms are in use for the specific services consumed - this indicates a lack of internal cryptographic inventory and is itself a supply chain risk signal.
Contractual language that prevents the customer from requiring algorithm upgrades within the contract term.
Sole reliance on a single cryptographic library with no published post-quantum upgrade path.

Document vendor responses with dates. A vendor that cannot answer these questions today but commits to a response timeline creates a traceable accountability record. A vendor that declines to engage is itself an audit finding.

Step 4: Building a Crypto-Agile Remediation Roadmap

The remediation roadmap translates assessment findings into a sequenced migration plan. It must account for three realities: that FIPS 203, 204, and 205 are the finalized standards organizations should migrate toward; that hybrid classical/post-quantum deployments will be operationally necessary during transition; and that cryptographic agility - the architectural capacity to swap algorithms without system redesign - is the property that makes the roadmap durable across future standard revisions.

Sequencing Migration Priorities

Use the risk classification matrix from Step 2 to sequence remediation. High-sensitivity, high-longevity systems migrate first. The NCCoE practice guides provide phased migration patterns for common infrastructure categories, including TLS, code signing, and key management - these should be referenced directly rather than recreated internally.^[^{NIST NCCoE}^]

For key encapsulation and key exchange, FIPS 203 (ML-KEM) is the designated standard.^[^{NIST FIPS 203}^] For digital signatures, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) address different operational profiles - ML-DSA for general-purpose signature schemes, SLH-DSA for use cases requiring hash-based security assumptions.^[^{NIST FIPS 205}^] The roadmap should specify which standard applies to each system category, not treat PQC as a single undifferentiated upgrade.

Hybrid Transition Planning

Security architects broadly recommend deploying hybrid cipher suites - combining classical and post-quantum algorithms - during the transition period to maintain backward compatibility while establishing quantum-resistant protection for new sessions. This approach is consistent with the NCCoE migration guidance and avoids the operational risk of cutting over entirely to unvalidated implementations before FIPS 140-3 validation of post-quantum modules is complete.^[^{NIST NCCoE}^]

Building for Crypto Agility

The roadmap is not a one-time migration plan - it is the foundation of an ongoing cryptographic governance capability. Crypto agility as an architectural property means that when NIST publishes revisions, or when the HQC backup standard moves toward finalization, the organization can update implementations without redesigning systems. Build this requirement into vendor contracts and internal system design standards now, before the remediation work begins - retrofitting agility into fixed cryptographic architectures is significantly more expensive than designing for it from the outset.

Each roadmap milestone should carry a target date, a named owner, a dependency list (including vendor commitments from Step 3), and a definition of completion that an auditor can verify independently.

Mapping Assessment Outputs to Audit, Board, and Regulatory Reporting

A completed assessment generates four categories of output that serve distinct reporting functions. Compliance officers should structure deliverables against these categories from the outset - not convert technical findings into compliance language after the fact.

Audit Evidence Package

The audit evidence package comprises: the scoped cryptographic inventory with methodology documentation; the risk classification matrix with supporting rationale; vendor assessment responses with dates; and the remediation roadmap with milestone owners. Together, these demonstrate a documented, systematic approach to managing cryptographic risk - the standard against which auditors will evaluate due diligence in the absence of a sector-specific mandate. Where a mandate does exist (NSA CNSA 2.0 for national security system operators, NIST IR 8547 timelines for federal agencies), the package must additionally map each finding to the specific requirement and show progress against it.^[^{NSA CNSA 2.0}^]

Board Risk Reporting

Board reporting on PQC readiness should translate assessment findings into three statements: the organization's current exposure profile (which systems carry material cryptographic risk and why); the migration timeline and resource commitment required to close that exposure; and the residual risk that will remain at each phase of the roadmap. Avoid algorithm-level technical detail in board presentations - focus on data categories at risk, regulatory consequences of delay, and the governance decisions required from the board (budget approval, vendor contract mandates, policy adoption).

Regulatory Response Readiness

Financial services regulators, federal agency oversight bodies, and sector-specific auditors are beginning to ask about PQC preparedness. CISA's guidance positions the cryptographic inventory as the baseline expectation for critical infrastructure operators.^[^CISA^] Organizations that have completed Steps 1 through 4 can respond to regulatory inquiries with a structured package rather than an ad hoc narrative. That distinction matters in enforcement contexts: a documented, scoped, dated assessment demonstrates organizational seriousness in a way that verbal assurances do not.

Repeating the Assessment

A PQC readiness assessment is not a point-in-time exercise. The standard landscape will evolve - NIST's post-quantum portfolio is not closed, and sector-specific regulations will introduce new requirements as they mature. Build a reassessment trigger into the governance framework: at minimum annually, and additionally when a new primary standard is published, when a significant vendor changes its cryptographic posture, or when a regulatory inquiry arrives. The assessment framework described here should be treated as a standing operating procedure, not a project with a completion date.

Key Takeaways

CISA, NIST, and NSA jointly identify completing a cryptographic inventory as an immediate action requirement for critical infrastructure operators - not a future planning milestone.^[^CISA^]
NIST finalized FIPS 203, 204, and 205 in August 2024, providing concrete migration targets that compliance programs can be built around.^[^{NIST FIPS 203}^]
Risk classification must account for data longevity, not just sensitivity - high-longevity regulated data encrypted today with RSA or ECC represents a current exposure under the harvest-now, decrypt-later threat model.^[^CISA^]
Vendor assessment is a compliance obligation, not optional due diligence - third-party cryptographic choices are part of the organization's risk and audit profile.
The NCCoE Migration to Post-Quantum Cryptography practice guides provide a methodology baseline that compliance teams can adopt directly rather than developing internally.^[^{NIST NCCoE}^]
A dated, scoped, and assigned assessment output is an audit artifact. An undocumented internal discussion is not.
Crypto agility - the architectural capacity to replace algorithms without system redesign - must be built into remediation work and vendor contracts, not deferred to a later phase.

Concrete next action: This week, open the NIST NCCoE Migration to Post-Quantum Cryptography practice guide at pages.nist.gov/nccoe-migration-post-quantum-cryptography, identify the discovery volume, and assign a named individual with formal ownership of producing a cryptographic inventory for your five highest-risk systems within 60 days. Record the assignment, the scope boundary, and the target date in writing. That single documented step is the difference between a PQC program that exists and one that can be verified.