Admin Consent Workflow for Applications Not Configured

Without the admin consent workflow, non-administrator users have no built-in way to escalate permission requests for applications. As a result, they may resort to workarounds or, if user consent is allowed, grant permissions themselves (see "Unrestricted User Consent for Applications" IoE). In both cases, the organization loses visibility and control over permission grants, weakening enforcement of least privilege.

Consent phishing attacks (also known as illicit consent grant attacks) trick users into granting access to malicious apps that appear legitimate. Without an approval workflow, there's no review layer to flag suspicious permission scopes like Files.ReadWrite (full access to user files) or Mail.ReadWrite (read and write access to all mailboxes). As a result, attackers can gain persistent access to user data, access that isn't revoked by password changes or MFA.

Without the admin consent workflow, administrators must handle permission requests through ad hoc channels like email, chat, or direct contact which create audit blind spots. There's no automated request process, reminder system, or record of who approved what, when, or why. This lack of auditing makes it difficult to prove that proper review occurred before granting application permissions.

The MS.AAD.5.3v1 policy from the CISA "M365 Secure Configuration Baseline for Microsoft Entra ID," mandated by BOD 25-01, requires that "An admin consent workflow SHALL be configured for applications." Microsoft also recommends in Configure Microsoft Entra for increased security that "Admin consent workflow is enabled."

Enable and configure the admin consent workflow in your Entra ID tenant to establish a clear, standardized process for users to request permissions for applications that require admin consent. When enabled, users see an 'Approval required' dialog and can submit a justification. The system automatically routes the request to designated reviewers. This structured workflow covers all requests and gives administrators full visibility into all pending requests.

After enabling the admin consent workflow, administrators must assign appropriate reviewers. To approve requests, reviewers must hold a specific role such as Global Administrator, Cloud Application Administrator, Application Administrator, or Privileged Role Administrator. Assigning someone as a reviewer does not elevate their privileges. Reviewers without the required role can view, block, or deny requests, but only those who already hold a role authorized to grant tenant-wide admin consent can approve them. Tenable recommends assigning the "Cloud Application Administrator" role whenever possible, as it provides the necessary privileges without the broad access of the "Global Administrator" role, which you should reserve for emergencies. However, only Global Administrators can approve admin consent requests for applications requesting Microsoft Graph app roles.

Periodically audit the list of reviewers to keep assignments up to date as personnel change. New reviewers can only see requests created after their assignment, while removed reviewers retain access to previous requests. Administrators should carefully plan reviewer additions and removals to prevent gaps in coverage.

With the review process formalized, configure email notifications and expiration settings for consent requests. These settings alert reviewers when new requests are submitted or nearing expiration. Users who submit requests receive notifications when their requests are approved, denied, or blocked. Defining an expiration period prevents stale requests from lingering indefinitely.

Name: Admin Consent Workflow for Applications Not Configured

Codename: ADMIN-CONSENT-WORKFLOW-FOR-APPLICATIONS-NOT-CONFIGURED

Severity: Medium

Type: Microsoft Entra ID Indicator of Exposure