The accountable team is the one responsible for entitlement approval, revocation, and evidence retention across the full privilege lifecycle. If identity, device, and application teams each own a different step, accountability becomes fragmented and audit outcomes get weaker, not stronger. Central governance needs one decision owner even if controls are distributed.
Why This Matters for Security Teams
Shared privileged access across platforms only works when one team owns the decision, the evidence, and the lifecycle. When identity, infrastructure, and application teams each control a slice of the process, no one can prove who approved access, who revoked it, or who retains the audit trail. That ambiguity is exactly where NHI risk compounds, especially because privileged non-human identities are often over-entitled and poorly inventoried. NHI Mgmt Group notes that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which makes fragmented accountability more dangerous, not less. The issue is not just control ownership, but governance ownership across the full privilege lifecycle. Security teams often assume distribution equals resilience, but distributed control without a single accountable owner creates gaps in approval, revocation, and retention that auditors will still trace back to one organisation. In practice, many security teams encounter missing evidence only after access has already been misused or failed an audit, rather than through intentional review.
How It Works in Practice
The accountable team should be the one that can answer four questions at any time: who approved the privilege, why it was granted, when it expires, and what evidence proves revocation happened. That usually means a central identity, security, or governance function owns the policy and the audit record, while platform teams execute the technical steps. This separation is common, but the accountability must not be split. The OWASP Non-Human Identity Top 10 and the NHI Mgmt Group 52 NHI Breaches Analysis both reinforce the same operational lesson: privilege sprawl becomes incident material when ownership is unclear.
A workable model usually includes:
- One named approval authority for shared privileged access requests.
- One revocation owner responsible for removing access across every connected platform.
- One evidence owner who retains tickets, logs, attestations, and expiry records.
- Platform-specific administrators who implement controls but do not own the governance decision.
- Periodic re-certification tied to the business purpose of the access, not just the account name.
That model maps cleanly to standard governance expectations, but the mechanics vary by environment. In cloud, the accountable team may control IAM policy and delegated admin roles. In SaaS, it may control role assignment and token revocation. In CI/CD or automation platforms, it may also need to oversee secrets rotation and pipeline permissions because those privileges can be reused silently. Current guidance suggests that the accountable team should be able to revoke access without waiting on every downstream owner, even if those owners supply implementation support. These controls tend to break down when access is federated across legacy systems and each platform stores its own approval record because no single source of truth exists.
Common Variations and Edge Cases
Tighter central ownership often increases coordination overhead, requiring organisations to balance faster platform operations against stronger auditability. That tradeoff becomes sharper in federated enterprises, mergers, and managed service arrangements where several teams legitimately touch the same privileged path. There is no universal standard for this yet, but best practice is evolving toward a single accountable governance owner with delegated technical execution.
Two edge cases come up often. First, in shared admin models, a platform team may insist it owns the access because it can technically grant it. That is a control operator, not necessarily the accountable authority. Second, in outsourced or third-party managed environments, the vendor may execute the change while the customer retains accountability for approval, scope, and review. The customer still needs evidence, even if the vendor runs the console.
This is also where broader NHI governance matters. The same lifecycle ownership logic appears in the NHI Mgmt Group Ultimate Guide to NHIs — Key Challenges and Risks, especially where secrets, service accounts, and API keys outlive the teams that created them. One relevant benchmark is that only 20% of organisations have formal processes for offboarding and revoking API keys. That gap shows why accountability cannot be implied by tooling alone. It must be assigned, documented, and testable across every platform where privilege exists.
Related resources from NHI Mgmt Group
- What breaks when privileged access is split across multiple tools and platforms?
- Who is accountable when a cloud workload retains privileged access after it should have been removed?
- How should identity teams handle access decisions when user attributes are split across multiple systems?
- How should security teams audit privileged access across multiple clouds?
