Start by scanning critical public domains to establish a baseline, then separate TLS key exchange support from certificate algorithms and from internal cryptographic dependencies. The early win is useful, but the programme only becomes real once teams map ownership, replacement order, and the machine identities tied to those assets.
How to frame the first phase of a PQC migration
The right starting point is not “replace everything with quantum-safe crypto.” It is to establish what is exposed, what depends on it, and what breaks first if you change it. For internet-facing domains, that usually means inventorying TLS endpoints, separating key exchange from certificate signing, and identifying the services and machine identities that will drive the migration order.
For a practical reference on the migration path, teams can use Post-Quantum Readiness for Identity and PKI to keep the focus on inventory, crypto-agility, and the parts of the stack that actually need replacement rather than treated as one generic crypto problem.
The first useful question is whether the domain is only terminating TLS or also relying on the same certificate chain, trust store, or key infrastructure elsewhere. That distinction matters because a domain may be easy to test for PQC readiness at the edge while still depending on legacy algorithms deeper in the path, including load balancers, service-to-service trust, or automation that renews certificates. Migration starts when those dependencies are made explicit.
For the certificate and lifecycle side, Machine Identity, PKI and Certificate Lifecycle Guide is the better companion because the early work is usually about certificate inventory, renewal flow, and ownership rather than only about new cryptographic primitives.
What should be separated before any rollout
Teams should separate three layers that are often conflated in casual planning: TLS key exchange, certificate algorithms, and internal cryptographic dependencies. Key exchange affects how sessions are established. Certificate algorithms affect how the server is authenticated. Internal dependencies include anything that signs, verifies, stores, renews, or distributes cryptographic material across systems. If those layers are not separated, teams can mis-rank the work and create false confidence from a partial pilot.
That separation also helps with replacement order. A domain with many public endpoints may need client compatibility testing for hybrid TLS key exchange before it needs any certificate change. Another may need certificate lifecycle automation first because renewal tooling, HSM integration, or public CA policy is the real bottleneck. The migration plan should reflect the dependency chain, not the novelty of the algorithm.
This is where internet-facing domains often reveal broader identity and access dependencies. Certificate issuance, renewal, and rotation are usually machine-driven processes, so the migration plan has to account for the identities that request, approve, or deploy those certificates. If ownership is unclear, or if the same automation path serves multiple environments, the risk is not just cryptographic lag, it is migration drift.
What good looks like for the first 90 days
A sensible first phase is a baseline scan across critical public domains, followed by a clean inventory of TLS termination points, certificate authorities, renewal tooling, and any services that pin, cache, or validate certificates in custom ways. From there, teams should classify each asset by migration complexity, external exposure, and business criticality. That gives you a real sequence: inventory first, compatibility testing second, dependency mapping third, and cutover planning only after those inputs are known.
For practitioners, the best sign that the programme is real is that the team can name the owner of each domain, the replacement path for each cryptographic dependency, and the control point for each certificate lifecycle event. If any of those are unknown, the work is still discovery, not migration.
What to verify: whether the domain can support a staged change without breaking client compatibility, whether certificate automation can be updated without manual exception handling, and whether every external domain has an accountable owner who can approve the change. What to measure: the percentage of critical domains with a complete cryptographic inventory and a documented replacement order.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-57 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | PQC migration depends on managing certificate and key lifecycles for public domains. |
| SC-12 — Cryptographic Key Establishment and Management | The subject is the staged replacement of TLS and cryptographic dependencies for public domains. | |
| CM-8 — System Component Inventory | The answer starts with a baseline inventory of internet-facing domains and crypto dependencies. | |
| Recommendation — Update authenticator lifecycle controls to inventory, rotate, and replace cryptographic material in sequence. Plan key-establishment changes separately from certificate algorithm changes and validate each dependency path. Build an inventory of exposed domains, TLS endpoints, and supporting cryptographic components before migration. | ||
| NIST SP 800-57 | Key management lifecycle | PQC migration is fundamentally about the lifecycle of keys and related cryptographic dependencies. |
| Recommendation — Align key lifecycle planning to replacement order, rotation, and retirement of legacy algorithms. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The topic is cryptographic change management for public-facing services and supporting systems. |
| Recommendation — Document cryptographic usage, dependencies, and migration decisions under cryptography controls. | ||
Practitioner Guidance
What to prioritise: Start with the internet-facing assets that combine high exposure and low operational tolerance for outages. A public domain with simple TLS termination but many downstream certificate consumers should be handled differently from a smaller domain with deeply embedded cryptographic dependencies.
Decision rule: If a domain can be isolated into a pilot with clear ownership, known certificate flows, and low client risk, use it to validate the inventory model and rollout sequence. If the domain supports production traffic with brittle clients or custom trust logic, treat it as a planning input first, not an early cutover candidate.
Common mistake: Teams often treat “PQC-ready” as a binary label for the domain. In practice, readiness is layered, and the certificate algorithm, session establishment method, and renewal machinery rarely move on the same schedule.
Practitioner takeaway: The first migration deliverable is not a new algorithm, it is a trustworthy dependency map that tells you what must change, in what order, and who owns each step.
Related resources from NHI Mgmt Group
- How should security teams prioritise PQC migration for internet-facing systems?
- Why do internet-facing domains get prioritized in PQC planning?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams secure internet-facing local AI inference servers?