An unfamiliar Microsoft 365 application is not automatically malicious—but a confirmed unauthorized consent grant can keep exposing mail or files after the user changes a password.
Guidance checked: August 24, 2026, 1:03 p.m. EDT / 17:03 UTC
This guide is for the narrow but costly moment when a Microsoft 365 administrator finds a suspicious connected application and must answer three questions: What access was granted? Who granted it? How can we revoke the bad permission without breaking a legitimate business system?
It is not another general mailbox-compromise checklist. If an account is actively compromised, start with our complete Microsoft 365 account-containment guide, which covers disabling the user, session revocation, app passwords, authentication methods, forwarding, Inbox rules, logs, messages, files, payments, and endpoint cleanup. If you are doing routine housekeeping rather than responding to an incident, use our broader connected-app access audit.
This guide applies when
- A Microsoft 365 work or school user approved an unexpected “Allow this app” request.
- An administrator finds a questionable app in Microsoft Entra ID under Enterprise applications.
- A security alert or audit log points to a new consent grant.
- An app requests mail, files, contacts, directory, or offline access that does not match its business purpose.
- A password was changed after phishing, but nobody reviewed application permissions.
An unfamiliar display name by itself does not prove compromise. Accounting add-ins, backup products, scanners, CRM integrations, mobile clients, and security tools may use technical names employees never see. The correct response is an evidence-based permission review, not mass deletion.
Not directly covered
- Personal Outlook.com or consumer Microsoft accounts; their connected-app controls differ.
- Google or Apple connected-app cleanup, which the June 17 guide covers.
- On-premises Exchange Server without Microsoft 365 and Entra ID.
- Malware removal from the affected computer.
- A complete business-email-compromise investigation.
What an app-consent grant actually means
Microsoft describes permissions and consent as the process that lets an application access data or perform actions. In a business tenant, the important distinctions are:
- Delegated permission: the application acts on behalf of a signed-in user and is limited by both the granted permission and that user’s own access.
- Application permission: the application can act as itself without a signed-in user. These permissions generally require administrator consent and can have broad impact.
- User consent: an individual user grants the application allowed access for that user or group context.
- Admin consent: an administrator grants permissions for the organization or a broader population.
The word consent does not mean the application is trustworthy. It means someone authorized a requested access path. Conversely, an app with broad permissions is not automatically malicious; a legitimate backup or security system may need substantial access. The review must connect the app, publisher, permission, grantor, scope, time, and real business purpose.
Do not ask only “Do we recognize the name?” Ask “Does this exact permission, for this exact scope, belong to this exact business purpose?”
Before you revoke anything
1. Contain an active account compromise first
If phishing, suspicious sign-ins, unexpected sent mail, or payment fraud is still unfolding, application review is only one branch of the response. Microsoft’s compromised-account guidance treats account disablement, password reset, app-password replacement, active-session revocation, MFA-method review, application consent, role review, forwarding, hidden Inbox rules, and audit investigation as separate tasks.
Session revocation invalidates the affected user’s active sign-in sessions and refresh tokens associated with that user. It should not be described as removing an application permission or terminating every possible app-only access path. Consent must be inspected and revoked separately.
2. Preserve the evidence
Record the following before changing the grant:
- application display name, application ID, and service-principal object ID;
- publisher name and whether Microsoft marks the publisher verified;
- every delegated and application permission shown;
- whether the grant appears under User consent or Admin consent;
- the user, group, or organization scope;
- consent time, grantor, relevant audit event, and related sign-ins;
- known owner, vendor, contract, ticket, or integration documentation;
- business systems that might stop if the permission is removed.
Do not paste tenant IDs, user addresses, tokens, customer data, or screenshots containing sensitive mail into public tickets or chat.
3. Use a separate, independently protected administrator
Do not administer the suspect application from the same potentially compromised account. Use a verified administrator whose password, MFA methods, sessions, and device are independently trusted. If no trustworthy administrator exists, stop and use the tenant’s documented emergency-access or Microsoft support process.
Review the grant in Microsoft Entra
Microsoft’s current portal path is:
Microsoft Entra admin center → Entra ID → Enterprise apps → All applications → select the application → Permissions
Then review both views:
- Admin consent: permissions granted for the organization.
- User consent: permissions granted for a specific user or group.
Select each permission to open its details. Translate the technical name into its practical effect. A profile-read permission is not equivalent to permission to read mail, read and write files, maintain offline access, modify directory data, or act without a signed-in user.
Build a one-line purpose test
For each permission, complete this sentence:
“This application needs [permission] for [users/scope] because it performs [documented business function], owned by [person/vendor].”
If nobody can complete that sentence with evidence, the grant deserves escalation. It is still not proof of maliciousness, but it is not ready to remain silently trusted.
The safe decision tree
Case A: the app is legitimate and the permission matches its purpose
- Document the owner, purpose, permissions, renewal/review date, and support contact.
- Confirm the publisher and acquisition path through a source independent of the original consent message.
- Keep only the permissions the integration actually needs.
- Set a future access review if the tenant’s licensing and governance tools support it.
Do not remove a working application simply because its display name is technical or unfamiliar.
Case B: the app is legitimate but overprivileged
Do not blindly revoke a single permission and assume the application will gracefully reduce its scope. Ask the app owner or vendor whether a lower-privilege configuration is supported. Define:
- which users and workflows are affected;
- whether data collection stops immediately;
- whether re-consent will be required;
- what the rollback or replacement path is;
- how success will be tested after the change.
Then schedule the least-disruptive supported correction. Overprivilege is a security issue, but an uncontrolled production outage is not a good remediation plan.
Case C: user consent is confirmed unauthorized
Contain the affected user through the full incident workflow, preserve the evidence, and revoke the unauthorized delegated grant using Microsoft’s current Graph or PowerShell method. Microsoft notes a portal limitation: you cannot revoke permissions from the User consent tab in the portal. That operation requires Microsoft Graph API calls or PowerShell.
If you do not routinely administer Microsoft Graph permissions, do not paste a broad removal script from a forum. Microsoft’s official procedure requires privileged scopes such as application, directory, delegated-permission-grant, or app-role-assignment access. A mistake can affect more than one user or grant.
Case D: admin consent is confirmed unauthorized
The Entra Permissions view can revoke an admin-consented permission. Before selecting Revoke permission, verify the exact application, exact permission, tenant scope, and business dependencies. An organization-wide grant can affect many users.
During a confirmed active breach, containment may outweigh availability. Make that an explicit incident decision, record the person authorizing it, preserve the before-state, and define how legitimate access will be restored if the application was misclassified.
Case E: evidence is incomplete
Do not force a binary answer. Temporarily contain the affected user or integration where business risk requires it, preserve logs, contact the documented owner or vendor through a known channel, and escalate to a qualified Microsoft 365 administrator or incident responder. “Unknown” is a valid evidence state; it should trigger controlled investigation, not guesswork.
Why “delete the enterprise app” is usually the wrong first move
The enterprise application shown in your tenant represents a service principal. Deleting it is broader than removing one confirmed unauthorized grant and can erase the local configuration other users or systems depend on. It can also complicate the investigation by destroying useful context.
Microsoft’s permissions guidance separates delegated grants, application permissions, and user or group assignments. It also warns that these are not the only authorization systems. Microsoft Entra roles, Exchange role-based access control, and Teams resource-specific consent can grant access through other paths.
Narrowest safe change first: revoke the confirmed bad permission or assignment, validate the result, and delete the service principal only when the application itself is confirmed unwanted and the impact is understood.
How to verify the revocation worked
- Reopen the application’s Permissions page. Confirm the targeted grant is absent and unrelated grants remain unchanged.
- Re-read the affected user or group assignment. Verify the correct principal—not a similarly named user—was changed.
- Check audit logs. Preserve the revocation event, time, administrator, target application, and affected permission.
- Test the business workflow. A known legitimate user should confirm whether the application still performs its approved function—or correctly fails when the entire app was unauthorized.
- Monitor sign-ins and application activity. Look for continued suspicious access, new consent attempts, or use of another service principal.
- Continue the full account investigation. Review authentication methods, roles, forwarding, hidden Inbox rules, sent mail, files, and endpoints. Revoking consent is not a complete breach response.
Do not interpret an immediate sign-in failure as proof that every issued token, copied file, or attacker-controlled mailbox rule is gone. Verification must cover the exact control you changed and the wider incident paths separately.
Prevent the same grant from returning
Microsoft explicitly warns that revoking a current permission does not stop users from consenting again. Review:
- which users may consent to applications;
- which permission levels are eligible for user consent;
- whether only verified publishers or selected permissions are allowed;
- whether an admin-consent workflow is available for legitimate requests;
- whether risky consent events generate alerts or review tickets;
- who owns the enterprise-application inventory.
Small organizations that do not use Conditional Access can evaluate Microsoft Security Defaults as a baseline. Microsoft says Security Defaults requires MFA, blocks legacy authentication, and blocks device-code flow. Organizations with Entra ID P1 or P2 and more complex requirements should evaluate Conditional Access rather than treating Security Defaults as a universal fit.
Change-control warning: do not flip tenant-wide consent or authentication settings during an incident without checking scanners, line-of-business applications, service identities, mobile clients, and other dependencies.
Good review versus costly shortcuts
| Good | Risky |
|---|---|
| Match app, publisher, ID, permission, scope, grantor, time, owner, and business purpose. | Decide by display name or logo alone. |
| Use a separate trusted administrator and preserve the before-state. | Investigate from the compromised account. |
| Revoke the narrow confirmed bad grant. | Delete every unfamiliar enterprise application. |
| Distinguish User consent from Admin consent and use Microsoft’s documented method. | Assume the portal performs every revocation type. |
| Test the approved business workflow and inspect audit logs afterward. | Declare success because one consent row disappeared. |
| Review consent policy to prevent reapproval. | Revoke once while leaving the same approval path open. |
Two practical examples
Unfamiliar but legitimate
An employee flags an app with a technical name. The administrator finds that it was approved six months earlier by the company’s documented expense-platform owner, has a verified publisher, accesses only the expected user profile, and matches normal sign-in activity. The right result is to document the owner and review date—not delete it.
Confirmed illicit user consent
An employee approves a fake document-viewer application after a phishing message. The grant time matches the click, the publisher is unverified, the requested mail and offline-access permissions do not match a document preview, and nobody owns the integration. The administrator contains the user, records the app and grant, uses Microsoft’s documented user-consent revocation method, verifies the grant is gone, and continues the full mailbox and identity investigation. The password change and consent revocation are separate controls.
Frequently asked questions
Does changing the password revoke Microsoft 365 app consent?
No. Password reset, user-session revocation, app-password replacement, and application-consent revocation are separate tasks in Microsoft’s response guidance.
Can I revoke user consent from the Entra Permissions tab?
Microsoft’s current documentation says no. The portal can revoke an admin-consented permission, while user-consented permissions require Microsoft Graph or PowerShell.
Should I revoke every permission an app has?
Only when the app is confirmed unauthorized and that is the intended containment scope. For a legitimate but overprivileged app, determine the vendor-supported least-privilege configuration and business impact first.
Will revocation stop the user from approving the app again?
Not by itself. Microsoft says you must also address the application’s ability to request the permission or configure how users may consent.
Does revoking consent remove data the app already copied?
No guarantee. Revocation stops the authorization path you removed; it does not retrieve data already exported or erase information stored by a third party. Investigate exposure and notification duties separately.
When should a small business call for help?
Escalate when the app has organization-wide consent, application permissions, privileged roles, unclear ownership, payment or regulated-data exposure, hybrid identity, multiple affected users, or any removal that could stop a critical business system.
Your next action
If a suspicious app appears today, capture its ID, publisher, permissions, consent type, scope, grantor, time, and owner before making a change. Contain an active compromise, then revoke the narrow confirmed unauthorized grant and verify it through permissions, audit logs, and the affected workflow.
Need practical Microsoft 365 help in Port Saint Lucie, Jensen Beach, Fort Pierce, or Vero Beach? Schedule an appointment with The IT Guys.
Primary sources
- Microsoft Learn — Respond to a compromised cloud email account (updated July 17, 2026; checked August 24, 2026)
- Microsoft Learn — Review permissions granted to enterprise applications (updated March 6, 2025; checked August 24, 2026)
- Microsoft Learn — Overview of permissions and consent in the Microsoft identity platform (checked August 24, 2026)
- Microsoft Learn — Security Defaults in Microsoft Entra ID (checked August 24, 2026)