AI and Post-Quantum Cybersecurity: A Migration Playbook

Post-quantum cybersecurity is no longer a contest to predict the date of a cryptographically relevant quantum computer. It is a multi-year engineering program to find where quantum-vulnerable public-key cryptography exists, understand what it protects, replace it without breaking dependent systems, and prove that old paths cannot silently return.

Artificial intelligence can help with discovery and prioritization. It can classify code findings, connect a certificate to an application owner, extract migration commitments from vendor documents, and identify likely cryptographic dependencies in configuration or architecture records. It cannot certify an algorithm, prove an implementation is constant-time, or decide that an undocumented system is safe. Deterministic scanners, protocol tests, cryptographic expertise, and standards remain the authority.

As of 30 July 2026, the implementation baseline is concrete. NIST published FIPS 203, FIPS 204, and FIPS 205 in August 2024. They specify ML-KEM for key establishment, ML-DSA as the primary lattice-based signature scheme, and SLH-DSA as a stateless hash-based signature alternative. NIST’s current post-quantum cryptography project page says organizations should begin applying the standards now and describes a transition that removes quantum-vulnerable algorithms from NIST standards by 2035, with high-risk systems moving earlier. That is enough reason to inventory and pilot now, without making sensational claims about quantum timelines.

Start With the Threat You Actually Have

Large quantum computers would threaten commonly deployed public-key mechanisms based on integer factorization or discrete logarithms, including RSA, finite-field Diffie–Hellman, elliptic-curve key agreement, and ECDSA. Symmetric cryptography has a different risk profile and is not replaced by ML-KEM or ML-DSA.

Two clocks matter:

Confidentiality clock: how long information must remain secret.
Migration clock: how long discovery, procurement, protocol changes, testing, rollout, and retirement will take.

If the sum of those periods extends beyond the organization’s acceptable quantum-risk horizon, work is already time-sensitive. “Harvest now, decrypt later” describes an adversary collecting encrypted traffic today in the hope of decrypting it later. Long-lived health, identity, defense, intellectual-property, and infrastructure data deserve priority even when the system handling them is not otherwise at the top of a normal vulnerability queue.

Signatures create a separate problem. Long-lived software updates, device firmware, legal records, code-signing chains, and archived evidence may need authenticity after today’s signing algorithms are no longer considered sufficient.

Know What the NIST Standards Do

Standard	Algorithm	Primary purpose
FIPS 203	ML-KEM	Establishing a shared secret for encryption protocols
FIPS 204	ML-DSA	General-purpose digital signatures
FIPS 205	SLH-DSA	Hash-based signature alternative with different trade-offs

A key-encapsulation mechanism is not itself a complete channel protocol. A signature algorithm is not an identity or certificate lifecycle. Applications normally consume these primitives through TLS, SSH, IPsec, PKI, code-signing, secure boot, messaging, or vendor products. Teams must follow the profile and protocol specifications relevant to that system rather than dropping a new primitive into a custom construction.

NIST selected HQC in March 2025 for future standardization as an additional key-establishment option, but selection is not the same as a published FIPS. Track ongoing work; do not mark an environment migrated based on an experimental or vendor-specific interpretation.

The NCCoE Migration to Post-Quantum Cryptography project separates the challenge into cryptographic discovery and interoperability. That is a useful operating model: first establish what exists, then prove that replacements work across real products.

Build a Cryptographic Inventory, Not a Spreadsheet of Algorithms

An inventory must connect cryptography to business and technical context. At minimum, record:

application, service, device, library, or protocol;
business owner and technical owner;
environment, network exposure, and data flow;
cryptographic function: encryption, key agreement, signature, certificate, secure boot, or update validation;
algorithm, parameter or key size, library, version, and hardware dependency;
certificate issuer, trust store, expiry, and renewal path where relevant;
protected data category and required confidentiality or authenticity lifetime;
upstream and downstream dependencies;
vendor support and contractual migration date;
evidence source, scanner timestamp, confidence, and reviewer;
target state, test status, exception, and retirement date.

Call this a cryptographic bill of materials if the term helps adoption, but do not reduce it to a package list. Runtime termination at a load balancer, a hard-coded public key in firmware, a SaaS webhook signature, a smartcard, a database client, and a disaster-recovery appliance may not appear in the same software composition report.

