Executive Summary

• What it is: Application consent is the permission an employee grants when they click “Accept” to let a third-party app access Microsoft 365 data — email, files, calendar, or in some cases, company-wide directory data.
• The risk: Left unrestricted, this becomes a way for attackers to gain lasting access to company data without ever needing a password or triggering MFA.
• Why it matters now: A growing number of attacks skip ransomware entirely — attackers use authorized app access to quietly pull large volumes of data, then issue a straight extortion demand to leak or sell it.
• The fix: Requiring admin approval before new apps get access. For GreenLoop clients, this means every consent request comes to GreenLoop first — we screen it, then get sign-off from your organization’s designated Security Authorizers, expediting the review whenever business needs require it — so this stays a fast, manageable step rather than a bottleneck.
• Who this applies to: Every organization, regardless of size. Smaller organizations are frequently targeted precisely because this control is left off by default.

What “App Consent” Actually Means

Whenever someone signs into a third-party app or website using their Microsoft 365 account — think scheduling tools, e-signature platforms, meeting-summary bots, CRM integrations — that app asks for permission to access specific data on the user’s behalf: email, calendar, files, contacts, or in some cases, directory-wide information covering every user in the company.

That permission request is called consent. Depending on how a tenant is configured, one of two things happens:

• User consent: the employee sees a prompt, clicks “Accept,” and the app is authorized — no IT involvement at all.
• Admin consent: the request is routed to an administrator, who reviews exactly what the app is asking for before it’s authorized, either for that one user or the entire organization.

By default, Microsoft 365 tenants allow a wide range of user consent. For many apps, granting consent essentially only allows users to sign in with their company email address, but for many others, granting consent potentially adds extensive access to tenant data that employees have access to. Allowing user consent therefore risks employees being able to grant access to company data without any review from company decision-makers or IT.

Why Unrestricted User Consent Is a Risk for Your Business

The modern cybersecurity threat landscape adds an additional layer. Threat actors have built entire campaigns — commonly called consent phishing or illicit consent grants — around this exact gap. Instead of stealing a password, an attacker registers a malicious (or convincingly disguised) application and sends employees a link to “sign in” with their Microsoft 365 account. If user consent is allowed, the employee’s own credentials become irrelevant: they’ve just authorized the attacker’s app to read mail, access files, or worse, on an ongoing basis.

A few things make this particularly dangerous compared to a typical phishing attack:

• It doesn’t require a stolen password or a bypassed MFA prompt. The user is authenticating as themselves and simply granting a permission. Standard defenses like MFA don’t stop this.
• Access can persist quietly. Once granted, app consent grants continue working in the background without prompting for access. Rotating user credentials for compromised users have no effect on applications that were consented and they must reviewed and revoked separately.
• Some permissions are organization-wide. Certain requests aren’t scoped to just the one employee’s mailbox — they can request read access across every mailbox or every file library in the tenant, depending on what’s approved and by whom.
• Employees can’t reasonably evaluate these requests themselves. Consent screens list technical permission names and publisher details that most non-technical staff have no practical way to vet in the moment.

The Cybersecurity Landscape: Bulk Data Theft and Extortion Campaigns

The reason this control has become non-negotiable rather than “nice to have” is a shift in what attackers actually do once they get in. A growing share of recent campaigns skip ransomware and encryption entirely. Once an attacker has an authorized app in place, they don’t need to plant malware or lock anything down — they simply use that legitimate, API-level access to quietly pull large volumes of data out of the organization: entire mailboxes, file libraries, or CRM and customer records. The extortion demand comes afterward: pay up, or the stolen data gets leaked or sold.

This “steal now, extort later” pattern is particularly effective because it hides in plain sight:

• It looks like normal application traffic. Bulk data queries through an authorized app’s API access don’t trigger the same alarms as a malware infection or a suspicious sign-in.
• It scales fast. A single authorized app with broad read permissions can pull years of email history or an entire customer database in hours.
• There’s no ransom note until it’s too late. Unlike ransomware, which announces itself immediately, this approach can go undetected for weeks while data is being extracted, meaning the damage is already done by the time anyone finds out. It’s not unusual for companies to not be aware anything is wrong until the threat actor who has compromised them reaches out with an extortion demand.

This is exactly why application consent deserves the same level of attention as endpoint security and email filtering — it’s increasingly one of the primary paths attackers use to get bulk access to sensitive data before an extortion attempt, not just an occasional edge case.

Why This Applies to Every Organization

It’s tempting to assume this is an “enterprise problem” because of the scale of data involved. In practice, the opposite is often true. Organizations are frequently targeted precisely because consent is left wide open by default and no one is reviewing what’s been authorized. There’s no dedicated security team scanning for unusual app grants, and a single employee clicking “Accept” can be enough to expose company-wide data. The size of the organization doesn’t reduce the blast radius of a single bad consent grant; it just reduces the odds anyone catches it.

What GreenLoop Recommends and Configures

As part of GreenLoop’s standard 365 best-practices, we configure client tenants so that application consent follows the principle of least privilege by default — and, critically, so that “admin approval” means a real human review by one of our trained technicians:

1. Restrict user consent to low-risk permissions from verified publishers. Rather than allowing consent for any app, users can only self-approve apps from Microsoft-verified publishers requesting a pre-approved set of low-impact permissions (e.g., reading the signed-in user’s own basic profile). Anything beyond that requires review.
2. Enable the Admin Consent Workflow, with GreenLoop handling the review. Blocking user consent outright can create friction when employees need a legitimate business app approved quickly. Instead, we turn on Entra ID’s admin consent workflow so a blocked user can submit a justification and request review. That request routes to GreenLoop first: we screen exactly what the app is asking for and why, then bring it to your organization’s designated Security Authorizers for final approval before anything is granted. When a request is time-sensitive, we expedite the review so it doesn’t hold up your team’s work.
3. Review requests based on real risk. Every admin consent request is evaluated for what the app is actually asking to do — distinguishing between permissions that act only on behalf of the signed-in user versus permissions that grant standing, organization-wide access — before it’s brought to your Security Authorizers for a decision.
4. Limit approved apps to the users who need them. Rather than defaulting every approved app to “available to everyone in the company,” we scope access to the relevant group of users where practical, so a single approval doesn’t become blanket access for staff who will never use the tool.
5. Periodically audit existing consent grants. Tenants accumulate app permissions over time, including from apps that are no longer in active use. We periodically review what’s already been granted and remove access that’s no longer needed or was never fully justified.

What This Looks Like for Your Team

In practice, most employees won’t notice a change for the tools they already use. The difference shows up when someone tries a new app: instead of an unrestricted “Accept” button, they see a message that admin approval is required, along with an option to submit a request.

From there, here’s what happens behind the scenes: GreenLoop receives the request and screens it — reviewing exactly what the app is asking to access and why — before presenting it to your organization’s designated Security Authorizers for a final decision. This gives your organization real oversight of what’s being approved, without requiring your team to personally evaluate technical permission scopes for every new app. If a request is urgent, we expedite the review so approved tools aren’t held up waiting on a routine review cycle. It’s a small amount of friction in exchange for closing a gap that doesn’t show up in typical password- or MFA-focused security conversations.

FAQ

Does this slow down employees from adopting new tools?
There’s a brief review step for apps that haven’t already been vetted, but GreenLoop screens requests promptly and can expedite anything time-sensitive before it goes to your Security Authorizers for final sign-off. As with most security-oriented controls, it’s a deliberate trade-off: a short, human-reviewed step versus an unreviewed, potentially organization-wide data grant.

We’ve been running fine without this — why change now?
Most Entra tenants have accumulated app consent grants over time without anyone reviewing them. Attackers have also shifted tactics — increasingly favoring quiet bulk data theft through authorized apps over traditional ransomware — which makes this gap far more consequential than it used to be.

Who are the “Security Authorizers,” and why does GreenLoop need them?
Security Authorizers are the people at your organization designated to make the final call on changes that carry security impact, including admin consent requests. GreenLoop screens every request first and provides our assessment, but the approval decision rests with your organization’s own designated authorizers — keeping you in control of what gets access to your data. Contact your Account Manager to determine who your Security Authorizers are, or make any changes.

Does this replace MFA or other security controls?
No. Admin-approved consent addresses a different attack path than password theft or MFA fatigue. It works alongside your existing MFA and conditional access policies, not in place of them.

What happens to apps we’re already using?
Existing approved apps aren’t affected. This control governs new consent requests going forward, and we separately review what’s already been granted as part of ongoing tenant audits.

References

• Application consent management and evaluation of consent requests — Microsoft Learn
• Configure the admin consent workflow — Microsoft Learn
• Consent experience for applications in Microsoft Entra ID — Microsoft Learn
• Defending SaaS-based applications against OAuth abuse — Microsoft Security Blog
• Understanding OAuth application attacks and defenses — Red Canary