Key takeaways

  • An OAuth consent grant gives an app standing access to data without a password or a second factor, so a malicious app can survive a password reset.
  • Restrict user consent to verified publishers and low-risk permissions, or turn it off, then route everything else through the admin consent workflow.
  • Name reviewers, set a service-level target for requests and record the reason for every approval or denial.
  • Review existing grants on a schedule. Old, unused apps with broad permissions are the usual finding.

Start with the answer: control who can consent to applications in Microsoft Entra ID, send every request that goes beyond a short safe list to a named reviewer, and audit the grants you already have. Attackers know that tricking one employee into clicking Accept on a look-alike app can give them mailbox or file access that does not depend on the user's password, and that keeps working after a password change until the grant is revoked. Consent governance closes that door without blocking the apps your staff genuinely need.

What consent actually does

When a person signs in to a third-party app with a work account, the app asks for permissions, such as reading mail, reading files or acting on the user's behalf at any time. If the user accepts, Entra ID records a grant. The app then receives tokens and can call Microsoft services within that grant. Some permissions can be approved by a user. Others, usually the broad tenant-wide ones, require an administrator. Microsoft Learn describes this split in its overview of user and admin consent, and it is the starting point for any policy.

Illicit consent phishing exploits the gap. The attacker registers an app with a convincing name, sends a link, and the victim sees a genuine Microsoft sign-in page followed by a consent prompt. Nothing looks like a fake login page, so many filters and many people miss it.

Step 1. Decide what users may approve

In the Entra admin center, the user consent settings under Enterprise applications control what staff can approve alone. Microsoft documents three broad choices: do not allow user consent, allow consent only for apps from verified publishers requesting low-impact permissions, or allow consent for any app. The last option is the riskiest and, for most organizations, should not be the long-term setting. A common target is the middle option, with the definition of low-impact permissions reviewed by security, or no user consent at all for tenants that handle regulated data. Group-owner consent and the consent policies behind these settings deserve the same review.

Step 2. Turn on the admin consent workflow

If users cannot approve an app, they need somewhere to go or they will look for a workaround. The admin consent workflow lets a user request approval from inside the consent prompt. The request goes to reviewers you choose, who can approve, deny or block. Practical points from Microsoft's configuration guidance:

  • Choose reviewers who understand the data. A user, group or role can be a reviewer, so use a small named group rather than one person.
  • Enable email notifications to reviewers, and reminders, so requests do not sit unseen.
  • Set how long a request stays open before it expires.
  • Know the permission needed to configure the workflow and to review requests, and give it to as few people as the job allows.

Write down what reviewers should check before approving. That is the next section.

Step 3. Review risky apps consistently

A good review is short and repeatable. Ask the following.

  • Who publishes the app, and is the publisher verified? An unverified publisher asking for broad access is a reason to stop.
  • Which permissions does it request? Reading all mail, reading all files, sending mail as the user and offline access deserve a clear business reason.
  • Is it delegated access, where the app acts as a signed-in user, or application access, where it acts with no user present? Application permissions are broader and need more scrutiny.
  • Does the business need it, and is there an approved alternative already in use?
  • Who owns the app internally, and who will remove it when the project ends?

Record the decision and the reason in your ticketing or governance record. When a request is denied, tell the user why and offer the approved option. That keeps people inside the process.

Step 4. Audit what is already granted

Policy only affects new requests. The grants you made years ago, or that users made before the policy, are still in force. Review the list of enterprise applications and their permissions on a schedule. Look for apps with no recent sign-ins, apps from unfamiliar publishers, apps with high-privilege application permissions and apps whose owners have left. Entra ID also offers access reviews, and Microsoft documents that they can include applications, which makes recurring review practical for larger tenants. Revoke what is unneeded. If you suspect a malicious app, disable it, revoke its grants and tokens, then look through the sign-in and audit logs to see which accounts consented and what the app accessed.

Step 5. Watch for new consent events

Send consent-related audit events to your monitoring tool and alert on a new grant of high-impact permissions, a consent by an executive or administrator, and a sudden wave of consents to the same unfamiliar app. A single alert of this kind has caught real incidents because the activity looks legitimate everywhere except in the consent log.

What this will not do

Consent governance does not replace strong sign-in controls, phishing-resistant authentication or user training. It also does not cover every integration, such as apps that use service accounts, API keys or secrets. Include those in your application inventory. Keep the settings and reviewer list documented, because auditors and cyber insurers increasingly ask how third-party app access is controlled.

A short checklist

User consent restricted or off, admin consent workflow enabled, reviewers named and trained, review questions written down, existing grants audited, stale apps removed, consent events monitored, and an owner assigned for every approved app. Our cybersecurity team can help you put this in place. Start with our Cybersecurity service.

Sources

This article is general information, not legal or compliance advice. Rules and product behavior differ by sector, contract and version; confirm details with your counsel, auditor and vendor documentation. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity