Who is accountable when agencies cannot show a defensible process for managing end-of-support systems?

Why This Matters for Security Teams

End-of-support systems are not just an asset management problem. They create a defensibility problem: if an agency cannot show how it identified unsupported platforms, prioritised remediation, and accepted or mitigated risk, leadership is left exposed during audit, incident response, or public accountability reviews. Current guidance from the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives both point to the same operational reality: if you cannot evidence lifecycle control, you cannot credibly claim risk ownership.

The accountability question usually lands on the organisation that owns the environment, but the failure is almost always shared across infrastructure, security, procurement, and operations. Unsupported systems often persist because no single team owns the full replacement path, and because discovery data is incomplete. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which is why lifecycle risk so often stays hidden until an exception becomes a finding.

In practice, many security teams encounter unsupported systems only after audit requests or an outage forces the issue, rather than through intentional lifecycle governance.

How It Works in Practice

A defensible process starts with continuous discovery, not annual spreadsheets. Agencies need an inventory that ties each system to an owner, business function, data sensitivity, support status, and a dated remediation decision. That inventory should distinguish between systems that are still supported, systems that are in vendor grace periods, and systems that are formally exempted with compensating controls. The point is not perfection; the point is evidence.

From there, accountability becomes a managed workflow. Security sets the policy, operations validates exposure, procurement tracks vendor support dates, and leadership resolves funding or mission tradeoffs. NHIMG’s NHI Lifecycle Management Guide is useful here because the same lifecycle discipline applies to service accounts, API keys, and other non-human identities that may depend on deprecated systems. If the platform cannot be retired immediately, the supporting identities and secrets still need review, rotation, and least-privilege scoping.

• Track end-of-support dates alongside asset ownership and business criticality.
• Document exceptions with expiry dates, risk acceptance, and compensating controls.
• Use continuous discovery to confirm whether the system is still active, exposed, or linked to secrets.
• Bind remediation to decommissioning, migration, or isolation milestones rather than open-ended backlog items.

For evidence under scrutiny, pair internal records with controls from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially asset management, risk response, and configuration oversight. These controls tend to break down when agencies rely on static CMDBs that are not reconciled against live systems because unsupported assets and orphaned dependencies drift out of view.

Common Variations and Edge Cases

Tighter lifecycle governance often increases short-term operational overhead, requiring agencies to balance mission continuity against remediation cost and downtime risk. That tradeoff is real, especially in public sector environments with procurement delays, legacy integrations, and systems that cannot be patched in place.

Best practice is evolving, but current guidance suggests the same accountability model still applies even when an agency outsources hosting or uses shared services. The environment owner remains responsible for proving that support status is known, exceptions are approved, and the risk is monitored. Vendor dependence does not remove internal accountability; it changes the evidence trail.

Edge cases deserve explicit treatment. Air-gapped systems may have slower refresh cycles, but they still need a documented support strategy. Crown-jewel systems may justify temporary exceptions, but those exceptions should be time-bound and reviewed by leadership. When unsupported platforms also host secrets or non-human identities, the urgency increases because lifecycle failure becomes access risk. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that visibility and lifecycle discipline are inseparable.

Related resources from NHI Mgmt Group

• Who is accountable when legacy applications cannot support modern MFA methods?
• What breaks when digital ID systems cannot support both wallet storage and verification across providers?
• Who is accountable for documenting data flows and access paths in agentic AI systems?
• Who is accountable when Essential Eight maturity evidence cannot stand up to an audit or customer review?