The authorisation a user or administrator gives to an application to act on their behalf. Once granted, that consent can outlive a password reset or even off-boarding unless it is explicitly reviewed and revoked, creating long-lived access that security teams must govern.
Expanded Definition
Delegated consent is the permission a human user or administrator grants to an application so it can act on that person’s behalf, often through OAuth-based workflows. In NHI security, the important issue is not the login event itself but the standing authorisation that remains after the original business need changes. Definitions vary across vendors when delegated consent is mixed with app registration, token issuance, or enterprise admin consent, so practitioners should treat the consent record, the token, and the underlying NHI as separate governance objects. That distinction matters because delegated consent can survive password resets, user rehires, and even off-boarding until it is reviewed and revoked. In modern identity programs, this makes it a governance control as much as an authentication feature, and it should be mapped to lifecycle review, least privilege, and revocation discipline described in the NIST Cybersecurity Framework 2.0. The most common misapplication is assuming a password reset removes all application access, which occurs when consented tokens and app-level grants are left active.
Examples and Use Cases
Implementing delegated consent rigorously often introduces administrative overhead, requiring organisations to weigh user convenience against tighter review, approval, and revocation processes.
- A finance employee approves a reporting app to read mailbox data, and that approval remains valid after role changes unless the consent is revalidated.
- An admin grants a SaaS integration broad tenant-wide access, creating a durable NHI pathway that should be tracked alongside other standing permissions in the Ultimate Guide to NHIs.
- An AI assistant receives delegated permission to create tickets on behalf of a service desk agent, which is useful operationally but must be scoped and monitored like any other identity grant.
- A third-party workflow tool is approved to sync files from a shared drive, and the access persists even after the sponsoring team leaves the project.
- Security teams use consent review campaigns to identify stale or excessive grants, then align the cleanup with access governance and NIST Cybersecurity Framework 2.0 recovery and protection practices.
In practice, the term is most visible where delegated authority crosses application boundaries, especially in cloud productivity suites, identity platforms, and AI-enabled workflows. The operational question is not whether consent was once justified, but whether it is still justified now.
Why It Matters in NHI Security
Delegated consent becomes a security problem when teams confuse user intent with ongoing authorisation. A user may leave, change departments, or lose a password, yet the application grant can continue to operate with valid tokens or refresh paths. That is why consent review belongs in the same lifecycle discipline as secrets rotation, off-boarding, and privilege reduction. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently, which helps explain how long-lived grants persist unnoticed in production. The same governance gap appears in the Ultimate Guide to NHIs, where excessive privilege and weak visibility repeatedly amplify risk. A mature program treats delegated consent as an entitlement that must be inventoried, time-bounded where possible, and periodically reapproved in line with Zero Trust and least privilege principles from the NIST Cybersecurity Framework 2.0. Organisations typically encounter delegated consent as a root cause only after a compromise, unexpected data exposure, or failed off-boarding, at which point it becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Delegated consent creates standing access that must be inventoried and revoked like other NHI permissions. |
| NIST CSF 2.0 | PR.AC | Delegated consent is an access governance issue tied to permission management and least privilege. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of granted access, including consented application authority. |
Track delegated grants, review scope regularly, and revoke stale consent during access governance cycles.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
