Who is accountable when a legacy system or vendor path is left with standing access?

Why This Matters for Security Teams

standing access in a legacy system or vendor path is not just a technical oversight. It is an ownership failure that turns a temporary exception into a permanent exposure. When access is left in place, the real risk is not only compromise, but also ambiguity about who must review, remove, or renew that access when business conditions change. That ambiguity is exactly where attackers and audit findings thrive. The OWASP Non-Human Identity Top 10 frames excess privilege and lifecycle gaps as recurring identity failure modes, and NHIMG’s Ultimate Guide to NHIs shows how often that failure becomes systemic rather than isolated. One NHIMG finding is especially telling: only 20% of organisations have formal processes for offboarding and revoking API keys. In practice, many security teams discover the standing path only after the system has already been relied on for months, rather than through intentional review.

How It Works in Practice

Accountability for standing access should be explicit across three layers: identity ownership, platform ownership, and application ownership. The identity owner is responsible for the lifecycle of the credential or service account. The platform owner is responsible for the control plane that issued or stored the access. The application owner is responsible for proving the business need still exists. If a vendor path is involved, the vendor contract and the internal sponsor must both define who can approve, rotate, and revoke access. Operationally, this works best when standing access is treated as an exception with a named expiry date, a review cadence, and a documented fallback if the owner disappears. Current guidance from CISA Zero Trust Maturity Model and the OWASP Non-Human Identity Top 10 suggests that access should be continuously discoverable, not buried in tickets or tribal knowledge. NHIMG’s 52 NHI Breaches Analysis is useful here because it shows how often identity misuse persists when no one is assigned to retire it. A practical control set usually includes:

• owner mapping for every legacy account, integration key, and vendor credential
• time-bound exception approval with automatic expiry where possible
• quarterly review of standing access against actual usage
• revocation runbooks for systems that cannot support automated removal
• backup contact and escalation path when the primary owner leaves

These controls tend to break down when legacy systems have no native audit trail and the vendor insists on shared credentials because revocation becomes operationally risky and politically delayed.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance faster service continuity against stronger removal discipline. That tradeoff is real in mainframes, industrial systems, outsourced support paths, and integrations that were never designed for modern identity governance. In those environments, current guidance suggests documenting compensating controls rather than pretending the standing access is low risk. One common edge case is the “break-glass forever” account. Emergency access is legitimate, but if it lacks a review owner or expiry mechanism, it becomes permanent standing access by another name. Another is vendor-managed support access, where the vendor argues that continuity depends on always-on credentials. The better approach is to assign internal accountability anyway, then require evidence of use, scope, and renewal. If the system cannot support per-user accountability, the organisation should treat that as a risk acceptance decision, not a control pass. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — The NHI Market both reinforce a simple point: visibility and lifecycle ownership are what turn identity sprawl into governable access. Where those are missing, the question is not whether standing access exists, but how long it has been invisible.

Related resources from NHI Mgmt Group

• Who should be accountable for vendor access in healthcare systems?
• Who is accountable when a DDoS outage disrupts customer access?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who should be accountable for DNS access reviews?