10 Microsoft 365 Mistakes That Leave Small Businesses Wide Open

Introduction

We've audited hundreds of Microsoft 365 tenants. These mistakes appear in almost every one. Not occasionally — almost every single time. The same ten misconfigurations, sitting quietly in the background, waiting to be exploited.

Here's the uncomfortable truth: the breaches that make the news aren't caused by sophisticated zero-day exploits. They're caused by basic configuration errors that have been present for months or years. As Metis Security put it: "Zero-day vulnerabilities attract headlines. Misconfigurations cause breaches."

This isn't a theoretical list. Every mistake below comes from real tenant audits, supported by community reports from r/sysadmin, r/msp, and r/Office365, and documented by security researchers at Abnormal AI, Proofpoint, and Guardz. For each mistake, I'll show you what's wrong, why it matters, how to check, and exactly how to fix it.

Let's get into it.

1. MFA Not Enabled — or Enabled Badly Critical

What the mistake is

Admin accounts without MFA. Users relying on Security Defaults with no Conditional Access. MFA "enabled" but using SMS or phone calls — both trivially bypassed by SIM swap or adversary-in-the-middle attacks. A single Global Administrator account with no backup admin and no break-glass account.

Why it's dangerous

Microsoft's own research shows MFA reduces account compromise risk by 99.22%. Without it, a single phishing email or credential leak gives an attacker full account access. In 2025, Guardz Research Unit documented over 9,000 suspicious login attempts in a 21-day campaign targeting tenants with legacy auth, with attacks originating from Eastern Europe and APAC.

And when your only Global Admin gets locked out? Good luck.

"I'm completely locked out of my Microsoft 365 tenant due to an MFA issue. I'm the only global admin on the tenant… I cannot Reset MFA, Add another admin, Access the admin centre."

— Microsoft Q&A, November 2025

How to check

• Entra Admin Center → Identity → Overview → Properties → "Security defaults" toggle
• Entra Admin Center → Protection → Conditional Access → Policies (look for MFA policies)
• Microsoft 365 Admin Center → Users → Active Users → MFA column

How to fix it

1. Create a break-glass account — a cloud-only emergency access account with a FIDO2 hardware key, excluded from Conditional Access. Store credentials in a physical safe.
2. Enable Conditional Access requiring MFA for all users: Entra Admin Center → Protection → Conditional Access → New policy → All users → All cloud apps → Grant: Require MFA. Use report-only mode first to test impact.
3. Force MFA registration for all users before switching the policy to enforcement.
4. Disable per-user MFA (the legacy method) once Conditional Access is active.

Note: As of February 3, 2025, Microsoft made MFA mandatory for all Microsoft 365 Admin Center access. This is enforced, not optional.

2. Legacy Authentication Not Blocked Critical

What the mistake is

Legacy authentication protocols — Basic Auth, SMTP Auth, IMAP, POP3, older ActiveSync — remain enabled. These protocols cannot support MFA and are the primary vector for password spray attacks.

Why it's dangerous

Legacy auth bypasses all MFA and Conditional Access policies. An attacker with a valid password can log in via IMAP or SMTP Auth regardless of your MFA settings. Guardz Research Unit documented a coordinated campaign (March–April 2025) using BAV2ROPC to bypass MFA across thousands of tenants targeting financial services, healthcare, and manufacturing.

"Just saw a perfect real-world example of why disabling legacy authentication in M365 is critical. A small tenant (15 users) hit its daily outbound email limit, and all email got blocked. Tracing the issue, we found a deleted user's mailbox was still sending thousands of emails via SMTP AUTH — classic ghost account behavior."

— Byron Bates on LinkedIn, January 2026

How to check

• Entra Admin Center → Sign-in logs → Filter by "Client app" = Legacy authentication clients
• Microsoft 365 Admin Center → Settings → Org settings → Modern authentication (toggle)

How to fix it

