Delegated Consent

What Delegated Consent Means in Practice

Delegated consent is the permission boundary that lets an application act for a user or administrator with an approved scope. It is more than a one-time click, because the resulting grant can persist as a standing entitlement until it is reviewed, narrowed, or revoked. That makes it part of access governance, not just user experience.

Why Delegated Consent Becomes a Governance Problem

The security issue is not the idea of consent itself, but the durability and reach of the permission it creates. If an application can continue using a token, refresh flow, or delegated grant after the person who approved it no longer needs it, the organisation can end up with access that outlives the original business need.

This is especially important where the application can read mail, files, profile data, or directory information, because those permissions often expose more than a single transaction. The practical question is whether the delegated scope still matches the task the app is performing, and whether the approval is still valid for the current account state.

How Delegated Consent Differs From Direct User Access

Delegated consent authorises an application to use a user’s authority within a defined scope, rather than giving the app its own independent standing rights. That means the application may inherit the user’s permitted view of data or actions while the grant remains active, which can blur accountability if ownership and review are not clear.

In mature environments, that distinction matters because the organisation is not only managing people’s access, but also the apps and integrations that act as a proxy for them. A consent grant can therefore become a durable trust relationship that needs inventory, ownership, and periodic revalidation just like other access paths.

Review, Revocation, and Lifecycle Control

Delegated consent should be treated as a lifecycle object with an owner, a purpose, and an expiry condition. When the purpose ends, or when the user leaves, the grant should be reassessed rather than assumed to disappear with the account. If an application keeps a valid delegated path after off-boarding, the organisation may retain unwanted access even though the original user no longer exists in the environment.

Good control depends on knowing which applications hold consent, what scopes they requested, and whether those scopes are still justified. That is why delegated consent belongs alongside access recertification, app registration, and third-party review, not just login policy.

What Organizations Should Look For When Consent Is Granted

Teams should focus on the actual scope being approved, the sensitivity of the data or action involved, and whether the consent is being granted to a first-party app, a vendor app, or a tool used by many employees. A broad consent request is often the signal that the app is asking for more authority than the business process truly needs.

It is also worth checking whether the grant can be reviewed centrally and whether users understand what they are approving. Where consent is hidden inside a routine workflow, the organisation can lose sight of the permissions it has effectively delegated.

Risk and Threat Considerations

Delegated consent can become a long-lived access path if organisations do not actively review who approved it, what scope was granted, and whether the grant still matches the business need. That creates exposure even after password resets or account off-boarding, because the application may still hold a valid delegated route into data or services.

Failure mechanism: A consented application retains usable access tokens or refresh-based authority after the original user session is gone, allowing the app to continue acting within the approved scope until the grant is explicitly removed.

Impact: Unreviewed consent can preserve access to mail, files, directories, or workflow actions, increasing the chance of data exposure, persistence, and unmanaged third-party access.

Practitioner Guidance

Why practitioners should care: Delegated consent is often granted once and then forgotten, but its risk profile changes whenever the user leaves, the app changes behaviour, or the requested scope grows. Treat it as an access control decision with an owner, not a one-time convenience setting.

Governance implication: Establish clear review ownership for consented applications so that approvals are periodically revalidated against business need, scope, and account status.

Practitioner takeaway: If you cannot quickly answer who approved the grant, what it can still reach, and when it was last reviewed, the consent is already drifting into unmanaged access.

Related resources from NHI Mgmt Group

• What do banks get wrong about customer consent in delegated access?
• What breaks when delegated consent is broader than the task actually needs?
• What is the difference between consumer consent and B2B delegated consent in open banking?
• How do MCP auth changes affect consent sprawl and delegated access revocation?