Quantum Academy
Retiring SHA-1 took the public web almost 12 years, and in 2026 some systems still depend on it. Researchers announced the first collision attack on SHA-1 faster than brute force in February 2005. Chrome stopped trusting SHA-1 certificates in January 2017, and NIST has set December 31, 2030 as the date by which SHA-1 should be phased out of every application. The fastest stage was the one where browser makers set the deadline, and the slowest began after their cutoff.
SHA-1 is a hash function. It maps any input to a 160-bit value, and a digital signature is computed over those 160 bits instead of the whole document. A collision is a pair of different inputs with the same hash, so a signature on one is valid for the other. The 2005 attack was roughly 2,000 times faster than brute force. NIST had already published the replacement, SHA-2, in August 2002.
The SHA-1 timeline
Researchers, NIST, Microsoft, Google, Mozilla and the CA/Browser Forum produced these dates. The CA/Browser Forum is where certificate authorities (CAs), the organizations that issue certificates, agree with browser makers on rules for publicly trusted certificates.
| Date | Event |
|---|---|
| February 2005 | Xiaoyun Wang, Yiqun Lisa Yin and Hongbo Yu announce a collision attack on full SHA-1 |
| March 2006 | NIST tells federal agencies to use SHA-2 for digital signatures after 2010 |
| January 2011 | NIST’s SP 800-131A deprecates SHA-1 for signature generation and disallows it after 2013 |
| November 2013 | Microsoft bars the CAs it trusts from issuing SHA-1 TLS and code-signing certificates after January 1, 2016 |
| September 2014 | Google announces Chrome’s SHA-1 sunset |
| October 2014 | CA/Browser Forum Ballot 118 passes, banning new SHA-1 certificates from January 1, 2016 |
| January 2017 | Chrome 56 stops trusting SHA-1 certificates, and Firefox 51 starts a staged rollout of the same change |
| February 2017 | CWI Amsterdam and Google announce SHAttered, the first public SHA-1 collision |
| January 2020 | Gaëtan Leurent and Thomas Peyrin publish SHA-1 is a Shambles, the first chosen-prefix collision |
| December 2022 | NIST sets December 31, 2030 for phasing SHA-1 out of all applications |
| January 2026 | The CA/Browser Forum votes to end the remaining SHA-1 signatures in public certificates and revocation lists, effective September 15, 2026 |
In a chosen-prefix collision, the attacker picks both starting documents, such as two certificates with different names. The attacker then computes an addition to each so that both have the same hash. Leurent and Peyrin estimated the cost at about US$45,000 of rented GPU time.
How long each stage took
Group the dates into stages and you get three durations.
- The standards stage lasted almost nine years, from the 2005 attack to the end of 2013, NIST’s cutoff for SHA-1 in federal signature generation. NIST set that cutoff in 2011, three years later than the end-of-2010 deadline in its 2006 policy.
- The browser stage lasted just over three years, from Microsoft’s announcement in November 2013 to Chrome 56 on January 25, 2017.
- The tail stage is almost 14 years long, from January 2017 to NIST’s 2030 end date, which is longer than the first two stages combined.
The browser stage was over before the first public collision. Google shipped Chrome 56 four weeks before the SHAttered announcement on February 23, 2017. In 2014, Chrome’s security team had said it wanted sites to stop using SHA-1 “by the time an attack against SHA-1 is demonstrated publicly.”
Run the same count for post-quantum cryptography. SHA-2 had been a published standard for almost 14 and a half years when Chrome 56 shipped. NIST published its first post-quantum standards on August 13, 2024, among them ML-KEM (Kyber) for key establishment in FIPS 203 and ML-DSA (Dilithium) for signatures in FIPS 204. That’s about a decade before 2035, the year the UK’s National Cyber Security Centre sets for completing migration and the year the White House chose in 2022 as its goal for mitigating as much quantum risk as feasible. At SHA-1’s pace from published standard to browser cutoff, the public-web stage would end around 2039.
The long tail
Every browser cutoff applied only to publicly trusted TLS certificates. Three groups of systems outside the browsers took years longer.
Payment terminals and embedded devices
In February 2016, weeks after the CA/Browser Forum’s ban began, a payment processor asked Mozilla to let its CA issue nine new SHA-1 certificates. More than 10,000 payment terminals connected to the servers involved, and according to the request, their “equipment does not support SHA-256 and cannot be replaced in time.” Mozilla agreed, provided each certificate was logged publicly, lasted no more than 90 days and expired by December 31, 2016.
Other devices kept using SHA-1 for years. OpenSSH turned off RSA signatures with SHA-1 by default in version 8.8, in September 2021. Its developers told administrators how to re-enable them, host by host, for “older SSH implementations that have not been upgraded.”
Internal PKI
An internal public key infrastructure (PKI) is the set of CAs an organization runs for itself, trusted only on machines where it installs its own root certificate. Browser makers exempted internal PKI from each public cutoff, then withdrew the exemptions one by one. Google said it would remove Chrome’s enterprise policy for SHA-1 certificates from local roots in the first release after January 1, 2019. Microsoft Edge supported a similar policy through version 91 and dropped it in version 92, in mid-2021. Firefox ended SHA-1 support for all certificates, including imported roots, in version 103 in July 2022, five and a half years after the public cutoff.
Code signing
A code-signing signature is the one an operating system checks before it installs software or an update, so it has to verify on the oldest machines still in service. Microsoft switched Windows Update to SHA-2-only signatures in 2019. Windows 7 machines needed a separate SHA-2 support update by August 13, 2019, to keep receiving updates. On August 3, 2020, Microsoft removed SHA-1-signed Windows content from its Download Center.
What differs this time
To replace SHA-1, CAs and software vendors changed the hash function used in each signature. A CA reissuing an RSA certificate changed sha1WithRSAEncryption to sha256WithRSAEncryption. The key type, the certificate format and the 256-byte size of an RSA-2048 signature stayed the same. Post-quantum migration replaces the public-key algorithms themselves, for key establishment and signatures. In NIST’s draft transition plan, IR 8547, RSA, ECDSA, and finite-field and elliptic-curve Diffie-Hellman would be deprecated after 2030 at the 112-bit security level, and they and EdDSA would be disallowed after 2035.
The replacements’ keys and signatures are larger. According to FIPS 204, ML-DSA signatures are 2,420 to 4,627 bytes and its public keys 1,312 to 2,592 bytes. An RSA-2048 signature is 256 bytes. Google turned on post-quantum key exchange by default in Chrome 124, and in May 2024 its engineers wrote that “the size issues are even worse for authentication.”
An attacker with a SHA-1 collision can forge new signatures but learns nothing from traffic recorded years ago. An attacker with a quantum computer able to break RSA or elliptic-curve key exchange could decrypt that recorded traffic, so an adversary can store encrypted data today and read it once such a computer exists. For key establishment, your deadline depends on how long your data has to stay confidential. Chrome’s team rated migrating authentication “less urgent than key exchange” for that reason.
There may be no public announcement of Q-Day, the point at which someone can run a quantum computer that breaks RSA and elliptic-curve cryptography. An adversary decrypting recorded traffic has every reason to stay quiet, and on Q-Day itself, nothing visible breaks. A post-quantum plan needs SHA-1’s order of events, with the deadline set before anyone demonstrates a break.
Lessons for post-quantum planning
Plan around the deadlines vendors act on
NIST’s SHA-1 deprecation dates applied to federal agencies, not to the commercial CAs selling certificates for the public web. Those CAs issued SHA-1 certificates until the CA/Browser Forum’s ban began on January 1, 2016, when issuance “mostly halted,” according to Mozilla. Using Firefox telemetry, Mozilla measured SHA-1 use on the web at 3.5% in May 2016 and 0.8% that October, before any browser had stopped trusting it. Browser makers decide which CAs their products trust, so the CAs worked to the dates Microsoft announced in 2013 and Google in 2014. The IETF barred SHA-1 signatures in TLS 1.2 with RFC 9155 only in December 2021, almost five years after the browser cutoff.
For each supplier in your post-quantum plan, write down which deadline applies to them, whether a browser’s rules for trusted CAs, a procurement rule, a regulator’s date or a contract clause. For SHA-1’s final stage, NIST chose a purchasing rule, and modules that still use SHA-1 after 2030 won’t be permitted for federal purchase. Where a supplier has no binding date, put one in the contract.
Inventory first
At least two publicly trusted CAs missed the CA/Browser Forum’s September 15, 2026 deadline to revoke their remaining SHA-1 subordinate CA certificates, the intermediate links in a certificate chain. In incident reports to Mozilla, one said it had overlooked the requirement for two legacy certificates, and another said a planned review of its CA certificates “was not carried out.”
Count the verifiers as well as the signers. The payment terminals couldn’t verify SHA-256 signatures, and Windows 7 accepted SHA-2 update signatures only after a separate patch. In your post-quantum inventory, list every system that uses a public-key algorithm for key establishment or signatures, with its owner and every device that verifies its signatures.
Budget for stragglers
Write the exception process before anyone asks for an exception. Mozilla’s 2016 conditions are a usable template, with a named scope, public logging, a 90-day maximum lifetime and a fixed end date. Then budget separately for equipment that can’t be upgraded at all. In a post-quantum program, that equipment includes operational technology such as industrial control systems and medical devices. SHA-1’s stragglers were still in service in 2026, almost ten years after the public cutoff, so plan for post-quantum stragglers on a similar timescale.
Our PQC Migration Project Management course covers the program work these lessons require, including governance models, multi-year funding, team composition, phased planning with the PQC Migration Framework, metrics and board reporting.
A check for your own estate
Export your internal issuing CA’s certificate and its latest certificate revocation list (CRL), the signed list of certificates the CA has withdrawn. Then check the signature algorithm on each.
openssl x509 -in issuing-ca.pem -noout -text | grep 'Signature Algorithm'
openssl crl -in issuing-ca.crl -noout -text | grep 'Signature Algorithm'Add -inform DER if the files are binary. If either command prints sha1WithRSAEncryption or ecdsa-with-SHA1, the systems that rely on that CA still depend on SHA-1, years after Chrome and Firefox stopped trusting it on the public web. Put them at the top of your post-quantum straggler list.