Permissions define what an application can do, and consent is the mechanism that grants those permissions. Delegated permissions act on behalf of a signed-in user, while application permissions allow the app to act without a user. Review requested permissions before granting consent, limit who can approve them, and monitor for over-privileged apps and unexpected high-impact consent grants.
What permissions mean in Microsoft Entra ID
Permissions describe the scope of access an application receives in a tenant. In practice, they define whether the app can read user data, call Microsoft APIs, manage resources, or perform tenant-wide actions, and they should be treated as an authorization boundary rather than a formality in the sign-in flow.
In Entra ID, the permission model is part of the app’s trust profile. A low-friction request can still grant broad API reach, so the important question is not whether the app can sign in, but what it can do after consent is granted and whether that matches the business need.
Requested permissions should be evaluated against the app’s purpose, the data it will touch, and the blast radius if the app is abused. A permissions list that looks normal at a glance can still hide high-impact access when it includes Graph scopes, directory-level rights, or write privileges that are not required for the workflow.
How consent grants access
Consent is the approval step that allows the application to use the permissions it requested. For delegated permissions, the app acts in the context of a signed-in user, so the effective access is bounded by that user’s own rights plus the consented scopes. For application permissions, the app can act independently of a user, which makes the consent decision materially more sensitive.
The consent path matters because it can turn a simple onboarding step into standing access. User consent, admin consent, and consent policies should be separated operationally, since each one creates a different level of trust and review expectation. The safer the app’s requested scope, the less likely consent becomes a hidden privilege escalation path.
Consent should never be treated as a one-time administrative checkbox. Apps may be granted permissions long before they are widely deployed, and those permissions can later be abused if the app registration, secret, or token-handling path is compromised. Review the requested access in the context of the app’s actual runtime behavior, not just its vendor description.
What strong control looks like in practice
Strong control starts with limiting who can approve consent and with maintaining a clear approval standard for high-impact permissions. The safest model is to require review for anything that can access mail, files, directory data, or tenant-wide settings, especially when the request includes application permissions rather than delegated ones.
It also helps to pair consent governance with app inventory and permission review. The Entra ID Applications and Consent Guide is useful when you need a practical view of consent policies, admin consent workflow, and consent phishing patterns. For broader Entra hardening, the Active Directory and Entra ID Hardening Guide helps place app consent inside the larger access-control and privileged-access picture.
Monitor for unusual consent grants, especially newly approved apps with broad Microsoft Graph access, tenant-wide role-adjacent permissions, or permission combinations that do not fit the app’s stated function. The relevant operational question is whether the permission set is proportionate to the workflow, not whether the app was published by a recognizable vendor.
Risk and Threat Considerations
Permissions and consent are attractive abuse paths because they can convert a legitimate enterprise app into a trusted access channel. If a user or admin approves excessive scopes, an attacker who later compromises the app, its secret, or its token flow may inherit access that looks legitimate to the tenant.
Failure mechanism: Overbroad consent, especially for application permissions, creates a durable access path that can be reused for data theft, mailbox access, directory enumeration, or privilege expansion if the app is misused or compromised.
Impact: The result can be tenant-wide data exposure, stealthy persistence through a trusted enterprise app, or unauthorized actions that bypass normal user-facing controls and monitoring expectations.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Consent should grant only the access an app truly needs. |
| IA-5 — Authenticator Management | App consent commonly exposes credentials and tokens that need lifecycle control. | |
| AU-2 — Event Logging | Consent events and permission grants need auditability for review and detection. | |
| Recommendation — Restrict app permissions to the minimum scopes required for the workflow. Rotate and revoke app secrets and tokens when consented access changes. Log consent grants and review them for unusual or high-impact permission changes. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Apps with excessive Microsoft Graph or API permissions can overreach intended functions. |
| Recommendation — Validate that app permissions do not expose functions beyond the app’s business purpose. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Application permissions and service access can create overprivileged non-human access. |
| Recommendation — Audit app grants and remove any permissions that exceed the workload’s true need. | ||
Practitioner Guidance
What to verify: Check whether each requested permission is necessary for the app’s documented function, and treat any high-impact Graph or directory scope as a separate approval decision rather than a routine consent prompt.
Decision rule: If an app asks for application permissions or access that outlives a single user session, require explicit review and separate approval authority; if the scope cannot be justified, block it rather than compensating with after-the-fact monitoring.
Common mistake: Teams often approve consent because the app is useful or widely deployed, then assume the risk is low because the app is “known.” In Entra ID, the relevant control is the granted scope, not the brand name.
Practitioner takeaway: Consent is the moment authorization becomes real, so the right control objective is to keep the approved scope small, the approver set narrow, and the resulting app access continuously reviewable.
Related resources from NHI Mgmt Group
- What breaks when OAuth consent approval is abused in Microsoft Entra ID?
- Why do role changes and OAuth consent grants in Microsoft Entra ID create higher risk than ordinary administrative activity?
- How should security teams extend Microsoft Entra ID to legacy on-premises applications without rewriting every app?
- What breaks when teams try to modernize legacy applications too quickly for Microsoft Entra ID?