Top 5 M365 Misconfigurations
I've Seen in Enterprise Environments

Legacy authentication refers to older protocols — POP3, IMAP, SMTP Auth, Exchange ActiveSync, and Basic Auth — that were designed before modern identity standards existed. These protocols authenticate with a username and password alone, with no support for MFA, Conditional Access, or token-based security.

As of May 1, 2026, Microsoft permanently retired IDCRL (the legacy SharePoint sign-in method) — making this a right-now issue for any tenant still running scripts, Power BI refreshes, or Power Automate flows with stored credentials.

Legacy auth is a backdoor past MFA. An attacker with a stolen password can authenticate via IMAP or SMTP and completely bypass every Conditional Access policy you've built. This is the most exploited initial access vector in M365 environments — password spray attacks specifically target these endpoints because they're invisible to modern detection.

# In Entra ID → Monitoring → Sign-in logs
# Filter: Client app = "Exchange ActiveSync", "IMAP", "POP3", "SMTP"
# Or use KQL in Log Analytics:

SigninLogs
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP4", "POP3", "SMTP", "Other clients")
| where ResultType == "0"  // successful sign-ins only
| summarize count() by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by count_ desc

Run this for at least two weeks before enforcing a block to avoid breaking legitimate workflows.

# Entra ID → Security → Conditional Access → New Policy

Policy Name: "Block Legacy Authentication"

Users:    All users
Exclude:  Break-glass accounts, Service accounts still needing it

Target Resources: All resources

Conditions → Client apps:
  ☑ Exchange ActiveSync clients
  ☑ Other clients

Grant: Block access

# Start in Report-only mode for 1–2 weeks first

• Immediately revoke all session tokens: Revoke-AzureADUserAllRefreshToken
• Force password reset on all accounts that authenticated via legacy protocols in the last 90 days
• Audit mailbox rules for any forwarding rules created post-compromise
• Check for new mail connectors, OAuth app consents, or inbox rules created by the attacker
• Review Entra ID audit logs for MFA method changes, new app registrations, or role assignments during the compromise window
• Block legacy auth immediately — do not wait for the audit period

M365's default configuration allows virtually any user to invite external guests to Teams, SharePoint, and OneDrive. Once invited, guest accounts can persist indefinitely — even after the project or relationship ends. Many organizations have hundreds or thousands of stale guest accounts with lingering access to sensitive workspaces.

Separately, anonymous sharing links (the "Anyone with the link" default in SharePoint) allow files to be shared with zero authentication required and no expiration.

Guests are typically unmanaged identities. They bypass your employee lifecycle controls, device compliance policies, and often your DLP policies. With M365 Copilot now in most enterprise tenants, an overpermissioned guest can use AI-accelerated search to map and extract sensitive information far faster than a human attacker ever could.

