Post-quantum requirements become operational only when they reach certificate fields, certificate roles, revocation, and the components that validate them. Updated November 3, the CNSA Suite 2.0 profile for X.509 certificates and certificate revocation lists defines a public profile for applications using the US Government’s Commercial National Security Algorithm Suite.
The document is an Independent Stream Internet-Draft sent toward RFC publication. It is not an IETF standard and does not represent IETF consensus. It applies directly to specified national security and high-value government contexts; other organizations should treat it as informative unless their own policy or contract adopts it.
A profile is a set of linked configuration facts
Recording “CNSA 2.0” or an algorithm name is not enough to establish conformance. The profile applies requirements to X.509 certificate and CRL structures, algorithms, extensions, certificate roles, revocation, and the behavior of components that issue or process them.
A defensible inventory should connect:
- certificate fingerprint, serial number, issuer, subject, validity, and policy identifiers;
- certificate role: self-signed CA, subordinate CA, end-entity signature, or key establishment;
- signature and public-key algorithms, parameter sets, identifiers, and encoded values;
- required and optional extensions, criticality, key usage, constraints, and name information;
- CRL issuer, distribution path, signature algorithm, update cadence, and validation evidence;
- trust anchor, certification path, cross-certificate, relying-party policy, and trust-store location;
- CA, registration authority, HSM, library, firmware, application, service, and endpoint versions;
- device, host, rack or cloud location, environment, owner, supplier, and business service;
- policy source, applicability, effective date, exception, target state, and work owner; and
- discovery method, timestamp, scope, confidence, and known coverage gaps.
Those relationships let a reviewer determine not only which algorithm appears, but whether the certificate is valid for its role and whether the relying infrastructure enforces the intended profile.
Issuance and validation are different control surfaces
A CA can issue a profile-compliant certificate while an endpoint, gateway, trust store, or application fails to validate it correctly. The reverse is also possible: a library may support the algorithms, while issuance templates or HSM policies cannot produce the required structure.
Teams should track capability, configuration, issuance, deployment, presentation, path building, revocation checking, and policy acceptance as separate states. A successful lab issuance is not proof that production relying parties select the intended path.
Evidence should name exact certificate hashes, component versions, configurations, test vectors, times, and results. Supplier statements can supplement that evidence but should not replace local verification.
Revocation is part of the migration boundary
PQC migration discussions often focus on keys and certificates, while CRL signing, publication, retrieval, freshness, and validation receive less attention. Yet revocation infrastructure is itself cryptographic infrastructure.
An organization needs to know which CA signs each CRL, where it is hosted, how clients retrieve it, which algorithms protect it, what happens when it is stale or unavailable, and which systems use another notification method. That information should link to the same canonical CA, service, and ownership records as the certificate population.
Testing must include failure behavior. A client that silently skips revocation checks during an outage has a different security posture from one that fails closed, and policy may differ by environment or service criticality.
Government scope must remain explicit
The profile’s public availability does not make it universally mandatory. Inventory should record why a system is in scope: national security designation, high-value information, contract, procurement requirement, internal policy, or voluntary adoption. That prevents a useful technical profile from becoming an unexplained enterprise-wide claim.
Where CNSA 2.0 is a target, migration plans should map every certificate role and dependent component, not only public web endpoints. Exceptions need owners, compensating controls, expiration dates, and evidence.
What organizations should do next
First, translate profile requirements into machine-readable checks by certificate role, while preserving citations and applicability rules.
Second, join certificate and CRL findings to canonical infrastructure, CA, trust-store, application, owner, supplier, and location records.
Third, test issuance and validation independently across representative components. Include path building, revocation, failure modes, rollover, and rollback.
Finally, monitor the document through publication and reconcile final text, supplier support, and organizational policy before closing migration work.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect certificates, keys, algorithms, applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Core is source-available and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The document remains an Internet-Draft and its final publication details may change. Conformance to this profile does not by itself prove implementation security, operational availability, correct scoping, complete discovery, or successful interoperability across every relying system.
Source
- Commercial National Security Algorithm Suite 2.0 Profile for Certificates and Certificate Revocation Lists, draft-jenkins-cnsa2-pkix-profile-07, Independent Submission, updated November 3, 2026.