Who is accountable when access remains active in a disconnected application?

Accountability sits with the application owner and the identity governance team together, because both the control gap and the exception management process determine whether access persists. If the organisation cannot revoke access in time or prove who approved it, the governance model has failed regardless of whether a policy exists.

Why This Matters for Security Teams

When access remains active in a disconnected application, the immediate risk is not just stale entitlement. It is the breakdown of control ownership: the application may still enforce access locally while the identity team believes deprovisioning has completed. That gap creates audit exposure, residual privilege, and a clear path for misuse if an account or token is later rediscovered. The issue is especially common in systems that are not continuously synchronized with the central identity stack.

Security teams should treat this as a governance failure, not a paperwork issue. The organisation must be able to prove who approved access, who owns the application lifecycle, and what mechanism is responsible for revocation when the app is offline or disconnected. NHI Management Group’s Ultimate Guide to NHIs frames this as a lifecycle control problem: identity state is only useful when it can be enforced across the full environment, including disconnected services. OWASP’s Non-Human Identity Top 10 likewise highlights that unmanaged machine access becomes a persistent attack surface when cleanup is inconsistent.

In practice, many security teams discover the problem only after an audit, an incident, or a failed offboarding request, rather than through intentional control testing.

How It Works in Practice

Accountability in this scenario is shared, but not diluted. The application owner is accountable for the system of record, its access model, and whether the application can receive and act on revocation events. The identity governance team is accountable for the governance workflow, approval traceability, entitlement review, and escalation when automated deprovisioning fails. If either side assumes the other is handling the exception, access often remains active indefinitely.

In practice, the right operating model includes three checks:

• Map every disconnected application to a named owner and an explicit deprovisioning path.
• Define whether revocation is push-based, scheduled, or manual when connectivity is absent.
• Record exception approvals with expiry dates and a fallback control when sync is unavailable.

For machine identities and service accounts, the same logic applies to credentials, tokens, and certificates. The issue is not only whether access can be removed, but whether the organisation can prove that removal was attempted, accepted, and verified. That is why current guidance increasingly links lifecycle governance to discovery and remediation discipline, as reflected in The State of Secrets in AppSec. It also aligns with identity governance expectations in NIST’s Cybersecurity Framework, where access control and asset accountability must work together.

Disconnected applications tend to break down when ownership is unclear, revocation depends on manual follow-up, and no one validates whether access removal actually reached the target system.

Common Variations and Edge Cases

Tighter deprovisioning controls often increase operational overhead, requiring organisations to balance rapid access removal against legacy-system constraints. That tradeoff becomes sharper in environments with air-gapped systems, outsourced platforms, or applications that only synchronize on a schedule.

There is no universal standard for this yet, but best practice is evolving toward explicit exception handling with expiry, compensating controls, and periodic reconciliation. If an application cannot accept automated revocation, the application owner should document the residual risk and the identity governance team should enforce review cadence until the gap is closed. For high-risk access, the organisation should treat “cannot revoke” as a temporary exception, not a stable operating state.

This is also where disconnected applications often overlap with broader NHI governance problems. A stale service account can remain active long after a human leaves, a vendor contract ends, or a process changes. NHI Management Group’s 52 NHI Breaches Analysis shows why persistent identity drift is so frequently exploited, while OWASP’s guidance reinforces the need to inventory and retire machine access with the same rigor used for human accounts.

When ownership is split across IT, security, and application teams without a single revocation authority, the practical answer is that accountability is shared until the control failure is corrected, then it becomes measurable again.

Related resources from NHI Mgmt Group

• Who is accountable when access remains active after a leaver event?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when access remains active after a mass exodus?
• Who should be accountable when a SaaS application is retired but access remains?