Model overview · 0 — None · 1 — Initial · 2 — Foundational · 3 — Advanced · 4 — Managed · 5 — Optimized
Level 3 adds full cryptographic visibility and agility. Vendors can account for all cryptographic use cases and update algorithms without major redesign.
Criteria
A product meets Level 3 when all Level 2 criteria are met, plus:
Criterion 3.1.1
A full cryptographic inventory is maintained, covering all use cases within the product where cryptography is applied. The inventory must address every applicable category in the Cryptographic Inventory Taxonomy below; categories that do not apply to the product must be marked not applicable with a written justification — categories may not be omitted.
Criterion 3.1.2
Non-quantum-safe features are formally documented and flagged — either for planned remediation, risk acceptance, or compensating controls.
Criterion 3.1.3
A Software Bill of Materials (SBOM) or equivalent component inventory is available, enabling consumers to identify cryptographic dependencies.
Criterion 3.1.4
Crypto-agility mechanisms exist for key product features: at least two algorithms can be selected for the same cryptographic role through configuration (for example two different signature algorithms, or a pure-PQC vs. hybrid option in the same role) without major architectural redesign or a hardware refresh. Selecting only between parameter sets of the same algorithm (for example ML-KEM-768 and ML-KEM-1024) does not by itself satisfy this criterion.
Criterion 3.1.5
A documented long-lived exposure register identifies which data flows handled by the product carry a long-lived protection requirement, and which algorithm protects each. The register must cover both exposure classes: Harvest-Now-Decrypt-Later (HNDL), where confidentiality must survive future decryption, and long-lived integrity and authenticity, including Trust Now, Forge Later (TNFL), where signed artifacts and trust relationships must remain trustworthy against future signature forgery throughout their required lifetime.
Cryptographic Inventory Taxonomy
A Level 3 cryptographic inventory must cover, at minimum, the following categories. For each category, list the algorithms, parameter sets, and components used — or mark the category not applicable with a justification:
- Data in transit (e.g., TLS, VPN, application protocols)
- Data at rest (e.g., disk, database, object storage encryption)
- Identity, authentication, and certificates
- Code, firmware, and update signing
- Key wrapping and key-encryption keys (KEKs)
- Random number generation and entropy sources
- Telemetry, logging, and audit-trail integrity
- Build, CI/CD, and supply-chain signing (where part of the product)
- Attestation and remote-attestation (where applicable)
- Backup, archival, and long-term storage
- Long-term validation of existing evidence (verification of previously created signatures, seals, and timestamps; archive timestamp renewal; hash and signature agility for already-signed records)
The final category concerns evidence that has already been created. Re-encryption can protect retained copies and reduce future confidentiality exposure, but cannot protect ciphertext already captured by an adversary. For signatures, seals, and timestamps, continued mathematical verification alone does not establish authenticity once forgery becomes feasible. Products that create, validate, or preserve such evidence must identify how its integrity and authenticity are preserved, for example through timely archive timestamp or evidence renewal before the existing protection becomes vulnerable. Simply replacing a signature does not recreate the original signing event. Products that hold no such evidence mark the category not applicable with a justification.
Assessment questions
Existing product documentation and test results may be reused where they directly support the requirement for the assessed version, configuration, and scope. Cite the exact section or result for each requirement; a generic document reference is insufficient. Reuse does not waive any criterion. Record whether evidence was reviewed, a test was observed, or a test was independently reproduced, and identify gaps.
The assessment report must record:
- SBOM analysis — tool name and version (e.g., Syft, cdxgen, Dependency-Track, Microsoft sbom-tool), and date run.
- Quantum-safety check — tool or script used to identify quantum-unsafe libraries or algorithm identifiers in the SBOM/CBOM, findings summary, and date.
- Inventory cross-check — whether inventory claims were verified against SBOM tool output, and whether any code-level check was performed.
- Code review (if performed) — manual or automated; tool(s) used (e.g., Semgrep, CodeQL, grep-based algorithm identifier search); scope (full codebase / cryptographic modules only / dependency list only); and findings.
- Tool-vs-disclosure gaps — each discrepancy between tool output and vendor disclosure recorded individually.
- Unverified claims — flag each explicitly as "vendor-stated, not independently verified".
Discrepancies between tool findings and vendor disclosure are the most significant findings at Level 3 — each must be individually recorded.
Cryptographic Inventory
Question 3.2.1
Can the vendor provide the cryptographic inventory for the assessed product version?
Request the inventory document. Record: title, version number (must correspond to the assessed product release — not a generic or latest-version document), date of last update, and format. A complete inventory entry must include: algorithm name, parameter set, key size, usage context, and component name — e.g., "ML-KEM-768 — TLS 1.3 key exchange — server-side — component: tls-engine v2.3". Entries listing only the algorithm name without parameter set and component attribution are incomplete — record which fields are missing.
Question 3.2.2
Does each inventory entry include algorithm, parameter set, key size, usage context, and component?
Sample at least five entries across different components. For each sampled entry, record whether all five fields are present. An entry showing "ML-KEM" without a parameter set (512 / 768 / 1024) cannot be independently verified against a standard — flag each such entry.
Question 3.2.3
How frequently is the inventory reviewed and updated?
Request the inventory for the current and one previous product release. Compare entries. Record the version and last-updated date for each document. An inventory with no changes between major releases that included PQC updates is not actively maintained — record this as a process gap.
Non-Quantum-Safe Feature Disclosure
Question 3.3.1
Does the product contain any features that still use non-quantum-safe algorithms? If yes, list them by component and algorithm.
Cross-reference the vendor's disclosure against SBOM analysis: run the SBOM through a quantum-safety checking tool (e.g., a CycloneDX crypto analyser or a script that checks library versions against a known PQC-capable threshold). Record: tool name and version, date run, and any gap between tool findings and vendor disclosure. Each gap is a finding and must be individually recorded with the component name, algorithm, and the vendor's explanation (or its absence). Ask explicitly: "What features in this product cannot currently operate with quantum-safe algorithms only?"
Question 3.3.2
For each non-quantum-safe feature: is the risk formally documented with a target remediation date?
Record each non-quantum-safe feature with: algorithm name and parameter set, component, risk acceptance statement reference (document title, version, date), and target remediation version/date. "Some legacy features remain" without a feature-by-feature breakdown is not acceptable. Each non-quantum-safe feature must have its own entry.
Question 3.3.3
Can the vendor provide a redacted or anonymised SBOM or CBOM that preserves algorithm-level detail?
Record the format (SPDX / CycloneDX), schema version, and the scope of redaction (e.g., "proprietary component names removed, algorithm entries preserved"). A redacted artefact that removes all algorithm data is not useful — record this as a limitation of the evidence. If the vendor refuses to provide any inventory artefact in any form, record this explicitly and flag it as a risk signal that limits the evidential basis of the assessment.
SBOM
Question 3.4.1
Does the vendor provide an SBOM in SPDX or CycloneDX format?
Request the SBOM for the assessed product version. Record: format and schema version (e.g., CycloneDX 1.6), generation tool and version (e.g., Syft 1.4.0, cdxgen 10.7, Microsoft sbom-tool 2.x), generation method (automated CI pipeline / manual export / hybrid), generation date, and the product version covered. Validate the SBOM using a validator (e.g., CycloneDX CLI at https://github.com/CycloneDX/cyclonedx-cli, or NTIA minimum elements checker). Record the validation result. Run a quantum-safety check and compare against the vendor's own disclosure — record any gaps.
Question 3.4.2
Does the SBOM include cryptographic library dependencies with version numbers?
Check that all cryptographic libraries appear in the SBOM with explicit version numbers — a library entry without a version cannot be assessed. Common libraries to look for include OpenSSL, wolfSSL, Bouncy Castle, AWS-LC, Microsoft CNG / BCryptPrimitives, NSS, mbedTLS, LibreSSL, Botan, Crypto++, LibOQS, and PQ Code Package. For each library, the assessor must independently verify — from the library's own official release notes or PQC documentation page — whether the listed version supports the vendor's claimed quantum-safe algorithms. A library version that does not support the claimed algorithm is a finding; record the library name, listed version, and the vendor's explanation. Record any library whose version number is absent.
Question 3.4.3
Is the SBOM updated with each product release?
Request SBOMs for the current and one previous release. Compare the library entries and version numbers. If two SBOMs are identical for releases that should have included dependency updates, the SBOM process is likely not integrated with the build pipeline — record this as a process gap. Record the version and date of each SBOM compared.
Question 3.4.4
Does the SBOM identify the assessed product itself, and its third-party components, with standardised product identifiers — Common Platform Enumeration (CPE), Package URL (purl), or SPDX externalRef of type cpe23Type / purl?
Record, for the top-level product component: the CPE identifier and any Package URL (purl) present in the SBOM, and the SBOM field in which each is declared. If neither is present for the top-level product, this is a finding — without a standardised identifier the product cannot be correlated with CVE feeds (e.g., the NIST National Vulnerability Database) or with the Certified Products & Services registry. Sample at least five third-party components from the SBOM and record whether each carries a CPE or purl. Components with neither identifier should be noted; widespread absence indicates an inventory that cannot be machine-correlated with vulnerability data.
Crypto Agility
Question 3.5.1
How does the product support algorithm updates without major architectural redesign? Demonstrate that at least two distinct algorithms can be selected for the same cryptographic role through configuration.
Request a design document or written architectural description of the crypto agility mechanism. Record: document title, version, date. Ask the vendor to identify, for at least one role (e.g., signing, key exchange), the two algorithms that can be selected and the configuration step to switch between them. The two options must be different algorithms or different constructions (e.g., pure-PQC vs. hybrid) — selecting between parameter sets of the same algorithm (e.g., ML-KEM-768 vs. ML-KEM-1024) does not satisfy this question on its own. Ask the vendor: "If ML-KEM-768 were deprecated tomorrow, walk me through exactly what would change in this product and what the customer impact would be." Record the answer with its source (document reference or "verbal, unconfirmed"). A credible answer names a specific mechanism — configurable cipher suite list, algorithm policy file, algorithm registry — not "we would release a patch".
Question 3.5.2
Are cryptographic algorithm identifiers and parameters externalised from hard-coded values?
Ask to see the specific configuration file, policy document, or API that controls algorithm selection. Record the file name, format, and a sample of relevant content (which algorithm identifiers appear). Confirm by asking: "Can you change the algorithm for TLS key exchange without rebuilding the product?" Record the answer and whether the assessor was able to verify it in a test environment. Hard-coded algorithm names requiring a full rebuild are a finding.
Question 3.5.3
Has the vendor executed or simulated a controlled algorithm transition for at least one feature?
Request written documentation: what was changed, the test environment, the test procedure, and the outcome. Record document title, version, and date. A verbal claim that a transition was tested without any written record is flagged as "vendor-stated, not documented". A documented proof-of-concept with a test procedure and result is strong evidence — note whether the procedure is reproducible by an independent assessor.
Key Lifecycle and Deprecation
Question 3.6.1
Which algorithms protect the keys (KEKs, key-wrapping keys, root keys) used by the product itself — not only the keys exchanged with peers?
Cryptographic agility for traffic algorithms is undermined if the keys protecting them are wrapped with classical algorithms vulnerable to a future quantum attacker. Record each KEK / key-wrapping role with: algorithm, parameter set, key size, and whether it is classical or quantum-safe. A product that exchanges traffic with ML-KEM but wraps long-lived keys with RSA-2048 must document this explicitly — it is a finding for any data with long confidentiality requirements.
Question 3.6.2
Does the product use random number generation appropriate for cryptographic key material?
Record the random bit generator, implementation and version, entropy source, instantiation and reseeding process, and the security strength required by each supported algorithm and parameter set. Check the applicable algorithm specification and random bit generation requirements. Distinguish seed length from entropy and security strength; do not apply a universal 256-bit seed threshold. Record unsupported assumptions, insufficient entropy, or failure to meet the applicable requirements as findings. For ML-KEM, consult FIPS 203 section 3.3 and Table 2.
Question 3.6.3
Has the vendor published an algorithm deprecation policy describing how it responds to a vulnerability or parameter-set deprecation in an algorithm the product depends on?
Record the policy document URL, version, and date. The policy should state: how the vendor monitors algorithm developments; the maximum time between a credible deprecation event and a vendor advisory; and the mechanism used to remove or disable the affected algorithm. Absence of any published policy is a finding. The detail need not match a security-incident response process but must be a written commitment.
Long-Lived Exposure Register (including HNDL and TNFL)
Question 3.7.1
Does the vendor maintain a written long-lived exposure register covering confidentiality, integrity, and authenticity requirements for data, signed artifacts, and trust dependencies handled by the product?
Request the register and record its title, version, and date. For each applicable data class, signed artifact, or trust dependency, identify the exposure class, required protection or reliance lifetime, algorithms and parameter sets, affected components or relying parties, and planned protection or migration measures. Long-lived confidentiality includes Harvest Now, Decrypt Later (HNDL): re-encryption can protect retained copies, but cannot protect ciphertext already captured by an adversary. Long-lived integrity and authenticity include Trust Now, Forge Later (TNFL): future compromise of a signature algorithm can permit forged artifacts or impersonation while the corresponding keys or trust anchors remain accepted. Consider signed documents, seals, timestamps, audit records, certificates, software and firmware updates, and authentication trust dependencies where applicable. Record both preservation of authentic existing evidence and replacement or retirement of vulnerable signing and verification dependencies before compromise. Mathematical signature verification alone is insufficient to establish authenticity after forgery becomes feasible. Identify the timing and limitations of archive timestamp renewal, evidence renewal, or other preservation measures; do not imply that re-signing recreates the original event. HNDL and TNFL are descriptive risk labels, not additional maturity levels. If either exposure class is omitted despite an applicable product use, record a finding; justify any not-applicable conclusion.
Production-Scale Validation
Question 3.8.1
Has the quantum-safe implementation been exercised at a scale and in an environment representative of real production use — not only in a developer or lab setting?
Request the test report. Record: test environment (cloud region, instance class, network topology, peer implementations), workload profile (request rate, concurrent sessions, key-operation rate, payload sizes), duration, and the algorithm/parameter sets exercised. The test must simulate conditions the product is expected to encounter in production — a single-instance lab measurement, a unit test, or a notebook-scale benchmark is not sufficient evidence for this question. Record any production deployment where the configuration has been run in earnest. Absence of any representative test is a finding; deeper benchmarking and SLA correlation is required at Level 5.
Evidence checklist
The items below are a level-specific summary of the artefacts a vendor should be able to produce. They can serve as a concise request list for an assessor, or as a self-assessment reference for a vendor preparing evidence before a formal assessment. The detailed requirements and acceptance criteria for each item are in the assessment questions above. All artefacts from Level 1 and Level 2 remain required.
Evidence 3.e.1
Cryptographic inventory document or summary (publicly available or under NDA), covering every category in the Cryptographic Inventory Taxonomy.
Evidence 3.e.2
SBOM in SPDX or CycloneDX format for the current release, with Common Platform Enumeration (CPE) and/or Package URL (purl) identifiers recorded for the top-level product (and for third-party components where available).
Evidence 3.e.3
Documentation describing crypto-agility mechanisms and how to use them, naming at least two algorithms selectable for the same role.
Evidence 3.e.4
A list of non-quantum-safe features with their documented risk status.
Evidence 3.e.5
Algorithm deprecation policy.
Evidence 3.e.6
Long-lived exposure register covering confidentiality (including HNDL), integrity and authenticity (including TNFL), required lifetimes, affected trust dependencies, and protection or migration measures.
Evidence 3.e.7
Identification of the DRBG / RNG used for cryptographic key material and its seed strength.
Evidence 3.e.8
A production-representative test or deployment record demonstrating the quantum-safe configuration operating under realistic load.
