Microsoft 365 security: 11 settings that are wrong on almost every tenant we audit.

When we onboard a new client, one of the first exercises is auditing their existing Microsoft 365 tenant. After dozens of these, the same eleven misconfigurations show up over and over. Most take 5–15 minutes to fix. Together they account for the majority of preventable account compromises we see in the field.

This isn't a comprehensive M365 hardening guide — that would be a small book. It's the field-tested list of things to check first because they have the worst expected-value ratio: high impact, low effort, almost always wrong. If you're an IT admin doing internal triage, or a business owner trying to ask your existing provider the right questions, work this list top to bottom.

One caveat: Microsoft moves admin UIs around constantly. The exact paths I'll mention work as of mid-2026 but Microsoft will rename and relocate some of these. The principles don't change.

1Legacy authentication is enabledCritical

Legacy auth protocols — POP3, IMAP, SMTP AUTH, EWS, MAPI/HTTP, ActiveSync basic auth — don't support MFA. An attacker who gets a valid username/password can authenticate via these protocols and completely bypass your MFA enforcement. Microsoft has been deprecating basic auth for years, but new tenants still default to allowing it for some protocols, and old tenants may have never disabled it.

Check: Entra ID → Conditional Access → Sign-in logs. Filter by "Client app" = "Other clients." If you see successful sign-ins from non-modern clients, legacy auth is being used.

Fix: Create a Conditional Access policy that blocks legacy authentication for all users. Microsoft has a published template named "Block legacy authentication." Roll it out in report-only mode first to catch any service accounts or printer/scanner credentials that depend on basic auth — these need to migrate to OAuth or get app passwords with extreme caution.

2MFA is "enabled" but not enforcedCritical

The most common compromise pattern we see. The org "has MFA" — meaning users are asked to enroll, but if they don't, they can still log in with just a password. This is sometimes called the per-user MFA mistake or the "MFA invitation" anti-pattern. We've audited tenants where 40% of users hadn't enrolled and nobody noticed.

Check: Entra ID → Security → Authentication methods → Registration campaign. Also check Entra ID → Properties → "Security defaults" status. If you have any Entra ID P1 or P2 licensing, look at Conditional Access policies.

Fix: Three approaches in order of preference:

• Best: Conditional Access policy requiring MFA for all users on all cloud apps (requires Entra ID P1). Block sign-in if MFA isn't completed.
• Acceptable: Security Defaults turned on (free, no P1 needed). This enforces MFA for all users with reasonable defaults but less control.
• Insufficient: Per-user MFA, registration campaigns, or "encouraging" enrollment. Not a substitute for enforcement.

Audit which users have actually completed enrollment after rollout — there will be holdouts. Either they enroll or they can't log in. There's no middle ground in 2026.

3Too many global administratorsCritical

Microsoft's recommendation is 2–4 global admins (break-glass + named admins). We routinely audit tenants with 8, 12, 25 global admins. Often these include developers who needed admin access "temporarily" three years ago, the previous IT person who left in 2022, the CEO's son-in-law who set up the tenant in 2017.

Check: Entra ID → Roles & admins → Global Administrator. Count. If it's more than 5, you have a problem.

Fix: Move people to less-privileged roles. Exchange Administrator can manage email without needing Global Admin. User Administrator can manage user accounts. Privileged Authentication Administrator can reset MFA without Global Admin. Microsoft has 70+ built-in admin roles — almost nobody needs Global Admin to do their job. Maintain 2–3 named Global Admins plus 1 break-glass emergency account with the credentials in a sealed envelope in a safe.

4Inbox forwarding rules to external addressesCritical

The classic indicator of account compromise. An attacker who gets into an account often creates a forwarding rule that silently copies inbound mail to an attacker-controlled address. They use this to harvest financial information, reset password attempts, and identify next targets for spearphishing.

Even when not malicious, external auto-forwarding is risky: it bypasses your DLP, retention, and audit logging. It's almost never the right answer to a legitimate business need.

Check: Exchange admin center → Mail flow → Remote domains. Then run this PowerShell against your tenant:

Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingSmtpAddress -ne $null} | Select-Object Name, ForwardingSmtpAddress

Also run:

Get-Mailbox -ResultSize Unlimited | Get-InboxRule | Where-Object {($_.ForwardTo -ne $null) -or ($_.ForwardAsAttachmentTo -ne $null) -or ($_.RedirectTo -ne $null)}

Fix: Disable external auto-forwarding tenant-wide via Exchange admin center → Mail flow → Anti-spam policies → Outbound spam policy → "Automatic forwarding rules" → "Off - Forwarding is disabled." Investigate any existing external forwards before turning this on; some may be legitimate but should be migrated to a different pattern (shared mailbox, distribution list, etc.).

5SharePoint & OneDrive external sharing wide openHigh

Default new SharePoint tenants allow sharing with anyone, including via anonymous "Anyone with the link" URLs that don't require sign-in. We routinely find sensitive documents — contracts, employee data, financial records — shared via Anyone links that are still active years later, indexable by search engines and accessible by anyone who has the URL.

Check: SharePoint admin center → Policies → Sharing. Look at the External sharing slider for SharePoint and OneDrive. If either is set to "Anyone," you have exposure.

Fix: Default both SharePoint and OneDrive external sharing to "New and existing guests" or stricter. This requires external recipients to authenticate (Microsoft account or one-time passcode) before accessing shared content. The minor friction is worth the audit trail and the ability to revoke access.

Then run a sharing audit: SharePoint admin center → Content Services → Reports. Identify and review files shared via Anyone links. Most of them shouldn't have been.

6No tenant restriction on guest user creationHigh

