Who is accountable when a business system still requires deprecated TLS support?

Why This Matters for Security Teams

Deprecated TLS support is not just a technical legacy issue. It is an accountability problem because the exception often outlives the business reason that created it. When a system cannot be upgraded, security, application, and platform owners need a named decision-maker who owns the risk acceptance, tracks the remediation plan, and proves the exception is still justified. Without that, the exception becomes hidden technical debt.

This matters because weak exception governance usually shows up alongside broader identity and control failures. NHIMG notes that 71% of NHIs are not rotated within recommended time frames, and the Ultimate Guide to NHIs also highlights how often organisations lack visibility into long-lived access paths. In practice, teams that tolerate old TLS versions often tolerate other exceptions too, which means the real risk is not the protocol alone but the absence of a clear owner for the exception lifecycle. The NIST Cybersecurity Framework 2.0 reinforces that governance and risk ownership must be explicit, not implied. In practice, many security teams encounter this only after an audit finding, customer escalation, or production incident has already exposed the gap.

How It Works in Practice

The accountable person is the one who can approve, challenge, and retire the exception. In mature environments, that person is usually the system owner or service owner, with security setting policy and reviewing risk. Application teams may request the exception, but they should not be the final owner unless they also control the remediation roadmap and the business tradeoff.

For deprecated TLS, practical accountability usually includes four elements:

• A named exception owner with decision authority.
• A documented business justification for why the legacy protocol is still needed.
• An expiry date or review cadence, plus a remediation milestone.
• Evidence that compensating controls are in place, such as network segmentation, strict cipher configuration, and monitoring.

That approach aligns with the governance logic in the Ultimate Guide to NHIs, where long-lived access and secrets must be owned, reviewed, and retired rather than left to drift. The same principle applies to protocol exceptions: if nobody owns the expiry, nobody owns the risk. Security teams should also tie the exception to a formal review in their vulnerability or architecture governance process, so it is visible in change control and not buried in a ticket queue. Current guidance suggests pairing the exception with compensating controls and a hard sunset, because a deprecated protocol is usually tolerated only when an upstream dependency, vendor constraint, or embedded system cannot yet be changed. These controls tend to break down when ownership sits in a shared mailbox or committee, because no single person is empowered to force remediation.

Common Variations and Edge Cases

Tighter exception governance often increases coordination overhead, requiring organisations to balance operational continuity against the cost of repeated reviews. That tradeoff is real, especially for industrial systems, medical devices, or third-party integrations where TLS deprecation is outside the immediate control of the business system owner.

In those cases, current guidance suggests treating the exception as temporary even when the underlying constraint is long-lived. Best practice is evolving, but the pattern is consistent: define who owns the risk, who funds the fix, and who can accept the residual exposure after each review cycle. If a vendor insists on old TLS, procurement and vendor management should be pulled into the decision, not left outside it. If the exception protects a critical service, security may accept a reduced control set, but only with documented compensating controls and a retirement plan.

One useful way to think about accountability is that the business owner owns the outcome, the security team owns the standard, and the application owner owns the implementation path. If those roles are unclear, the exception will persist long after the original justification has expired.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• When does a short-lived API key still create material risk?
• Who is accountable when an inactive non-human identity is still present after business use has ended?
• Who is accountable when insider fraud happens in a shared business system?