Why does a practical SHA-1 collision capability increase risk for PKI even if the attack is expensive?

Why SHA-1 collisions matter to certificate trust

A collision-capable attacker can manufacture two different inputs with the same SHA-1 digest, which weakens any PKI process that still depends on SHA-1 for trust decisions, signature validation, or certificate-related integrity checks. The practical risk is not limited to immediate breakage, it is that once a collision exists, trust assumptions become easier to undermine in ways that are hard to notice until an attacker has already shaped the artifact, certificate, or chain.

In PKI, the security property being protected is not just mathematical correctness, but the ability to distinguish authentic, intended material from maliciously substituted material. When a hash function no longer provides strong collision resistance, the assurance behind certificates, signed content, and related metadata becomes less durable even if exploitation remains expensive today. For that reason, security teams treat a working collision as a structural trust problem, not a narrow cryptographic curiosity.

That matters because PKI is often used to anchor software distribution, TLS trust, code signing, document signing, and internal certificate-based controls. Once a collision path is demonstrated, the remaining question becomes whether a targeted adversary can find a place where SHA-1 still influences acceptance decisions or legacy verification logic. If so, the attacker may be able to create ambiguous or substituted artifacts that still satisfy the verifier’s expected hash relationship. See the practical certificate lifecycle guidance in Machine Identity, PKI and Certificate Lifecycle Guide for the lifecycle side of that problem.

A useful way to think about the issue is that the attack cost can fall faster than defenders expect. Even a high-cost collision today can become materially more feasible as compute gets cheaper, tooling improves, and attacker workflows become more optimized. That is why cryptographic migration decisions should be based on future exposure, not just current feasibility. The certificate ecosystem also tends to have long-lived artifacts and slow replacement cycles, which makes deprecated hashes persist in places that are easy to overlook. The combination of legacy trust and improving attacker economics is what makes SHA-1 risky even before it becomes trivial to attack.

For practitioners, the key distinction is between “expensive” and “acceptable.” A collision that is expensive for a random attacker may still be practical for a well-funded adversary, a high-value target, or a long-horizon campaign. If SHA-1 appears anywhere in certificate issuance, signing, chain validation, or subordinate trust tooling, the exposure is cumulative: the more broadly it is embedded, the more places a collision-capable attacker can try to exploit legacy acceptance.

Risk and Threat Considerations

The risk is that SHA-1 stops being a reliable separator between authentic and attacker-chosen content, so certificate-based trust can be manipulated without breaking the entire PKI model at once. That creates a window where legacy systems may continue to accept material that should no longer be trusted, especially if they validate only part of the chain or still permit SHA-1 in older workflows.

Failure mechanism: An attacker uses a practical collision to create two different certificate-related objects, or two different contents under the same hash, so the verifier accepts a malicious substitution as if it were the original trusted object.

Impact: This can undermine integrity, enable forged trust relationships, and weaken certificate-based identity assertions, which in turn increases the chance of unauthorized signing, impersonation, or tampering that is hard to detect after the fact.

Practitioner Guidance

What to prioritise: Inventory every place SHA-1 still appears in PKI-adjacent trust paths, including certificate chains, signature validation, legacy code-signing policy, embedded devices, and internal tooling. The highest-risk systems are the ones that still make an allow or deny decision based on SHA-1, even indirectly.

What to verify: Confirm whether SHA-1 is used only for non-security compatibility metadata or whether it affects acceptance, signature validity, or trust decisions. If a system still treats a SHA-1 result as security-relevant, it should be treated as a migration exception rather than a stable control.

Decision rule: If the hash influences trust, plan replacement or containment immediately; if it is present only for backward compatibility, document that use tightly and set a removal date. The longer a SHA-1 dependency remains in certificate workflows, the more likely it is to become a practical attack path rather than a theoretical weakness.

Practitioner takeaway: The real risk is not whether SHA-1 collisions are cheap today, but whether you still rely on SHA-1 anywhere that turns a hash into trust. Once that happens, the cryptographic weakness becomes an identity and integrity problem, and the migration clock is already running.

Related resources from NHI Mgmt Group

• Why do open-weight models increase cyber risk even when they do not introduce new attack techniques?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?