They should separate the transport-security work from the certificate-format work. Hybrid key exchange can usually be planned earlier, while certificate migration depends on browser, CA, and device support. Splitting the programme reduces compatibility risk and makes progress possible before full ecosystem readiness arrives.
Why PQC migration should split transport security from certificate migration
PQC changes two different parts of the stack, so teams should not treat them as one release train. tls key exchange can usually move earlier through hybrid approaches, while certificate-format migration depends on support from browsers, certificate authorities, operating systems, appliances, and embedded devices. Separating the work keeps progress moving without forcing every dependency to be ready at once.
The practical advantage is sequence control. Transport protection can often be updated in server-to-server paths, test environments, and selected client populations before the public certificate ecosystem is fully ready. Certificate changes are harder because they affect trust chains, validation logic, tooling, renewal workflows, and device compatibility, which means the failure mode is often interoperability rather than simple patching.
That is why a split programme is usually the right planning model: one workstream for cryptographic negotiation on the wire, another for the certificate and trust infrastructure that signs, distributes, and validates identities. For the certificate side, teams should plan against the ecosystem realities documented by the CA/Browser Forum, because browser and CA policy is a central constraint on public certificate migration.
What changes first in real environments
hybrid key exchange is often the earlier win because it can be introduced where both endpoints support it, without waiting for every certificate consumer to accept a new format. That makes it useful for reducing harvest-now, decrypt-later exposure in traffic that matters most, even while the broader certificate estate is still conventional.
Certificate migration moves more slowly because it is not only a cryptographic question, it is a compatibility question. Some systems care about chain length, signature algorithms, parser support, hardware security modules, certificate transparency expectations, revocation behaviour, and the operational software that issues and renews certificates. A programme that assumes all of those layers will update together usually stalls.
This is also where inventory matters. Teams need to know where certificates terminate, which services depend on them, and which clients or appliances will be the slowest to update. Guidance on key lifecycle and cryptoperiod planning in NIST SP 800-57 Key Management is useful here because PQC migration is not just algorithm selection, it is lifecycle management across the full key estate.
For teams that need a broader migration map, the Post-Quantum Readiness for Identity and PKI guide is a good reference point for sequencing certificates, signing, authentication, and inventory work without conflating the transport and certificate layers.
How to keep the programme moving without breaking compatibility
The safest operational pattern is to run two coordinated tracks with different exit criteria. The transport track can finish when negotiated algorithms, performance, and fallback behaviour are validated. The certificate track should finish only when the issuer, relying parties, browsers, devices, and automation tooling all accept the new certificate profile in production conditions.
That split helps teams avoid the common mistake of waiting for full ecosystem readiness before doing anything. In practice, the organisation can often upgrade its most controllable paths first, gather compatibility data, and then expand outward. Where the environment uses workload or service certificates, the migration path can be easier to stage, which is one reason the Guide to SPIFFE and SPIRE is relevant for teams thinking about workload identity and mTLS in parallel with PQC.
Teams should also separate acceptance testing by risk. A failed TLS handshake is a different operational problem from a rejected certificate chain, and the remediation path is different in each case. By isolating the two, teams can prove where the breakage sits and avoid overcorrecting one layer to fix a problem in the other.
Risk and Threat Considerations
The main risk in combining both changes into one effort is that teams lose visibility into which layer caused a compatibility failure. That can delay rollout, widen blast radius, and encourage unsafe fallback choices that keep legacy cryptography alive longer than intended.
Failure mechanism: If hybrid key exchange and certificate-format changes are bundled together, a single unsupported client, CA workflow, or appliance can block the whole migration path, or push teams toward broad exceptions and insecure rollback settings.
Impact: The organisation may keep vulnerable cryptography in place longer, misdiagnose outages, or create uneven trust behaviour across applications and endpoints. In the worst case, the programme appears to “fail” when only one layer was actually incompatible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | NIST SP 800-57 Part 1 — Key Lifecycle Management | PQC migration changes key lifecycles, cryptoperiods, and algorithm transitions. |
| Recommendation — Plan key lifecycle transitions separately from certificate rollout and validate cryptoperiod impacts. | ||
| CIS Controls v8 | CIS-13 — Data Recovery | Migration sequencing reduces outage risk from incompatible crypto changes. |
| Recommendation — Stage cryptographic changes to preserve service availability during cutover. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | PQC alters cryptographic use across TLS and certificate operations. |
| Recommendation — Update cryptographic requirements and implementation rules for both transport and certificate trust paths. | ||
| NIST CSF 2.0 | PR.DS-04 — Data is subject to management of cryptographic protections | PQC affects how cryptographic protections are applied to data in transit. |
| PR.PS-02 — Software, firmware, and information integrity are protected | Certificate and TLS changes depend on software and firmware compatibility. | |
| Recommendation — Separate crypto-protection changes by layer and verify each transition path independently. Test endpoint and appliance compatibility before broad PQC rollout. | ||
Practitioner Guidance
What to prioritise: Establish separate readiness criteria for transport negotiation and certificate issuance. If a path can adopt hybrid key exchange without changing its certificate profile, move that first and use the results to de-risk the later certificate transition.
What to verify: Validate support across the full chain of dependency, including browsers, CAs, device firmware, TLS libraries, reverse proxies, and certificate automation. If any of those components cannot accept the new certificate shape, treat that as a certificate migration constraint rather than a transport-security blocker.
Practitioner takeaway: PQC migration succeeds faster when teams treat TLS key exchange and certificates as related but separate programmes, because sequencing reduces compatibility risk and makes partial progress possible before the entire ecosystem catches up.
Related resources from NHI Mgmt Group
- Guide: Machine Identity, PKI and Certificate Lifecycle Guide
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should teams reduce the risk from exposed NHI secrets?
- How should teams think about ServiceNow in an NHI programme?