A TLS service can negotiate a post-quantum hybrid key agreement while still authenticating with a traditional certificate chain. A single pqc_ready: true field cannot describe that state usefully.
Instead, give each connection two linked workstreams: key establishment and authentication. Then record what is specified, what the products support, what your tests observed, and what your trust policy accepts. Those are different kinds of evidence.
This article proposes an inventory you can take to a platform review. The sample service and all sample results below are fictional; this is a planning template, not a deployment or benchmark report.
Start with one connection, not one application
Consider a browser connecting to an edge gateway, which then opens another TLS connection to an origin API. The gateway-to-origin connection needs its own row. Success on the browser-facing connection does not establish anything about the second connection.
Use a connection ID that joins the inventory to an owner, a change record, and a test report. Add the relying-party population explicitly: “supported desktop browsers” and “partner Java clients” are different acceptance scopes. If you use mutual TLS, inventory client authentication as well as server authentication.
| Field | What to record | Why it matters |
|---|---|---|
connection_id |
Client population, TLS terminator, destination, environment | Prevents evidence from one hop being reused for another |
protection_need |
Data class, required confidentiality period, applicable obligations | Helps prioritize the migration without inventing a universal deadline |
key_establishment |
Protocol, offered groups, observed negotiated group, fallback policy | Separates an enabled option from an observed connection |
authentication |
Leaf public-key algorithm, handshake signature, issuer signatures across the chain | A certificate’s subject key and its issuer’s signature are different dependencies |
implementation |
Client/server/library versions, build options, provider or HSM dependencies | Makes the claim reproducible and bounded |
trust_policy |
CA, trust-store owners, relying-party requirements, approval evidence | Cryptographic support alone does not establish acceptance |
evidence |
Test ID, date, versions, configuration, path, observations, limitations | Connects each result to the environment actually tested |
change_control |
Owner, rollback condition, exception expiry, retirement condition | Gives unresolved work a destination |
Store references to secret-management records, not private keys or access tokens, in this inventory.
Keep standards evidence separate from deployment evidence
As checked on 21 September 2026, these documents describe different layers:
| Layer | Primary source | What it supports |
|---|---|---|
| Key encapsulation algorithm | NIST FIPS 203 | Specifies ML-KEM; this is not a signature algorithm |
| Digital signature algorithm | NIST FIPS 204 | Specifies ML-DSA for generating and verifying signatures |
| TLS hybrid key agreement | RFC 10024 | Defines X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 for TLS 1.3 |
| X.509 representation | RFC 9881 | Specifies identifiers and conventions for ML-DSA public keys and signatures in certificates and CRLs |
RFC 10024 was published in August 2026. An old inventory that still calls this particular specification an Internet-Draft needs a version update. That update does not prove that an installed TLS stack supports it.
Likewise, RFC 9881 is not evidence that your issuing CA, browsers, trust stores, or operational tooling will accept a proposed certificate profile. Record each dependency against its own current documentation and actual tests. Include current errata when reviewing the standards; the NIST landing pages link to potential updates.
The inventory below is an engineering proposal. It is not a schema mandated by those standards. It follows the broader goal of changing cryptography while preserving security and service continuity described in NIST CSWP 39upd1 on crypto agility.
Use evidence states instead of a readiness checkbox
For each workstream, maintain separate fields for specification, implementation, lab evidence, and production evidence. Use explicit states such as unknown, documented, tested_pass, tested_fail, and not_applicable_with_reason.
Do not collapse them into an ordered score. A published specification and an unsupported client can coexist. A lab pass and a production failure can coexist. An empty field means unknown, never success.
Here is a deliberately incomplete fictional inventory record for a private API pilot:
{
"schema_version": "1.0",
"example_only": true,
"connection_id": "partner-client-to-private-api",
"environment": "planned_lab",
"owner": "example-platform-team",
"key_establishment": {
"protocol_target": "TLS 1.3",
"group_target": "X25519MLKEM768",
"specification": "RFC 10024",
"implementation_support": "unknown",
"observed_group": null,
"lab_evidence": "not_tested",
"production_evidence": "not_tested"
},
"authentication": {
"current_leaf_key": "unknown",
"current_handshake_signature": "unknown",
"current_chain_signatures": [],
"migration_target": "not_selected",
"ca_support": "unknown",
"trust_policy_acceptance": "unknown",
"lab_evidence": "not_tested",
"production_evidence": "not_tested"
},
"evidence_refs": [],
"fallback_policy": "requires_review",
"rollback_trigger": "requires_review",
"next_action": "Identify both TLS implementations and the relying parties"
}
Notice what is missing: an assertion that the API is quantum-safe. Selecting a target group is a planning decision. It produces no measured compatibility or security result.
Give the two workstreams different acceptance gates
For key establishment, propose a test matrix that includes supported and unsupported peers, the real network path, full handshakes and resumption, and the expected behavior when the target group cannot be used. Capture the negotiated group for the applicable handshake type, errors, and fallback decisions. Do not infer a fresh hybrid exchange from a resumed session without checking how that session established its keys. TLS 1.3 separates key exchange from authentication and permits different resumption modes; see RFC 8446, sections 2 and 4.2.9.
Measure handshake traffic, latency and resource usage against an explicitly defined baseline. Record sample size and conditions. Choose thresholds with the service owner; this article supplies no measured values or universal performance budget.
For authentication, identify the leaf key, handshake signature and each certificate-chain signature separately. Test the proposed profile through issuance, delivery, path validation, renewal and the applicable revocation checks. Include every relying-party class in scope. For mutual TLS, repeat this for client certificates and server-side validation.
| Observation | State you may record | Claim it does not establish |
|---|---|---|
| A hybrid group is documented by the vendor | Implementation support is documented for the named version | Your deployed configuration negotiated that group |
| A lab handshake negotiated the target group | That test passed on that path and version | Certificate authentication migrated to PQ signatures |
| A private lab accepts an ML-DSA certificate chain | That validation test passed under that trust configuration | Public browsers or external partners accept it |
| A fallback connection succeeds | Availability behavior matched the test expectation | The fallback retained the target PQ property |
Fallback and rollback deserve a recorded security consequence. A recovery path that restores service using traditional key establishment may be operationally useful, but it must remain visible as an exception to the target protection policy. Assign an owner, an expiry or review date, and a condition for removing it.
Make evidence expire when its assumptions change
A useful evidence reference points to a specific report with versions, configurations, client population, path, timestamp and limitations. Reopen affected acceptance gates when any of those assumptions changes. Examples include a TLS-inspection appliance added to the route, a library upgrade, or a new trust-store population.
Retirement is another gate. “The new group is available” is different from “the old mode is no longer used within the stated scope.” Keep a residual-use inventory and time-bounded exceptions before closing the migration item.
For the wider sequence from inventory through testing and retirement, our PKI Channel migration roadmap (Japanese) includes a stage diagram and completion criteria. It complements the connection-level worksheet here. PKI Channel is operated by the author account.
Start your next review with one connection and two questions: what was actually observed for key establishment, and what was actually accepted for authentication? If either answer has no bounded evidence, record the gap and its next owner.
AI disclosure: This draft was researched and written by an AI agent under the publisher’s direction. The inventory and fictional example are proposals, not reports of tests we performed. Primary references were checked on 21 September 2026. Independent human technical review is pending.
Top comments (0)