Separate the destination from the capability
Selecting a post-quantum algorithm answers one question: which cryptographic approach should this use case adopt? Crypto agility answers another: how will the organisation change cryptography safely when requirements change again? Confusing the two can leave a modern algorithm inside a system that remains difficult to maintain.
NIST's migration guidance frames agility around replacing cryptographic assets without disruption and maintaining interoperability. Our perspective is that this is an operating capability as much as a design property. It needs people who can authorise a change, engineers who can deliver it and evidence that the service still behaves as intended.
Give policy a route into engineering
A cryptographic policy should identify approved uses and the process for exceptions. It also needs a route into the systems that implement it. Ask which team maintains a shared library, who controls configuration and which services depend on a provider. An instruction to replace an algorithm is not yet an executable change.
We recommend assigning both a policy owner and a service owner to significant transitions. The first explains the security requirement; the second owns operational consequences. Their agreement should cover the target state, prerequisites and acceptance evidence. Unresolved constraints belong in an explicit decision record, not in an engineer's private workaround.
Make flexibility specific to the architecture
Look for places where cryptographic choices can be changed without rewriting business logic. Depending on the system, that might mean a maintained provider interface, a shared service or controlled configuration. These are design options to evaluate, not a promise that one abstraction will make every application agile.
NCSC warns that post-quantum algorithms are not necessarily drop-in replacements for existing algorithms in protocols or systems. This makes architectural review essential. A component may support the intended algorithm while the surrounding service still needs changes. Establish what the complete communication or trust path requires before describing the service as ready.
Test the transition, not just the component
A pilot should test representative interactions between systems, including dependencies that cannot be upgraded at the same time. Define what successful authentication, connection establishment and recovery look like for the actual service. Measure relevant behaviour in that environment rather than borrowing performance claims from a different implementation or workload.
Plan how an unsuccessful deployment will be contained. A rollback route should be understood and governed, with any temporary security exposure made explicit. Where a transition uses a hybrid approach combining traditional and post-quantum cryptography, NCSC recommends treating it as an interim measure that allows a later move to post-quantum-only operation.
Keep the capability after the programme
QUAMO connects discovery across perimeter, cloud, network and code to a C-BOM and prioritised migration waves. That evidence can inform the operating model: what needs attention, who must act and which dependencies constrain the sequence. It does not remove the engineering work needed to implement and assure each change.
No product fully automates post-quantum cryptography migration. Cystel supports controlled implementation alongside QUAMO's discovery-driven roadmap. The lasting objective should be a repeatable practice for reviewing cryptographic exposure, approving changes and checking outcomes. An organisation becomes more agile when the next transition has a known route through the business, not merely a new algorithm name.