Model overview · 0 — None · 1 — Initial · 2 — Foundational · 3 — Advanced · 4 — Managed · 5 — Optimized
Level 4 adds a CBOM, zero-legacy capability, and explicit hybrid/composite support. Suitable for high-assurance and regulated environments.
Criteria
A product meets Level 4 when all Level 3 criteria are met, plus:
Criterion 4.1.1
A Cryptographic Bill of Materials (CBOM) is maintained, detailing each algorithm in use, key sizes, protocol contexts, and usage purposes.
Criterion 4.1.2
Zero-Legacy Capability: the product can be configured to disable all non-quantum-safe algorithms throughout the product — including in low-level components such as boot, firmware update signing, hardware-bound operations, and internal diagnostics — while remaining fully functional. Zero legacy means zero legacy. If a non-quantum-safe algorithm cannot be disabled in any in-scope component, the product does not meet Level 4 for that component, and an assessment must record this as a finding that caps the product's level.
Criterion 4.1.3
Symmetric and hash algorithms used to protect data with long-lived confidentiality or integrity requirements, for every exposure class recorded in the Level 3 long-lived exposure register, meet the parameter strengths recommended by NIST (or an equivalent national authority) for use beyond the anticipated availability of cryptographically relevant quantum computers.
Criterion 4.1.4
The vendor clearly documents whether hybrid (classical + quantum-safe combined) and/or composite (algorithm-fused) modes are supported, and in which contexts.
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:
- CBOM analysis — whether vendor-provided or assessor-generated; tool name and version; generation method (automated CI pipeline / manual export / hybrid); date generated; product version covered.
- SBOM-to-CBOM cross-check — method used to verify every cryptographic library in the SBOM maps to at least one CBOM entry, and any gaps found.
- Zero-legacy testing — product version; configuration applied; test tool name and version; exact test command or procedure; outcome (classical connection rejected / accepted / untested).
- Hybrid/composite verification — whether the assessor tested interoperability with a reference implementation; if so: implementation name and version, and result.
- Unverified claims — flag each explicitly as "vendor-stated, not independently verified".
Any claim at Level 4 that was not independently tested must be explicitly flagged in the report.
Cryptographic Bill of Materials (CBOM)
Question 4.2.1
Does the vendor produce a CBOM for this product? Request it in machine-readable format (CycloneDX with cryptoProperties extension, or equivalent).
Record: format and schema version (CycloneDX 1.6+ supports full cryptoProperties), generation tool name and version (e.g., IBM Sonar crypto-analyzer, cdxgen with crypto extension, CycloneDX Maven/Gradle plugin), generation method (automated CI pipeline / manual export / hybrid), date generated, and product version covered. Perform an SBOM-to-CBOM cross-check: for each cryptographic library listed in the SBOM, verify that at least one algorithm entry appears in the CBOM. Record any library that is present in the SBOM but has no corresponding CBOM entry — each is a coverage gap.
Question 4.2.2
Does the CBOM record algorithm, parameter set, key size, protocol context, and usage purpose per entry?
Validate a sample of at least five entries across different components. For each: record whether all fields are present — algorithm, parameter set (e.g., ML-KEM-768 not just "ML-KEM"), key size, protocol context, and usage purpose. Record the sampling method (which entries were checked and why). An entry reading "AES-256-GCM — TLS 1.3 record encryption — post-handshake" is complete. An entry reading "AES" or "ML-KEM" without parameter set and context is not — record it as a gap.
Question 4.2.3
Does the CBOM cover third-party cryptographic libraries, listing which algorithms each library contributes?
A CBOM that lists "OpenSSL 3.3" without listing which OpenSSL algorithms are in active use is incomplete at Level 4. Check: does each third-party cryptographic library entry have child entries for specific algorithms? Record which libraries have algorithm-level entries and which have library-name entries only. Libraries with no algorithm-level entries must be flagged.
Question 4.2.4
What tools and processes are used to generate and validate the CBOM? What are the known coverage gaps?
Request the vendor's CBOM generation process document. Record: tool(s) name and version, automation level (fully automated / manual / hybrid), whether the CBOM is generated per build or periodically, and the documented coverage gaps. Common gaps include: native code (C/C++) with statically compiled libraries, dynamically loaded plugins, hardware-bound cryptography, and firmware blobs. A vendor who cannot state how the CBOM was generated cannot have its accuracy independently assessed — record this as a fundamental evidence limitation.
Question 4.2.5
Does the CBOM bind each cryptographic-asset entry to the component that contains it via a standardised product identifier — Common Platform Enumeration (CPE) or Package URL (purl) — so that algorithm-level findings can be correlated with CVE feeds and asset inventories?
In CycloneDX (cryptography extension), this is typically a cpe or purl field on the component referenced by each cryptographic-asset. Sample at least five cryptographic-asset entries and record, for each, the referenced component identifier and whether a CPE or purl is present. Library-level entries that are not linked to a component identifier cannot be matched against the NIST National Vulnerability Database — record each gap individually. The top-level product component must carry the same CPE identifier as the one recorded for the certification application.
Zero-Legacy Capability
Question 4.3.1
Can the product be configured to disable all non-quantum-safe algorithms? Provide the exact configuration steps.
Record the exact configuration mechanism (configuration file key, API call, CLI flag, UI setting) and the documentation URL. Where possible, reproduce in a test environment: apply the zero-legacy configuration, then test using a client that supports only classical algorithms — e.g., openssl s_client -cipher "AES256-SHA" -tls1_2 -connect host:port. Record: test tool name and version, exact command used, product version, configuration applied, and outcome (connection rejected / accepted). A connection that succeeds under this test is a finding.
Question 4.3.2
When configured in zero-legacy mode, does the product remain fully functional with a quantum-safe client?
Test with a representative quantum-safe workload. Record: test environment details, product version, zero-legacy configuration applied, quantum-safe client tool and version (e.g., OpenSSL, a TLS client with ML-KEM support), test procedure, and outcome. Document any feature that fails or degrades in zero-legacy mode — each exception must be named, scoped, and risk-assessed.
Question 4.3.3
Are there components in which non-quantum-safe algorithms cannot be disabled — e.g., internal diagnostics, boot sequences, hardware-enforced algorithms, firmware update signing, or root-of-trust operations?
Zero legacy means zero legacy: any in-scope component in which a non-quantum-safe algorithm cannot be disabled is a finding that caps the product's PQCMM level below Level 4 for the affected component. Record each such component by: name, algorithm in use, reason it cannot be disabled, the vendor's planned remediation timeline, and the resulting effective maturity level for that component. The assessment report must clearly state where the product does and does not achieve zero-legacy operation.
Symmetric and Hash Strengths for Long-Lived Data
Question 4.4.1
For data with long-lived confidentiality or integrity requirements (as identified in the long-lived exposure register at Level 3), do the symmetric and hash algorithms used meet the strengths recommended by NIST or an equivalent national authority for use beyond the anticipated availability of cryptographically relevant quantum computers?
Record, for each long-lived data class identified in the register: the exposure class, the symmetric algorithm and key length, the hash algorithm and output length, and the NIST or national-authority guidance referenced (e.g., NIST SP 800-131A, BSI TR-02102, ANSSI cryptographic recommendations). Both exposure classes must be covered. For harvest-now-decrypt-later classes, assess the strengths protecting confidentiality. For long-lived integrity and authenticity classes, including TNFL exposure, assess the hash and signature strengths that the existing evidence depends on, including the timing and protection of any archive timestamp or evidence-renewal mechanism the product applies. Cross-reference the signing, verification, and trust-dependency migration recorded in 3.7.1; adequate hash strength alone does not establish resistance to signature forgery. A long-lived data class protected with symmetric or hash strengths below the referenced guidance is a finding. A register entry with no corresponding assessment here is also a finding.
Hybrid and Composite Support
Question 4.5.1
Does the product support hybrid key exchange or hybrid authentication? If yes, which specific hybrid schemes, and which standard or draft?
Record scheme-level specifics: e.g., X25519+ML-KEM-768 per draft-ietf-tls-hybrid-design (record the draft version number — implementations based on superseded drafts may not interoperate with current versions). "We support hybrid" without naming the scheme and draft version is not assessable. Where possible, test interoperability with a reference implementation (e.g., OpenSSL configured for the same scheme) and record: tool name and version, test command, and outcome.
Question 4.5.2
Does the product support composite algorithms? If yes, which schemes and which standard or draft?
Record: scheme name (e.g., id-MLDSA65-RSA2048-PKCS15-SHA256), reference standard or draft (e.g., draft-ounsworth-pq-composite-sigs with specific draft version, or ETSI TS 119 312 with section reference). Proprietary composite schemes that deviate from published drafts must be flagged as an interoperability risk and recorded with the vendor's explanation of the deviation.
Question 4.5.3
In which protocols, features, or configurations is hybrid/composite mode available?
Record each feature area with the specific hybrid/composite scheme implemented and a configuration example or documentation URL. "Full hybrid support" without a feature-level breakdown requires decomposition before recording. Request the specific configuration parameter or API call for each named feature.
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, Level 2, and Level 3 remain required.
Evidence 4.e.1
CBOM in CycloneDX format (with cryptography extension) or equivalent structured format.
Evidence 4.e.2
Configuration guide for enabling zero-legacy mode, including a list of any caveats.
Evidence 4.e.3
Technical documentation of hybrid and composite support with protocol/standard references.
Evidence 4.e.4
Test results or validation reports confirming zero-legacy operation.
