Most Microsoft 365 tenant compromises do not need a zero-day: they walk through settings that were left at a permissive default, switched off during a migration, or never reviewed after an administrator left. This list ranks the ten misconfigurations that most often turn a phished password or a forgotten account into a tenant-wide incident, with what to check, how to detect abuse and how to fix each one. Each item is tied to the matching policy in CISA's Secure Cloud Business Applications (SCuBA) Microsoft 365 secure configuration baselines, which are mandatory for US federal civilian agencies and a useful reference for everyone else, and to Microsoft's own Entra documentation. It is written for Microsoft 365 administrators, identity teams and security leads. For the full control set, read the Microsoft 365 Security Guide; this page is the short list of what goes wrong most often.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
The Top 10 at a glance
| # | Misconfiguration | What it enables | CISA SCuBA policy |
|---|---|---|---|
| 1 | MFA gaps and weak MFA methods | Password spray and phished passwords become sign-ins | MS.AAD.3.1v1, MS.AAD.3.2v2, MS.AAD.3.5v2 |
| 2 | Legacy authentication and SMTP AUTH left on | Sign-ins that bypass MFA and Conditional Access | MS.AAD.1.1v1, MS.EXO.5.1v1 |
| 3 | Too many standing Global Administrators | One stolen account owns the tenant | MS.AAD.7.1v1 to MS.AAD.7.8v1 |
| 4 | Users can consent to any app | Consent phishing and persistent token access | MS.AAD.5.1v1 to MS.AAD.5.3v1 |
| 5 | Unmanaged app registrations and secrets | Long-lived credentials with Graph permissions | MS.AAD.5.5v1 to MS.AAD.5.7v1 |
| 6 | External auto-forwarding allowed | Silent mail exfiltration after account takeover | MS.EXO.1.1v2 |
| 7 | Open SharePoint and OneDrive sharing | Data shared with "Anyone" links that never expire | MS.SHAREPOINT.1.1v1 to MS.SHAREPOINT.3.1v1 |
| 8 | Ungoverned guests and Teams external access | Impersonation and data access from outside | MS.AAD.8.1v1 to MS.AAD.8.3v1, MS.TEAMS.2.1v2 to MS.TEAMS.2.2v2 |
| 9 | Logging not retained or not monitored | No evidence and no detection | MS.AAD.4.1v1, MS.EXO.13.1v1 |
| 10 | No tested break-glass accounts, or badly built ones | Lockout during an incident, or a backdoor admin | MS.AAD.7.1v1 (with Microsoft emergency access guidance) |
The ranking is our judgement of how directly each setting leads to tenant compromise or data loss when left wrong. Your order may differ: treat items 1 to 4 as the first fortnight's work whatever your size.
1. MFA gaps and weak MFA methods
The misconfiguration: MFA enforced for some users but not all, with exclusions for "service" accounts, executives or a migration group that were never removed; or MFA in place but relying on SMS, voice and push approvals that can be phished or fatigued (MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation).
Why it matters: password spraying (T1110.003) and adversary-in-the-middle phishing remain the most common way in. An account without MFA, or with a phishable method, turns either into a valid cloud session (T1078.004 Cloud Accounts).
How to check: review every Conditional Access policy's exclusions and the Authentication methods registration report; list users with no registered method and users whose only methods are SMS or voice.
How to fix: SCuBA MS.AAD.3.2v2 requires MFA for all users and MS.AAD.3.1v1 phishing-resistant MFA for all users; MS.AAD.3.6v1 requires phishing-resistant MFA for highly privileged roles as a minimum. Disable SMS, voice call and email one-time passcode methods (MS.AAD.3.5v2), show sign-in context in Microsoft Authenticator (MS.AAD.3.3v2) and block device code flow where it is not needed (MS.AAD.3.9v1). Tenants without Entra ID P1 licences can use security defaults, which Microsoft describes as requiring all users to register for MFA, requiring MFA for administrators and blocking legacy authentication. See the Phishing-Resistant MFA Guide and the AiTM Phishing Guide.
2. Legacy authentication and SMTP AUTH left on
The misconfiguration: legacy protocols that cannot perform modern authentication are still allowed, typically kept for an old multifunction printer, a line-of-business app or a scripted mailbox; SMTP AUTH is enabled tenant-wide rather than for the one mailbox that needs it.
Why it matters: a protocol that cannot do MFA cannot be protected by MFA. Spray attacks target these endpoints precisely because a correct password is enough.
How to check: filter Entra sign-in logs by client app for legacy clients over the last 30 days; review the tenant and per-mailbox SMTP AUTH settings in Exchange Online.
How to fix: block legacy authentication with Conditional Access (MS.AAD.1.1v1) and disable SMTP AUTH (MS.EXO.5.1v1), then re-enable it only per mailbox where a documented device still needs it while you replace it. Run the blocking policy in report-only mode for two weeks first to find the remaining users. See the Legacy Authentication and ROPC Retirement Guide and Exchange Online SMTP AUTH Basic Auth Retirement.
3. Too many standing Global Administrators
The misconfiguration: a dozen or more permanent Global Administrators, many of them daily-use accounts, some synchronised from on-premises Active Directory, with nobody alerted when the role is assigned.
Why it matters: every permanent Global Administrator is a full-tenant compromise waiting for one phish. Synchronised admin accounts let an on-premises compromise climb into the cloud. Adding a role to a controlled account is a standard persistence step (T1098.003 Additional Cloud Roles).
How to check: export role assignments for Global Administrator and other highly privileged roles, separating active from eligible, and flag synchronised and guest accounts.
How to fix: SCuBA sets a minimum of two and a maximum of eight Global Administrators (MS.AAD.7.1v1); finer-grained roles instead of Global Administrator (MS.AAD.7.2v1); cloud-only admin accounts separate from on-premises or federated identities (MS.AAD.7.3v1); no permanent active assignments for highly privileged roles (MS.AAD.7.4v1); approval to activate Global Administrator (MS.AAD.7.6v1); and alerts on assignment and activation (MS.AAD.7.7v1, MS.AAD.7.8v1). Privileged Identity Management provides the eligible, time-bound model. See the Privileged Identity Management (PIM) Guide and Microsoft 365 admin centres and admin roles.
4. Users can consent to any app
The misconfiguration: the tenant still lets users grant third-party applications access to their mail, files and profile without review, and there is no admin consent workflow, so users either consent or raise tickets that stall.
Why it matters: consent phishing skips the password entirely. The attacker's app receives OAuth tokens (T1528 Steal Application Access Token) that survive password resets and MFA changes until the grant is revoked.
How to check: review the user consent setting under Enterprise applications, and list delegated and application permission grants to apps from unverified publishers, especially Mail.Read, Mail.ReadWrite, Files.Read.All and offline_access.
How to fix: restrict user consent (MS.AAD.5.2v1) and configure an admin consent workflow (MS.AAD.5.3v1). Microsoft's guidance is to allow user consent, if at all, only for apps from verified publishers and only for permissions you classify as low impact. Allow only administrators to register applications (MS.AAD.5.1v1). Low-impact permission classification matters as much as the publisher check. See the Consent Phishing and Illicit OAuth Grants Guide.
5. Unmanaged app registrations and secrets
The misconfiguration: app registrations and service principals created for integrations and tests years ago, holding client secrets with multi-year expiry and high Microsoft Graph or Exchange application permissions, with no owner.
Why it matters: these are non-human identities with tenant-wide data access and no MFA. Adding a new secret to an existing app is a well-known persistence technique (T1098.001 Additional Cloud Credentials), and the resulting tokens are used to move laterally (T1550.001 Application Access Token).
How to check: inventory service principals with application permissions, their owners, credential type and expiry, and last sign-in from the service principal sign-in logs.
How to fix: SCuBA recommends blocking application password (client secret) addition (MS.AAD.5.5v1), restricting secret lifetime to 180 days or less (MS.AAD.5.6v1) and certificate lifetime to 365 days or less (MS.AAD.5.7v1). Prefer certificates or federated credentials, scope Exchange application access with RBAC for Applications, assign an owner to every app, and remove unused ones. See How to find and remove stale service principals in Entra ID, the Azure Entra Client Secrets Security Guide and the Microsoft 365 Application Access Policies and RBAC for Applications Guide.
6. External auto-forwarding allowed
The misconfiguration: mailboxes can automatically forward mail to external addresses, through inbox rules or mailbox forwarding settings.
Why it matters: a forwarding rule (T1114.003 Email Forwarding Rule) is the classic first move after a mailbox takeover. It keeps copying invoices and conversations to the attacker after the password is reset, feeding business email compromise.
How to check: report mailboxes with ForwardingSmtpAddress set and inbox rules that forward, redirect or delete; review the outbound spam filter policy's automatic forwarding setting.
How to fix: disable automatic forwarding to external domains (MS.EXO.1.1v2), allowing named exceptions through a controlled policy only. Pair it with external sender warnings (MS.EXO.7.1v1) and SPF, DKIM and DMARC at p=reject (MS.EXO.2.2v3, MS.EXO.3.1v1, MS.EXO.4.2v1). See the Exchange Online Security Guide and the Business Email Compromise Response Playbook.
7. Open SharePoint and OneDrive sharing
The misconfiguration: organisation-level sharing set to "Anyone", the default link type "Anyone with the link" with edit rights, and no expiry on anonymous links.
Why it matters: anonymous links are forwarded, indexed and forgotten; they work for whoever holds them, with no sign-in (T1530 Data from Cloud Storage). Over-shared content also becomes visible to AI assistants that search on a user's behalf.
How to check: review the SharePoint admin centre sharing settings at organisation and site level, and run sharing reports for "Anyone" links.
How to fix: SCuBA limits external sharing for SharePoint and OneDrive to "Existing guests" or "Only people in your organization" (MS.SHAREPOINT.1.1v1, MS.SHAREPOINT.1.2v1), sets the default sharing scope to "Specific people" (MS.SHAREPOINT.2.1v1) with view-only default permissions (MS.SHAREPOINT.2.2v1), and where "Anyone" links are allowed, sets expiry to 30 days or less (MS.SHAREPOINT.3.1v1). Relax per site, not tenant-wide, where a team genuinely needs external collaboration. See the SharePoint and OneDrive Security Guide.
8. Ungoverned guests and Teams external access
The misconfiguration: anyone can invite guests from any domain, guests can enumerate the directory, and Teams allows chats from any external or unmanaged account.
Why it matters: open Teams external access is used for help desk impersonation and malware delivery; stale guests keep access to sites and teams long after a project ends.
How to check: review External collaboration settings in Entra, guest counts and last sign-in, and the Teams external access and unmanaged accounts settings.
How to fix: restrict guest access to directory objects (MS.AAD.8.1v1), limit invitations to the Guest Inviter role (MS.AAD.8.2v1) and to authorised domains (MS.AAD.8.3v1). In Teams, enable external access per domain only (MS.TEAMS.2.1v2) and prevent unmanaged users from initiating contact (MS.TEAMS.2.2v2). Run access reviews on guests. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide and the Email Bombing and Help Desk Impersonation over Teams Guide.
9. Logging not retained or not monitored
The misconfiguration: sign-in and audit logs kept only at their default retention inside the portal, nobody reviewing them, and mailbox auditing assumed rather than verified.
Why it matters: without exported logs there is no detection of items 1 to 8 and no evidence when an incident is found weeks later.
How to check: confirm the Unified Audit Log is on, mailbox auditing is enabled (MS.EXO.13.1v1), and Entra sign-in, audit, service principal sign-in and risk logs are exported to your SIEM (MS.AAD.4.1v1) with retention that matches your investigation window.
How to fix: stream logs to the SIEM and alert on the events in the detection table below. Block high-risk users and sign-ins where Entra ID Protection is licensed (MS.AAD.2.1v1, MS.AAD.2.3v1). See the Microsoft 365 Unified Audit Log Guide for Detection and the Entra ID Sign-In and Audit Log Detection Guide.
10. No tested break-glass accounts, or badly built ones
The misconfiguration: either no emergency access account, so a Conditional Access mistake or MFA outage locks everyone out, or a "break-glass" account with a simple password, no MFA, no monitoring and sign-in from anywhere.
Why it matters: the first case turns a configuration error into an outage; the second is a permanent Global Administrator that bypasses every control on this list.
How to check: identify emergency accounts, their authentication methods, Conditional Access exclusions, the alert on their sign-in and the date of the last test.
How to fix: Microsoft recommends two or more cloud-only emergency access accounts on the *.onmicrosoft.com domain, not federated or synchronised, protected with phishing-resistant methods such as FIDO2 passkeys that differ from those of normal admin accounts, with credentials stored securely in separate locations, excluded only from Conditional Access policies that could block them, and monitored so any sign-in raises an alert. Test them on a schedule. See the Break-Glass Account Guide.
Detection: what to alert on
| Event | Log source | Misconfiguration it exposes |
|---|---|---|
| Successful sign-in with a legacy client app | Entra sign-in logs | 2 |
| Many failed sign-ins across many accounts from few IPs | Entra sign-in logs | 1, 2 (password spray) |
| Add member to role (Global Administrator or other privileged role) outside PIM | Entra audit logs | 3 |
| Consent to application; Add delegated or app role assignment grant | Entra audit logs | 4 |
| Add service principal credentials; Update application (certificates and secrets) | Entra audit logs | 5 |
| New-InboxRule or Set-InboxRule with forwarding; Set-Mailbox with ForwardingSmtpAddress | Unified Audit Log | 6 |
| AnonymousLinkCreated | Unified Audit Log | 7 |
| Sign-in by any emergency access account | Entra sign-in logs | 10 |
Measure progress with five numbers: percentage of users with phishing-resistant MFA registered; legacy authentication sign-ins per week (target zero); count of permanent Global Administrators (two to eight, ideally only break-glass); apps with application permissions and no owner; and "Anyone" links older than 30 days. CISA's ScubaGear tool assesses a tenant against these baselines and reports each policy as pass or fail, which makes a repeatable monthly score.
Common failure patterns
- Fixing production, forgetting the other tenants: legacy test tenants and test OAuth apps with elevated access can be a path into the corporate tenant. Items 1, 4 and 5 apply to every tenant you own, including trials and test tenants.
- Exclusions that become permanent: a Conditional Access exclusion group created for a migration still holds hundreds of users a year later. Review exclusions monthly and give each one an expiry.
- Blocking legacy authentication in report-only mode forever: the policy exists and the dashboard looks green, but it never moved to "On".
- Revoking access after consent phishing but leaving the grant: password resets do not remove OAuth grants or app credentials. Remove the grant and the service principal, and revoke refresh tokens.
- Treating device management as separate: a hijacked admin with Intune rights can push actions to every device; protect Intune administrator roles with the same PIM and phishing-resistant controls as Global Administrator, and use multi-administrator approval for destructive actions where available.
Mapping to CISA SCuBA, ATT&CK and NIST
| Item | MITRE ATT&CK technique | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| 1. MFA gaps | T1110.003, T1621, T1078.004 | IA-2, IA-2(1) | PR.AA-01 |
| 2. Legacy authentication | T1110.003 | CM-7, AC-17 | PR.PS-01 |
| 3. Standing admins | T1098.003 | AC-6(5), AC-2 | PR.AA-05 |
| 4. User consent | T1528, T1566.002 | AC-6, CM-7 | PR.AA-05 |
| 5. App registrations | T1098.001, T1550.001 | IA-5, AC-2 | PR.AA-01 |
| 6. Auto-forwarding | T1114.003 | AC-21 | PR.DS-01 |
| 7. Open sharing | T1530 | AC-21, AC-3 | PR.DS-01 |
| 8. Guests and external access | T1078.004 | AC-20, AC-2 | PR.AA-05 |
| 9. Logging | All of the above | AU-2, AU-6, AU-12 | PR.PS-04, DE.CM-03 |
| 10. Break-glass | T1078.004 | AC-2, CM-6 | PR.AA-05 |
Where to start
- Week one: run ScubaGear or an equivalent configuration assessment in read-only mode against every tenant you own, including test and trial tenants, and record the baseline.
- Week one: create and test two emergency access accounts (item 10) before changing any Conditional Access policy.
- Weeks one to two: put MFA for all users and the legacy authentication block into report-only, review impact, then switch them on (items 1 and 2).
- Weeks two to four: cut Global Administrators to the two to eight range, move the rest to eligible PIM assignments, and restrict user consent with an admin consent workflow (items 3 and 4).
- Month two: inventory app registrations and secrets, disable external auto-forwarding, tighten sharing defaults and guest settings (items 5 to 8).
- Ongoing: export logs, alert on the detection table, and rerun the assessment monthly. Roll back any change by switching the policy to report-only, not by deleting it.
Practitioner checklist
- Every user covered by MFA with no undocumented exclusions; privileged roles on phishing-resistant methods.
- Legacy authentication blocked and SMTP AUTH off except named mailboxes.
- Two to eight Global Administrators, cloud-only, eligible through PIM with approval and alerts.
- User consent restricted, admin consent workflow live, permissions classified.
- Every app registration has an owner; secrets 180 days or less, or replaced by certificates or federated credentials.
- External auto-forwarding disabled; SPF, DKIM and DMARC at p=reject.
- SharePoint and OneDrive default links "Specific people", view-only; "Anyone" links expire within 30 days or are disabled.
- Guest invitations restricted; Teams external access per domain; guest access reviews scheduled.
- Entra and Unified Audit Log data streaming to the SIEM with alerts for the detection table.
- Emergency access accounts tested in the last quarter, with sign-in alerts confirmed.
Standards and references
- CISA: Secure Cloud Business Applications (SCuBA) Project
- CISA: ScubaGear and Microsoft 365 secure configuration baselines
- Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
- Microsoft Learn: Configure how users consent to applications
- Microsoft Learn: Security defaults in Microsoft Entra ID
- MITRE ATT&CK: Email Forwarding Rule
- MITRE ATT&CK: Steal Application Access Token
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Microsoft 365 Security Guide · Microsoft 365 Security Checklist · Entra ID Security Guide · Conditional Access Guide · Microsoft 365 Tenant Compromise Playbook