Build a PQC migration inventory that separates key exchange from certificate signatures

PKI security — Mon, 21 Sep 2026 05:58:59 +0000

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.