Policy changes alone do not remove risk. If old certificates remain in use, teams can end up with systems that violate the new policy, create audit findings, and still expose data or signing workflows to weak trust assumptions. The practical consequence is that compliance and actual security diverge until every active certificate path is verified and remediated.
Why excluding SHA-1 in policy is not enough on its own
Updating policy changes the rule set, but it does not change what is already deployed. If legacy certificates remain active, an organisation can be compliant on paper while still trusting weak certificates in production, which is the exact gap that creates audit issues and security exposure. The real control boundary is the certificate estate, not the policy document.
That distinction matters because certificate risk is lifecycle risk: issuance, deployment, renewal, replacement, and retirement all have to be covered. A policy can ban SHA-1 today, but any certificate still chained into authentication, signing, or mutual TLS can continue to function until it is found and remediated.
Certificate lifecycle guidance such as the CA/Browser Forum and NIST SP 800-57 Key Management both reflect the same operational reality: trust only improves when weak material is removed from use, not when it is merely disallowed going forward.
What remains exposed when old certificates are not audited
Un-audited certificates create a hidden trust layer. You may have systems that still authenticate with deprecated certificates, software signing workflows that still rely on them, or integrations that continue to accept them because no one has checked the active inventory. That leaves both compliance and actual security drifting apart.
The risk is not limited to direct SHA-1 validation. Any certificate that remains trusted can preserve a broken assurance path, especially where certificate-based authentication or token binding is involved. If the certificate is old, duplicated, unmanaged, or embedded in an automation flow, revoking policy without inventory leaves the weakest link intact.
This is why machine and workload certificate governance is central to the issue. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide and Guide to SPIFFE and SPIRE both emphasise that certificates are part of an identity and trust lifecycle, so unmanaged remnants matter even when the policy has already changed.
What organisations should verify before they trust the policy change
Teams should verify that the certificate inventory is complete, that each active certificate is mapped to an owner and use case, and that any remaining SHA-1 dependency has a defined replacement path. If they cannot show where a certificate is used, they cannot prove the policy change is effective.
For broader identity and certificate governance, NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful because it ties inventory, auditability, and access governance to real operational evidence. At the protocol level, RFC 8705 shows why certificate-bound trust paths must be treated as live dependencies, not theoretical ones.
Risk and Threat Considerations
When organisations only update the policy, the main risk is stale trust. Deprecated certificates can remain embedded in authentication, signing, or service-to-service flows long enough to create audit findings and preserve weak trust assumptions even after the written standard has changed.
Failure mechanism: The environment still accepts or relies on certificates that should have been replaced, so the policy ban is not enforced at the certificate estate level.
Impact: Compliance evidence becomes unreliable, remediation is delayed, and an attacker or failure in a legacy trust path can still affect authentication, integrity, or confidentiality.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate retirement and cryptoperiod control are central to removing SHA-1 trust. |
| Recommendation — Enforce key lifecycle limits and retire weak certificates from all active trust paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates are authenticators that must be inventoried, rotated, and revoked when weak. |
| AU-2 — Event Logging | Auditability depends on logging certificate usage and remaining trust dependencies. | |
| Recommendation — Track and revoke certificate authenticators that remain active after policy changes. Log certificate use and review the logs to find remaining SHA-1 dependencies. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | SHA-1 deprecation is a cryptographic control issue requiring active replacement. |
| Recommendation — Replace deprecated cryptography and verify no active certificate still depends on it. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Cryptographic trust weaknesses can preserve exposure if legacy certificates remain in use. |
| Recommendation — Remove weak certificate dependencies from systems that protect data or signing flows. | ||
Practitioner Guidance
What to prioritise: Start with a complete certificate inventory, then rank certificates by whether they support production authentication, signing, or external trust. Those paths carry the highest blast radius if a SHA-1 certificate is still present.
What to verify: Confirm not only that SHA-1 is disallowed for new issuance, but that every existing certificate has been located, owner-assigned, and checked for actual use. A policy exception is safer than an unknown live dependency.
Practitioner takeaway: Treat the policy update as the beginning of remediation, not the proof of it, because only validated removal of active SHA-1 certificates closes the gap between stated control and real trust.
Related resources from NHI Mgmt Group
- How should organisations audit AI use that happens outside approved tools?
- Why do organisations need an ISO 27001 information security policy beyond passing an audit?
- When should organisations review and update a data classification policy?
- What happens when organisations deploy AI without visibility and audit trails?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
