Who is accountable for access requests when users ask for access on behalf of others?

Why This Matters for Security Teams

When someone requests access on behalf of another person, the real risk is not just who clicked “submit.” It is whether the organisation can prove who needed the access, who vouched for it, and who accepted the residual risk. That matters for auditability, segregation of duties, and incident response. The OWASP Non-Human Identity Top 10 is useful here because delegated access often creates the same accountability gaps seen in NHI workflows: unclear ownership, weak approvals, and poor traceability. NHIMG’s Ultimate Guide to NHIs shows how quickly access control failures become operational exposure when identity ownership is blurred.

This question is often mishandled because teams treat delegated requests as a workflow convenience instead of a control decision. If the requester is not the eventual user, the approval record must still show who is accountable for the business need and who is accountable for granting access. In practice, many security teams encounter this only after access is over-provisioned, not through deliberate governance.

How It Works in Practice

Accountability should be split across the workflow, but never diluted. The requester is accountable for accurately representing the need, the approver is accountable for validating that need, and the access administrator is accountable for implementing the grant exactly as approved. For controlled environments, that means the ticket, approval record, and identity audit trail should preserve all three roles, even when a manager, assistant, or system submits the request on another person’s behalf.

Current guidance suggests treating delegated requests as a traceability problem first and an access problem second. NIST SP 800-53 Rev. 5 reinforces the need for accountable access control and auditable authorization, which is why the evidence trail matters as much as the entitlement itself. For NHI-adjacent governance, NHIMG’s Ultimate Guide to NHIs also highlights that visibility and ownership are prerequisites for controlling privilege sprawl.

• Capture the actual end user, the requester, and the approver as distinct fields.
• Require a business justification that names the person who will use the access.
• Preserve who approved, who provisioned, and when the access was activated.
• Use periodic review to confirm the delegated requester is still authorised to act in that role.
• Apply the same approval depth to delegated requests as direct requests, unless policy explicitly says otherwise.

Where organisations mature this well, delegation becomes a controlled exception with full evidence, not an informal shortcut. These controls tend to break down when shared inboxes, informal managers, or service desks are allowed to submit requests without naming the true beneficiary, because accountability becomes impossible to reconstruct after the fact.

Common Variations and Edge Cases

Tighter delegated-access controls often increase ticket handling time and review overhead, so organisations have to balance speed against the need for defensible accountability. That tradeoff is real, especially in high-volume support desks, but it is still better than creating ambiguous approvals that cannot survive audit scrutiny.

There is no universal standard for every delegation scenario. Best practice is evolving for cases such as executive assistants, temporary deputies, shared business functions, and automated request submissions. In those environments, policy should define whether the requester is acting as a proxy, whether proxy authority must be pre-approved, and whether the approver must be different from both the requester and the beneficiary. The key is not to eliminate delegation, but to make it explicit and reviewable.

NHIMG’s 52 NHI Breaches Analysis is a useful reminder that weak identity attribution often precedes broader compromise, while OWASP’s Non-Human Identity Top 10 reinforces the importance of traceable ownership and least privilege across automated and delegated workflows. The practical rule is simple: if an organisation cannot show who asked, who benefited, and who approved, the request was not actually accountable.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access requests are approved through chat and incident tools?
• Who should be accountable for approving access when requests are routed through self-service workflows?
• How should security teams govern access requests for sensitive resources without slowing down operations?
• Who should be accountable for securing disconnected applications when access is managed through custom API automation?