1. Audit legacy auth usage: Check sign-in logs for any active IMAP/POP3/SMTP Auth/Exchange ActiveSync connections.
2. Migrate dependencies: Printers and scanners using SMTP Auth → move to Microsoft 365 SMTP relay. LOB apps → update to OAuth/modern auth.
3. Block legacy auth via Conditional Access: New policy → All cloud apps → Conditions: Client apps → check "Exchange ActiveSync clients" and "Other clients" → Grant: Block access. Use report-only mode for 2 weeks first.

# Check legacy auth sign-ins via PowerShell (Graph SDK)
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "clientAppUsed ne 'Browser' and clientAppUsed ne 'Mobile Apps and Desktop clients'" -Top 100 | 
  Select-Object UserPrincipalName, ClientAppUsed, CreatedDateTime

3. No Conditional Access Policies (or Broken Ones) Critical

What the mistake is

Either no Conditional Access policies at all, or a single poorly configured mega-policy. Common broken setups: only requiring MFA from outside the office (the "trusted location" trap), one policy for all users that locks everyone out when it breaks, and guest users completely excluded from policies.

Why it's dangerous

Without Conditional Access, even with MFA enabled, attackers using AiTM (adversary-in-the-middle) phishing can steal session tokens post-MFA and log in from anywhere. CA can require device compliance, block unknown locations, and enforce session lifetime limits — none of which Security Defaults can do.

"One common issue with Conditional Access is the incomplete configuration of security policies. Many organizations use a single policy requiring all users to use MFA… the organization's public IP addresses are excluded because they are considered trusted. This means employees working exclusively in the office are NEVER prompted to set up or use MFA. Attackers who obtain login credentials can register the second factor without being noticed."

— SecureCloud Experts

How to check

• Entra Admin Center → Protection → Conditional Access → Policies
• Look for: number of active policies, any in report-only (blue label), policies applying to all users vs. specific groups, exclusions that shouldn't exist

How to fix it — minimum CA policy set for SMBs

1. Require MFA for all users — all apps, all platforms
2. Block legacy authentication — block all legacy auth client types
3. Require MFA for admin roles — use phishing-resistant methods (FIDO2) for Global Admin
4. Require compliant/hybrid device for sensitive apps — SharePoint, Teams with sensitive labels
5. Block risky sign-ins (requires Entra ID P2) — auto-block sign-ins with high risk score

Always maintain minimum 2 Global Admins and a properly configured break-glass account. Implement all policies in report-only mode first, review for 1–2 weeks, then switch to enforcement.

4. SPF/DKIM/DMARC Not Configured (or DMARC at p=none) High

What the mistake is

SPF record missing or incorrect (extremely common with GoDaddy auto-setup). DKIM not enabled in Exchange Online. DMARC record either missing or permanently set to p=none — monitoring only, no enforcement. Third-party senders (Mailchimp, HubSpot, SendGrid) not included in SPF. SPF record exceeding the 10-lookup limit.

Why it's dangerous

Without DMARC enforcement, anyone can spoof your domain. Clients receive phishing and invoice fraud emails that appear to come from your domain — complete with employee photos in Outlook.

"We use 365 and have an SPF record published with a hard fail as well as using DKIM signing… We're still seeing mail coming in that's spoofed so that Outlook even shows the f***ing photo of the employee they're spoofing. We have a DMARC policy published with p=none at the moment."

— u/ on r/sysadmin

The community response was blunt: "A policy of p=none is not much of a policy. You only get reporting, but you're not advising any other mailservers to drop emails that fail the DKIM or SPF tests."

How to fix it

1. Enable DKIM: Security.microsoft.com → Email & Collaboration → Policies & Rules → Threat Policies → Email Authentication Settings → DKIM. Create CNAME records (selector1, selector2) in your DNS registrar.
2. Fix your SPF record: Should include v=spf1 include:spf.protection.outlook.com -all. Add all other email senders. Test at learndmarc.com.
3. Implement DMARC progressively:

# Start with monitoring
v=DMARC1; p=none; rua=mailto:[email protected]

