Crypto Agility: Turn Vendor Roadmaps into Acceptance Tests

01 / Field notes

Executive Summary

A supplier can promise “crypto agility” while leaving customers unable to change an algorithm without replacing hardware, coordinating every partner or accepting an undocumented outage. The useful capability is a supported transition that preserves the required security properties and operations.

NIST's CSWP 39upd1, updated in June 2026, discusses crypto agility across protocols, software, hardware and infrastructure. NIST NCCoE's migration work also distinguishes discovery and interoperability activities. [1][2] Use that context to turn broad roadmap language into specific acceptance evidence.

This guide provides an original procurement and renewal worksheet. It is designed for technical evaluation, not as legal contract language or a guarantee that every supplier can support the same transition schedule.

02 / Field notes

Prerequisites / Lab Setup

Select a real dependency and identify its cryptographic role, owner, current version and expected service life. Gather the supplier's supported configuration, release policy and migration statements. Separate generally available capabilities from previews, experiments and planned features.

Define the business constraints before the meeting: acceptable downtime, supported clients, data lifetime, hardware replacement limits and responsibility for testing. A supplier cannot give a meaningful migration plan if the customer's required deployment population is unspecified.

03 / Field notes

Technical Analysis

Ask for the exact boundary of support

“Supports post-quantum cryptography” might refer to one connection, one library API or one optional build. Ask which operation and protocol it covers, which algorithm and parameter set are implemented, and which components remain outside that scope. Require versioned documentation rather than an undated slide.

For a fictional managed API, the supplier supports a new key-agreement group at its edge but not on a private origin connection. That is a specific capability worth evaluating. It is not equivalent to a complete end-to-end migration, and the acceptance record should say so.

Turn promises into a pilot

Choose representative clients and a staging environment. Define allowed and disallowed behavior before testing. For a signature transition, include both new and old verifiers and the intended retirement rule. For a transport change, observe actual negotiation and failure behavior across the relevant paths.

Agree on evidence that can be shared without exposing secrets: software versions, redacted configuration, negotiated identifiers, error counts and test conditions. Do not demand private signing keys or sensitive production captures as proof. If a supplier cannot expose a detail, ask what alternative assurance is available and record the limit.

Plan rollback without disguising downgrade risk

Operational rollback is important, but it may restore a security property the project is trying to retire. Document who may approve that state, how long it can remain and what compensating treatment applies. A button labeled “compatibility mode” does not remove the need for a decision.

Some transitions are not easily reversible. New signatures may be unverifiable by old components, trust-anchor changes may require coordinated updates and devices may enforce anti-rollback rules. Identify those points before rollout rather than discovering them during an outage.

Include portability and retirement

Ask how data, key references, configuration and audit evidence can be moved or retired. Avoid assuming that exporting a certificate means the entire operational dependency is portable. Hardware-backed keys, managed identities and proprietary formats may create constraints that should be understood before renewal.

Maintain an inventory entry with the supplier's response, evidence date and next review trigger. A material version change, support announcement or cryptographic advisory should reopen the relevant questions. The record should evolve with the dependency instead of remaining a one-time questionnaire.

The future value of crypto agility is resilience to many kinds of change: algorithm transitions, implementation defects and vendor replacements. Post-quantum migration is a major driver, but the same operational discipline helps when an unrelated cryptographic component needs urgent replacement.

04 / Field notes

Mitigation / Defense

Use cryptographic discovery to prepare the supplier conversation and hybrid TLS testing for one concrete pilot. Accept a capability because the evidence meets your requirement, not because the roadmap uses the most ambitious language.

05 / Field notes

References

Sources checked 28 October 2026. The current reference is CSWP 39upd1 rather than its superseded predecessor. The managed API and acceptance matrix are illustrative. No supplier's undisclosed implementation, certification or future delivery date is asserted.

1. CSWP 39upd1: considerations for achieving crypto agility ↗NIST · accessed 2026-10-28
2. Migration to post-quantum cryptography ↗NIST NCCoE · accessed 2026-10-28

Questions readers ask