PQC Readiness Assessment Template
Post-quantum readiness is not one product switch and should not be reduced to a universal percentage. An organization may have strong cryptographic discovery but no certificate migration path. A cloud service may support a post-quantum key exchange at one endpoint while its managed key service lacks the required key type. A laboratory pilot may work while production clients remain incompatible.
This assessment evaluates separate capabilities and requires evidence for each conclusion. It helps a team identify the next action, owner, dependency, test, and rollback requirement without claiming that the organization as a whole is “quantum safe.”
Download the editable PQC readiness assessment CSV. It includes example rows that should be removed or replaced.
Use the Cryptographic Inventory Guide and CBOM template to gather evidence first. Use the PQC Migration Plan Template after the assessment identifies concrete work.
What this assessment measures
The framework asks whether an organization can discover, decide, test, deploy, monitor, and reverse changes for each important cryptographic function. It does not predict when a cryptographically relevant quantum computer will exist. It also does not certify compliance with a law, framework, or customer requirement.
Assess a defined scope, such as one business service, product line, or portfolio tier. Record the scope statement and date. “The company” is usually too broad for evidence-based answers.
Evidence-based status levels
Use these statuses for each capability:
| Status | Meaning | Minimum evidence |
|---|---|---|
| Not assessed | No accountable review | None |
| Gap identified | Required capability is missing or unknown | Finding and affected scope |
| Planned | Owner, dependency, and target action exist | Approved work item or plan |
| Pilot | Tested in a bounded non-production environment | Configuration and test results |
| Production validated | Deployed in defined production scope with monitoring and rollback | Change record, telemetry, and acceptance evidence |
| Not applicable | Capability is outside the defined scope | Written rationale and approver |
Do not average these into a single score. Report the distribution, critical gaps, and evidence age. A red gap in firmware verification can dominate the risk of many green documentation controls.
The ten assessment domains
1. Cryptographic inventory and CBOM
Can the team locate public-key cryptography in code, protocols, certificates, libraries, cloud services, HSMs, firmware, and third-party products? Are dependencies and owners represented? Are findings refreshed when systems change?
Evidence may include scanner output, certificate inventory, cloud configuration exports, a CBOM, repository findings, and sampled manual validation. Inventory completeness must be stated against a scope, not asserted globally.
2. Data longevity and business prioritization
Has the organization identified data whose required confidentiality lifetime extends beyond the expected migration window? Has it considered traffic that can be captured now and decrypted later if vulnerable key establishment is used?
Evidence should link data classification and retention to actual cryptographic functions. Do not apply a generic “harvest now” label to every symmetric or hashing use.
3. Algorithm and protocol agility
Can algorithms and parameters change through configuration, or is a code, firmware, hardware, certificate, or vendor update required? Can the system support parallel configurations during transition? Are algorithm identifiers, message sizes, and negotiation behavior handled correctly?
NIST’s crypto-agility work treats agility as an operational capability, not a slogan. The Crypto Agility guide explains how inventory, policy, interfaces, testing, and governance reduce migration risk.
4. PKI and certificate lifecycle
Can certificate authorities, enrollment systems, revocation, validation, trust stores, appliances, clients, and monitoring process the target algorithms and larger artifacts? Is the distinction between certificate signature, subject public key, and handshake key establishment understood?
A vendor supporting ML-DSA signing in one service does not prove that every X.509 workflow or relying party interoperates with it.
5. HSM, KMS, and key lifecycle
Assess key generation, import, storage, use, backup, replication, rotation, audit, deletion, and recovery separately. Record software-backed, HSM-backed, external key manager, and single-tenant limitations. Product availability must be capability-specific and sourced to current vendor documentation.
Use the PQC vendor questionnaire when documentation does not answer lifecycle and roadmap questions.
6. Network protocols and endpoints
Assess TLS, VPN, SSH, service mesh, load balancers, proxies, CDN, remote access, and device protocols. Record the exact client and server versions, algorithm or hybrid construction, negotiation evidence, fallback behavior, and production status.
Supporting post-quantum TLS at one edge does not protect application signatures, stored data keys, SSH, code signing, or internal connections. The cloud provider capability comparison demonstrates why provider-wide labels are misleading.
7. Code signing and long-lived verification
Identify software packages, containers, mobile applications, firmware, bootloaders, update systems, release manifests, and offline recovery images. Determine how long signatures must verify and which installed devices cannot receive a new verifier.
Evidence must cover signing keys, HSM support, build pipeline, distribution format, trust anchors, verifier compatibility, rollback, and recovery.
8. Third-party and vendor dependencies
Can suppliers state support by algorithm, function, product version, environment, and availability stage? Is roadmap language kept separate from generally available capability? Are contractual notice, end-of-life, update, and evidence obligations defined?
Use capability rows, not “Vendor X is PQC ready.” The vendor support matrix is a starting map, not a substitute for procurement evidence.
9. Testing and interoperability
Does the organization have representative clients, servers, certificates, hardware, network paths, and failure cases? Can it measure latency, CPU, memory, handshake or artifact size, HSM throughput, and operational error rates? Are downgrade and fallback behaviors reviewed?
FIPS 203, 204, and 205 are final standards. Protocol integrations and product implementations can still be drafts, previews, limited releases, or unsupported. Record both standards status and product status.
10. Deployment, monitoring, and rollback
Is there a phased rollout with acceptance criteria? Can teams see which algorithm was negotiated or which key performed an operation? Can they revert without silently restoring a prohibited or insecure configuration? Are incident response and support teams prepared for new failure modes?
Rollback is not an excuse for indefinite fallback. It is a controlled response to interoperability or availability failure, with ownership and an expiry condition.
How to run the assessment
Step 1: Define scope and critical services
Name environments, business services, data classes, and exclusions. Select critical workflows rather than surveying policy documents alone.
Step 2: Interview owners with evidence open
Include application, platform, network, PKI, identity, cloud, hardware, build, security, procurement, and risk owners as relevant. Ask them to show configurations, inventories, test results, or vendor documentation.
Step 3: Complete one row per capability and scope
The CSV includes domain, capability, scope, status, evidence, gap, dependency, owner, next action, target date, test, rollback, and verification fields. Split rows when production and test status differ or when one provider supports only one cryptographic function.
Step 4: Challenge optimistic labels
Change “pilot” to “planned” if no test evidence exists. Change “production validated” to “pilot” if only a preview service or one client was tested. Mark vendor roadmap statements as dependencies, not implemented capability.
Step 5: Build a prioritized gap register
Prioritize with business impact, data lifetime, exposure, dependency lead time, replacement availability, and operational complexity. Do not invent a universal deadline. Government requirements apply to defined organizations and systems; private-sector plans should cite the policy or risk basis they actually use.
Step 6: Convert actions into a migration plan
Every material gap needs an owner, next action, evidence requirement, and review date. Transfer implementation candidates to the migration plan with target algorithm, tests, rollout, monitoring, and rollback.
Reporting without a readiness score
A useful report shows:
- scope and exclusions;
- count of capabilities by evidence-based status;
- critical gaps and affected services;
- unsupported vendor or hardware dependencies;
- pilots awaiting production validation;
- evidence older than the chosen review period;
- next decisions and accountable owners.
You may use a heatmap across domains, but do not sum unlike risks into a badge. Explain what each color means and allow a critical capability to remain visible.
Common assessment mistakes
Counting standards as deployments: A final NIST algorithm standard does not make a product, protocol, or device implementation available.
Treating hybrid TLS as complete migration: Key establishment is one function. Authentication, signatures, code signing, stored keys, and internal protocols remain separate.
Accepting vendor-wide claims: Ask for exact algorithm, operation, product, version, region, backing type, release status, and limitations.
Ignoring rollback: A pilot without a tested failure path is not ready for production.
Using policy as evidence: A policy can define a target, but it does not prove that deployed systems comply with it.
Practical takeaway
Run this assessment on one critical service first. Demand evidence for every status, keep capabilities separate, and turn gaps into owned tests. The result should tell an engineering leader what to do next, not merely produce a reassuring percentage.
FAQ
Is this a compliance assessment?
No. It is an operational readiness framework. Map it to applicable legal, regulatory, contractual, or government requirements with qualified advice and explicit scope.
Why does the template avoid a total score?
Averages hide critical dependencies and imply false equivalence between controls. Capability status, evidence, and business impact are more actionable.
Can a vendor roadmap count as readiness evidence?
It is evidence of a dependency or plan, not evidence of available capability. Record the source, date, scope, and committed or noncommitted status.
Does support for ML-KEM make a system post-quantum ready?
No. ML-KEM addresses key establishment. Signatures, certificates, code signing, key management, protocols, clients, deployment controls, and other functions need separate assessment.
How often should the assessment be repeated?
Review it when architecture, software, providers, standards, or policy change, and on a defined periodic cycle. High-change or critical systems need more frequent verification.