Topic starter
25/06/2026 10:34 pm
TL;DR: Older TLS versions remain widely enabled even as client usage has dwindled, with SSL Pulse showing 88% of HTTPS-enabled sites supporting TLS 1.0 and 85% supporting TLS 1.1, according to DigiCert. The real issue is not adoption speed but the long tail of systems that still depend on deprecated protocol paths and weak cryptography.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “Deprecating TLS 1.0 & 1.1”.
Key questions
Q: How should security teams phase out TLS 1.0 and 1.1 without breaking key services?
A: Start by mapping every client that still negotiates the old protocols, especially APIs, scripts, and bundled tools.
Q: Why do older TLS versions remain risky even when few clients use them?
A: Because risk comes from continued acceptance, not just traffic volume.
Q: How do security teams know whether TLS deprecation is actually complete?
A: They know it is complete when no production endpoint, integration, or dependency can successfully negotiate TLS 1.0 or 1.1.
Practitioner guidance
- Inventory every TLS endpoint and client dependency Build a complete list of web properties, APIs, automation scripts, libraries, and embedded clients that still negotiate TLS 1.0 or 1.1.
- Disable legacy protocol fallback paths Remove TLS 1.0 and 1.1 support from servers after confirming that no required client still depends on them.
- Test machine clients separately from browsers Validate API consumers, developer utilities, scheduled jobs, and dependency bundles in isolation so hidden compatibility issues surface before production changes.
Bottom line: Older TLS support can remain a live security issue even when client usage has largely disappeared, because servers often continue to advertise weak fallback paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 11:09 pm
Legacy protocol support is a lifecycle failure, not a feature flag problem: TLS 1.0 and 1.1 remain exposed because organisations often treat protocol deprecation as a one-time configuration change instead of an inventory, dependency, and retirement process. That mindset leaves long-tail clients, APIs, and bundled libraries untouched. The practitioner lesson is that protocol shutdown needs governance, not just a configuration ticket.
A question worth separating out:
Q: What is the difference between TLS preference and TLS enforcement?
A: Preference means a server will try to use the strongest protocol first, but still accepts older versions if a client asks. Enforcement removes the older versions entirely, which is the only state that actually closes the downgrade path and makes deprecated TLS unavailable in practice.
👉 Read our full editorial: Deprecating TLS 1.0 and 1.1 exposes lingering protocol risk