Microsoft 365 tenant security audit (2026), block legacy auth, lock down OAuth consent, and kill risky mailbox rules

A tenant can look calm and still be wide open. Attackers rarely need malware when they can sign in, grant an app access, then siphon email in the background. That is why a Microsoft 365 security audit in 2026 should start with three controls that break common takeover paths.

This guide focuses on what to change, where to click, what to query, and what evidence to save. It also assumes you want a safe rollout that will not break older clients overnight.

Before you change anything: scope, licensing, and audit evidence

First, define the audit window (for example, the last 30 to 90 days). Next, confirm you can see the logs you need. Microsoft’s 2026 security push includes stronger identity protections, such as Authenticator removing Entra credentials from rooted or jailbroken devices starting February 2026. Those improvements help, but they do not replace tenant hardening.

Use this quick licensing map as a planning aid (confirm in your tenant because SKUs vary):

If you are not ready for Conditional Access, review Microsoft Entra security defaults and decide whether you can enable them without conflicting controls.

For evidence, create an “Audit Artifacts” folder per tenant and save exports as you go. Aim for screenshots of policy blades, plus CSV exports of affected users, apps, and mailboxes.

Block legacy authentication (stop the password-spray side door)

What attackers do

Password spray is still the workhorse. If legacy auth is allowed, attackers can avoid modern controls and keep trying basic credentials over older protocols (IMAP, POP, SMTP AUTH, older Office clients). One weak password can be enough.

If legacy auth is still enabled for broad user sets, assume a spray will eventually hit a valid pair.

Where to configure it (Entra admin center)

Follow Microsoft’s baseline for this control and use Conditional Access to block legacy protocols. Microsoft’s reference policy is here: Block legacy authentication with Conditional Access.

1. Go to Microsoft Entra admin center, Identity, Protection, Conditional Access.
2. Create a new policy (or use templates if available).
3. Assign users, start with a pilot group (exclude break-glass accounts).
4. Target “Client apps” and select legacy authentication clients (other clients).
5. Set Grant to “Block access”.
6. Set the policy to “Report-only” first, then move to “On”.

Recommended baseline in 2026:

• No tenant-wide exceptions outside break-glass, service accounts you are actively migrating, and documented vendor dependencies.
• Add a companion policy that requires phishing-resistant MFA for admins where possible, but keep that separate from the legacy block for easier troubleshooting.

Detection: what “bad” looks like

In Entra sign-in logs, “bad” often appears as repeated failures with legacy client types, then a success without an MFA claim.

PowerShell (Microsoft Graph) examples:

• Pull recent sign-ins and filter legacy client usage: Get-MgAuditLogSignIn -All | Where-Object { $_.ClientAppUsed -match "IMAP|POP|SMTP|MAPI" }
• Look for high failure counts by IP or user: Get-MgAuditLogSignIn -All | Group-Object UserPrincipalName | Sort-Object Count -Descending | Select-Object -First 20

Remediation rollout (pilot, exceptions, monitoring, rollback)

Start with a pilot group that includes IT and a few “old Outlook” users. Watch report-only results for at least a week. Then:

• Move policy to “On” for the pilot.
• Add exceptions only with an owner, a ticket, and an end date.
• Expand in rings (10 percent, 50 percent, then all).

Rollback should be rare. If you must, disable only the blocking policy, keep your other sign-in controls active.

Evidence to capture:

• Screenshot of the Conditional Access policy assignments and client app settings.
• Export of sign-in logs showing legacy usage before and after enforcement.

Lock down OAuth consent (stop consent phishing and silent access)

What attackers do

OAuth consent phishing flips the script. The user signs in “normally,” then grants a malicious app permissions to read mail, files, and contacts. After consent, the attacker can access data without stealing the password again.

For the authoritative settings and policy options, use Manage app consent policies.

Where to configure it (Entra admin center)

1. Go to Microsoft Entra admin center, Identity, Applications, Enterprise applications.
2. Open Consent and permissions (wording can vary by tenant).
3. Set user consent to not allow users to consent to high-impact permissions.
4. Enable an admin consent workflow so users can request approvals.
5. Require vetted publishers where possible (verified publisher checks reduce lookalike risk).

Recommended baseline in 2026:

• Least privilege for app permissions. Approve the smallest permission set that meets the business need.
• Require admin approval for anything that can read mail, read all files, or act as the user.
• Limit who can approve consent (separate role assignment, no standing global admin).

