Post-Quantum Migration for NHIs Guide: Preparing Machine Credentials

Most quantum-vulnerable keys in an organisation do not belong to people: they belong to workloads, devices, pipelines and integrations that nobody will notice until a migration breaks them. Certificates for mTLS, SSH host and user keys, JWT signing keys, code signing keys and device identities are created by automation, embedded in configuration and often owned by no one. That makes non-human identities (NHIs) both the bulk of post-quantum work and the part most likely to be missed. This guide is for NHI programme owners, PKI teams and platform engineers. It covers how to find machine credentials that use RSA and elliptic curve cryptography, what the standards and protocols support as of October 2026, how to prioritise and sequence migration, and how to measure it. General post-quantum strategy is covered in the Post-Quantum Cryptography Migration Guide and identity-wide readiness in the Post-Quantum Readiness Guide; this page does not repeat them.

Key takeaways

• NIST's 2035 date applies to machine keys too. The draft NIST IR 8547 proposes disallowing RSA, ECDSA, EdDSA and ECDH after 2035, with 112-bit strengths deprecated after 2030, and the NCSC asks for discovery by 2028 and completion by 2035.
• Key exchange can move now, signatures mostly cannot. Hybrid ML-KEM is standardised for TLS 1.3 and default in OpenSSH, while post-quantum signatures in certificates, SSH and tokens are standardised but thinly supported.
• Short-lived credentials are an advantage. Workloads that receive certificates and tokens automatically can change algorithm by changing the issuer; static keys and embedded trust anchors are where migration stalls.
• Inventory by credential, not by server. The unit of work is each key, its algorithm, its issuer, its relying parties and its owner.
• Size and verification support are the real constraints. ML-DSA public keys and signatures are many times larger than ECDSA ones, and every verifier must understand the new algorithm before an issuer can switch.

Why NHIs carry most of the migration

A person typically has a handful of public-key credentials, such as a passkey or smart card. A single Kubernetes cluster can issue thousands of workload certificates a day. Machine credentials are also the ones with the longest verification tails: a firmware signature checked by a device for fifteen years, a code signing chain checked by every installed copy of a product, or a JWKS endpoint trusted by dozens of partner APIs. Each of these needs every verifier updated before the signer can switch. The NCSC notes that confidentiality protections can be migrated soonest, while certificate-based PKI and IoT and ICS protocols will follow more slowly. For NHI teams that means two parallel tracks: switch key exchange where platforms allow, and prepare signature migration through inventory, agility and supplier pressure.

The standards and timelines, as of October 2026

IR 8547 permits hybrid approaches during the transition: the SP 800-56C composite technique combines a classical and a post-quantum shared secret, and dual signatures are acceptable provided at least one component algorithm is NIST-approved. It also states NIST does not expect to transition away from symmetric standards such as AES as part of this migration, so HMAC-signed tokens, symmetric API keys and secrets encrypted with AES are not the priority.

Machine credential types and their migration path

For deeper treatment of each credential type see the Machine Identity, PKI and Certificate Lifecycle Guide, the SSH Key Management Guide and the Code Signing Security Guide.

Building a machine credential crypto inventory

A post-quantum inventory for NHIs is an extension of the NHI inventory you should already hold, with algorithm fields added. The NCSC recommends combining top-down discovery (core services and architecture) with bottom-up discovery (low-level cryptographic use), and covering cloud, on-premises, network equipment, endpoints and IoT.

• Certificates: export every issued certificate from internal CAs, cloud certificate services and service mesh CAs, and scan endpoints for presented certificates. Record public key algorithm and size, signature algorithm, issuer, lifetime and the workload it identifies.
• Token signing keys: pull JWKS from every IdP, authorisation server and STS. The kty, alg and crv values show the algorithm directly. Record every relying party that validates them.
• SSH: list host keys and authorised user keys by type, and log negotiated key exchange algorithms on servers to see which clients still negotiate classical-only exchange.
• KMS and HSM keys: list asymmetric keys by key spec in each cloud KMS and HSM partition. Note that in AWS KMS the key spec is fixed at creation, so an ML-DSA key is a new key, not a setting change.
• Code and libraries: search source and dependency manifests for cryptographic libraries and hard-coded algorithm names. A cryptographic bill of materials (CBOM) records the result per application.
• Third parties: list which vendors hold or validate your machine credentials, and ask for their roadmap. The NCSC explicitly asks organisations to check that managed service providers are doing the same assessment.

For each credential, record an owner. Unowned keys are the ones that will block a cut-over. See the NHI Ownership Guide and the Cryptographic Key Management Guide.

Prioritising and choosing a strategy

The NCSC lists five strategies for each system: migrate in place, re-platform, retire the service, run it to end of life, or tolerate the risk. For machine credentials, two questions decide the order.

• Does it protect long-lived secrets in transit? Service traffic carrying credentials, keys or long-lived personal data is exposed to capture now and decryption later. Move this traffic to hybrid ML-KEM key exchange first; it is the one change that removes a present-day risk.
• How long must its signatures be trusted, and how many verifiers are there? Firmware roots and code signing chains verified for a decade come next in planning, because their verifier base takes longest to update. Short-lived workload certificates and access tokens come later, because they can switch quickly once verifiers are ready.

Small and large organisations

Smaller organisations mostly depend on cloud providers, SaaS vendors and operating system updates. Their work is inventory, enabling hybrid key exchange when offered, removing static keys and writing post-quantum requirements into contracts. Large organisations and anyone running their own PKI, devices or IdP must also build parallel CAs, run interoperability tests and fund hardware refresh. The NCSC warns that costs could be significant and recommends budgeting for both preparation and migration.

