Why You Need a PQC Readiness Assessment
The post-quantum cryptography (PQC) transition is not a single event — it’s a multi-year organizational transformation affecting technology, processes, and people. Before you can plan a migration, you need an honest assessment of where you stand today.
Most organizations overestimate their readiness and underestimate the scope of change required. A systematic assessment reveals:
- Unknown exposures: Cryptographic usage you didn’t know existed
- False assumptions: Beliefs about your cryptographic posture that don’t match reality
- Resource gaps: Skills, tools, and budget shortfalls that will block migration
- Timeline risks: Dependencies and complexities that extend your timeline beyond compliance deadlines
This 50-point checklist provides a structured framework for evaluating PQC readiness across eight critical dimensions. Score each item honestly — the value of this exercise lies in accurate self-assessment, not optimistic scoring.
How to Use This Checklist
Scoring System
For each item, assign one of these scores:
| Score | Meaning | Criteria |
|---|---|---|
| 0 | Not started | No activity or awareness in this area |
| 1 | Aware | Recognized as a need but no action taken |
| 2 | In progress | Active work underway but not complete |
| 3 | Complete | Fully addressed and documented |
Maturity Levels
Sum your scores across all 50 items (maximum 150) and assess your maturity:
| Total Score | Maturity Level | Assessment |
|---|---|---|
| 0-30 | Critical | Significant risk of missing compliance deadlines |
| 31-60 | Early | Foundation work underway but major gaps remain |
| 61-90 | Developing | Good progress but key areas need attention |
| 91-120 | Advanced | Well-positioned but optimization needed |
| 121-150 | Mature | Comprehensive readiness across all dimensions |
Section 1: Cryptographic Inventory (Items 1-10)
The foundation of PQC readiness is knowing what cryptography you use, where, and how.
1.1 Complete Cryptographic Asset Discovery
□ Item 1: You have deployed automated cryptographic discovery tools across all production environments.
What “complete” means: Discovery covers applications, infrastructure, network protocols, certificates, and key stores. Not just a sample — comprehensive coverage.
□ Item 2: Your cryptographic inventory includes non-production environments (development, staging, DR).
Why it matters: Non-production environments often mirror production cryptography and can introduce vulnerable patterns when promoted.
□ Item 3: You have identified cryptographic usage in third-party and SaaS services.
Challenge: Third-party crypto is often opaque. Vendor questionnaires, network inspection, and contractual requirements help fill gaps.
□ Item 4: Your inventory is maintained in a machine-readable format (CycloneDX CBOM recommended).
Why format matters: Machine-readable CBOMs enable automation — policy enforcement, compliance reporting, and risk calculation at scale.
□ Item 5: Cryptographic discovery runs continuously (not as a one-time exercise).
Reality check: Infrastructure changes daily. A CBOM generated six months ago is already inaccurate. QCecuring CBOM provides continuous monitoring to maintain inventory accuracy.
1.2 Inventory Completeness Validation
□ Item 6: You have validated discovery results against known system architectures.
Verification approach: Compare discovered crypto against architecture documentation. Gaps in either direction indicate discovery or documentation issues.
□ Item 7: Shadow cryptography has been investigated (developer-implemented, undocumented crypto).
Common findings: Hardcoded encryption keys, custom crypto wrappers, undocumented algorithm selections in configuration files.
□ Item 8: Hardware cryptographic components are inventoried (HSMs, TPMs, crypto accelerators).
Scope: Include all hardware hosting key material or performing cryptographic operations.
□ Item 9: Certificate infrastructure is fully mapped (all CAs, intermediate CAs, trust chains).
Detail needed: Signing algorithms, key sizes, validity periods, subordination relationships.
□ Item 10: Cryptographic inventory has been reviewed and accepted by system owners.
Governance: Each system owner should validate that the CBOM accurately reflects their system’s cryptographic reality.
Section 2: Algorithm Classification (Items 11-17)
Understanding which algorithms are quantum-vulnerable versus quantum-safe.
□ Item 11: All asymmetric algorithms (RSA, ECC, DH, DSA) have been identified and counted.
Classification: Every instance of RSA (any key size), ECDSA, ECDH, DH, and DSA in your inventory is quantum-vulnerable and requires migration.
□ Item 12: Symmetric algorithm usage has been validated (AES-256 confirmed vs. AES-128).
Nuance: AES-256 is quantum-safe. AES-128 offers reduced security under Grover’s algorithm (effectively 64-bit — insufficient). Identify and plan AES-128 upgrades.
□ Item 13: Hash function usage has been classified by security margin.
Classification:
- SHA-384, SHA-512, SHA3-256+: Adequate for post-quantum
- SHA-256: Acceptable for most uses but verify against CNSA 2.0 scope
- SHA-1, MD5: Already deprecated, immediate remediation needed
□ Item 14: Each quantum-vulnerable algorithm has been mapped to its hosting systems.
Output: A clear list — “RSA-2048 is used in systems X, Y, Z for purposes A, B, C.”
□ Item 15: Algorithm usage has been categorized by function (encryption, signing, key exchange, hashing).
Why: Migration approach differs by function. Key exchange migrates to ML-KEM, signatures to ML-DSA, firmware signing to LMS/XMSS.
□ Item 16: Cryptographic protocols have been classified (TLS versions, cipher suite configurations).
Detail: Not just “TLS 1.2” but specific cipher suites enabled, preferred order, and fallback behavior.
□ Item 17: Any custom or proprietary algorithms have been identified and assessed.
Risk: Custom algorithms may have unknown quantum vulnerability characteristics. Engage cryptographic experts for assessment.
Section 3: Data Sensitivity Mapping (Items 18-24)
Understanding what data is protected by quantum-vulnerable cryptography and how long it needs protection.
□ Item 18: Data classification levels are defined and applied consistently.
Prerequisite: You can’t assess crypto risk without knowing data sensitivity. Ensure classification (public, internal, confidential, restricted, top secret) is applied.
□ Item 19: Data retention periods are documented for systems with quantum-vulnerable crypto.
Critical question: If data must remain confidential for 25 years, and CRQCs may arrive in 10 years, that data is already at HNDL risk.
□ Item 20: Harvest Now, Decrypt Later (HNDL) exposure has been assessed per data category.
Formula: If (data retention period) > (estimated time to CRQC), data is at HNDL risk today.
□ Item 21: The most sensitive data has been mapped to its cryptographic protections.
Priority: Crown jewels (most sensitive, longest-lived data) must be identified and their cryptographic protection verified.
□ Item 22: Data flows crossing organizational boundaries have been identified.
Risk: Data in transit over public networks faces higher HNDL risk than data within controlled environments.
□ Item 23: Regulatory data protection requirements have been mapped to cryptographic controls.
Examples: GDPR data minimization, HIPAA encryption requirements, SEC data retention — each may intersect with PQC migration priorities.
□ Item 24: Data archival and backup encryption has been assessed for quantum vulnerability.
Often overlooked: Backups and archives may be encrypted with quantum-vulnerable keys and retained for decades. These represent significant HNDL targets.
Section 4: Vendor Assessment (Items 25-30)
Evaluating whether your technology vendors can support PQC migration.
□ Item 25: Critical vendors have been surveyed about PQC roadmaps.
Questions to ask: When will your product support ML-KEM/ML-DSA? Do you have FIPS 140-3 validation planned? What is your hybrid deployment timeline?
□ Item 26: Vendor responses have been evaluated for credibility and timeline alignment.
Red flags: Vague timelines, no mention of specific algorithms, dependency on “future NIST guidance” (already available), no FIPS validation plan.
□ Item 27: Vendor contracts include PQC capability requirements for renewals/upgrades.
Contractual protection: Future procurements should require CNSA 2.0-aligned algorithm support or clear migration paths.
□ Item 28: Alternative vendors have been identified where primary vendors lack PQC plans.
Risk mitigation: Don’t wait for an unprepared vendor. Identify alternatives now even if you don’t switch immediately.
□ Item 29: Cloud service provider PQC capabilities have been evaluated.
Check: AWS, Azure, GCP, and other cloud providers all have PQC roadmaps — verify that the services you use are on those roadmaps and timelines align with your needs.
□ Item 30: Open-source cryptographic library PQC support has been assessed.
Key libraries: OpenSSL 3.x (via oqs-provider), BoringSSL, NSS, Bouncy Castle, libsodium — confirm PQC algorithm availability for your technology stack.
Section 5: Hybrid Testing (Items 31-36)
Validating that hybrid (classical + PQC) deployments function correctly in your environment.
□ Item 31: A test environment for PQC/hybrid cryptography has been established.
Minimum: An isolated environment where PQC algorithms can be tested without production risk.
□ Item 32: Hybrid TLS key exchange has been tested (e.g., X25519MLKEM768).
Validation: Confirm that hybrid TLS handshakes complete successfully, certificates validate, and data flows correctly.
□ Item 33: Performance impact of PQC algorithms has been measured in your environment.
Metrics: Handshake latency, throughput, CPU utilization, memory usage, bandwidth consumption. Compare against current baselines.
□ Item 34: Interoperability testing has been performed with key partners/clients.
Reality: Your systems don’t operate in isolation. Verify that PQC-enabled systems interoperate correctly with partners.
□ Item 35: PQC certificate chain validation has been tested end-to-end.
Complexity: PQC certificates are larger. Verify that all components in the validation chain handle larger signatures and keys correctly.
□ Item 36: Rollback procedures have been validated for hybrid deployments.
Safety net: Confirm that you can revert to classical-only if PQC deployment causes issues, without service disruption.
Section 6: Key Management Readiness (Items 37-42)
Ensuring your key management infrastructure can support PQC operations.
□ Item 37: Key management systems (KMS) PQC compatibility has been assessed.
Check: Can your KMS generate, store, and manage PQC key types? ML-KEM and ML-DSA keys are significantly larger than RSA/EC keys.
□ Item 38: HSMs have been evaluated for PQC algorithm support.
Reality: Many deployed HSMs lack PQC support. Firmware upgrades may be available, or hardware replacement may be needed. Lead times for HSM procurement can be 6-12 months.
□ Item 39: Key sizes and storage requirements have been projected for PQC.
Impact: ML-DSA-87 public keys are 2,592 bytes vs. 33 bytes for ECDSA P-256. Storage, bandwidth, and processing impacts must be planned.
□ Item 40: Certificate lifecycle management supports PQC certificate types.
Requirements: Enrollment, issuance, renewal, revocation, and archival processes must all handle PQC certificates.
□ Item 41: Key rotation procedures accommodate PQC key types.
Consideration: LMS/XMSS stateful signatures require state management — traditional key rotation doesn’t apply directly.
□ Item 42: Disaster recovery procedures account for PQC key material.
Backup: PQC keys must be included in DR planning. Stateful signature keys (LMS/XMSS) require special backup procedures to maintain state consistency.
Section 7: Compliance Alignment (Items 43-47)
Mapping your PQC readiness against applicable compliance frameworks.
□ Item 43: Applicable compliance frameworks requiring PQC have been identified.
Common frameworks: CNSA 2.0, PCI DSS 4.0, DORA, NIS2, FedRAMP (evolving), CMMC 2.0.
□ Item 44: Compliance timelines have been mapped against your migration plan.
Critical check: Does your planned migration timeline meet all applicable deadlines? If not, where are the gaps?
□ Item 45: Compliance reporting capabilities for cryptographic posture exist.
Automation: Can you generate reports demonstrating CNSA 2.0 alignment from your CBOM? QCecuring CBOM provides automated compliance reporting mapped to frameworks including CNSA 2.0 and PCI DSS 4.0.
□ Item 46: Audit evidence for cryptographic inventory is maintained and accessible.
Documentation: Auditors will require evidence that your CBOM is current, comprehensive, and acted upon.
□ Item 47: Cross-framework compliance efficiencies have been identified.
Opportunity: A single CBOM and risk assessment can satisfy multiple compliance requirements simultaneously.
Section 8: Training and Organizational Readiness (Items 48-50)
Ensuring your team has the knowledge and organizational support for PQC migration.
□ Item 48: Development teams have received PQC awareness training.
Content: What quantum computing threatens, which algorithms are affected, what secure coding for PQC looks like, how to implement crypto-agility.
□ Item 49: Security and operations teams understand PQC monitoring requirements.
Skills: How to interpret CBOM data, how to detect quantum-vulnerable algorithm reintroduction, how to respond to PQC-related incidents.
□ Item 50: Executive sponsorship for PQC migration is secured with budget allocation.
Critical: PQC migration without executive support and dedicated budget will stall. Leadership must understand the compliance deadlines and business risk.
Assessment Interpretation Guide
Score 0-30: Critical Readiness Gap
Your organization has not meaningfully started PQC preparation. Given CNSA 2.0 deadlines, this represents significant compliance and security risk.
Immediate actions:
- Deploy cryptographic discovery (QCecuring CBOM) for immediate visibility
- Brief leadership on quantum risk and compliance deadlines
- Establish a PQC working group with dedicated resources
- Begin vendor conversations about PQC roadmaps
Score 31-60: Early Stage
You’ve recognized the need and started initial work, but major gaps remain across multiple dimensions.
Priority actions:
- Complete cryptographic inventory across all environments
- Perform risk assessment on discovered quantum-vulnerable assets
- Establish test environments for PQC experimentation
- Develop formal migration plan with resource allocation
Score 61-90: Developing
Good foundation is in place but execution gaps exist — likely in testing, vendor readiness, or organizational alignment.
Focus areas:
- Close specific gaps identified by this assessment
- Advance hybrid testing from lab to pre-production
- Formalize compliance reporting capabilities
- Train broader engineering teams on PQC implementation
Score 91-120: Advanced
Strong posture across most dimensions. Focus on optimization, completeness, and sustained operations.
Refinement areas:
- Address any remaining zero-scored items
- Optimize migration plans based on testing results
- Establish continuous monitoring and drift detection
- Share learnings across the organization
Score 121-150: Mature
Comprehensive readiness. Your organization is well-positioned for PQC migration and likely ahead of most peers.
Sustain activities:
- Maintain momentum through execution phases
- Monitor evolving standards and guidance
- Contribute learnings to industry
- Consider mentoring supply chain partners on PQC readiness
Reassessment Schedule
This assessment is not a one-time exercise. Reassess regularly:
| Maturity Level | Reassessment Frequency |
|---|---|
| Critical | Monthly |
| Early | Quarterly |
| Developing | Quarterly |
| Advanced | Semi-annually |
| Mature | Annually |
Each reassessment should document score changes, newly identified gaps, and actions taken since the last assessment.
Accelerating Your Score
Highest-Impact Actions
If you can only do five things from this checklist, do these:
- Deploy automated CBOM generation (Items 1, 4, 5) — QCecuring CBOM addresses these immediately
- Classify algorithm vulnerability (Item 11) — identify all quantum-vulnerable crypto
- Assess HNDL exposure (Item 20) — find your most urgent risk
- Test hybrid TLS (Item 32) — prove PQC works in your environment
- Secure executive sponsorship (Item 50) — nothing else happens without leadership support
Common Assessment Mistakes
- Scoring 3 without evidence: “Complete” means documented, validated, and maintained — not just “we did it once”
- Ignoring third parties: Your security is only as strong as your vendors’ PQC readiness
- Confusing awareness with action: Knowing about PQC is a 1; having deployed PQC is a 3
- Skipping continuous monitoring: A one-time inventory that isn’t maintained is already obsolete
- Underestimating training needs: PQC migration requires skills most teams don’t yet have
Key Takeaways
- Honest self-assessment reveals the real gaps — optimistic scoring helps nobody
- Most organizations score 20-50 on initial assessment — this is normal but demands urgent action
- Cryptographic inventory is the foundation — Items 1-10 unlock everything else
- HNDL risk assessment is non-negotiable — your most sensitive data may already be compromised
- Vendor readiness affects your timeline — assess and influence vendor PQC plans early
- Testing validates assumptions — lab results often differ from expectations on performance and compatibility
- Compliance deadlines are firm — CNSA 2.0’s January 2027 gate is 6 months away
- QCecuring CBOM accelerates Items 1-10 — automated discovery turns weeks of work into days
- Executive sponsorship is the biggest enabler — without budget and organizational commitment, scores plateau
- Reassess regularly — this is a living document that tracks your migration maturity over time