Gaps in Operational Visibility for Post-Quantum Cryptographic Readiness in Networked Computing Environments

The migration from classical to post-quantum cryptographic algorithms is operationally complex. An organization may operate hundreds or thousands of TLS endpoints, certificate authority responders, API gateways, and load balancers, each independently negotiating cryptographic algorithms. Compliance with mandates such as NSA CNSA 2.0 requires not only deploying PQC-capable infrastructure but also verifying, continuously, that deployed infrastructure is actually using PQC algorithms in practice. Existing network monitoring frameworks — including IPFIX , SNMP-based management, and flow-based telemetry — do not define data models or collection semantics for cryptographic algorithm metadata extracted from live protocol negotiations. Certificate management protocols such as ACME and OCSP convey certificate status but not operational algorithm usage at runtime. This document identifies the functional requirements that a standards-compliant PQC readiness observability framework must satisfy, describes gaps in existing standards, and motivates future protocol work. No new protocol mechanisms are specified.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

An administrator seeking to determine the PQC readiness posture of their infrastructure today must manually inspect individual TLS handshakes, parse certificate chain metadata, and cross-reference OCSP and CRL signing algorithms. No existing standard defines: A telemetry data model for cryptographic algorithm observations extracted from live network protocol negotiations. A readiness classification taxonomy distinguishing quantum-vulnerable, hybrid-transitional, and fully PQC-compliant configurations. A method for aggregating per-endpoint algorithm observations into an organization-level PQC readiness metric suitable for reporting to management or regulators. A mechanism for mapping observed algorithm posture against regulatory compliance deadline frameworks and generating gap analyses.

The IETF hybrid key exchange draft and RFC 9794 define hybrid cryptographic configurations combining classical and PQC algorithms (e.g., X25519+ML-KEM-768, ECDSA-P256+ML-DSA-65). These hybrid configurations occupy a transitional security posture — stronger than purely classical configurations but not yet fully PQC-compliant. Existing monitoring tools provide no mechanism to detect hybrid configurations, distinguish them from classical or fully PQC configurations, or assign them an appropriate intermediate compliance status.

RFC 7696 provides protocol design guidelines for algorithm agility — enabling selection of algorithms without hard-coded dependencies. However, algorithm agility without operational visibility creates a compliance risk: infrastructure that is algorithm-agile by design may silently negotiate quantum-vulnerable algorithms in production, with no monitoring system capable of detecting this condition.

The degree to which a networked computing environment's cryptographic algorithm usage in active protocol negotiations and certificate infrastructure is consistent with post-quantum cryptographic requirements. A cryptographic algorithm whose security is broken or significantly weakened by a CRQC, including RSA, ECDSA, ECDH, and DSA. A cryptographic configuration combining a classical algorithm and a post-quantum algorithm as defined in . A cryptographic algorithm standardized by NIST in FIPS 203, FIPS 204, or FIPS 205 (ML-KEM, ML-DSA, or SLH-DSA), used without classical algorithm dependency. Cryptographically Relevant Quantum Computer, as defined in context of Mosca's inequality . Harvest Now, Decrypt Later. A threat model in which an adversary records encrypted data today for future decryption once a CRQC becomes available. A network location at which cryptographic protocol metadata — cipher suite, key exchange algorithm, signature algorithm — can be passively observed from live protocol negotiations without decrypting application payloads.

RFC 6277 specifies rules for server signature algorithm selection in OCSP responses. While this enables algorithm agility in certificate status responses, it does not define a mechanism for monitoring whether OCSP responders are issuing responses signed with PQC algorithms, or for aggregating OCSP signing algorithm observations across an infrastructure.

RFC 9162 defines Certificate Transparency (CT) as an append-only log mechanism for public accountability of CA issuance. CT logs record issued certificates but do not provide: Real-time observation of the algorithms actually negotiated in live TLS handshakes. Aggregated readiness metrics across an organization's infrastructure. Mapping of observed posture against compliance deadline profiles.

The IP Flow Information Export (IPFIX) protocol defines a framework for exporting flow-based network telemetry. The IPFIX information elements do not include fields for cryptographic algorithm identifiers observed in TLS handshakes, preventing existing flow telemetry infrastructure from being used for PQC readiness monitoring without extension.

The IETF draft for hybrid key exchange in TLS 1.3 defines NamedGroup code points for hybrid constructions such as X25519MLKEM768. While this enables hybrid key exchange negotiation, no monitoring standard defines how to collect, aggregate, or report on the prevalence and distribution of these hybrid algorithm selections across a deployed infrastructure.

REQ-OBS-1: The framework MUST define a data model for cryptographic algorithm observations extracted from live network protocol negotiations, including at minimum: cipher suite identifiers, key exchange algorithm identifiers, digital signature algorithm identifiers, and certificate chain algorithm attributes. REQ-OBS-2: The framework MUST support passive observation of cryptographic protocol metadata without requiring decryption of application-layer payload data. REQ-OBS-3: The framework SHOULD support observation at multiple infrastructure tiers, including TLS termination points, certificate authority endpoints, OCSP responders, CRL distribution points, API gateways, and load balancers.

REQ-CLASS-1: The framework MUST classify each observed cryptographic algorithm into one of at least three readiness categories: quantum-vulnerable, hybrid-transitional, and PQC-compliant. REQ-CLASS-2: The framework MUST correctly identify and classify hybrid cryptographic configurations as defined in , including at minimum ML-KEM-based hybrid key exchange and ML-DSA-based hybrid signature configurations.

REQ-SCORE-1: The framework SHOULD support computation of a per-endpoint readiness metric derived from the classified algorithms observed at that endpoint. REQ-SCORE-2: The framework SHOULD support computation of an aggregate organizational readiness metric from per-endpoint observations, with the ability to weight endpoints by operational criticality. REQ-SCORE-3: The framework MUST support time-series storage of readiness observations to enable historical trend analysis of PQC migration progress.

REQ-COMP-1: The framework MUST support mapping of per-endpoint readiness observations against configurable compliance deadline profiles, including at minimum the CNSA 2.0 migration timeline. REQ-COMP-2: The framework MUST generate gap reports identifying endpoints and certificate infrastructure components that require algorithm migration before applicable deadlines.

REQ-REM-1: The framework SHOULD produce prioritized remediation guidance identifying which endpoints require migration action, ordered by the combination of compliance deadline proximity and operational risk exposure. REQ-REM-2: The framework SHOULD support analysis of the dependency relationships between endpoints to assist operators in planning safe migration sequences.

The primary threat model motivating this document is HNDL: adversaries that capture data encrypted with quantum-vulnerable algorithms today can decrypt it once a CRQC becomes available. For PKI infrastructure, the additional concern is that a CA signing key protected by a quantum-vulnerable algorithm compromises the entire certificate hierarchy under that key, affecting all relying parties. Mosca's inequality quantifies the urgency: if the estimated time to CRQC is less than the sum of the time required to complete migration and the required confidentiality lifetime of the protected data, then the organization is already at risk. A readiness observability framework enables operators to measure their current posture against this threshold continuously. Passive observation of cryptographic metadata from live network traffic introduces a privacy consideration: the metadata observed (certificate fingerprints, endpoint identifiers, algorithm selections) may be sensitive in some deployment contexts. Implementations MUST apply appropriate access controls to telemetry collection and storage infrastructure. A readiness observability framework MUST NOT require decryption of application-layer payload data. Observation MUST be limited to cryptographic protocol metadata visible in plaintext during the handshake phase.

This document has no IANA actions. Future work specifying a concrete PQC readiness telemetry data model may require IANA registration of new IPFIX Information Elements or YANG data model namespaces.