Algorithm deprecation is not a future risk, it is a current compliance requirement with documented timelines published by NIST, NSA, and ETSI. The compliance challenge is not that these timelines are secret or hard to find. It is that they are distributed across multiple standards documents, written for different audiences, and updated on different schedules, making it operationally difficult for a security team to produce a consolidated view of which algorithms they are running and when each one transitions from active to deprecated. The Algorithm Sunset Timer consolidates this into a single reportable output. Check your algorithm timelines
What the Algorithm Sunset Timer Does
The tool tracks cryptographic algorithm deprecation timelines based on published guidance from NIST, NSA, and ETSI. For each algorithm your organisation selects, it returns the current status, governing body position, deprecation date or range, and recommended replacement algorithm.
The coverage spans the algorithm classes in common enterprise use:
Algorithms broken by Shor's algorithm (completely vulnerable to a cryptographically relevant quantum computer): RSA (all key sizes), ECDSA, ECDH, and DH. For these algorithms, "sunset" means cryptographic failure on quantum hardware. not just reduced security margin. Migration away from these is the core objective of the NIST PQC programme, which produced NIST FIPS 203, 204, and 205 as the finalised replacement standards on 13 August 2024.
Algorithms weakened by Grover's algorithm: AES-128. Grover's algorithm provides a quadratic speedup in key search, reducing AES-128's effective security from 128 bits to approximately 64 bits post-CRQC, below the recommended security threshold. AES-128 is not broken in the same sense as RSA; it retains some security margin but falls below what NIST considers acceptable for long-term use. The recommended migration is to AES-256, which retains approximately 128 bits of effective security post-CRQC and is considered quantum-resilient under current standards.
Algorithms already deprecated on classical security grounds: SHA-1. Its deprecation timeline predates quantum computing concerns entirely. NIST deprecated SHA-1 under SP 800-131A beginning in 2011 and formally prohibited it for digital signatures in 2014. The timer includes SHA-1 because organisations still encounter it in legacy systems, but its deprecation should be understood as driven by classical collision attacks (Wang et al., 2005; fully broken in 2017 by Stevens et al.) rather than quantum threat. SHA-256, by contrast, is weakened to approximately 128-bit classical equivalent under quantum but remains acceptable under current guidance.
AES-256: quantum-resilient. Grover's algorithm reduces effective security from 256 bits to approximately 128 bits post-CRQC, which remains acceptable under NIST's current security thresholds. AES-256 is the recommended migration target from AES-128.
The tool's value is consolidation, not revelation. A compliance officer who needs to confirm which algorithms are in the "transitioning" or "deprecated" state for an audit does not need to cross-reference four separate standards documents, they need a single reportable output that maps their algorithm selections to governing body positions and timelines.
Why Algorithm Deprecation Timelines Matter for Your Organisation
The transition clock started on 13 August 2024 when NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are the finalised post-quantum cryptographic standards for key encapsulation and digital signatures. The approved migration targets now exist. An organisation that has not begun mapping its current algorithm exposure to these timelines is behind its peers in the organisations that have.
CNSA 2.0 sets transition timelines specifically for National Security Systems (NSS). Commercial and private-sector organisations are not directly bound by CNSA 2.0. NSS obligations apply to US government systems and contractors operating within the NSS classification. For commercial organisations, the equivalent compliance drivers are NIST's finalised PQC standards and sector-specific regulatory frameworks. NIS2, which entered enforcement in October 2024 for EU essential and important entities, and DORA, which became applicable in January 2025 for EU financial entities, both require proportionate cryptographic risk management under their respective risk management obligations. Neither regulation mandates specific PQC algorithms; ETSI and ENISA technical guidance supports PQC migration as a demonstrable technical measure under both frameworks. UK organisations post-Brexit are not subject to EU NIS2 or DORA directly. They follow UK NIS Regulations (2018) and NCSC post-quantum cryptography migration guidance, which endorses NIST-standardised PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) and sets a three-phase migration timeline to 2035. NCSC guidance is the UK equivalent of NIST guidance for most government and critical national infrastructure purposes.
The asymmetry problem is real: once an algorithm is formally deprecated by NIST or NSA, the regulatory and audit pressure it generates arrives faster than most organisations can complete migration. An organisation that waits for RSA-2048 to be formally deprecated before beginning to act will discover that its auditors and regulators expect a migration programme already in motion, not one being initiated in response to the deprecation notice.
Most organisations do not know which cryptographic algorithms they are running. not because they lack the expertise to care, but because cryptographic inventories are rarely maintained with the same rigour as other IT asset records. Firmware records, custom application code, legacy middleware, and inherited PKI hierarchies accumulate algorithms that were provisioned years ago and never revisited. The timer cannot substitute for a cryptographic inventory, but it gives compliance teams the timeline framework to know why completing that inventory is urgent.
The RSA-2048 trajectory is particularly clear: NIST migration guidance makes the direction unambiguous, and an organisation that waits for a formal deprecation announcement before planning its migration will be migrating under time pressure rather than by design.
Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.
How to Use the Algorithm Sunset Timer
Step 1. Open the tool. No registration required.
Step 2. Select all cryptographic algorithms currently in use in your organisation. The tool presents a checklist. Tick all algorithms that apply anywhere in your cryptographic estate: RSA (select the key size if you know it), ECDSA, ECDH, AES-128, AES-256, SHA-1, SHA-256, DH, and others. If you are uncertain about the full algorithm inventory, start with the most common algorithms: RSA, ECDSA, and AES-128 as a baseline, this covers the majority of enterprise cryptographic exposure.
Step 3. Review the timeline output. Each selected algorithm displays its current status indicator (active, transitioning, or deprecated), the governing body position (NIST, NSA CNSA 2.0, or ETSI), and the deprecation date or date range.
Step 4. Identify algorithms in the "transitioning" or "deprecated" state. These are your immediate compliance concerns. For "transitioning" algorithms, the clock is running. For "deprecated" algorithms, you are already in a non-compliant state against the relevant guidance.
Step 5. Review replacement recommendations. For each flagged algorithm, the tool shows the NIST-approved replacement: ML-KEM (FIPS 203) for key encapsulation in place of RSA/DH; ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for digital signatures in place of RSA/ECDSA.
Step 6. Export the output. The tool generates a reportable format suitable for compliance documentation or a board briefing.
Practical note: organisations with layered infrastructure, cloud services, on-premises servers, OT systems, embedded devices, may need to run the algorithm selection multiple times for different layers of their estate. The timer is algorithm-aware, not asset-aware. Use it alongside the Cryptographic Asset Prioritisation Matrix to connect algorithm timelines to the specific assets that depend on each one.
How to Interpret the Algorithm Sunset Timer Results
The status labels carry specific meaning:
Active: the algorithm is currently within the acceptable use period under governing body guidance. Migration is recommended but the algorithm is not yet deprecated.
Transitioning: the algorithm is within a defined transition period. Governing body guidance requires organisations to have migration plans in place and to have begun active migration. This is not a passive status, a "transitioning" label requires an active migration programme to be underway.
Deprecated: the algorithm has been formally deprecated by the relevant standards body. If you are running a deprecated algorithm in a system subject to the relevant regulatory framework, you are operating outside compliance. Immediate prioritisation in your migration programme is required.
For algorithms with date ranges rather than specific dates: governing body guidance is sometimes expressed as a transition window (e.g. "deprecated by [year range]") rather than a single cut-off date. The range reflects that compliance windows are applied by system type or sector. Your specific date may be earlier than the end of the range if your system classification places you in the early-transition group.
To connect these timelines to your migration programme, run the Cryptographic Asset Prioritisation Matrix for asset-level prioritisation, and consult the NIST PQC Algorithm Selector to confirm which replacement algorithms are appropriate for each use case in your environment.
Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.
