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.
Why .default can widen a consented grant again
.default is not a fresh, least-privilege request for only the scopes you typed into a specific call. It asks for the permission set already configured on the app registration, so the effective consent surface can snap back to the registration’s full configured set. That makes it easy for a previously narrowed tenant decision to be expanded again if the flow is not tightly governed.
Which Microsoft consent paths can reintroduce the full set
The main paths that matter are interactive consent and tenant-wide admin consent. A flow such as prompt=consent can present the broader set again, while /adminconsent can authorise the configured permissions for the tenant even when a prior decision tried to keep the grant smaller. The practical issue is not the wording of one request, but whether the tenant actually controls every path that can trigger consent.
That is why consent trimming on its own is not durable if app registration settings still advertise a larger permission bundle. The registration remains the source of truth for what can be requested, and the runtime flow can surface that bundle again unless the application owner and tenant owner coordinate the registration, consent policy, and admin approval path.
What practitioners should verify before trusting a “scoped” consent
Check the app registration, not only the token or one successful consent dialog. If the registration still carries broader delegated or application permissions, a later consent interaction may restore them. Also check whether admin consent is permitted, who can invoke it, and whether users can trigger fresh consent prompts that bypass the intent of the earlier narrowing decision.
For tenant operators, the useful control is to treat consent as a lifecycle state, not a one-time event. Review the registration, constrain who can grant consent, and make sure the approved permission set is the one that will actually be presented by the app’s common authentication and authorisation flows.
Risk and Threat Considerations
A carefully reduced consent can fail open if the tenant leaves alternate consent pathways available. The risk is privilege re-expansion, where a user or administrator unknowingly reauthorises broader access than was originally intended, increasing the blast radius of the app if it is later abused or compromised.
Failure mechanism: the permission bundle configured on the registration remains broader than the intended tenant decision, and a later consent flow re-presents that broader bundle through prompt=consent or admin consent.
Impact: the app can regain access to APIs or data that the tenant believed had been removed, undermining least privilege and making the original consent reduction unreliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about preventing broader-than-intended app access. |
| IA-5 — Authenticator Management | Consent and grant decisions depend on controlling the credentials and tokens that enable access. | |
| Recommendation — Limit consent and app permissions to the minimum required set. Manage tokens and secrets so broadened consent cannot be abused. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Consent widening is an access-control governance issue for app grants. |
| Recommendation — Define and enforce approval rules for app consent and permission changes. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Consent flows can reauthorize access when the permission decision is not tightly controlled. |
| API5 — Broken Function Level Authorization | Admin-consent style pathways can authorize broader functions than intended. | |
| Recommendation — Validate that auth and consent flows cannot restore unintended access. Restrict high-privilege grant paths to approved administrators. | ||
Practitioner Guidance
What to verify: Compare the effective permissions on the service principal with the registration’s configured permissions and with the paths users can still reach, including admin-consent routes. If those three do not match the intended scope, treat the consent decision as incomplete.
Decision rule: If a permission must stay trimmed, control the registration and the grant path together, otherwise assume a future consent interaction can widen the grant again. The safe state is not “we once reduced it,” but “the broader request can no longer be reintroduced without an explicit change decision.”
Practitioner takeaway: Consent scope is only durable when the registration, consent workflow, and tenant approval boundaries all point to the same permission set.
Related resources from NHI Mgmt Group
- Why do Microsoft first-party apps create extra risk in consent phishing attacks?
- Who is accountable when OAuth consent abuse succeeds in a Microsoft environment?
- How should security teams reduce Microsoft 365 identity risk from default settings?
- How should security teams handle OAuth consent risk in Microsoft 365?