TL;DR: Mozilla plans to warn on SHA-1 certificates in Firefox and eventually reject them outright, aligning with Microsoft and Google’s earlier deprecation timeline and accelerating the move away from legacy certificate trust, according to DigiCert. The practical lesson is that certificate lifecycle management must surface weak algorithms before browsers do, or user-visible trust failures will arrive first.
At a glance
What this is: DigiCert’s article says Mozilla will start warning on SHA-1 certificates in Firefox and eventually reject them, showing that legacy certificate trust is being phased out across the browser ecosystem.
Why it matters: This matters because IAM and security teams need certificate inventory, renewal, and replacement processes that identify weak algorithms before browsers turn them into user-visible outages.
Context
SHA-1 is a certificate trust problem, not just a cryptography problem. Once browser vendors begin warning on it, the issue becomes operational: teams must find every issued certificate that still depends on a weakening algorithm and remove it before trust errors hit end users.
The governance gap is simple. Certificate lifecycle management often tracks expiry dates and ownership, but not algorithm strength or browser policy shifts. That leaves security teams reacting to external deprecation schedules instead of managing trust posture on their own timeline.
For identity and access programmes, this is a machine identity issue as much as a public web issue. Certificate trust is part of workload and service authentication, so deprecation pressure lands on PKI inventory, renewal workflows, and the control plane that governs non-human credentials.
Key questions
Q: What breaks in practice when SHA-1 certificates are still in use after deprecation dates?
A: When SHA-1 remains in service past deprecation deadlines, browsers may stop treating sites as fully trustworthy and users can see warnings or blocked access. That creates immediate business disruption for public-facing systems. The deeper failure is that certificate-based trust no longer holds, so systems depending on those chains become operationally fragile.
Q: Why do browsers deprecate weak certificate algorithms before all systems move?
A: Browsers have to protect users at ecosystem scale, so they cannot wait for every organisation to remediate on its own schedule. Weak algorithms become a trust risk once attacks are plausible, and browser vendors enforce that risk through warnings and rejection. The result is external control pressure on internal certificate governance.
Q: How should teams prioritise certificate replacement when SHA-1 is still present?
A: Start with externally trusted services, then move to internal systems that support authentication, automation, or workload identity. Prioritisation should follow exposure and business dependency, not just expiry order. That way, the services most likely to hit browser trust failures are removed from risk first.
Q: How do certificate teams know whether trust deprecation is being managed well?
A: They should be able to show a complete inventory of certificates by algorithm, owner, and replacement status, plus a remediation plan aligned to browser timelines. If weak algorithms still surface late in renewal cycles, trust deprecation is not under control.
Technical breakdown
Why SHA-1 deprecation changes certificate trust decisions
SHA-1 is a hash algorithm used in certificate signing workflows, and browser vendors treat it as too weak for future trust decisions because collision attacks are becoming practical. When trust decisions are tied to browser policy, the certificate is no longer just cryptographically valid or invalid. It also has to survive ecosystem enforcement. That is why Mozilla’s warning path matters: it turns an algorithmic weakness into an operational trust event that can break access before a certificate expires.
Practical implication: Track algorithm strength as part of certificate governance, not just expiry.
How browser warnings turn PKI debt into user-facing failures
Browser warnings create a staged deprecation path. First comes console or developer warning, then browser-level untrusted connection errors for newly issued certificates, and finally broader rejection of SHA-1 whenever it is encountered. That sequence matters because it compresses remediation windows. Organisations that rely on old certificates can have working infrastructure suddenly become untrusted in the browser even though the certificate still exists and may not yet have expired.
Practical implication: Inventory certificates against browser deprecation timelines, not only renewal dates.
Why certificate lifecycle management must include algorithm migration
Certificate lifecycle management is often treated as issuance, renewal, and revocation, but algorithm migration is part of the same lifecycle. If teams do not know where SHA-1 still exists, they cannot plan replacement work, test trust chains, or prioritise high-exposure services. The real control problem is discovery across the certificate estate, because browser policy changes expose hidden legacy uses that were previously tolerated. This is where PKI governance and operational inventory intersect.
Practical implication: Build certificate discovery and replacement into lifecycle operations.
NHI Mgmt Group analysis
Weak algorithm trust is now a lifecycle governance issue, not a cryptography footnote. Once browsers begin warning on SHA-1, the control failure is no longer theoretical. Organisations that only watch expiration dates are governing the wrong variable. The practitioner conclusion is that algorithm strength has to be managed as part of certificate ownership and renewal policy.
Certificate inventory without algorithm visibility leaves hidden trust debt. A certificate can be issued, renewed, and technically present while still being operationally obsolete. That gap becomes visible only when browser policy changes. The practitioner conclusion is that discovery must extend beyond valid-versus-expired to include signed-with-what and accepted-by-whom.
Browser deprecation timelines effectively become external control enforcement for PKI. The article shows that Microsoft, Google, and Mozilla are converging on the same direction, which means trust policy is being set by the ecosystem rather than by individual organisations. The practitioner conclusion is that internal certificate governance has to move ahead of public browser enforcement.
Certificate lifecycle management is the named concept that matters here. The issue is not simply replacing SHA-1. It is managing a lifecycle where algorithm choice, issuance policy, renewal timing, and trust compatibility are all linked. The practitioner conclusion is that PKI programmes need explicit ownership of cryptographic deprecation risk.
Legacy trust assumptions fail when service and browser policy move faster than internal change windows. SHA-1 worked inside older trust models because deprecation was slow enough to tolerate drift. That assumption fails once browser vendors enforce untrusted connection errors on a predictable schedule. The practitioner conclusion is that trust transition planning must be as deliberate as certificate issuance itself.
What this signals
Certificate trust deprecation is a governance signal, not just a browser event. Security teams should treat algorithm retirement as a standing lifecycle issue because external trust policy will keep tightening. When that happens, the organisations with the best inventory discipline will absorb the least disruption.
The operational boundary has shifted from issuance to compatibility. A certificate is only useful if the ecosystem still accepts it, so PKI programmes need to measure deprecation exposure alongside renewal dates and ownership.
The broader lesson for identity teams is that trust material must be managed as inventory with policy context. That applies to public TLS, internal PKI, and any service authentication flow that still depends on legacy certificate choices.
For practitioners
- Inventory all SHA-1 certificates Identify every certificate, intermediate, and trust chain that still depends on SHA-1 across web, service, and internal environments. Include long-lived certificates that may not appear in normal renewal queues.
- Prioritise external-facing services first Replace SHA-1 certificates on internet-facing applications before browser enforcement makes the problem visible to users. Treat high-traffic customer paths and developer portals as the first remediation tier.
- Align renewal work to browser policy Map certificate replacement timelines against known browser deprecation milestones so renewal cycles do not extend beyond the point where trust warnings begin to break access.
- Embed algorithm checks in PKI governance Add algorithm validation to certificate approval, renewal, and exception workflows so weak cryptography is blocked before it reaches production trust chains.
Key takeaways
- SHA-1 deprecation shows that certificate trust is governed by ecosystem policy as much as by cryptographic validity.
- The main exposure is hidden inventory, where legacy certificates remain in use until browsers begin rejecting them.
- Teams that track algorithm strength alongside renewal timing can replace weak certificates before users see trust failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | SHA-1 certificates are legacy trust material that persists beyond the point browsers now accept. |
| NHI-01 — Improper Offboarding | Deprecated certificates are effectively unoffboarded trust credentials still active in the estate. | |
| Recommendation — Replace SHA-1 certificates before browser policy turns them into untrusted trust anchors. Retire SHA-1 certificates through explicit offboarding in your certificate lifecycle process. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article is about retiring weak cryptographic material through lifecycle governance. |
| Recommendation — Apply key lifecycle governance to detect, replace, and retire SHA-1-backed certificates. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity and Protection | Weak certificate trust undermines the integrity of protected communications. |
| Recommendation — Use PR.DS-10 to manage certificate trust and prevent weak cryptography from remaining in production. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate ownership and lifecycle tracking are governance functions analogous to account management. |
| Recommendation — Track certificate ownership and retire weak trust material using CIS-5 governance discipline. | ||
Key terms
- SHA-1 Deprecation: SHA-1 deprecation is the process of phasing out acceptance of SHA-1 based certificates and related trust chains. In practice, it forces organisations to inventory certificates, test interoperability, and migrate before browsers, vendors, or internal policy stop trusting SHA-1.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Browser trust boundary: The set of browser behaviours that the organisation implicitly relies on when a user approves an identity action in-page. It matters because rendering, overlays, and input handling can change what the user sees, making the browser part of the security control path rather than a neutral container.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org