Detection: what “bad” looks like

Bad signals include new service principals for unfamiliar apps, grants to “Mail.Read,” “Files.Read.All,” or broad offline access, and consent events outside business hours.

PowerShell (Microsoft Graph) examples:

• Review OAuth2 permission grants: Get-MgOauth2PermissionGrant -All | Select-Object ClientId,ResourceId,Scope,ConsentType,PrincipalId
• List recently created service principals (spot unexpected apps): Get-MgServicePrincipal -All | Sort-Object CreatedDateTime -Descending | Select-Object -First 30 DisplayName,AppId,CreatedDateTime

In addition, review Entra audit logs for “Consent to application” events and correlate to the user and source IP.

Remediation rollout

Pilot with a small business unit first. When you turn on admin consent workflow, users will feel the friction. That is the point, but you still need a fast approval SLA.

If you discover a risky app:

• Remove the service principal.
• Revoke the user’s refresh tokens and sessions.
• Review mailbox rules next, because consent attacks often pair with email persistence.

Evidence to capture:

• Screenshot of consent settings and admin workflow configuration.
• Export of OAuth2 permission grants before and after tightening.

Kill risky mailbox rules and external forwarding (stop quiet exfiltration)

What attackers do

After a mailbox compromise, attackers often create inbox rules that forward, redirect, or delete messages. It is stealthy, and it can survive a password reset if you do not remove the rule.

A good primer on “hidden rule” tradecraft is Hidden inbox rule detection, which helps explain why rules are a favorite persistence method.

A password reset ends a session, but it does not clean up malicious inbox rules for you.

Where to configure it (Defender portal and Exchange admin center)

Block the easy path first, then hunt.

1. Microsoft Defender portal: Email and collaboration, Policies and rules, Threat policies, Anti-spam (outbound).
2. Set automatic external forwarding to Off (or the strictest option your org can support).
3. Exchange admin center: review mail flow settings that allow external forwarding (remote domains and transport rules), and tighten defaults.

Recommended baseline:

• External auto-forwarding blocked for all users, with short, documented exceptions.
• Mailbox auditing enabled (verify it stays on for user mailboxes).
• Alerts for new inbox rules that forward externally, delete, or “stop processing more rules.”

Detection: what “bad” looks like

Exchange Online PowerShell examples:

• Find mailbox-level forwarding: Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -ne $null -or $_.ForwardingAddress -ne $null -or $_.DeliverToMailboxAndForward -eq $true } | Select-Object UserPrincipalName,ForwardingSmtpAddress,DeliverToMailboxAndForward
• Find inbox rules that forward or redirect: Get-Mailbox -ResultSize Unlimited | ForEach-Object { Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo } | Select-Object MailboxOwnerId,Name,ForwardTo,RedirectTo,ForwardAsAttachmentTo,Enabled }

Bad looks like external recipients you do not recognize, rules created right after a risky sign-in, or rules that delete or move security notifications.

Remediation rollout

Start by exporting findings, then remediate in this order:

1. Remove malicious inbox rules and disable forwarding.
2. Revoke sessions and reset credentials for impacted users.
3. Add the user to higher sign-in protection and investigate related app consent grants.

Roll out outbound forwarding blocks in rings if the business uses forwarding for workflows. Monitor helpdesk volume and add exceptions only with manager approval.

Evidence to capture:

• Export of forwarding settings (mailbox and inbox rules) before and after cleanup.
• Screenshot of outbound anti-spam policy showing forwarding disabled.

Final verification checklist for a 2026 tenant review

• Legacy auth blocked with Conditional Access (policy in report-only first, then enforced).
• Break-glass accounts excluded and tested, with strong MFA and monitoring.
• User OAuth consent restricted, admin consent workflow enabled, approvals limited to a small group.
• OAuth grants reviewed and risky apps removed, sessions revoked where needed.
• External forwarding blocked at the policy level, exceptions documented with end dates.
• Inbox rules audited for forward, redirect, delete, and stop-processing patterns.
• Artifacts saved (screenshots plus exports) for policies, logs, and remediation outputs.

A Microsoft 365 security audit gets real when it changes attacker economics. Close the side doors, control app permissions, then strip out mailbox persistence. After that, the rest of the hardening work gets a lot easier.