# After 2-4 weeks of clean reports, move to quarantine
v=DMARC1; p=quarantine; rua=mailto:[email protected]

# Goal: full rejection
v=DMARC1; p=reject; rua=mailto:[email protected]

5. Audit Logging Disabled or Not Monitored High

What the mistake is

Unified Audit Log not enabled (it was default-off in older tenants). Audit logging enabled but never monitored. No alerting on critical events — new admin added, forwarding rules created, mass file downloads. Standard retention of only 90–180 days, meaning incidents discovered late leave no forensic trail.

Why it's dangerous

When an incident occurs — account compromise, data exfiltration, insider threat — you cannot investigate without logs. Teams discover months-old breaches and find they have no way to understand what happened.

"I tried to check the Purview Admin Audit log to see any activity my account did during the period it was compromised, but auditing was turned off for the tenant. Since this is a new tenant I set up about four years ago, it seems auditing has been off since its creation."

— u/ on r/Office365, April 2025

As Metis Security noted in their audit findings: "Weak audit logging does not usually attract attention until something goes wrong. At that point, organisations discover that they cannot reliably answer basic questions about who accessed what, when, and how."

How to fix it

1. Verify audit logging is enabled: Microsoft Purview (compliance.microsoft.com) → Audit → Click "Start recording user and admin activity" if not active.
2. Or via PowerShell:

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

3. Set up alerts in Purview for: new inbox rules, mass file downloads, admin role changes, external sharing changes.
4. Upgrade retention if needed — standard is 90–180 days. E5 or Purview Suite gives 1 year.
5. Enable Customer Lockbox (E5 or add-on): Admin Center → Settings → Org settings → Security & Privacy → Customer Lockbox.

6. External Email Forwarding Not Blocked High

What the mistake is