By default, any user in a Microsoft 365 tenant can invite external guests into Teams, SharePoint sites, or shared resources. This means a regular user can add their consultant, their friend, their previous employer — none of which goes through IT review. Over time you accumulate hundreds of inactive guest accounts that have access to internal data.

Check: Entra ID → External identities → External collaboration settings. Look at the "Guest invite settings" section.

Fix: Restrict guest invitations to admins, or at minimum to users in a specific group (Members can invite). Then perform a guest cleanup: identify guest accounts that haven't signed in for 90 days and disable them; review the remainder for current business need.

7Anti-phishing policies at default settingsHigh

Microsoft Defender for Office 365 ships with reasonable default policies, but they're tuned conservatively to minimize false positives in initial setup. In production, you want stricter settings on impersonation protection, spoof intelligence, and mailbox intelligence.

Check: Microsoft 365 Defender portal → Email & collaboration → Policies & rules → Threat policies → Anti-phishing.

Fix: Use Microsoft's Standard or Strict preset security policies as a baseline. Then customize:

• Enable impersonation protection for your domain and any look-alike domains (e.g., if you're slyderconsultinggroup.com, add common typos: slydercosulting.com, etc.)
• Add your CEO, CFO, and other high-value targets as protected users (Microsoft's mailbox intelligence flags impersonation attempts of these specific people)
• Set "If message is detected as impersonation: Quarantine the message"

8Safe Attachments and Safe Links not enabledHigh

If you have Microsoft 365 Business Premium or any E5 SKU, you already pay for Microsoft Defender for Office 365 P1 or P2. Many tenants never turn it on. Safe Attachments detonates attached files in a sandbox before delivery; Safe Links rewrites URLs in messages so they're checked against threat intelligence at click-time.

Check: Microsoft 365 Defender portal → Email & collaboration → Policies & rules → Threat policies → Safe Attachments and Safe Links. Look at the policy list — most tenants only have the default minimal policies.

Fix: Apply Microsoft's Standard preset security policies to all users. This automatically configures Safe Attachments (Dynamic Delivery — users get the message immediately while attachments scan in the background) and Safe Links (URLs rewritten in mail, Office docs, and Teams). The performance impact is minimal; the security impact is substantial.

9Audit logging disabled or short retentionMedium

Microsoft 365's unified audit log is the forensic record of every administrative action and many user activities. It's essential for investigating incidents. We still encounter tenants where audit logging was never turned on — meaning there's no record to investigate from.

Default retention is 90 days for most events with E3, longer with E5. For compliance-driven organizations, 90 days is often insufficient.

Check: Microsoft Purview → Audit. If you see "Auditing is not enabled," it's not enabled.

Fix: Enable unified audit log if not already on. With E5 or compliance add-ons, configure retention policies to extend logs to 1 year or 10 years for sensitive activities. Document the retention setting in your IT policies — auditors will ask.

10Service accounts with passwords that never expire and admin rightsHigh

Service accounts created for printers, scanners, line-of-business apps, third-party integrations. Set up once, password noted on a sticky note (or in plaintext in someone's notes app), set to never expire, often with Global Admin or unnecessarily broad permissions.

These accounts are a common compromise vector. Attackers who phish a regular user and then enumerate the tenant often find service accounts that haven't rotated credentials in years.

Check: Audit all accounts with disabled password expiration. Cross-reference against accounts with privileged roles. Identify which are actively used (Entra ID sign-in logs).

Fix: For each service account: convert to a managed identity if the consuming app supports it; otherwise, rotate the password and document it in your password manager. Reduce privileges to the minimum required. For service accounts that genuinely need elevated permissions, enable Privileged Identity Management (PIM) for just-in-time elevation if you have Entra ID P2.

11No conditional access for risky sign-insMedium

Entra ID Identity Protection (P2) detects risky sign-ins — sign-ins from unusual locations, anonymous IP addresses, infected devices, leaked credentials, atypical travel patterns. Detection is great. Doing nothing about the detection is the problem.

Check: Entra ID → Security → Identity Protection. Look at sign-in risk reports.

Fix: Create Conditional Access policies that respond to risk levels:

• Medium risk sign-in → require MFA
• High risk sign-in → block or require admin reset
• Risky user (multiple risk events) → require password change at next sign-in

This functionality requires Entra ID P2 licensing (or Microsoft 365 E5). If you don't have it, the manual workflow is monitoring the sign-in logs for risky events and responding manually — which doesn't scale beyond about 25 users.

The diagnostic test.

If you're an IT admin or business owner reading this, here's the fastest way to triage your own tenant: log in to Microsoft 365 admin center → Compliance Manager and check your Secure Score. It's Microsoft's automated assessment of your tenant security posture against their recommended baseline.

Most tenants we audit start in the 30–45% range. After remediating the eleven items above, most reach 65–75%. With ongoing maturity work (deeper Defender configuration, DLP policies, Insider Risk, full compliance frameworks), 85%+ is achievable. Above 90% is enterprise territory.

If your Secure Score is below 50%, you have meaningful exposure and high-leverage work to do. None of it requires expensive new licensing — most of it uses features already in your existing M365 subscription. You're just not using them.

One closing point about M365 security.

People sometimes ask why we recommend Microsoft 365 to clients when Microsoft's security defaults are this weak out of the box. Two answers. First: every major SaaS platform has the same problem — they ship with defaults tuned for "won't break anything on day one," not "secure on day one." Google Workspace, Slack, Zoom, Salesforce all have the same dynamic. Second: M365 actually has the controls. Many platforms claim to support enterprise security but lack the actual policy primitives. M365's challenge is that the controls exist but aren't on by default. That's a configuration problem, not a platform problem — and it's fixable in a focused engagement.

If you want help working through your tenant, that's exactly the kind of engagement we're built for. Book a call and we'll do an honest read of where you stand.