The joint CISA, NSA, and NIST quantum-readiness guidance emphasizes roadmaps, inventories, risk analysis, and vendor engagement. CISA has also published a strategy for automated PQC discovery and inventory tools. These sources reinforce an important point: discovery is a program, not one scan.

Use AI as a Triage Layer

An effective discovery pipeline combines different evidence types:

Deterministic collection: source and binary scanning, dependency analysis, certificate enumeration, network and protocol observation, configuration parsing, cloud inventory, hardware records, and procurement data.
Normalization: map aliases and implementation names to canonical algorithms, products, owners, and assets.
AI-assisted classification: extract likely cryptographic use from unstructured documentation, group duplicate findings, infer candidate owners, identify unclear vendor statements, and propose missing relationships.
Rule-based risk scoring: calculate priority from documented factors.
Expert validation: confirm high-impact findings, protocol meaning, remediation choice, and evidence.

Require every AI-derived field to retain its source excerpt, confidence, model version, and validation state. “Probably RSA” is a queue item, not an inventory fact.

Models are particularly useful when the evidence is messy: a decades-old architecture PDF, a ticket that names an appliance by nickname, or a vendor response that discusses “quantum-safe readiness” without naming a supported standard. They are less useful for facts a parser can establish exactly. Do not ask a language model to recognize an object identifier when a tested decoder can do it deterministically.

For a broader pattern that binds AI claims to source material and review, use evidence-first automation. If discovery agents can read repositories or ticketing systems, apply least-privilege tool design.

Prioritize With Data Lifetime and Replacement Friction

A practical priority model considers:

consequence if confidentiality or authenticity fails;
remaining secrecy or validation lifetime;
external exposure and collection feasibility;
algorithm and protocol vulnerability;
system criticality;
number of dependencies;
replacement lead time;
vendor readiness;
ability to update remotely;
and availability of a standards-conformant path.

Avoid a mysterious “AI risk score.” Publish the factors and weights, let owners challenge incorrect inputs, and retain the calculation. A simple, explainable tier is often better:

Tier 0 — immediate containment: unsupported or incorrectly implemented cryptography already creates present-day risk.
Tier 1 — early PQC migration: long-lived sensitive data, roots of trust, code signing, critical infrastructure, identity, and difficult-to-update devices.
Tier 2 — planned platform transition: major services with supported upgrade paths and manageable dependencies.
Tier 3 — monitor or retire: short-lived low-impact data, systems already scheduled for decommissioning, or standards-dependent cases without a stable deployment profile.

Do not let quantum planning distract from current cryptographic failures. Expired certificates, exposed private keys, weak randomness, obsolete TLS, bad key storage, and missing rotation need remediation now.

Design for Crypto Agility

Crypto agility is the ability to change algorithms, parameters, certificates, keys, libraries, and protocol profiles without rebuilding the entire business process. It requires more than a configuration flag.

Good design separates:

business logic from cryptographic provider;
algorithm policy from application code;
key lifecycle from deployment lifecycle;
credential format from transport;
and migration telemetry from secret material.

Maintain an allowlisted policy with explicit versions. Support controlled dual operation only where the protocol profile and security analysis define it. A hybrid construction can reduce dependence on a single algorithm during transition, but an improvised combination can add downgrade paths, parsing ambiguity, larger messages, and false confidence. Follow the standards body or product profile for the protocol.

For devices and operational technology, update size, memory, handshake latency, certificate size, boot time, hardware acceleration, and intermittent connectivity may dominate the plan. The correct target algorithm is not helpful if the device cannot receive or verify the update safely.

Test the Migration as a System

Cryptographic unit tests are necessary and insufficient. Build an interoperability matrix across clients, servers, libraries, operating systems, proxies, certificate services, hardware modules, and recovery environments. Test:

success with approved target profiles;
rejection of malformed keys, signatures, and ciphertexts;
downgrade and algorithm-confusion attempts;
certificate-chain and trust-store behavior;
key rotation and overlapping validity;
backup, restore, disaster recovery, and offline verification;
handshake size, latency, CPU, memory, and connection failure;
logging that identifies the negotiated profile without leaking secrets;
rollback that does not silently restore a vulnerable default;
and removal of the legacy path after the approved coexistence period.

