Post-Quantum Migration Is an Inventory Program Disguised as Cryptography

The post-quantum deadline is easy to misunderstand because no cryptographically relevant quantum computer has arrived. That makes migration feel speculative. The data being protected, however, is moving through today’s networks. An adversary can collect a long-lived secret now and wait to decrypt it later. Meanwhile, public-key infrastructure, code-signing roots, embedded devices, and partner protocols can take a decade to replace.

NIST has standardized the first post-quantum algorithms: ML-KEM for key establishment, ML-DSA and SLH-DSA for digital signatures. Its transition planning points toward deprecating and ultimately removing quantum-vulnerable public-key algorithms by 2035, with high-risk systems moving earlier. AWS has published a migration plan, enabled hybrid post-quantum TLS for AWS KMS, and added ML-DSA signing keys to KMS.

Those milestones make implementation possible. They do not make migration a cipher-suite toggle. The central problem is that most organizations cannot enumerate where asymmetric cryptography establishes trust, which party controls each endpoint, how long the protected data must remain confidential, or which middlebox will reject a larger handshake. Post-quantum readiness begins as an asset and dependency program.

Separate three clocks

Every migration decision sits between three clocks. The first is the time until a capable quantum adversary exists, which remains uncertain. The second is the confidentiality life of the data. A health record, state secret, genomic dataset, or trade secret collected today may still matter in fifteen years. The third is replacement lead time: how long it takes to change the protocols, certificates, firmware, counterparties, and auditors that depend on the old algorithm.

Risk begins when data life plus replacement time approaches the quantum timeline. That is why waiting for a definitive breakthrough is structurally late. The organizations with the longest-lived secrets and slowest-moving infrastructure need to begin first even if the probability curve remains debatable.

Signatures add another dimension: trust life. A software update signed today may be validated by a device in service for years. A root certificate or document signature may need to remain trustworthy long after issuance. Inventory must therefore capture both confidentiality and authenticity, not simply locate TLS endpoints.

Know what must change—and what does not

Quantum attacks threaten widely used public-key systems such as RSA and elliptic-curve cryptography more directly than modern symmetric encryption. AES-256 and strong hash functions remain the recommended class of protection for symmetric use; the migration urgency is concentrated in key establishment, signatures, certificates, and the protocols built around them.

AWS KMS illustrates the distinction. Its envelope-encryption data keys use AES-256 and are already positioned for quantum resistance. But a client connecting to KMS traditionally negotiates a public-key TLS exchange, so a recorded session could have long-term confidentiality implications. AWS’s hybrid mode combines classical ECDH with ML-KEM. An attacker must break both components to recover the session secret, preserving classical assurance while adding post-quantum protection.

That hybrid approach is a transition tool, not an excuse to declare the workload “quantum safe.” It protects the network leg to KMS. It does not alter an application’s separate TLS connections, third-party API calls, SSH access, certificates, signing systems, or data exported elsewhere.

Build a cryptographic bill of materials

A useful inventory record identifies the system and owner; algorithm and key size; whether the primitive encrypts, establishes keys, signs, or authenticates; library and version; certificate authority or key provider; data classification and retention; external counterparty; hardware or firmware dependency; expiry; and known migration path.

Populate it from several sources. Certificate inventories find managed and public endpoints. Code and dependency scanning locate cryptographic libraries. Load balancer, proxy, API gateway, VPN, SSH, and service-mesh configurations expose protocols. KMS and CloudHSM metadata show centrally managed keys. Network telemetry can reveal negotiated TLS versions and key exchanges. Procurement records identify products whose cryptography is invisible to source scanners.

No single tool produces a complete list. Reconcile the evidence and explicitly record blind spots. “No vulnerable cryptography found” means little if unmanaged appliances, partner connections, and embedded clients were never examined.

Make the record continuous. A development team can reintroduce RSA after a migration unless approved algorithms are enforced in templates, libraries, and policy. Cryptographic agility is the ability to find and change primitives repeatedly, not the completion of one replacement project.

Start with controlled hybrid pilots

AWS KMS is an attractive first pilot because the provider controls the service endpoint and exposes a client setting. Supported clients can enable hybrid post-quantum TLS, and CloudTrail’s tlsDetails.keyExchange field can show X25519MLKEM768, providing evidence that the intended exchange actually occurred.

