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.
Why certificate replacement should follow exposure, not expiry order
When SHA-1 is still present, the replacement queue should reflect where trust breaks first, not which certificates expire soonest. External services are the highest-priority candidates because browser and client trust stores are least forgiving there. Internal certificates matter next when they support authentication, automation, or workload identity, because those chains can turn a weak certificate into a wider access problem.
The practical test is business dependency plus trust surface. A certificate on an internet-facing service can create immediate user-visible failures, while an internal certificate can silently disrupt service-to-service authentication or automated jobs if it sits on a critical path. That is why replacement planning should be risk-led, not calendar-led.
For workload and machine identities, certificate replacement is a lifecycle issue, not just a cryptographic refresh. The more a certificate is embedded in service authentication or east-west traffic, the more carefully teams need to stage replacement, validate trust chains, and confirm that every dependent system can still authenticate after cutover.
Which certificates create the most operational and trust risk?
Start with the certificates most likely to fail in public trust contexts, then work inward to certificates that would interrupt core services. A SHA-1 certificate on a browser-facing endpoint is usually a more urgent problem than the same algorithm on a low-risk internal system, because the first failure is immediate trust rejection rather than a deferred technical weakness.
Internal certificates deserve earlier treatment when they protect automation, API calls, or service-to-service authentication. Those use cases can fail in ways that are harder to spot than a browser warning, because the outage may appear as an application defect, a failed pipeline, or an unavailable workload rather than as a visible certificate error.
Replacement also needs to consider trust chain complexity. Where an old certificate anchors multiple systems, the risk is not only the certificate itself but the number of dependent services that may fail together during cutover.
How teams should sequence replacement without creating avoidable outages
The safest sequence is to inventory where SHA-1 still exists, then rank each certificate by exposure, dependency, and blast radius. Publicly trusted services come first, then certificates that support authentication paths, automation jobs, and workload identity, then lower-impact internal uses. That ordering reduces the chance that an overlooked trust dependency becomes the outage trigger.
Replacement should be staged with validation at each boundary. Teams should confirm who consumes the certificate, what protocol or trust store relies on it, and whether the new certificate chain is accepted everywhere it needs to be. This matters especially when certificates are reused across environments or embedded in automation, where one missed reference can break multiple systems at once.
Where possible, reduce the change size by replacing one trust boundary at a time. The goal is not simply to eliminate SHA-1 quickly, but to do so in a way that preserves service continuity and avoids creating a new failure through rushed rollout.
Risk and Threat Considerations
SHA-1 is problematic because it weakens trust in places where certificate validation is expected to be deterministic. The main risk is not theoretical cryptographic weakness alone, but the operational exposure created when a weak certificate is still trusted by browsers, services, or automated clients.
Failure mechanism: A SHA-1 certificate remains on a high-value trust path until a browser, client, or internal dependency refuses it or an attacker abuses the residual trust relationship. In practice, that can produce trust failures at the edge or silent disruption inside authentication and automation chains.
Impact: Users can lose access to externally exposed services, automation can fail, workload authentication can break, and incident response may be delayed because the root cause looks like a service fault rather than a certificate issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management Recommendations | Certificate replacement depends on lifecycle and cryptoperiod management. |
| Recommendation — Align certificate rotation to key lifecycle policy and retire weak algorithms first. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate replacement is part of authenticator lifecycle control for systems and services. |
| IA-9 — Service Identification and Authentication | Internal workload and automation certificates support service authentication paths. | |
| Recommendation — Rotate and revoke weak certificates as part of authenticator lifecycle management. Replace service certificates in dependency order and validate service-to-service authentication after cutover. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Prioritising by exposure and dependency matches verify-every-request thinking for trusted paths. |
| Recommendation — Reassess every certificate trust path and segment replacement by exposure and dependency. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Weak certificate algorithms affect trust protection for exposed services and data flows. |
| Recommendation — Inventory and replace weak certificates that protect externally exposed data flows first. | ||
Practitioner Guidance
What to prioritise: Treat externally trusted services as the first replacement wave, then move to internal certificates only after you have mapped every authentication and automation dependency. A certificate that authenticates a workload or pipeline usually deserves earlier attention than a certificate that merely exists in a low-risk internal segment.
What to verify: For each replacement, verify the full chain, the consuming clients, the trust store path, and the fallback behaviour if validation fails. If a certificate is reused across systems, assume the blast radius is larger than the inventory record suggests.
Practitioner takeaway: SHA-1 cleanup is a dependency-management exercise as much as a cryptography exercise, and the safest ordering is the one that removes the most exposed trust paths first.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Which control should teams prioritise when certificate libraries fail safe assumptions?
- How can security teams know whether certificate trust is still reliable?
- How do security teams know whether unsafe deserialisation is still present in production?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org