PQC StatusCrypto agility is the ability of a system to change its cryptographic algorithms, parameters and keys without rewriting application code and without waiting for a new product release. It is not a feature you buy: it is a set of engineering properties, mainly configuration instead of hardcoded choices, protocol level negotiation, a current inventory, clean abstraction boundaries, and automated key and certificate lifecycles. Regulators now describe the same capability in their own words, for example the DORA technical standards require an encryption policy with provisions for changing cryptographic technology as cryptanalysis develops.
What crypto agility means
A useful working definition: a system is cryptographically agile when a competent operator can swap an algorithm, a key size or a protocol version in a controlled change window, using configuration and automation that already exist, and can prove afterwards what is now in use. The test is operational, not theoretical. If changing a key exchange group means editing source code, rebuilding a container image, renegotiating with a vendor or discovering undocumented dependencies, the system is not agile, whatever its documentation claims.
Three distinctions are worth holding on to:
- Agility is not the same as post-quantum readiness. Post-quantum cryptography (PQC) is a destination. Agility is the vehicle. A server that offers a hybrid post-quantum key exchange today but cannot change it next year has solved one migration and prepared for none.
- Agility is not negotiation alone. Transport Layer Security (TLS) negotiates. Stored data formats, signed firmware, hardware security modules, payment terminals and embedded devices often do not. Those are where agility has to be designed rather than configured.
- Agility has an order of priority. Harvest now, decrypt later (HNDL) describes recorded traffic that an adversary keeps until decryption becomes possible. Recorded sessions are protected only by the key exchange, which is why key establishment migrates first and signatures can follow. Our article on harvest now, decrypt later explains that ordering in detail.
Configuration over code, negotiation over hardcoding
The first property is that algorithm selection lives in configuration that an operator owns, in one place per host or per service, and is reviewed like any other control. Centralized cryptographic policy beats per application flags, because per application flags are what get forgotten.
TLS: named groups and an ordered preference list
In TLS 1.3 the key exchange is a named group, negotiated per connection. The Internet Assigned Numbers Authority (IANA) registry lists the hybrid groups X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED), alongside the pure ML-KEM groups (IANA TLS parameters). ML-KEM is the key encapsulation mechanism (KEM) standardized by NIST in FIPS 203 on 13 August 2024. RFC 10024 (August 2026) specifies post-quantum traditional hybrid key agreement for TLS 1.3.
An agile configuration states an ordered preference and keeps a classical fallback, so that a client which does not support the hybrid group still connects. OpenSSL 3.5 or later is required for the ML-KEM groups:
# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2
Verify from the outside before and after any change, with a read only test:
# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'
At the web server layer the same preference is one directive, for example ssl_ecdh_curve X25519MLKEM768:X25519; in nginx built against a suitable OpenSSL. Our guide to enabling ML-KEM on nginx, Apache, HAProxy and Caddy gives the per product syntax and the version minimums. Test in staging first, and keep the fallback group.
SSH: the same pattern, already shipped
OpenSSH is a good model of agility in practice. Version 9.0 (8 April 2022) made a hybrid key exchange the default. Version 9.9 (19 September 2024) added mlkem768x25519-sha256. Version 10.0 (9 April 2025) made it the default key agreement, and 10.1 (6 October 2025) warns when a connection negotiates a non post-quantum key agreement, through WarnWeakCrypto, enabled by default (OpenSSH release notes). Operators who had expressed preferences in configuration inherited the change; those who had pinned one algorithm in scripts did not.
# list what this client supports, then set an ordered preference
ssh -Q kex
# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256
Inventory, abstraction and automation
An inventory you can query, not a spreadsheet you rewrite
You cannot change what you cannot list. An inventory earns its place when it answers a question in minutes: which services still negotiate a classical only key exchange, which certificates use which signature algorithm, which libraries provide the primitives, and who owns each. Record at least the asset, the protocol and version, the algorithms and key sizes, the purpose, the owner, the library or module version, and the renewal mechanism. A cryptographic bill of materials (CBOM) is one machine readable way to hold this; see what a CBOM is. Treat the CBOM as our suggested practice rather than a legal requirement.
Abstraction layers that hide the algorithm
Application code should ask for a capability, not a name. Four patterns carry most of the benefit:
- Call through a provider or a thin internal library. One module resolves policy to primitives, so one change propagates.
- Version every stored format. Prefix ciphertexts, tokens and signed envelopes with an algorithm identifier and a format version, so old data stays readable while new data uses the new algorithm.
- Never assume sizes. ML-KEM public keys and ciphertexts, and ML-DSA signatures, are considerably larger than their elliptic curve equivalents. Fixed length database columns, fixed buffers, message size caps and protocol fields sized for 32 byte keys are the most common hard blocker. Prefer length prefixed fields.
- Keep a dual verify path. Accept and verify both the old and the new algorithm during the transition, then remove the old one on a dated schedule.
Keys and certificates that rotate without a human
Rotation you perform once a year by hand is not a control, it is a rehearsal you will fail. Automated issuance and renewal, short certificate lifetimes, and an alert on an unrenewed certificate are what make an algorithm change routine: when the signature algorithm changes, the pipeline simply issues different certificates. Rotation drills belong in the change calendar. Stateful hash-based signatures (LMS and XMSS, standardized in NIST SP 800-208) are an exception that proves the rule: their state handling makes naive duplication of a signing key unsafe, so they need deliberate key management rather than generic automation.
Where regulation asks for agility, and what evidence fits
Several texts require the capability without using the phrase. The table separates what each text literally says from how we suggest evidencing it. This is information, not legal advice: confirm your own obligations with your counsel or supervisor.
| Source | What the text requires | Evidence that fits (our interpretation) |
|---|---|---|
| DORA, Commission Delegated Regulation (EU) 2024/1774, Art. 6 | An encryption and cryptographic controls policy including provisions for updating or changing cryptographic technology based on developments in cryptanalysis | A policy clause naming the trigger, the decision owner and the change procedure, plus the last dated review |
| DORA RTS Art. 7 | Key management across the whole lifecycle, and a register of certificates for ICT assets supporting critical or important functions | A certificate register with issuer, algorithm, expiry and owner, and renewal automation logs |
| PCI DSS v4.0.1 requirement 12.3.3 (mandatory since 31 March 2025) | Cipher suites and protocols in use documented and reviewed at least every 12 months, with monitoring of continued viability and a documented strategy for anticipated cryptographic changes | A per service cipher suite inventory, the dated annual review, and the migration plan it refers to |
| NIS2, Directive (EU) 2022/2555, Art. 21(2)(h) | Policies and procedures regarding the use of cryptography and, where appropriate, encryption | The same policy, mapped to national transposition |
| US federal: OMB M-26-15 (24 June 2026) | An automated, continuously updated cryptographic inventory for agencies | Tooling output on a schedule, not a manually maintained file |
Read the exact wording in Regulation (EU) 2024/1774, and see our pages on DORA and PCI DSS v4.0.1 for the dated milestones. Keep the hedges straight: the EU Coordinated Implementation Roadmap v1.1 is coordinated guidance for Member States rather than a regulation binding companies, BSI TR-02102-1 is a technical guideline, ANSSI states that its post-quantum recommendations are not yet regulatory obligations outside its regulated scope, and NIST IR 8547 remains an initial public draft.
Pitfalls that quietly defeat agility
- Pinning one algorithm in code or scripts instead of expressing an ordered preference in configuration.
- Removing the classical fallback too early. Keep X25519 after X25519MLKEM768 until your client population is measured.
- Keeping obsolete pre-standard groups. The Kyber draft TLS groups are obsolete: move to X25519MLKEM768 and the other registered hybrids.
- An inventory without owners. A list no one is accountable for does not produce change.
- Forgetting the long lived artefacts: signed firmware, document signatures, backups and archived data outlive the systems that created them.
Measure what your systems negotiate today
Agility starts with an honest baseline, and the externally visible part of it is quick to obtain: scan your domain with PQC Status to see which TLS versions, cipher suites, key exchange groups and certificate algorithms your server actually negotiates. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation, as our methodology page explains. The concrete next step is to take that result, record each service in your cryptographic inventory with an owner, then move algorithm selection for one service into central configuration and rehearse changing it in staging.