Crypto-agility: definition, challenges and roadmap for 2026-2029
Crypto-agility is an organisation's ability to replace a cryptographic algorithm, key or certificate without interrupting its services or rewriting its applications. It underpins two concurrent workstreams: migration to the post-quantum algorithms standardised by NIST in 2024, and the reduction of TLS certificate lifetimes to 47 days by 2029, a timeline on which SPIE Switzerland supports companies and public administrations across Switzerland.
This article answers the questions an IT manager or CISO is likely to ask: what exactly the concept covers, why it is becoming an implicit regulatory requirement, what steps are required to build it, and what timeline to follow through 2029.
What is crypto-agility?
Crypto-agility is the set of technical, organisational and contractual capabilities that make it possible to replace and adapt cryptographic algorithms in protocols, applications, software and hardware, either as planned or in response to a vulnerability, without service interruption or redesign of the systems that depend on them.
The definition used by standards bodies stresses the word “capabilities”: crypto-agility is neither a product nor an isolated security measure, but a property of the architecture and the organisation. It covers protocols (TLS, IPsec, SSH), business applications, software libraries, hardware components (HSMs, smart cards, PLCs) and the infrastructure that connects them.
A crypto-agile organisation can answer three questions within a few days: where each encryption mechanism is used, who configures it, and what happens if an algorithm switch has to be made under time pressure. The opposite is the 2009 banking application with RSA-2048 hard-coded into it, for which the source code is no longer available.
A concrete sign that the topic has moved beyond forecasting: since 2024, Chrome and Cloudflare have deployed the X25519MLKEM768 hybrid by default for TLS key establishment. Your browser is already doing post-quantum cryptography without you having decided it should, which raises the corresponding question on the server side.
What is a cryptographic algorithm?
A cryptographic algorithm is a mathematical process that transforms data to guarantee its confidentiality, integrity or authenticity. There are three families of primitives: symmetric encryption (AES), asymmetric encryption and signatures (RSA, ECDSA, ECDH), and hash functions (SHA-2, SHA-3). Today's asymmetric algorithms are the ones directly threatened by quantum computers; symmetric algorithms and hash functions, as far as is currently known, only require longer keys.
What are the different levels of crypto-agility?
There are three levels of cryptographic agility: the operational level (renewing keys and certificates), the algorithmic level (substituting one primitive for another) and the architectural level (evolving protocols, libraries, HSMs and suppliers). Each level calls for different tools, skills and lead times.
Most Swiss organisations have partial control of the first level and only discover the other two during an audit. The architectural level is the most expensive because it involvesequipment with depreciation cycles of ten to fifteen years: building management systems, industrial controllers, payment terminals, network equipment.
Why does crypto-agility matter for your organisation?
Crypto-agility matters because the operational lifespan of algorithms keeps getting shorter: SHA-1 and RSA-1024 have been retired, RSA and elliptic curves will become obsolete in the face of quantum threats, and public certificates will be valid for only 47 days in 2029. Without this capability, every transition becomes an emergency project; with it, replacing an algorithm becomes planned maintenance.
The first driver is the quantum threat, summed up as “harvest now, decrypt later”. A TLS stream intercepted and stored in 2026 can be decrypted retroactively once a sufficiently powerful quantum computer becomes available. Any data whose confidentiality must hold for more than a decade, such as patient records, industrial patents, or information covered by banking secrecy or the Federal Act on Data Protection (FADP), is therefore exposed today, even though the machine capable of breaking RSA does not yet exist.
The second driver is regulatory. FINMA expects supervised institutions to manage operational risks, including information technology and cyber risks; the FADP requires technical measures proportionate to the risk; the Information Security Act (ISA) governs information security within the Confederation and among its suppliers. In Switzerland, it is the National Cyber Security Centre (NCSC) that publishes the reference technical recommendations for the post-quantum transition, not a foreign authority. None of these texts names a specific algorithm, but all of them make it indefensible to keep using encryption whose obsolescence is publicly documented.
The third driver is business strategy. Major contracting organisations, in Switzerland as in the European Union, are including post-quantum readiness in their supplier questionnaires and outsourcing contracts. A provider unable to document its cryptographic inventory loses tenders before the technical discussion even begins.
5 steps to building a crypto-agility strategy
A crypto-agility strategy is built in five steps: achieve full cryptographic visibility, prioritise assets according to data lifespan, introduce an abstraction layer (PKI, KMS, centralised libraries), automate key and certificate lifecycle management, and establish governance with regular switchover exercises.
- Cryptographic inventory and visibility. A discovery tool scans the network, code repositories and configurations to produce a cryptographic bill of materials (CBOM): algorithms, key sizes, locations, owners. The most frequent findings are forgotten self-signed certificates on building management system equipment and unmaintained TLS libraries.
- Risk analysis and prioritisation. Each asset is scored on data sensitivity, required confidentiality period and ease of replacement. Key exchange flows protecting long-lived data go to the top of the list.
- Abstraction. Cryptographic calls are centralised in an internal PKI, a KMS and validated libraries, so that an algorithm change is made through configuration rather than by modifying application code.
- Lifecycle automation. Key issuance, renewal, revocation and rotation run through standard protocols (ACME, EST, SCEP) and monitored pipelines.
- Governance and exercises. A cryptographic policy sets out authorised and deprecated algorithms; an annual exercise simulates the withdrawal of an algorithm, much like an incident response drill.
The classic trap is buying a discovery tool without assigning an owner to each asset: the inventory goes stale within six months and the operational ability to switch still does not exist. Prioritisation must be validated by the business units, because they are the ones who know the real lifespan of their data.
How to migrate to post-quantum cryptography: a practical guide
Post-quantum migration means replacing RSA and elliptic curves with the standards published by NIST in 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. France's ANSSI recommends a hybrid approach that combines a classical algorithm with a post-quantum one for the duration of the transition.
The first decision concerns sequencing. Key exchange comes before signatures, because TLS traffic recorded in 2026 and decrypted in 2036 is real damage, whereas a signature broken after the fact does not invalidate an authentication that has already taken place. Site-to-site VPNs, encrypted backups and long-term archives are therefore dealt with first.
The second decision concerns hybridisation. Combining ECDH and ML-KEM in a single exchange, as X25519MLKEM768 already does in Chrome, protects against as-yet-unknown weaknesses in the new algorithms, at the cost of a moderate computational overhead. Message sizes, however, increase significantly: an ML-DSA signature is considerably larger than an ECDSA signature of comparable security level, which lengthens TLS handshakes and can saturate constrained links or industrial controllers.
The third decision concerns hardware components. Many installed HSMs, gateways and smart cards will never receive post-quantum firmware. Their replacement must be planned in the infrastructure budget and in maintenance contracts; otherwise, the software migration may be blocked by a device with a fifteen-year depreciation cycle.
Cryptographic agility and TLS/SSL certificate management
The CA/Browser Forum is reducing the maximum validity of public TLS certificates from 398 days to 200 days as of 15 March 2026 (ballot SC-081), then to 100 days on 15 March 2027 and to 47 days on 15 March 2029. At this pace, manual renewal becomes unmanageable: automation via the ACME protocol is the foundation of certificate agility.
The rationale for this reduction is twofold. First, a compromised certificate or private key now offers a window of exploitation of only a few weeks. Second, a certificate estate renewed every seven weeks can adopt a new signature algorithm or key length in under two months, whereas an annually renewed estate would retain its old certificates for more than a year.
The constraint also applies to domain control validation (DCV), whose reuse will be limited to ten days in 2029. For an organisation running several hundred digital certificates on load balancers, customer portals and network equipment, automated renewal is the only viable method at this frequency.
How to organise automated renewal
An ACME deployment is built in four layers: an ACME client per platform (certbot, acme.sh, win-acme or the load balancer's built-in agent), a suitable validation method (DNS-01 for wildcard certificates and internal servers, HTTP-01 for public-facing sites), a public or private issuing authority that supports ACME, and monitoring that raises an alert ten days before expiry. Internal certificates follow the same discipline through an enterprise PKI, so that teams do not have to maintain two separate processes.
2026-2029 roadmap: post-quantum readiness in Switzerland
In Switzerland, no law yet sets a deadline for post-quantum migration, but FINMA, the FADP and the ISA all require security measures proportionate to the risk. The NCSC publishes the reference technical recommendations for Swiss organisations. The European Union's coordinated roadmap targets 2030 for high-risk use cases and 2035 for everything else. A Swiss organisation should have completed its inventory in 2026 and secured its critical flows before 2030.
- 2026: complete cryptographic inventory, owners assigned, first 200-day certificates, cryptographic policy approved by senior management
- 2027: move to 100 days, ACME automation rolled out across the board, hybrid ML-KEM pilots on VPNs and backups, post-quantum clauses in new supplier contracts
- 2028: hybrid key exchange extended to all external flows, replacement plan for HSMs and incompatible equipment, first ML-DSA signature tests
- 2029: 47-day certificates, DCV reuse limited to ten days, switchover of code and firmware signing, algorithm withdrawal exercise
- 2030 and beyond: high-risk flows fully post-quantum, gradual decommissioning of classical algorithms in remaining systems
The European timeline has a direct impact on Swiss exporters and on service providers to financial institutions, which must align with their customers and partners. The movement is international: several national authorities, including the NCSC in Switzerland, have issued calls to action on the post-quantum transition, and leading federal administrations have made the issue one of their digital security priorities.
Checklist: 10 immediate actions to start your crypto-agile transformation
Ten actions make it possible to get started on crypto-agility without a heavy transformation programme: they cover inventory, accountability, certificate automation and contract clauses, and can be carried out with existing teams and budgets within one to two quarters.
- List public certificates and their expiry dates using Certificate Transparency logs
- Scan internal TLS ports to identify protocol versions and active cipher suites
- Assign a named owner to every application that uses cryptography
- Classify data by required confidentiality period (under 5 years, 5 to 10 years, over 10 years)
- Deploy an ACME client on an initial non-critical scope and measure the successful renewal rate
- Ask software vendors and hardware manufacturers about their timeline for supporting post-quantum algorithms
- Add a crypto-agility clause to new outsourcing and maintenance contracts
- Enable hybrid key exchange (X25519MLKEM768 or equivalent) on a test VPN tunnel between two sites
- Write a one-page cryptographic policy listing authorised, tolerated and prohibited algorithms
- Schedule a tabletop algorithm withdrawal exercise with the infrastructure, application and compliance teams
FAQ: answers to frequently asked questions about crypto-agility
What is the difference between post-quantum cryptography and quantum cryptography?
Quantum cryptography refers to mechanisms based on the physical properties of quantum mechanics, such as quantum key distribution (QKD). Post-quantum algorithms, on the other hand, are classical mathematical processes (standardised by NIST as FIPS 203 to 205) designed to withstand a quantum computer while running on today's infrastructure. It is this second family that can be deployed in the short term and that forms the core of post-quantum migration.
What is the best post-quantum encryption algorithm?
No single algorithm suits every use case. ML-KEM (FIPS 203) is the benchmark for post-quantum key establishment: it is the one Chrome and Cloudflare already use in hybrid mode. ML-DSA (FIPS 204) is becoming the standard for everyday signatures, SLH-DSA (FIPS 205) for very high-assurance signatures despite its large size, and HQC has been selected by NIST as a backup algorithm to ML-KEM. For data at rest, AES-256 remains appropriate. The choice depends on the size, performance and certification constraints of the components.
Why prioritise migrating key exchange before signatures?
TLS traffic encrypted with RSA or ECDH today can be recorded and decrypted retroactively as soon as a sufficiently powerful quantum computer exists: this is the so-called “harvest now, decrypt later” attack. By contrast, a digital signature broken after the fact does not invalidate an authentication that has already taken place and been logged. VPNs, encrypted backups and long-term archives must therefore migrate to ML-KEM first, even before signatures are addressed.
How do you automate TLS certificate renewal with ACME?
ACME is a standardised protocol (RFC 8555) through which a client installed on the server proves control of a domain (via a DNS record or an HTTP file), then obtains and installs a certificate without human intervention. Full automation requires a client per platform (certbot, acme.sh, win-acme or the load balancer's native agent), a compatible public or private authority, properly controlled DNS write permissions and monitoring of renewal failures. With DCV reuse limited to ten days in 2029, this automation is no longer optional.
What do the NCSC, ANSSI and NIST recommend on cryptographic agility?
NIST standardised ML-KEM, ML-DSA and SLH-DSA in 2024 and defines crypto-agility as the set of capabilities needed to replace and adapt algorithms in protocols, applications, software and hardware. France's ANSSI advocates a phased transition with mandatory hybridisation for as long as experience with the new algorithms remains insufficient. In Switzerland, the National Cyber Security Centre (NCSC) is the local reference authority: its technical recommendations are aimed directly at Swiss public administrations and critical infrastructure operators.
What is CA/Browser Forum ballot SC-081?
Ballot SC-081 is the formal CA/Browser Forum decision that sets the timetable for reducing the validity period of public TLS certificates: a maximum of 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. It also limits the reuse of domain control validation (DCV) to ten days in 2029. This timetable makes ACME automation indispensable for any certificate estate of significant size.
Key takeaways
Three points sum up the approach. Crypto-agility starts with visibility: without an up-to-date cryptographic inventory, no migration can be managed. The certificate automation imposed by the move to 47 days in 2029 is the most accessible training ground for tackling post-quantum migration. Finally, hardware and supplier contracts determine the real timeline far more than application code does.
SPIE Switzerland supports Swiss companies and institutions in inventorying their cryptographic estate, automating their ICT services and preparing their technical infrastructure for the post-quantum era. To assess your organisation's crypto-agility maturity, visit our cybersecurity page or contact our teams.