Who is accountable for access in disconnected applications?

Why This Matters for Security Teams

Disconnected applications often sit outside the clean lifecycle controls that security teams expect from modern identity platforms. That creates a governance gap: access is requested in one place, provisioned in another, and revoked only if someone remembers to chase it. The result is not just administrative friction. It is unclear ownership, slow removal of access, and exceptions that quietly become permanent.

NHI Management Group’s Ultimate Guide to NHIs shows how often organisations lose visibility over non-human access, with only 5.7% reporting full visibility into service accounts. That same pattern appears in disconnected applications: the technical owner, identity team, and business approver each assume another group will act. The accountability question matters because access cannot be governed by policy alone if no one can prove who approved it, who can revoke it, and who must review it when the business need changes. Current guidance from OWASP Non-Human Identity Top 10 reinforces that identity sprawl and weak lifecycle ownership are common failure modes. In practice, many security teams encounter stale access only after an audit finding, incident, or decommissioning project has already exposed the gap.

How It Works in Practice

For disconnected applications, accountability should be mapped to the party that can actually change the access state, not just the party that requested it. That usually means shared accountability with explicit roles: the application owner defines business necessity, the identity governance function enforces process and evidence, and the business approver confirms need and duration. The control objective is simple: every access grant should have a named owner, a revocation path, and a review cadence.

In practice, teams should document three things for each disconnected system. First, who approves access on behalf of the business. Second, who can execute removal when access is no longer needed. Third, how evidence is stored so the change can be proven later. This is especially important when the system does not integrate with central IAM or PAM, because manual tickets and spreadsheets become the de facto control plane. The OWASP guidance on non-human identities is useful here because it frames lifecycle accountability as a core security requirement, not a back-office task. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how disconnected ownership often leads to excessive privileges and weak offboarding discipline. Where organisations have mature process, they also maintain a clear exception register, so temporary access does not survive beyond its justification.

• Assign a business owner for need and duration.
• Assign an operational owner for provisioning and revocation.
• Require evidence of approval, change, and review for every exception.
• Set a review date when the application cannot enforce automated expiry.

This approach aligns with the OWASP Non-Human Identity Top 10 emphasis on ownership, visibility, and lifecycle control, and it is reinforced by the broader findings in the 52 NHI Breaches Analysis, where failure to revoke or track access repeatedly shows up as a root cause. These controls tend to break down when disconnected applications have no reliable change record and access can only be modified by a single administrator or by offline manual steps.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster access delivery against stronger review and evidence requirements. That tradeoff becomes most visible in legacy platforms, acquired systems, and partner-managed applications, where no central identity workflow exists.

There is no universal standard for this yet, but current guidance suggests that accountability should move with control, not merely with title. If the application owner can define the business purpose but cannot revoke access, the identity governance team should own enforcement mechanics. If a third party administers the system, the contract should state who performs revocation, who supplies evidence, and how quickly emergency access is removed. In high-risk environments, a second approver or periodic recertification is often justified, but that should be a risk decision rather than a default assumption.

One common mistake is treating “shared responsibility” as a substitute for named responsibility. That creates ambiguity when access remains in place after a project ends, a vendor changes staff, or an integration is retired. The strongest control is a documented chain of accountability that survives staff turnover and audit scrutiny. NHI Management Group’s research on Ultimate Guide to NHIs shows that revocation discipline is often where organisations fail first, not in approval design. The practical answer is to assign one accountable owner, even when several teams share the work.

Related resources from NHI Mgmt Group

• What is the difference between protecting applications and protecting access?
• 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?