Default M365 settings often allow users (or attackers who've compromised an account) to create inbox rules that forward all emails to an external address. Most organizations never check for these rules.

Why it's dangerous

Silent, persistent data exfiltration. After compromising an account, attackers set up forwarding rules and monitor incoming emails for weeks or months — intercepting payment confirmations, redirecting invoices, gathering intelligence. This is the backbone of Business Email Compromise (BEC) attacks.

"Often, these attackers will deploy Rogue Apps or maintain a harmful session for extended periods… When these attackers prepare to act, you might notice new inbox rules set up to target accounting roles, often searching for terms like 'invoice' or 'bill pay'."

— u/ on r/msp, April 2025

How to fix it

1. Disable external auto-forwarding: Microsoft Defender portal (security.microsoft.com) → Email & Collaboration → Policies & Rules → Threat Policies → Anti-spam → "Anti-spam outbound policy (Default)" → Edit → Automatic forwarding rules → Off.
2. Review existing forwarding rules: Exchange Admin Center → Mail flow → Rules. Also check: Recipients → Mailboxes → select user → Mail flow settings → Email forwarding.
3. Create an alert for new forwarding rules in Microsoft Purview.
4. Review OAuth app permissions: Entra Admin Center → Applications → Enterprise Applications → revoke unused or unrecognized apps.

7. SharePoint/OneDrive Oversharing High

What the mistake is

Files shared with "Everyone" or "Anyone with a link" when it's not needed. Broken permission inheritance. Former employees retaining access via shared links long after departure. No expiration on external sharing links.

Why it's dangerous

When Microsoft Copilot started rolling out across organizations, it surfaced a massive hidden problem: files shared with "Everyone" that nobody knew were accessible organization-wide. This wasn't a new vulnerability — the files had always been overshared. Copilot just made it visible.

"The oversharing problem is real as hell — we've seen companies where 40%+ of their SharePoint content was accessible to 'Everyone' without anyone aware until Copilot highlighted it."

— u/ on r/sysadmin

How to fix it

1. Restrict sharing defaults: SharePoint Admin Center → Policies → Sharing → set slider to "Existing guests" or "Only people in your organization." Set link expiration: 30–90 days max for "Anyone" links.
2. Audit current sharing: SharePoint Admin Center → Reports → Sharing. Use PnP PowerShell to generate sharing link reports by site.
3. Implement sensitivity labels: Microsoft Purview → Information Protection → Labels. Labels can prevent download/copy on unmanaged devices and restrict external sharing.
4. Set permissions hygiene: New SharePoint sites default to Private. Disable "Anyone" links for sensitive libraries. Block sharing with personal accounts.

8. No Third-Party Backup High

What the mistake is

Small businesses assume "it's in Microsoft 365, so it's backed up." They rely entirely on the Recycle Bin (30-day default), version history (limited), and retention policies that are often not configured.

Why it's dangerous

Microsoft's Shared Responsibility Model explicitly states that protecting and recovering data is the customer's responsibility. Microsoft ensures service availability — not comprehensive data backup.

Data loss scenarios M365 native tools don't handle well: ransomware encrypting OneDrive files (sync replicates the encryption), mass deletion by a compromised admin account, mailbox data beyond the retention window, Teams chat history, and departing employee data after license removal.

"If ransomware hits your Microsoft 365 environment — encrypting files in OneDrive or SharePoint — those changes are synced and replicated. You're left with encrypted data in the cloud, and Microsoft won't roll it back for you."

— PalmIQ

How to fix it

1. Deploy a third-party cloud-to-cloud backup: Veeam Backup for Microsoft 365, Acronis, Spanning, Datto SaaS Protection, or AvePoint.
2. Cover all workloads: Exchange Online (mailboxes, calendars, contacts), OneDrive, SharePoint (sites, libraries, AND permissions), Teams (chat history).
3. Test restores regularly: Quarterly: single email restore. Semi-annually: SharePoint library restore. Annually: full scenario test.
4. Protect backup admin access — separate credentials from M365 admin (so a compromised M365 admin can't delete backups).

9. No DLP Policies (or DLP Stuck in Monitor-Only) Medium-High

What the mistake is

No Data Loss Prevention policies at all. Or DLP deployed in "test/audit" mode and never moved to enforcement. Or DLP policies so broad they generate thousands of false-positive alerts that everyone ignores. No DLP for Teams chat (only email and SharePoint covered). No endpoint DLP for USB, printers, or browser uploads.

Why it's dangerous

Sensitive data — credit card numbers, tax IDs, patient data, contract terms — leaks via email, Teams, or file sharing without anyone noticing. No DLP means no visibility and no enforcement.

"DLP without operational ownership becomes a compliance artefact rather than a security control. Policies generate noise, true data leakage goes unnoticed and alerts are ignored."

— Metis Security

How to fix it

1. Start with built-in templates: Microsoft Purview → Data Loss Prevention → Policies → Create policy. Use templates for PCI DSS, HIPAA, EU GDPR, or Financial Data. Start in Test mode.
2. Build gradually: Week 1–2: test mode, review matches. Week 3: enable alerts (not blocking). Week 4+: enable user notifications. Month 2+: enable blocking for high-confidence matches.
3. Extend coverage: Include Teams chat/channel messages. Add SharePoint and OneDrive. If E5: enable Endpoint DLP for USB, printers, and browser uploads.

10. Too Many Global Admins High

What the mistake is

Multiple users assigned Global Administrator when they need far less. Helpdesk staff using Global Admin for daily work. Service accounts given Global Admin "because it's easier." No separation between daily-use accounts and admin accounts.

Why it's dangerous

Every Global Admin account is a crown-jewel target. If compromised, an attacker has total control: create new admins, delete users, exfiltrate all data, disable every security policy. Metis Security describes it well: "Privilege creep is rarely the result of a single poor decision. It accumulates incrementally as access is granted to solve immediate problems… Once privilege creep sets in, attackers need only compromise a single account to gain extensive access."

"Giving users Domain Admin or Global Admin rights on their daily use account."

"Just give it domain admin, it'll work. No service account needs domain admin, ever."

— u/ on r/sysadmin

How to check

# Check Global Admin count via PowerShell (Graph SDK)
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$gaRole = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
Get-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id | Select-Object AdditionalProperties

How to fix it

1. Audit admin roles: Entra Admin Center → Roles and administrators → Global Administrator. Should be 2–4 people maximum.
2. Apply least privilege: Use Exchange Administrator for email management, SharePoint Administrator for SharePoint, User Administrator for user management, Security Administrator for security settings.
3. Implement PIM (requires Entra ID P2): Make Global Admin "eligible" rather than "assigned" — requires approval + justification to activate. Set maximum activation time: 1–4 hours.
4. Separate admin accounts: Create dedicated admin accounts (e.g., admin-jsmith@) used only for admin tasks. Daily work happens on a regular user account.

Honorable Mentions

These didn't make the top ten, but we see them in most audits too:

AiTM Phishing Succeeding Due to Weak Session Controls

No sign-in frequency enforcement means admin sessions stay active indefinitely. No persistent browser session restrictions. No phishing-resistant MFA (FIDO2/passkeys) for high-value accounts. Modern attacks bypass MFA entirely by stealing session tokens after MFA completes. Proofpoint documented multiple threat clusters using OAuth device code phishing in 2025. Fix: Enforce sign-in frequency for admins (4 hours), disable persistent browser sessions, and move admins to FIDO2 security keys.

Teams Sprawl Without Governance

Any user can create Teams by default — no naming conventions, no expiration policies, no ownership requirements. Netwrix research found 58% of M365 users had not posted in Teams channels within a benchmark period, yet those teams persist with all their data and permissions. Fix: Restrict Team creation to approved users, enforce naming conventions, set 365-day expiration policies, and require 2 owners per Team.

Unmanaged Guest Users

Metis Security puts it clearly: "Guest accounts often fall outside normal user lifecycle processes, meaning they are rarely reviewed, rarely challenged, and rarely removed." Fix: Create a dynamic group for all guest users using (user.userType -eq "Guest"), set up quarterly access reviews, and configure guest access expiration.

License Management Chaos

Inactive users holding licenses (departed employees), shared mailboxes assigned full user licenses they don't need, and auto-renewing subscriptions for unused services. Each inactive licensed account is valid attack surface. Fix: Quarterly license audits, remove licenses from blocked sign-in accounts, and convert shared mailboxes properly.

Ignoring Microsoft Secure Score

Microsoft Secure Score is a free, always-on security assessment that shows exactly what's misconfigured and how to fix it — ranked by impact. Most SMB tenants sit at 20–40 out of 100 and have never opened the dashboard. A well-managed SMB should target 70+. Fix: security.microsoft.com → Secure Score → sort by impact, tackle the 10+ point items first.

The Quick-Win Checklist

Here's every mistake at a glance, with risk level and what you need to fix it:

#	Mistake	Risk	License Needed
1	No MFA / weak MFA	Critical	Any (Security Defaults free; CA needs Entra P1)
2	Legacy auth enabled	Critical	Business Premium / E3+ (Conditional Access)
3	No Conditional Access	Critical	Business Premium / E3+ (Entra ID P1)
4	SPF/DKIM/DMARC not configured	High	Any (free DNS configuration)
5	Audit logging disabled	High	Any (free; Premium audit needs E5)
6	Email forwarding unrestricted	High	Any (Exchange admin setting)
7	SharePoint oversharing	High	Any (SharePoint admin setting)
8	No backup solution	High	Third-party add-on (~$3–6/user/month)
9	No DLP policies	Medium-High	Business Premium / E3 (basic); E5 for advanced
10	Excessive admin privileges	High	E5 for PIM; otherwise free best-practice

Where to start: Items 1–3 are Critical and should be addressed this week. Items 4–8 are High and should be resolved within 30 days. Items 9–10 are your next sprint after that. If you do nothing else, enforce MFA, block legacy auth, and disable external forwarding — those three changes alone will eliminate the majority of the attack surface we see exploited in real incidents.