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: NHI Mgmt Group's analysis, drawing on Senserva's blog post: Microsoft scoped consent lets admins grant only selected app permissions, separating requested scopes from effective entitlements.
Why it matters: It matters because IAM teams can right-size delegated access, limit blast radius, and treat consent as an access decision that must be reviewed, revoked, and audited like any other privilege change.
Context
In Microsoft identity platform terms, an app registration is a permission request, not an entitlement. The governance gap appears when teams treat the portal’s admin consent button as an all-or-nothing control and lose the distinction between what the application asks for and what the tenant actually grants.
Scoped consent, also called partial permission consent, lets the registration’s declared scopes and the live grant diverge on purpose. That matters for IAM and NHI governance because the effective permission set is what the tenant has authorised, not what the developer listed on the app object.
The article focuses on permission right-sizing, feature-gated consent, and the operational difference between requested scopes, delegated grants, and application permissions. For practitioners, the central issue is whether consent is being managed as a controlled entitlement lifecycle or as onboarding paperwork.
Key questions
Q: What breaks when app registrations are treated as live permissions instead of requests?
A: Teams lose sight of the effective entitlement set and may assume an application can use every declared scope. In reality, the grant object is what authorises access, so reviews, revocation, and feature checks must be based on the live grant rather than the registration’s requested scopes.
Q: Why can .default undo a carefully scoped Microsoft consent decision?
A: Because .default reuses the configured permission set on the registration, and flows such as prompt=consent or /adminconsent can reprompt for the full list. If the tenant does not control those pathways, a trimmed grant can be widened again without a new design decision.
Q: How do security teams know if scoped consent is actually working?
A: Look for a consistent delta between requested permissions and live grants, then confirm that token scopes match the smaller approved set. If the requested list and granted list are identical everywhere, consent is probably operating as a button click rather than a governance decision.
Q: When should organisations use scoped consent instead of granting the full app permission list?
A: Use it whenever the vendor asks for more than the enabled feature set, or when compliance rules limit specific data paths such as mailbox content or directory write access. Scoped consent is the right control when the tenant can justify a subset and wants the app to function with less privilege.
Technical breakdown
RequiredResourceAccess versus oauth2PermissionGrant
Microsoft splits declared permissions from granted permissions into two different objects. requiredResourceAccess on the application object is the developer’s requested scope list, while oauth2PermissionGrant is the actual delegated entitlement held in the directory. That distinction is the core of scoped consent: an app can ask for many permissions, but only the subset written into the grant string becomes live access. In practice, the live grant is what the API honours, while the registration is only input to consent flow and token generation. Misreading one as the other is how teams overestimate effective privilege.
Practical implication: review the grant object, not just the app registration, when deciding what the application can actually do.
How partial consent changes token behaviour
Partial consent works because token issuance reflects the granted scope set, not the full registration list. When a client uses dynamic consent or incremental consent, the resulting token contains only the scopes that were approved, and the scp claim should match that live entitlement. If the app assumes the registration equals runtime access, it fails later at the API call instead of at authorisation time. The article also shows that feature gating should check token scope, not configuration intent, because effective access is smaller than declared access whenever scoped consent is in use.
Practical implication: gate application features on returned token scopes and scp claims, not on the registration’s requested permissions.
.default and consent rehydration risks
The .default scope collapses scoped consent back toward static consent by asking for the configured permissions already recorded on the registration. That means it can preserve a partial grant if one already exists, but it can also re-prompt or restore the full list when used with prompt=consent, admin consent buttons, or /adminconsent flows. The article also notes that revocation trims the same grant object, but existing tokens remain valid until expiry, so the governance problem is not only what is authorised but how quickly that change takes effect in practice. In client credentials, there is no runtime partial consent path at all, only app role assignment time.
Practical implication: treat .default, admin consent, and grant updates as change-controlled events because they can undo or delay partial-rights decisions.
Threat narrative
Attacker objective: The objective is to preserve unnecessary access inside the tenant so that the application, or anyone abusing it, can reach more data and actions than the business intended.
- Entry occurs when a tenant accepts an app registration’s broad requested scopes as if they were unavoidable, often through a single admin consent action.
- Credentialed abuse follows when the live grant includes more delegated or application permissions than the feature path actually needs, expanding what the app can access.
- Escalation happens when the over-granted scopes unlock mailbox, directory, file, or tenant-wide actions that exceed the business intent behind the integration.
- Impact is the persistence of standing overreach, where unused scopes remain live until someone explicitly trims the grant or removes the app.
Breaches seen in the wild
- Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scoped consent is an entitlement-lifecycle problem, not a UI problem: The article shows that Microsoft app registrations ask for permissions, but oauth2PermissionGrant records what the tenant actually approved. That distinction is the governance boundary, because the control exists in the grant object and not in the application’s declared wish list. Practitioners should stop treating consent as a deployment step and start treating it as an entitlement change with review, revocation, and audit requirements.
Change control, not initial approval, is where partial consent usually fails: The most important risk is not that an app requests too much, but that later flows such as .default, admin consent, or /adminconsent can rehydrate the full registered permission set. That creates a governance drift pattern where a carefully trimmed grant is silently widened again. The implication is that scope right-sizing only holds if downstream consent pathways are controlled as tightly as initial approval.
Requested permissions are not effective permissions: This article sharpens a useful named concept, effective permission delta, the difference between what the developer asked for and what the tenant granted. When that delta is zero by default, nobody is making a governance decision at all. The practitioner consequence is to build reporting around the delta itself, because that is where overreach, unused privilege, and consent exceptions become visible.
Scoped consent is how feature-level access should be governed in SaaS-to-SaaS integrations: The vendor model described here is common across Microsoft-connected applications, where one registration supports several code paths and only some are needed by a given customer. That means the security question is not whether the integration is trusted, but which feature-specific scopes are justified for this tenant. The implication is to make permission review part of feature adoption, not only tenant onboarding.
Client credentials make the over-grant problem more structural, not less: For application permissions there is no user-driven partial grant at token time, only app role assignment at the service principal level. That means blast radius is determined entirely by what was assigned earlier, and there is no downstream consent dialogue to correct mistakes. Practitioners should therefore treat app role assignment as a privileged lifecycle event with the same scrutiny they apply to any standing machine entitlement.
What this signals
Effective permission delta: Security teams should measure the gap between requested scopes and granted scopes instead of assuming the app registration is the truth. That delta is where overreach, unused privilege, and consent exceptions become visible in a Microsoft tenant.
Consent reviews need to move closer to feature adoption. If an app only needs read access for pilot use, a tenant should not normalise write access just because the registration listed it, because the approval state becomes harder to unwind once the feature is live.
For practitioners
- Map declared scopes to live grants Compare requiredResourceAccess on the app registration with oauth2PermissionGrant and appRoleAssignment on the service principal. Use the delta to identify scopes that are requested, granted, or left over after feature changes.
- Review .default and admin consent paths Identify any app or workflow that uses .default, prompt=consent, /adminconsent, or the portal’s admin consent button. These paths can restore scopes that were deliberately trimmed, so they need change control and approval review.
- Gate features on effective scopes Check returned token scopes and the scp claim before enabling a feature such as calendar sync, file access, or mailbox actions. If the scope is absent, keep the code path closed rather than relying on the registration list.
- Right-size tenant-wide grants Trim oauth2PermissionGrant objects to the smallest live scope set that matches the purchased feature set, and remove unused permissions rather than leaving them in place. Recheck the same grant after product updates or contract changes.
- Audit application permissions separately Treat appRoleAssignment as a separate review stream for client-credentials apps because there is no user consent step at token time. Review each role assignment as a standing privilege with its own business justification.
Key takeaways
- Scoped consent exposes a basic IAM truth: a declared permission is not the same thing as an authorised entitlement.
- The operational risk is drift between what the app asked for and what the tenant actually granted, especially when later flows can restore the full list.
- Practitioners should review live grants, not registrations, and treat consent changes as governed entitlement updates.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on reducing app permissions to the minimum live grant. |
| NHI-01 — Improper Offboarding | Revoking unused scopes and trimming stale grants is a lifecycle control problem. | |
| NHI-07 — Long-Lived Secrets | Standing grants behave like persistent access that should not remain broader than needed. | |
| Recommendation — Apply NHI-05 by trimming app grants to the smallest scope set that still supports the feature. Use NHI-01 to remove stale consent and revoke permissions no longer justified by the business use case. Reduce long-lived access by replacing broad standing grants with narrow, reviewable permission sets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about managing the lifecycle and scope of credentials that authorise access. |
| Recommendation — Apply IA-5 to govern permission issuance, trimming, and revocation for application credentials and grants. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Scoped consent is fundamentally about effective entitlements in a tenant. |
| Recommendation — Use PR.AA-05 to verify that granted entitlements match the intended business scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Over-granted scopes increase the access available for post-compromise abuse and movement. |
| Recommendation — Map excessive app permissions to TA0006 and TA0008 when assessing blast radius and abuse potential. | ||
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.
- App Registration: An app registration is the identity object Entra ID uses to represent an application and its access requirements. It defines how the app authenticates, what permissions it can request, and which tenant resources it may reach. In security testing, it must be treated as a controlled access object, not a disposable configuration step.
- 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.
- Effective Permission Delta: The difference between the permissions an application requested and the permissions the tenant actually granted. In identity governance, this delta is where overreach, unused access, and consent drift become measurable and auditable.
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.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org