Choose a noncritical workload with direct network paths. Measure connection establishment, request latency, CPU, throughput, packet size, retry behavior, and cost before and after. Exercise proxies, inspection devices, NAT paths, and older runtime images. Larger post-quantum messages can trigger assumptions in middleboxes that ordinary functional testing misses.

Then expand by dependency cohort rather than flipping an organization-wide flag. A workload using the same runtime, SDK, proxy, and egress architecture gives reusable evidence. Maintain a tested rollback because availability is part of cryptographic security.

Telemetry is the acceptance criterion. A configuration saying post-quantum is enabled does not prove every connection negotiated it. Measure the percentage of eligible KMS calls using the expected key exchange and investigate fallback.

Treat ML-DSA as a lifecycle decision

AWS KMS now supports ML-DSA key pairs in the standardized 44, 65, and 87 parameter sets for signing and verification. That can simplify protected key custody and provides a concrete place to test post-quantum signatures. It does not mean every verifier, certificate format, package manager, or partner accepts those signatures.

Map the complete signing ecosystem: who creates the signature, where public keys are distributed, what validates it, how revocation works, how long validation must remain possible, and whether dual signatures are supported. Code signing, artifact attestation, documents, and device firmware have different lifetime and interoperability requirements.

Avoid a permanent dual-signature limbo in which the classical signature remains sufficient forever; an adversary will target the weaker path. Define the condition under which the post-quantum signature becomes mandatory and the classical path is retired.

Put requirements into procurement now

Much of the migration schedule belongs to vendors. Contracts signed in 2026 can either accelerate or block the 2030s transition. Ask suppliers for their cryptographic inventory, NIST-standard algorithm roadmap, hybrid support, firmware and client upgrade mechanism, telemetry, backwards-compatibility plan, and end date for quantum-vulnerable defaults.

Require evidence, not the phrase “quantum ready.” Which algorithm and parameter set? Which product version? Which interface? Is the feature generally available or planned? Does it cover transport, stored keys, signatures, or all three? Can the customer verify negotiation?

For long-lived equipment, make upgradeability and support duration selection criteria. A cheap appliance with immutable cryptography can become the most expensive item in the migration.

Govern the program by risk burned down

Counting post-quantum certificates rewards activity, not reduced exposure. Track the percentage of cryptographic uses inventoried with an owner; high-risk data flows protected against harvest-now-decrypt-later; long-lived trust anchors with approved migration plans; eligible connections negotiating hybrid exchange; critical vendors with dated commitments; and exceptions past expiry.

Risk acceptance should name the vulnerable primitive, affected data or trust function, exposure duration, dependency blocking change, compensating controls, and retirement date. “PQC not supported” is a status, not an exception rationale.

The program needs security architecture, PKI, application engineering, networking, procurement, legal, records management, and business owners. Cryptographers choose safe primitives. The enterprise changes the system around them.

The work to begin this quarter

Name an accountable executive and technical owner. Define a common inventory schema. Select the ten data flows with the longest confidentiality life and the ten trust systems with the longest replacement time. Pilot hybrid KMS transport in one well-instrumented workload. Add post-quantum questions to new contracts and renewals. Establish telemetry and an exception register.

None of those steps requires a prediction of the day a quantum computer breaks RSA. They respond to the facts already known: standards exist, migration takes years, secrets are being collected now, and unseen dependencies dominate the schedule.

Post-quantum migration looks like advanced mathematics from a distance. Up close, it is disciplined systems management: find the trust, understand its lifetime, replace it in stages, and prove that every hop changed.

Sources and reporting notes

• AWS post-quantum cryptography migration plan, updated April 23, 2026.
• NIST Post-Quantum Cryptography project, including FIPS 203, 204, and 205 and transition guidance.
• AWS KMS hybrid post-quantum TLS documentation, consulted for scope, supported clients, and performance considerations.
• AWS KMS ML-DSA documentation, consulted for signing support and parameter sets.

---

CloudDefender helps security teams connect cryptographic exposure to the cloud resources, data paths, and owners behind it—turning a distant algorithm deadline into an accountable migration program.