Notifications
Clear all
Topic starter
25/06/2026 10:40 pm
TL;DR: Only 15% of sites used SHA-256 certificates in September 2014, while Microsoft and Google were already tightening SHA-1 trust windows and browser warnings, according to DigiCert. The shift shows that certificate lifecycle management is a governance problem, not just a cryptography upgrade, because expiry, re-keying, and discovery determine whether trust holds or breaks.
NHIMG editorial — based on content published by DigiCert: What Is SHA-2 and How the SHA-1 Deprecation Affects You
By the numbers:
- Only 15% sites use SHA-256 certificates as of September 2014.
- Microsoft announced last year that it would end trust for SHA-1 SSL Certificates after January 1, 2017.
- Google announced they would be adding warning indicators for sites using SHA-1 certificates expiring after December 31, 2017.
Questions worth separating out
Q: What breaks when SHA-1 certificates are still in use after browser trust changes?
A: Sites may remain technically online but lose browser trust, which creates warning banners, user friction, and potential service interruption.
Q: Why do certificate deprecation events matter to IAM and security teams?
A: They reveal whether certificates are actually governed as identities.
Q: How can security teams know if certificate lifecycle management is working?
A: They should be able to identify every certificate, name an owner, track its algorithm and expiry, and prove a replacement path before trust changes occur.
Practitioner guidance
- Map every SHA-1 certificate to an owner Build an inventory of all external and internal certificates, then assign a named owner to each one so migration cannot stall in shared responsibility gaps.
- Re-key before browser trust deadlines Replace SHA-1 certificates with SHA-256 as soon as compatibility allows, using re-keying to reduce downtime and avoid user-facing browser warnings.
- Test platform compatibility before forcing migration Validate whether legacy applications, devices, and middleware support SHA-2 so exceptions are known before enforcement dates arrive.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step SHA-1 migration options for existing certificates across mixed platform environments
- Free tools for locating SHA-1 certificates on internal and external networks
- Compatibility guidance for older systems that may still require transitional handling
- Re-key and replacement workflow details for organisations managing large certificate estates
👉 Read DigiCert's guidance on SHA-1 migration and SHA-2 replacement →
SHA-1 deprecation and certificate lifecycle: are your controls ready?
Explore further
25/06/2026 11:19 pm
SHA-1 deprecation exposes certificate lifecycle debt, not just cryptographic debt. The practical failure is that many teams still treat certificates as configuration artefacts instead of governed identities with ownership, replacement triggers, and expiry management. Once a browser vendor changes trust behaviour, that assumption breaks immediately. Practitioners should read this as a lifecycle governance problem that sits inside NHI management, not outside it.
A few things that frame the scale:
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
A question worth separating out:
Q: Who is accountable when a deprecated certificate causes service disruption?
A: Accountability should sit with the asset or application owner, supported by the security team running certificate lifecycle governance. If responsibility is unclear, expiry and algorithm change events will keep surfacing as avoidable outages.
👉 Read our full editorial: SHA-1 deprecation exposes certificate lifecycle gaps for security teams
