Why does continued reliance on SHA-1 signed certificates create risk for enterprise PKI?

SHA-1 creates risk because practical collision attacks can make two different certificates appear to have the same valid hash, undermining trust in certificate issuance. If an attacker can forge a certificate that verifies as legitimate, systems that rely on certificate authenticity may accept it. That can compromise authentication, encryption trust, and any workflow built on certificate validation.

Why SHA-1 Signed Certificates Undermine PKI Trust

SHA-1 is no longer just “old.” In a certificate chain, a weak hash creates a structural trust problem because certificate validity depends on the assumption that the signature cannot be feasibly forged. Once collision attacks become practical, the cryptographic boundary around issuance and validation stops being reliable, even if the certificate format and chain logic still look correct.

That matters in enterprise PKI because a certificate is not only an encrypted container for a public key, it is also a policy statement about identity, key usage, and trust. If the signature algorithm can be attacked, the CA’s assertion can be subverted, and the surrounding systems may continue to treat the certificate as trustworthy until the weak algorithm is detected and removed.

How Collision Risk Changes Certificate Validation

The core issue is that SHA-1 collision resistance is what keeps two different certificate bodies from sharing a hash value that validates under the same signature. In practice, that means an attacker may be able to craft a malicious certificate structure that appears to have been legitimately signed, which breaks the normal assurance that “valid signature” equals “authentic issuance.”

This is especially dangerous in environments where certificate validation is embedded in other controls, such as TLS trust decisions, mutual TLS, code-signing workflows, or internal service authentication. The validation step may still succeed technically, but the security meaning of that success becomes unreliable if the hash function can be manipulated. For a broader view of why certificate lifecycle and key hygiene matter, see Machine Identity, PKI and Certificate Lifecycle Guide and NIST SP 800-57 Key Management.

Enterprises should also treat SHA-1 as a lifecycle and trust-store problem, not only a cryptography problem. A weak certificate may persist long after policy says it is obsolete if old roots, intermediates, appliances, or embedded systems still accept it, so the practical exposure is often hidden in compatibility layers rather than obvious in the CA console.

Why Legacy SHA-1 Certificates Still Create Enterprise Exposure

Continued SHA-1 reliance creates risk when organizations allow legacy certificates to remain trusted in browsers, internal applications, devices, or private PKI hierarchies. The danger is not limited to internet-facing TLS. Any workflow that uses certificate authenticity as a control can inherit the weakness, including authentication, encrypted channels, signing, and policy enforcement around trusted endpoints.

The transition problem is often operational: older hardware, vendor devices, or long-lived internal systems may reject faster migration schedules, so teams keep SHA-1 support “temporarily” and then forget it. That creates a long tail of exposure where the weakest link in the chain remains trusted even after stronger cryptography is available. In enterprise environments, that can make a forged or substituted certificate materially more credible than it should be.

When certificate authenticity is part of a machine-to-machine trust model, the impact extends beyond one host or application. Guide to SPIFFE and SPIRE shows the direction many modern environments take, toward stronger workload identity and explicit trust material, while legacy SHA-1 certificates keep trust anchored to a weaker signature primitive. Similarly, CA policy and issuance expectations are reflected in CA/Browser Forum baseline requirements, which exist in part to reduce trust in deprecated certificate practices.

Risk and Threat Considerations

SHA-1 creates an adversarial opportunity because collision attacks can be used to make two different certificate contents appear equivalent under the same hash. If a target environment still trusts SHA-1, the attacker’s objective is not to break encryption directly, but to exploit the trust decision that follows successful signature validation.

Failure mechanism: A malicious actor uses a feasible collision path to create a certificate or certificate-like artifact that validates under a trusted SHA-1 signature, then leverages the accepted trust relationship to impersonate, redirect, or authenticate as something the enterprise believes is legitimate.

Impact: The result can be forged trust in certificate issuance, weakened authentication, compromised secure transport, and downstream abuse of any application or device that treats the certificate as proof of legitimacy.

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 CSF 2.0 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 Recommendations	SHA-1 certificate risk depends on weak hash and key lifecycle decisions.
Recommendation — Retire SHA-1, enforce stronger algorithms, and manage cryptoperiods with algorithm agility.
NIST SP 800-53 Rev 5	SC-12 — Cryptographic Key Establishment and Management	PKI trust depends on controlled cryptographic material and algorithm choice.
Recommendation — Use approved cryptography and manage certificate/key lifecycles to prevent trust failure.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Legacy SHA-1 certificates are a cryptography control weakness requiring formal replacement.
Recommendation — Replace deprecated certificate algorithms and document cryptographic requirements in policy.
NIST CSF 2.0	PR.DS-01 — Data-at-rest is protected	Certificate trust protects encrypted and authenticated communications using cryptographic safeguards.
Recommendation — Adopt approved cryptographic protections for data and trust-bearing communications.
CIS Controls v8	CIS-3 — Data Protection	Weak certificate hashes weaken protection of sensitive communications and trust paths.
Recommendation — Eliminate weak certificate algorithms and validate cryptographic protection in inventories.

Practitioner Guidance

What to prioritise: Find every SHA-1 signed certificate in use, then rank them by trust impact. Certificates used for authentication, internal trust chains, code signing, or appliance interoperability are higher priority than isolated legacy artifacts because they can affect decision-making across multiple systems.

What to verify: Confirm whether SHA-1 appears only in old leaf certificates or is still present in intermediates, root chains, device firmware, and private CA templates. A single legacy root or intermediate can keep the weaker algorithm alive even if end-entity certificates have already moved on.

Decision rule: If a certificate participates in a trust decision, treat SHA-1 removal as a security remediation, not a cosmetic migration. If the only barrier is compatibility, use compensating controls and a retirement date, because the cryptographic risk does not improve just because the certificate still “works.”

Practitioner takeaway: The real issue is not that SHA-1 is outdated, it is that a trusted certificate chain built on a collision-prone hash can no longer provide dependable proof of authenticity.