Is the cryptographic choice configurable, hard-coded, product-controlled or supplier-controlled?
Why it matters
Cryptographic risk becomes operational risk when change is difficult.
Algorithms can be deprecated, vulnerabilities can emerge and standards can change. The risk is therefore not only whether unacceptable cryptography exists, but whether affected services can move to an acceptable alternative in time.
Legacy applications, embedded choices, vendor roadmaps, unsupported protocols, hardware, interoperability and business availability can all extend the real remediation window.
What to assess
Agility is a property of a dependency, not a yes/no enterprise label.
Which approved alternatives are already supported and interoperable?
What testing, certification, downtime or coordinated change would migration require?
Which vendors, platforms, hardware or counterparties control the migration path?
Can old and new cryptography coexist during a staged transition?
How quickly can affected services be identified and prioritised?
Risk lens
Two systems can use the same algorithm and have very different risk if one can change through configuration while the other requires hardware replacement and coordinated ecosystem change.
What enables agility
Configurable algorithms are only one part of the capability.
Visibility
Current cryptographic inventory and dependencies.
Approved alternatives
Defined standards and transition options.
Flexible implementation
Designs that avoid unnecessary hard-coding and proprietary coupling.
Interoperability planning
Understanding clients, servers, partners and coexistence requirements.
Testing & rollback
Repeatable validation of security, functionality, performance and recovery.
Supplier readiness
Roadmaps and commitments for products that constrain cryptographic choices.
What good governance looks like
Agility is designed and governed before an urgent migration.
Known constraintsSystems where change is hard, slow or externally controlled are visible.
Supported alternativesApproved target options and product capabilities are understood.
OwnershipTechnical, service and risk accountability for migration is clear.
Transition planningCoexistence, sequencing, testing, rollback and continuity are considered.
Supplier evidenceCritical vendor roadmaps and unresolved dependencies are tracked.
Change metricsTime-to-identify, plan, test and migrate can be measured for priority changes.
Resilience question
What can we change today so that the next cryptographic transition is faster, safer and more predictable?
What to do next
Reduce future migration friction deliberately.
Find constrained dependenciesPrioritise critical services with hard-coded, hardware-bound or supplier-controlled cryptography.
Define target alternativesKeep approved standards and transition patterns current.
Build change pathsDesign coexistence, testing and rollback before a deadline forces migration.
Influence procurementRequire cryptographic adaptability and roadmap transparency from strategic suppliers.
Learn from each migrationUse current remediation to remove the architectural constraint that made change difficult.
Quantum readiness
PQC is a major test of crypto-agility — not its only purpose.
The post-quantum transition exposes how deeply cryptography is embedded and how difficult coordinated migration can be.
The same capability supports future deprecation, vulnerability response, protocol change and technology refresh.
Authoritative sources