Crypto agility for post-quantum migration: an operating model, not a checkbox.

NIST CSWP 39upd1 frames crypto agility across protocols, applications, software, hardware, firmware, and infrastructures. That breadth matters because a modern service rarely owns its entire cryptographic path. A cipher or KEM can be embedded in a runtime, certificate profile, hardware security module, load balancer, device image, cloud control plane, supplier API, or operational procedure. Replacing one library does not prove that the complete path can change safely.

Agility is also not a synonym for post-quantum protection. A platform may switch algorithms quickly and still select an unsuitable construction, accept an insecure downgrade, or leave a legacy termination point exposed. The capability is valuable only when policy, implementation, validation, deployment, observation, and retirement remain connected. Post-quantum migration supplies a demanding use case for that capability; it does not replace the underlying engineering discipline.

The strongest architecture pattern is separation of concern. Applications request a security outcome through a stable service, provider, or policy interface; an approved profile binds that request to algorithms, parameters, key stores, certificate rules, and protocol versions. Configuration and policy are versioned, access controlled, reviewable, and deployable independently where the platform permits it. Dependency mapping shows which consumers will move when the profile changes.

This does not mean allowing arbitrary runtime algorithm selection. Unbounded plug-in behavior expands attack surface and makes assurance difficult. Maintain a small, explicitly approved set of profiles; authenticate policy updates; fail closed when a required profile is unavailable; and protect negotiation against downgrade. Where hard-coded cryptography cannot yet be removed, document it as migration debt with a replacement trigger rather than hiding it behind an agility label.

A cryptographic inventory answers what is present; an agility control plane answers who may change it, under which profile, with what evidence, and by when. Each record should connect a business service to its cryptographic use, implementation and version, key or certificate dependency, data classification, owner, supplier, target state, test status, rollout wave, and retirement evidence. Unknown ownership and unverified supplier claims should be visible risk states, not empty fields silently excluded from reporting.

Maintain a dated standards ledger alongside the inventory. Final FIPS, final guidance, Internet Standards, active Internet-Drafts, vendor previews, and internal experiments are different evidence classes. NIST IR 8547 can inform transition analysis, but its cited publication is an Initial Public Draft. That boundary prevents a roadmap from turning provisional dates or candidate mechanisms into mandatory enterprise policy without an explicit decision.

Conformance tests establish that an implementation follows the relevant algorithm or protocol specification, but production readiness needs a larger matrix. Exercise every client, server, proxy, certificate service, key store, appliance, library version, and supplier boundary that participates in the transaction. Measure handshake and message size, CPU and memory use, latency, throughput, connection failure, timeout behavior, logging, and operational recovery under representative load.

Negative tests are first-class evidence. Attempt unsupported negotiation, malformed inputs, version mismatch, expired credentials, partial deployment, unavailable key services, and downgrade paths. Rehearse rollback before release and define the security consequence of rollback: restoring service with an obsolete mechanism can be a risk acceptance, not a neutral operational step. For a hybrid construction, validate the actual combiner and protocol behavior rather than assuming that two named algorithms automatically provide two independent protections.

Most organizations cannot migrate independently of operating systems, cloud platforms, network devices, identity providers, certificate authorities, HSMs, embedded equipment, and managed services. Ask suppliers which exact product and version implements which final standard or protocol; whether capability is generally available, preview, or roadmap; what boundary has been tested; which configurations are supported; and how legacy material will be rotated and retired. A broad statement that a company is quantum-ready is not implementation evidence.

Procurement should preserve future change capacity. Require cryptographic inventory or CBOM information at an agreed level, machine-readable configuration where practical, supported profile changes, exportable logs, vulnerability and errata handling, interoperability evidence, rollback behavior, and contractual notification when algorithms or dependencies change. CISA's product-category resource helps organize vendor conversations, while the final architecture decision remains specific to the organization's threat, system, and assurance requirements.

A useful scorecard starts with coverage: percentage of in-scope services mapped, percentage of cryptographic dependencies with a known owner, and percentage of critical flows traced end to end. It then measures change capacity: median time to assess a standards update, time to publish an approved profile, time to complete testing, time to deploy, and time to retire the previous mechanism. These measures expose where the organization is waiting on architecture, suppliers, governance, or operations.

Quality measures prevent speed from becoming the only objective. Track supported-pair interoperability coverage, failed negotiations, fallback frequency, exception age, rollback rehearsal coverage, legacy dependency count, overdue certificate or key rotation, and the share of migrations with complete evidence. Report denominators and scope. Ninety percent coverage of an undefined inventory is not a meaningful readiness result.

A practical sequence is governance and discovery, risk prioritization, laboratory pilots, production pilots, scaled key-establishment migration, signature migration, and final decommissioning. OMB M-26-15 uses a comparable phased structure for United States federal non-national-security systems, with discovery in 2026–2027, pilots in 2027–2028, prioritized key establishment through 2030, signatures in 2031, and a 2035 full-migration horizon. Those dates are scoped federal direction, not universal deadlines for every private or international organization.

Define exit criteria for each wave: inventory completeness for the chosen boundary, accountable owners, final or explicitly accepted specification status, supported product versions, successful interoperability and load tests, trained operations, observed pilot behavior, a tested recovery plan, and approved residual risk. End the compatibility period by removing obsolete profiles, rotating affected material, updating evidence, and monitoring for reappearance. Keeping every old option forever is compatibility accumulation, not crypto agility.