Security teams should prefer stronger hashing algorithms such as SHA-256 for new TLS certificates, because weaker hashes like MD5 can be forged and SHA-1 has known collision concerns. The practical trade-off is compatibility, since older clients may not support newer algorithms. The safest approach is to standardise on stronger certificates while inventorying legacy systems that still require exceptions.
Why certificate hash choice is a security control, not just a compatibility setting
Certificate hashing affects trust, because the hash protects the integrity of the certificate signature chain. Stronger hashes such as SHA-256 are the baseline for new TLS deployments, while MD5 and SHA-1 are weak enough to create practical collision concerns. In compatibility terms, the question is not whether older clients can still connect, but how much legacy exposure you are willing to preserve.
For certificate policy, the practical target is to standardise on modern algorithms and treat exceptions as a managed inventory item. That means tls certificate selection should be aligned with the lifecycle expectations in NIST SP 800-57 Key Management, because algorithm strength and key lifecycle decisions belong together.
How broad client compatibility changes the deployment decision
Compatibility pressure usually comes from older operating systems, embedded devices, Java runtimes, or enterprise appliances that lag modern trust-store updates. Those clients may reject certificates signed with newer algorithms, so teams need to distinguish between a temporary interoperability issue and a permanent policy exception. The safest default is still to issue stronger certificates first, then test the remaining client population against that baseline.
If a legacy system cannot validate a SHA-256-signed certificate, the issue is usually in the client environment, not in the server certificate choice. A disciplined rollout often means keeping a compatibility register, testing representative client stacks early, and scheduling remediation for the few systems that cannot move. The same certificate lifecycle discipline is reflected in Machine Identity, PKI and Certificate Lifecycle Guide, which frames certificates as managed machine identity assets rather than static files.
Broad compatibility should not become a reason to keep weak hashing in production. If exceptions persist, they should be time-bound and tied to a specific legacy dependency, not left as an open-ended policy choice. That is especially important when certificates also support machine-to-machine trust or automated renewal paths, where weak or outdated trust assumptions can linger unnoticed.
What a secure migration path looks like in practice
A secure migration path starts with inventorying where certificates are consumed, not just where they are issued. Teams should identify externally facing services first, then internal services, appliances, and client libraries that may still depend on older signature algorithms. When the deployment involves workload identity or mutual TLS, a modern certificate standard also helps keep trust bundles and service authentication aligned, as described in Guide to SPIFFE and SPIRE.
For public TLS, certificate issuance policy should favour the strongest interoperable option available, then use exceptions only for systems that have been proven unable to upgrade. The operational goal is not to preserve every old client forever, but to reduce the blast radius of legacy compatibility until those clients are retired or fixed. That logic is also consistent with CA/Browser Forum baseline expectations for publicly trusted certificate issuance and revocation.
In environments where certificates are part of broader non-human authentication, organisations should also review whether the certificate is being reused across too many services or embedded in brittle automation. The Ultimate Guide to NHIs is useful here because it treats certificates alongside other machine-authentication material, which helps teams avoid treating certificate format choices in isolation from access design.
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 CSF 2.0, 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 | TLS certificate hash choice is tied to cryptographic algorithm and lifecycle policy. |
| Recommendation — Set certificate algorithm policy alongside key lifecycle and rotation rules. | ||
| NIST CSF 2.0 | PR.DS-10 — Cryptographic Protections | TLS certificates rely on cryptographic protection for integrity and trust. |
| Recommendation — Use approved cryptographic protections and retire weak algorithms. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | Certificate trust depends on managed cryptographic material and algorithm choices. |
| Recommendation — Standardise approved cryptographic mechanisms and lifecycle handling. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | TLS certificate hashing is a direct cryptography selection decision. |
| Recommendation — Define approved cryptography for certificate issuance and validation. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Weak certificate hashes undermine protected communications. |
| Recommendation — Require strong cryptography for transport protection and certificate policy. | ||
Practitioner Guidance
What to prioritise: Choose SHA-256 or stronger for new TLS certificates, then document every exception as a specific legacy client dependency with an expiry plan. Do not let “compatibility” become a standing reason to keep weak hashes in circulation.
What to verify: Test the actual client population that matters, including old browsers, embedded agents, middleware, and off-the-shelf appliances. If only a small set fails, isolate them and decide whether upgrade, replacement, or temporary exception is the lower-risk path.
Common mistake: Teams often solve the immediate interoperability problem by downgrading certificate policy for everyone. That trades a local convenience issue for a broad trust weakening that is harder to unwind later.
Practitioner takeaway: Modern hash selection should be the default, and compatibility should be managed through inventory and exception control, not by weakening the certificate standard for the whole environment.
Related resources from NHI Mgmt Group
- How should security teams implement Client ID Metadata Documents?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams prepare for shorter TLS certificate lifetimes?
- How should security teams handle Dynamic Client Registration in remote MCP deployments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