Engineering constraints to test early

• Size: RFC 9881 sets ML-DSA public keys at 1,312, 1,952 and 2,592 bytes for ML-DSA-44, 65 and 87, against 32 to 65 bytes for typical elliptic curve keys. Signatures are several kilobytes. Test HTTP header limits for JWTs, certificate chain sizes in TLS handshakes, and storage in constrained devices.
• Pure versus pre-hash: RFC 9881 allows only pure ML-DSA in certificates and RFC 9964 does not specify HashML-DSA for JOSE. Signing services that only accept a digest need the external mu approach described in RFC 9881 Appendix D, so check what your HSM or KMS supports.
• Key formats: both RFCs use a seed as the private key format (RFC 9964 requires a 32-byte seed for JWK). Key backup, escrow and export tools must handle this.
• Fallback: the NCSC asks organisations to confirm that systems actually use post-quantum algorithms rather than silently falling back. Log negotiated groups and algorithms, do not infer them from configuration.
• Hybrid during transition: hybrid key exchange keeps classical security if a new algorithm or implementation fails. For signatures, dual signing or parallel chains let verifiers move one at a time.

Phased migration plan

1. Assign ownership. Put post-quantum migration for machine credentials inside the NHI or PKI programme with a named lead, not a separate crypto project.
2. Extend the NHI inventory. Add algorithm, key size, issuer, verifiers and expiry to every certificate, key and token signing record. Target full discovery by 2028 in line with the NCSC.
3. Reduce static credentials. Move workloads to automatically issued, short-lived certificates and tokens, so later migration is an issuer change. See the Crypto-Agility Guide.
4. Enable hybrid key exchange in a pilot ring. Turn on X25519MLKEM768 for internal TLS and mlkem768x25519-sha256 for SSH on a subset of services. Watch handshake failures, latency and middleboxes that drop larger ClientHello messages.
5. Build parallel signing infrastructure in test. Create an ML-DSA CA and test token signing keys, issue to test workloads and record which verifiers fail.
6. Roll out by verifier readiness. Switch an issuer only when every relying party in the inventory has passed verification tests.
7. Keep rollback simple. During hybrid and dual-signature phases, rollback is reverting configuration to the classical group or chain. Keep classical keys valid until the new path has run cleanly for an agreed period.
8. Retire classical algorithms. Set retirement criteria (for example, no classical-only negotiations for 90 days) and disable classical options, ahead of the 2035 date.

Detection and measurement

Collect negotiated TLS groups from load balancers, proxies and service mesh telemetry, SSH key exchange algorithms from server logs, and algorithm fields from CA issuance logs and KMS key inventories. The NCSC suggests metrics such as how many clients use post-quantum algorithms and which do not.

• Inventory coverage: percentage of known machine credentials with algorithm, owner and verifier list recorded.
• Hybrid key exchange share: percentage of internal TLS and SSH sessions negotiating a hybrid ML-KEM group.
• Classical-only clients: count of distinct workloads still negotiating classical-only exchange, trending to zero.
• Static key count: long-lived machine keys that cannot be reissued automatically.
• Verifier readiness: percentage of relying parties that pass ML-DSA verification tests per issuer.
• Supplier roadmap coverage: percentage of critical vendors with a documented post-quantum roadmap.

Common failure patterns

• Scanning only internet-facing endpoints: external TLS scans miss service mesh certificates, SSH keys, JWKS keys and embedded device roots, which is where most machine credentials live.
• Switching an issuer before its verifiers: a token or certificate signed with ML-DSA breaks every relying party that cannot parse it. Migration order is verifiers first.
• Assuming configuration equals use: a hybrid group enabled on the server is not used if clients or middleboxes do not offer it. Measure negotiated algorithms.
• Leaving static keys in place: long-lived SSH user keys and client certificates have to be found and replaced by hand, and they are often unowned.
• Buying hardware without a roadmap: HSMs, devices and appliances bought now may still be in service in 2035. Make post-quantum algorithm support a procurement requirement.
• Losing control of signing keys during the transition: parallel CAs and dual signing double the keys to protect. The GitHub code signing certificate theft shows how a machine account's token can expose signing material; new post-quantum keys need the same protection as the old ones.

Where it sits in frameworks

Practitioner checklist

• Name an owner for post-quantum migration of machine credentials inside the NHI or PKI programme.
• Add algorithm, issuer, verifier and owner fields to every certificate, SSH key, KMS key and token signing key record.
• Complete machine credential discovery by 2028, including service mesh, SSH, JWKS and devices.
• Enable hybrid ML-KEM key exchange for internal TLS and SSH where supported, and log negotiated algorithms.
• Replace static machine keys with short-lived, automatically issued credentials.
• Stand up a test ML-DSA CA and token signing key and run verifier compatibility tests.
• Write post-quantum support and roadmaps into HSM, device, IdP and SaaS procurement.
• Track the final version of NIST IR 8547 and adjust plans if dates change.

Standards and references

• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards (initial public draft)
• NIST: Post-Quantum Cryptography project (FIPS 203, 204 and 205)
• UK NCSC: Timelines for migration to post-quantum cryptography
• IETF: RFC 10024 Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3
• IETF: RFC 9881 ML-DSA in X.509 certificates
• IETF: RFC 9964 ML-DSA for JOSE and COSE
• OpenSSH: Post-quantum cryptography
• NSA: CNSA 2.0 FAQ

Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Post-Quantum Readiness Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Crypto-Agility Guide · Cryptographic Key Management Guide