# Find all guest users and their last sign-in
Get-MgUser -Filter "userType eq 'Guest'" -All | Select-Object `
    DisplayName, Mail, SignInActivity, CreatedDateTime

# Flag stale guests: no sign-in in 90+ days
# Entra ID → Users → Filter: Guest accounts → Sort by Last sign-in

# Check SharePoint anonymous links
# SharePoint Admin Center → Reports → Sharing → filter by "Anyone"

Restrict who can invite guests: Entra ID → External Identities → External collaboration settings → set to "Only users assigned to specific admin roles."

# Restrict to authenticated guests only
Set-SPOTenant -SharingCapability ExternalUserSharingOnly

# Set anonymous link expiration (14 days)
Set-SPOTenant -RequireAnonymousLinksExpireInDays 14

# Require guests to authenticate
Set-SPOTenant -RequireAcceptingAccountMatchInvitedAccount $true

Enable quarterly access reviews in Entra ID for all guest accounts (requires Entra ID P2).

• Immediately disable the guest account in Entra ID — do not delete yet (preserve logs)
• Audit all resources the guest had access to: Teams, SharePoint sites, OneDrive shares
• Check Purview audit logs for bulk download activity, file moves, or export events by that account
• Review if the guest granted themselves app permissions or API access via Graph
• Notify your DPO/legal team if regulated data was accessed
• Purge all active sessions and tokens for that guest identity

Data Loss Prevention (DLP) in Microsoft Purview detects and blocks the movement of sensitive data — credit cards, SSNs, health records, IP — across Exchange, SharePoint, OneDrive, Teams, and endpoints. The misconfiguration isn't that DLP doesn't exist; it's that it's configured for Exchange only while Teams and SharePoint are left unwatched.

Without DLP, a compromised account — or a malicious insider — can exfiltrate your most sensitive files through Teams chat or OneDrive sync with no detection and no friction. In regulated industries, this isn't just a security issue — it's a compliance violation with fines attached.

# Purview → Data loss prevention → Policies
# For each policy, check "Locations" — you want ALL of:

✓ Exchange email
✓ SharePoint sites
✓ OneDrive accounts
✓ Teams chat and channel messages   ← most commonly missing
✓ Endpoint devices (requires Defender for Endpoint)

# If DLP alerts are zero → policy is misconfigured,
# not evidence of a clean environment.

• Purview Compliance Portal → Data loss prevention → Create policy → Use a template (PII, Financial, HIPAA, GDPR)
• Apply to all workloads: Exchange, SharePoint, OneDrive, Teams — never just one
• Start in Audit mode for 2–4 weeks to review false positives before moving to Block
• Use sensitivity labels alongside DLP — labels make classification visible and trigger stricter rules
• Route DLP alerts to a monitored mailbox or Sentinel — unreviewed alerts are useless

• Purview → Activity Explorer → filter by "File downloaded," "File copied," "Email sent" for the user/date range
• Check Defender for Cloud Apps for mass download alerts or unusual transfer patterns
• Pull Unified Audit Log: Search-UnifiedAuditLog -UserIds user@domain.com -RecordType SharePointFileOperation
• Identify what data was accessed, classify its sensitivity, initiate breach notification if regulated data was involved
• Enable DLP immediately in audit mode across all workloads — stop further leakage even mid-incident

The Global Administrator role has unrestricted access to everything in your tenant. The misconfiguration I see constantly: too many permanent GA accounts, teams sharing a single GA login, and admins doing day-to-day work from their admin account. Best practice is 2–4 Global Admins maximum, with access granted only through Privileged Identity Management (PIM) on a time-limited, just-in-time basis.

Every Global Admin account is a crown jewel target. Phish one, and the attacker can disable security policies, create backdoor accounts, exfiltrate your entire directory, and lock out your security team. The risk compounds with "daily driving" — admins checking email and clicking links from an account that can reconfigure your entire tenant.

# List all Global Administrators
Get-MgDirectoryRoleMember -DirectoryRoleId (
  Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
).Id | Select-Object DisplayName, UserPrincipalName

# More than 4 results = first action item.
# Check if any GA accounts have recent interactive sign-ins
# (they should only be used for admin tasks, never daily email)

• Entra ID → Identity Governance → Privileged Identity Management → Roles → Global Administrator
• Convert all permanent GA assignments to Eligible — admins activate the role for max 8 hours, requires MFA + justification
• Create 2 cloud-only break-glass accounts that bypass Conditional Access — store credentials in a physical safe
• Enforce that admin accounts are separate identities from daily-use accounts
• Use least-privilege roles for specific tasks: SharePoint Admin, Exchange Admin — not Global Admin
• Set PIM alerts for unexpected GA activations and review PIM audit logs monthly

• This is a Severity 1 incident — activate your IR plan immediately
• Use a break-glass account to revoke all sessions: Entra ID → User → Revoke sessions
• Audit ALL changes made while attacker had access: new users, MFA methods, CA policy modifications, app permissions
• Check for new privileged role assignments created by the attacker — remove immediately
• Review all Conditional Access policy changes — attackers commonly add exclusions to bypass CA
• Consider engaging Microsoft's Detection and Response Team (DART) for forensics

SPF, DKIM, and DMARC are DNS-based email authentication standards that together prove your domain is the legitimate sender of your outbound email — and tell receiving servers what to do when something claims to be from your domain but isn't.

• SPF — lists the IPs authorized to send email on behalf of your domain
• DKIM — cryptographically signs outbound email so the recipient can verify it
• DMARC — ties SPF and DKIM together with a policy: none / quarantine / reject

Without DMARC set to p=reject, attackers can send email that appears to come from your domain to anyone in the world. This is the foundation of Business Email Compromise (BEC). DMARC with p=none is monitoring mode, not protection — most organizations stay here indefinitely and never enforce.

# Check SPF
nslookup -type=TXT yourdomain.com
# Look for: v=spf1 include:spf.protection.outlook.com -all

# Check DMARC
nslookup -type=TXT _dmarc.yourdomain.com
# p=none  → monitoring only, NOT protected
# no record → fully exposed to spoofing

# Check DKIM
nslookup -type=TXT selector1._domainkey.yourdomain.com

# SPF (add to DNS)
v=spf1 include:spf.protection.outlook.com -all

# DKIM — enable in Defender portal → Email & Collaboration
# → Policies & Rules → Threat Policies → DKIM → Enable

# DMARC — Phase 1: Monitor
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

# DMARC — Phase 2: Quarantine (after 4–6 weeks of reports)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

# DMARC — Phase 3: Reject (target state)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

• Set DMARC to p=quarantine immediately — don't wait to phase gradually if active spoofing is occurring
• Register with a DMARC aggregate report service (Dmarcian, Valimail) for human-readable visibility
• Notify partners and customers that fraudulent email may be in circulation
• File abuse reports with the sending mail providers in your DMARC failure reports
• Enable Defender for Office 365 anti-spoofing policies and spoof intelligence