TL;DR: Scoped consent lets administrators grant only a subset of requested Microsoft identity platform permissions, according to Senserva, instead of turning every declared scope into a live entitlement. That shifts consent from a portal click to a governance decision, where partial grants, revocation, and feature-level access checks become the real control surface.
At a glance
What this is: This article explains scoped consent for Microsoft app registrations and shows how partial permission grants let admins approve only some requested scopes.
Why it matters: It matters because IAM teams need to govern what an application is actually entitled to, not what it asked for, especially when consent, revocation, and delegated access are all involved.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read Senserva's guide to scoped consent for Microsoft app registrations
Context
Scoped consent is the difference between an application request and an actual entitlement. In Microsoft identity platform terms, the app registration can ask for many permissions, but the grant object records the smaller set that the tenant truly approved. That distinction matters anywhere IAM teams govern delegated access, admin consent, and feature-scoped access for applications.
The governance problem is not whether an app can ask for more. It is whether administrators can see, review, and trim the effective permission set without losing track of what is live. That is the same control challenge that appears in NHI programmes whenever requested access, granted access, and operational use drift apart. For broader NHI lifecycle context, see the Ultimate Guide to NHIs.
This article is therefore about access decision quality, not just Microsoft mechanics. It shows how partial grants, incremental consent, and revocation logic turn permission review into an entitlement management discipline.
Key questions
Q: How should teams govern app consent when the requested scopes are broader than the feature in use?
A: Govern by the live grant, not the requested list. Approve only the scopes needed for the enabled feature, then validate the scp claim or consented scope string before the application exposes higher-risk functions. This keeps the tenant’s decision aligned to actual use instead of the developer’s maximum permission request.
Q: Why do partial consent controls matter for enterprise IAM teams?
A: They let the tenant separate a request from an entitlement. That matters because many applications over-request permissions for bundle convenience, while the business only uses a subset. Partial consent lets IAM teams preserve functionality while reducing blast radius, especially where write scopes, directory scopes, or mailbox access would otherwise be permanently live.
Q: What breaks when consent is re-run with .default or adminconsent?
A: A carefully trimmed grant can expand back to the full requested list. That happens because those flows reopen the static consent path and can restore permissions that were previously removed. Teams that rely on partial consent must treat consent replay paths as change events, or the effective entitlement set will drift upward again.
Q: How do security teams know consent governance is actually working?
A: They should look for evidence that banner choices, tag behaviour, and audit records all align across every relevant flow. A working programme shows the denied path is enforced, the granted path is consistent, and changes are controlled rather than improvised at the tag level.
Technical breakdown
Requested scopes versus granted scopes
Microsoft app consent uses two different objects. requiredResourceAccess on the application object is only the request, while oauth2PermissionGrant is the live delegated entitlement. The consented scope string is the authoritative source of what the tenant approved, and it can be narrower than the registration. That means effective access is determined by the grant, not the wish list. If teams review only app registration metadata, they miss the real security boundary and may approve features that were never intended to be live.
Practical implication: Review oauth2PermissionGrant objects as the control record, not application request metadata.
Why .default and prompt=consent can undo partial consent
The .default scope is static consent behaviour, not dynamic least privilege. It prompts for the configured permission set when no grant exists, and a prompt=consent flow can re-open the full registration list. That means a carefully trimmed grant can be expanded again if someone re-runs consent through the portal or adminconsent endpoint. Partial consent therefore survives only as long as consent workflows are tightly controlled and the re-prompt path is understood.
Practical implication: Treat consent re-prompt paths as change-controlled events, not routine administration.
How partial consent works for delegated and application permissions
Delegated permissions are stored per client, resource, and principal combination, so a subset can be granted by editing the scope string. Application permissions behave differently: they are assigned as app roles on the service principal, and partial consent happens at assignment time rather than token time. In both cases, the governance issue is the same. The tenant must know which permission subset is actually active, because token issuance will only reflect the grants that exist, not the permissions a developer requested.
Practical implication: Build separate review logic for delegated grants and app role assignments.
NHI Mgmt Group analysis
Scoped consent is an entitlement governance control, not a UX convenience. The article correctly shows that requested permissions and granted permissions are different objects, which is the real control boundary. That distinction matters because many tenants still treat admin consent as a one-time onboarding click instead of a living access decision. The practitioner conclusion is simple: if the grant is not the review target, the review is not governing access.
Partial permission consent exposes a useful but underused governance pattern for NHI-like access decisions. The same logic that applies to service accounts and tokens also applies here: ask for less, grant less, and keep the live entitlement smaller than the registration. That is especially relevant when third-party applications over-ask to support the largest customer use case. The practitioner conclusion is that consent design should follow actual feature use, not vendor bundle size.
Consent replays create standing privilege by accident. A trimmed grant can be restored by .default flows, portal admin consent, or the adminconsent endpoint, which means the tenant can silently drift back to the full requested set. This is a control failure because the governance model assumes someone will notice the replay and block it. The practitioner conclusion is that consent pathways need the same change discipline as privileged access changes.
Scoped consent only works when the effective permission set is observable. If teams cannot compute what is granted versus what was requested, they cannot answer basic entitlement questions. The article’s reporting example is important because it shows the right audit question is the delta between requested and granted scopes. The practitioner conclusion is that visibility into the delta is what makes partial consent governable at scale.
From our research:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.
- For a broader view of lifecycle governance, Ultimate Guide to NHIs , Key Challenges and Risks shows why over-privilege and visibility gaps keep recurring.
What this signals
Scoped consent is a useful reminder that entitlement design only works when the effective state is observable. If teams cannot easily distinguish requested permissions from granted permissions, they will keep overestimating what an application can do and underestimating what it should be allowed to do. That is why visibility into service accounts, grants, and token claims belongs in the same governance conversation as access review.
For identity programmes, the practical signal is to move from approval-by-form to approval-by-delta. A mature process tracks what was requested, what was granted, what was later removed, and which flows can silently restore the broader set. The OWASP Non-Human Identity Top 10 is a useful parallel reference when permissions and credentials start to drift together.
For practitioners
- Reconcile requested and granted permissions Build a report that compares requiredResourceAccess on app registrations with oauth2PermissionGrant and appRoleAssignment records so you can see the live entitlement delta.
- Block casual consent replays Treat admin consent, adminconsent endpoints, and .default-driven prompts as change-controlled events so a trimmed grant is not silently restored later.
- Gate features on effective scopes Check the scp claim or token scopes in application logic before enabling a feature, and fail closed when the live grant does not include the required permission.
- Review per-user and tenant-wide grants separately Inspect consentType values and separate principal-specific grants from AllPrincipals grants so tenant reporting does not miss accumulated user-level access.
Key takeaways
- Scoped consent turns Microsoft permissioning into a governance decision, because the live grant is what matters, not the registration wish list.
- Partial consent reduces blast radius when applications over-request scopes, but only if teams monitor replay paths that can restore the full set.
- IAM teams should validate effective scopes in tokens and build delta-based reviews so permission drift is visible before it becomes standing privilege.
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, NIST SP 800-53 Rev 5 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-03 | Partial consent addresses overbroad permissions and grant governance in NHI access. |
| NIST CSF 2.0 | PR.AC-4 | Scoped consent is a privilege management and least-access control issue. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the core control principle behind partial permission consent. |
| NIST Zero Trust (SP 800-207) | Scoped consent supports continuous entitlement verification in zero trust models. |
Limit each grant to the minimum scopes needed and remove unused scopes through change-controlled review.
Key terms
- Scoped consent: Scoped consent is approval that is limited to a specific action, resource, and duration. For AI agents, it is a practical way to prevent broad, reusable privilege while still allowing high-risk tasks to proceed with explicit accountability.
- Oauth2PermissionGrant: An oauth2PermissionGrant is the directory object that records delegated permissions that are actually live. It is the authoritative entitlement record for a client, resource, and principal combination, and it can be narrower than the registration's requested scope list.
- Admin Consent Replay: Admin consent replay is the act of re-running consent flows in a way that restores permissions previously trimmed away. It matters because a controlled partial grant can silently expand again when .default, portal consent, or adminconsent is used without governance oversight.
What's in the full article
Senserva's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step PowerShell examples for creating and trimming oauth2PermissionGrant records
- Full authorize URL examples for dynamic and incremental consent flows
- Token response handling details for scp validation in application code
- Audit query logic for comparing requested scopes with granted scopes across a tenant
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
