Cryptographic Agility Is a Governance Discipline, Not a Feature

The phrase "cryptographic agility" has entered procurement vocabularies at precisely the moment it is least understood. Vendors cite it in product sheets. Security teams name it as a strategic objective. The gap between naming the capability and possessing it remains unaddressed.

The question is not whether an organisation intends to be cryptographically agile. It is whether the governance, inventory, and architectural abstraction exist to make that intention operational. Without all three, cryptographic agility is a label, not a capability.

Agility Without Architecture Is a Vocabulary Exercise

NIST's Cybersecurity White Paper 39 (CSWP 39), updated in June 2026, defines cryptographic agility as "the capabilities needed to replace and adapt cryptographic algorithms" across protocols, applications, libraries, software, hardware, firmware, and infrastructure. The definition is deliberately broad because the problem is structural, not algorithmic.

Consider Triple DES. AES was standardised in 2001. Triple DES remained in production for over two decades afterwards, until NIST disallowed it in 2024, because algorithm references were hardcoded into application logic. Replacement required re-engineering the dependency chain. That is the antithesis of agility, and it persists across enterprise deployments today.

An organisation that cannot demonstrate, with documentary evidence, that its cryptographic primitives sit behind standardised APIs, that algorithm selection is policy-driven rather than application-embedded, and that tested rollback exists for failed transitions, does not possess cryptographic agility. It possesses a roadmap.

NIST CSWP 39 and Cryptographic Agility Maturity

Section 6.5 of CSWP 39 outlines a maturity model derived from the NIST Cybersecurity Framework, with four tiers. Partial: practices unstructured and unplanned, no formal crypto policy. Risk-Informed: policy approved by management but inconsistently applied. Repeatable: formally integrated into risk management, with defined roles and automated tooling. Adaptive: fundamental to organisational risk management, with policies adjusting in near real time to standards and threats. NIST also cites the Crypto-Agility Maturity Model (CAMM), a five-level framework by Hohm, Heinemann and Wiesmaier that scores implementation in finer gradations.

Both rest on the same foundation: a comprehensive inventory of cryptographic components, which NIST lists as algorithms, protocols, libraries, applications, certificates, and related crypto materials, and which industry practice has formalised as a Cryptographic Bill of Materials (CBOM). Without it, maturity assessment is speculation rather than measurement.

What the Maturity Progression Exposes

The progression exposes architecture. The higher tiers presuppose centralised, automated enforcement, for which NIST's Section 4.1 describes the Cryptographic Service Provider: algorithms exposed through a crypto API, with restrictions configured by administrators to implement policy set by the CISO. The Adaptive tier and the top of the CAMM scale converge: policy-driven, automated, responsive in near real time.

Neither model is a certification scheme. Self-reported maturity without independent validation is a claim, not a finding. The board relying on that claim carries the residual risk. SITG-Consulting's Cryptographic Agility Services deliver independent maturity assessment because self-declaration lacks the evidentiary weight regulators and auditors will require.

CNSA 2.0 and the 2027 Acquisition Gate

The NSA's CNSA 2.0 framework introduces hard deadlines. From 1 January 2027, newly acquired National Security Systems must support ML-KEM-1024, ML-DSA-87, AES-256, and SHA-384/512. By 2035, full resistance to cryptographically relevant quantum computers is required across the entire NSS estate.

Defence contractors, vendors, and integrators supplying into NSS environments must now demonstrate CNSA 2.0 readiness in procurement responses. Major defence acquisitions run 18 to 36 months, so RFPs drafted today are already subject to these requirements.

Cryptographic agility is embedded in this timeline by necessity. A system delivered in 2028 that supports ML-KEM-1024 but cannot transition to its successor without re-engineering is compliant on delivery and non-compliant on the next update. That is a single-use compliance exercise with a built-in expiry date, not agility.

The Governance Gap: Who Owns Cryptographic Agility?

NIST's strategic plan calls for a responsible official to lead the effort, with requirements communicated to data owners, IT and development teams, business partners, and supply chain vendors; Section 4.1 places policy with the CISO and enforcement with system administrators. The governance question is which of these holds decision authority over algorithm selection, deprecation, and transition scheduling.

In practice, this authority is fragmented. Application teams select algorithms from library defaults. Network teams inherit protocol-level choices. The CISO sets policy in principle but lacks enforcement mechanisms. No single function can say how long a mandated transition would take.

A defensible posture requires crypto policy documents, CSP enforcement logs, per-system maturity reports, and transition procedures tested under operational conditions. Absence of any component leaves the claim of agility unsubstantiated. DORA already requires EU financial entities to govern ICT risk encompassing cryptographic controls. Regulatory examination of these claims will intensify.

Cryptographic Agility as a Lifecycle Discipline

Agility is not a state achieved once. It is a lifecycle discipline of continuous inventory management, periodic maturity assessment, governance review, and transition testing, and it degrades the moment it stops being resourced.

FIPS 140-3 validation timelines illustrate the point. A validated module today may not support the algorithm set required in 18 months. Organisations relying on validated implementations must factor validation lead times into transition planning, or accept the gap between standardisation and validated availability as an operational risk requiring documented board-level acceptance. SITG-Consulting's FIPS 140-3 Gap Analysis addresses this intersection.

Three Questions for the Board

Three questions separate cryptographic agility from an aspirational roadmap.

Does a complete cryptographic inventory exist, and when was it last independently verified?

What is the organisation's cryptographic agility maturity level, and was that assessment independently conducted or self-reported?

If a regulatory directive arrived tomorrow requiring deprecation of a specific algorithm, how many days would the transition take, and what documented evidence supports that estimate?

An organisation that cannot answer all three has a governance gap, not a technical gap. SITG-Consulting's PQC Readiness Assessment and Cryptographic Agility Services close it: converting aspiration into auditable, board-reportable capability.