Use official test vectors and validated cryptographic modules where the assurance regime requires them. AI-generated test cases can expand fuzzing ideas, but they do not replace conformance vectors or expert review.

Control Vendors and the Supply Chain

Ask vendors for specific evidence:

Which products, versions, and features use quantum-vulnerable public-key cryptography?
Which NIST-standard algorithms and protocol profiles are supported?
Is support generally available, preview, experimental, or roadmap-only?
What interoperability and validation evidence exists?
What are the upgrade, licensing, hardware, performance, and key-migration requirements?
How will legacy modes be disabled and their use observed?
What happens to archived data, signatures, backups, and devices that cannot be upgraded?
What dates, support commitments, and notification duties are contractual?

An assistant can extract these answers from questionnaires, contracts, release notes, and bills of materials. A procurement or security owner must resolve contradictions. See our AI vendor-risk and procurement guide for evidence clauses and acceptance gates.

Track Migration Metrics That Expose Unknowns

Useful program measures include:

Measure	Why it matters
Assets with verified cryptographic inventory coverage	Shows known coverage, not merely scan volume
Findings with an owner and evidence source	Reveals orphaned risk
High-priority assets with an approved target profile	Separates planning from discovery
Interoperability paths tested successfully	Demonstrates real ecosystem readiness
Legacy negotiations observed in production	Identifies remaining downgrade or compatibility use
Vendors with contractual dates and named versions	Makes roadmap language accountable
Mean revocation and key-rotation completion time	Measures operational agility
Exceptions past expiry	Exposes permanent “temporary” coexistence
Unknown or low-confidence findings	Keeps uncertainty visible

Report denominators. “Eighty percent migrated” can mean 80% of applications, connections, certificates, business flows, or findings; those are not equivalent.

Use Explicit Release and Retirement Gates

A production migration should require:

approved algorithm and protocol profile;
traceable inventory record and data-lifetime classification;
threat model and architecture review;
independent interoperability and failure testing;
performance results under realistic load and packet conditions;
validated key generation, storage, rotation, recovery, and destruction;
monitoring for fallback or legacy negotiation;
rollback conditions and time limit;
owner sign-off; and
a dated gate for disabling the old path.

Do not close the work item when the new path turns on. Close it when required counterparties have moved, evidence is complete, and the quantum-vulnerable path is disabled or governed by a time-bounded exception.

A 120-Day Program Start

Days 1–30: appoint cryptography and business owners; define inventory schema, risk tiers, evidence requirements, and target reporting. Select a representative pilot rather than the easiest demo.

Days 31–60: collect source, binary, network, certificate, cloud, hardware, vendor, and documentation evidence. Use AI only to normalize and triage ambiguous records. Validate all Tier 1 candidates.

Days 61–90: choose approved target profiles, build an interoperability lab, measure performance and failure behavior, and negotiate missing vendor commitments.

Days 91–120: deploy one bounded production path with telemetry, exercise rollback and key recovery, monitor legacy negotiation, and use the evidence to refine the larger roadmap.

Frequently Asked Questions

Can AI discover every use of cryptography?

No. Encryption may be implemented in firmware, hardware, remote services, proprietary binaries, partner systems, or traffic the scanner cannot observe. Combine methods, record coverage boundaries, and keep “unknown” as a first-class result.

Should we wait for quantum computers to become more capable?

No for inventory, agility, vendor engagement, and high-risk pilots. These activities take years and improve current cryptographic hygiene. Deployment timing should follow approved standards, protocol profiles, system risk, and interoperability readiness—not headlines.

Does adopting ML-KEM protect stored data automatically?

No. ML-KEM establishes shared secrets; it does not re-encrypt existing archives or fix key management. Teams must identify how stored data was protected, its remaining secrecy lifetime, key hierarchy, backup copies, and re-encryption or compensating-control plan.

Is a vendor’s “quantum-safe” label enough?

No. Require the exact standard, parameter set, protocol profile, product version, validation status, default behavior, interoperability evidence, and legacy-disable procedure.

Sources and Further Reading

Sources and links were reviewed on 2026-07-30.