Microsoft 365 Security Hardening: 15 Settings Most Admins Miss
Fifteen Microsoft 365 settings that turn up wrong in every tenant we audit — identity, email, data protection, and the often-missed Conditional Access policies — with the exact admin paths, side effects, and the 90-minute version for the IT lead with time today.
Microsoft 365 ships with default settings designed for trial-friendliness, not for the security posture a regulated EU business needs. Fifteen settings consistently turn up wrong in the M365 reviews we run. Each one is small. Together they are the difference between a tenant that survives a BEC attempt and one that does not.
This is the practitioner's checklist. Fifteen settings, the rationale per setting, the exact admin path to fix it, and the side effects to plan for. Aimed at the IT lead who has 90 minutes and wants to move the needle without breaking anything.
Why "we use M365" is not a security posture
Out-of-the-box M365 is reasonable for a 5-person company in 2018. It is inadequate for any organisation in 2026 that values its data, its customers, or its regulators. The defaults assume goodwill — trust the user, trust the device, trust the network. The realities (BEC, phishing-resistant MFA, conditional-access governance) require a different posture.
The 15 settings below are not exotic. They are not buried in obscure PowerShell. They are admin-portal toggles or sensible Conditional Access policies that the original M365 setup either skipped or set to "report-only" and never enforced.
Settings 01-05: Identity (the most important plane)
Identity is the new perimeter. Five settings that close the largest attack surface in any M365 tenant.
Setting 01: Disable legacy authentication, organisation-wide
Why it matters. Legacy auth protocols (POP3, IMAP4, SMTP AUTH, MAPI, EWS basic, ActiveSync basic) bypass MFA and Conditional Access. An attacker with a valid username + password but no MFA token can authenticate via legacy protocols and access mailboxes silently.
Fix. Conditional Access policy:
Conditions:
Client apps → Other clients (legacy authentication clients)
Access control:
Block access
Side effects. Legacy mail clients (older Outlook versions, mobile email apps using basic auth, scanners-to-email) will stop working. Inventory legacy clients before flipping the switch. The mitigation is usually app-based MFA via OAuth or device-level mail clients that support Modern Authentication.
Setting 02: Phishing-resistant MFA for admin roles
Why it matters. SMS and app-based MFA are vulnerable to phishing (the AiTM attack pattern). Phishing-resistant MFA (FIDO2 / WebAuthn / Windows Hello for Business) is not. Every admin role compromise we have investigated in the last two years involved non-phishing-resistant MFA.
Fix. Conditional Access + Authentication Strengths policy:
Assignment:
Users → Directory roles → Global Admin, Privileged Authentication Admin,
User Admin, SharePoint Admin, Exchange Admin, etc.
Conditions: All cloud apps
Access control:
Grant → Require authentication strength → Phishing-resistant MFA
Side effects. Procure FIDO2 keys (Yubico, Token2, equivalent — €30-€60 per key). Pilot with 2-3 admins before broader rollout. Document break-glass procedure with non-FIDO MFA on the emergency account.
Setting 03: Number matching for push-based MFA
Why it matters. "Tap to approve" MFA is vulnerable to MFA fatigue attacks — bombard the user with prompts until they tap. Number matching displays a 2-digit number on the auth screen that must be typed into the authenticator app, defeating fatigue attacks.
Fix. Entra Admin → Security → Authentication methods → Microsoft Authenticator → Number matching: Enabled, scope: All users.
Side effects. Minor user-experience change. Roll out with a communication note.
Setting 04: Privileged Identity Management (PIM) for admin roles
Why it matters. Standing admin rights are the bane of identity security. PIM converts standing admin rights into just-in-time elevations with approval workflow, time limits, and audit trail. A compromised admin account has fewer paths to escalation when admin rights are JIT.
Fix. Entra Admin → Identity Governance → Privileged Identity Management → Azure AD roles. For each admin role, configure: Activation max duration 4-8 hours, approval required (with named approvers), notification on activation, justification required.
Side effects. Requires Entra ID P2 licensing. Admin users learn a new ritual — activate role before doing admin work. Worth the friction.
Setting 05: Sign-in risk-based Conditional Access
Why it matters. Entra ID Identity Protection scores sign-ins for risk (impossible travel, unfamiliar location, leaked credentials match, malware-linked IP). Without a CA policy that responds to risk, the signals exist but produce no action.
Fix. Conditional Access policy:
Conditions:
Sign-in risk → High
Access control:
Block (or require password reset + MFA)
A second policy for Medium sign-in risk: require MFA, log for review. Third policy for User risk → High: require password reset.
Side effects. Requires Entra ID P2. Plan for occasional false-positive blocks during travel — document the unblock procedure.
Settings 06-09: Email and collaboration
Setting 06: Safe Attachments + Safe Links
Why it matters. Defender for Office 365's Safe Attachments detonates suspicious attachments in a sandbox before delivery. Safe Links rewrites URLs in emails to a Microsoft-proxied URL that scans the destination at click time. Neither is on by default in non-E5 tenants and even E5 tenants frequently have policies in audit-mode rather than enforced.
Fix. Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies. Create Safe Attachments policy: enable for all users, "Block" mode (not "Replace"). Create Safe Links policy: enable for all users, scan URLs at click time, do not let users click through warning pages.
Side effects. Email delivery latency increases by 30-180 seconds for attachments. Communicate the change.
Setting 07: Anti-phishing policy with impersonation protection
Why it matters. The standard BEC attack vector is impersonation of executives or trusted external partners. Defender's anti-phishing policies detect impersonation patterns and either block or flag with a warning banner.
Fix. Defender portal → Threat policies → Anti-phishing. Create policy: enable Mailbox intelligence, protected users list (executives, finance, HR), protected domains list (key suppliers + partners), "Quarantine message" for high-confidence impersonation.
Side effects. Occasional false positive on legitimate external communications from new partners. Build the allow-list as you go.
Setting 08: SharePoint + OneDrive external sharing scope
Why it matters. SharePoint defaults to "Anyone with the link" external sharing. This is the most common cause of unintended data exposure in M365 tenants. The default also produces the oversharing problem that breaks Copilot rollouts.
Fix. SharePoint admin centre → Policies → Sharing. Set external sharing to "Existing guests" or "New and existing guests" (not "Anyone"). For OneDrive, match. Set default link type to "People in your organisation" (not "Anyone with the link").
Side effects. External sharing now requires authentication. Users who relied on anonymous links will need re-training. Worth the operational shift.
Setting 09: Block consent to third-party OAuth apps
Why it matters. Users can consent to OAuth apps that request broad permissions over their mailbox, contacts, OneDrive, calendar. Malicious OAuth apps are a known supply-chain attack vector and were responsible for several high-profile 2024-2025 breaches.
Fix. Entra admin → Enterprise applications → Consent and permissions → User consent for applications → "Do not allow user consent" or "Allow user consent for apps from verified publishers, for selected permissions". Plus: configure an admin consent request workflow so users can request and admins can approve specific apps.
Side effects. Legitimate productivity apps that ask for OAuth permissions need admin approval. Build the approval workflow before flipping the switch.
Settings 10-12: Data protection
Setting 10: Sensitivity labels deployed and required
Why it matters. Sensitivity labels (Microsoft Purview) provide the foundation for DLP, encryption, retention, and Copilot scope-control. Without labels, the more sophisticated data-protection controls are blind.
Fix. Microsoft Purview → Information protection → Labels. Create a label taxonomy aligned to your information classification scheme (typically: Public / Internal / Confidential / Restricted, sometimes with sub-labels). Publish a label policy with mandatory labelling for emails and documents. Pilot with one team; broaden over 4-8 weeks.
Side effects. User-experience change — every email + document needs a label. Training matters. Default labels can be set per group to reduce friction.
Setting 11: DLP baseline policies
Why it matters. Data Loss Prevention rules detect sensitive data flows (credit cards, IBAN, national IDs, custom patterns) and either log, warn, or block. Without DLP, the audit-trail of data egress is empty.
Fix. Purview → Data loss prevention → Policies. Create policies based on the built-in templates (GDPR, PCI DSS, country-specific PII). Start in "Audit" mode for 2-4 weeks to baseline. Then enable "Warn" with user override option. Finally, enable "Block" for high-confidence detections.
Side effects. Legitimate workflows that move sensitive data will trigger the policies. The audit phase identifies these; the exception process handles them.
Setting 12: Audit log retention extension
Why it matters. Default audit log retention is 180 days for E3, 1 year for E5. For DORA + NIS2 + ISO 27001 environments, you need longer retention. Forensic investigations of slow-burn compromises (where the breach happened 8 months before detection) require multi-year audit logs.
Fix. Two options: (1) Purview → Audit → Audit retention policies → configure 10-year retention for high-risk activities (requires E5 + add-on). (2) Stream audit logs to Sentinel via the Office 365 Management API and apply Sentinel retention rules. Option 2 is typically more economical for >1-year retention.
Side effects. Storage cost in Sentinel proportional to volume. Use Sentinel's Basic Logs tier for high-volume, low-fidelity audit categories.
Settings 13-15: The often-missed
Setting 13: Conditional Access enforcement for guest users
Why it matters. Guest users (B2B collaboration) often have weaker authentication than your own employees because they come from the partner's tenant. A guest from a less-hardened tenant becomes a foothold in yours.
Fix. Conditional Access policy:
Assignment:
Users → Include → Guest or external users → All guest and external users
Conditions: All cloud apps
Access control:
Grant → Require MFA + Compliant device OR Hybrid Azure AD joined device
This forces guests to satisfy your MFA + device-compliance requirements, regardless of their home tenant's policies.
Setting 14: Defender for Cloud Apps OAuth governance
Why it matters. Beyond user-consent block (Setting 09), Defender for Cloud Apps (formerly MCAS) provides continuous monitoring of OAuth apps. Newly granted permissions, app behaviour anomalies, automated revocation policies.
Fix. Defender portal → Cloud apps → OAuth apps. Review the existing OAuth app inventory. Revoke unused / suspicious apps. Create automated policies: revoke apps with high permission scope and low user count, alert on new app with admin consent.
Side effects. Requires Defender for Cloud Apps licensing (often bundled with E5).
Setting 15: Continuous Access Evaluation (CAE)
Why it matters. Standard token lifetimes mean a compromised session can outlast the compromise event by hours. CAE evaluates session validity continuously and revokes tokens within minutes of relevant events (password change, user disabled, location change, risk detected).
Fix. Entra admin → Conditional Access → Continuous Access Evaluation → enable in "Default" mode (vs Disabled). For higher-security tenants, "Strict" mode adds location enforcement.
Side effects. Generally invisible to users; occasionally a session refresh prompt. The improvement to security posture is significant.
The Conditional Access policy stack we recommend
Settings 01, 02, 05, 13 are all Conditional Access policies. Plus a few more. The recommended stack:
- Block legacy authentication (Setting 01)
- Require phishing-resistant MFA for admins (Setting 02)
- Require MFA for all users on first sign-in from new device/location
- Block sign-ins from high-risk countries (geofence allow-list)
- Sign-in risk: block High, require MFA on Medium (Setting 05)
- User risk: require password reset on High
- Require compliant device for sensitive apps (SharePoint, Exchange, Yammer)
- Require MFA + device compliance for guest users (Setting 13)
- Block access from unmanaged macOS / iOS / Android devices unless app-protection policy applied
- Require terms-of-use acceptance on first sign-in (audit trail)
Roll out in report-only mode first. Monitor 1-2 weeks for false-positive impact. Promote to enforced one policy at a time with pilot groups.
The licensing reality
| Setting | Minimum license | Note |
|---|---|---|
| 01, 03, 09, 13, 15 | Entra ID Free | Available to all tenants |
| 02, 05 | Entra ID P1 (or P2 for full risk policies) | Bundled with E3 / E5 |
| 04 | Entra ID P2 | Bundled with E5; standalone available |
| 06, 07 | Defender for Office 365 P1+ | Bundled with E5; standalone available |
| 08 | Free | SharePoint admin centre setting |
| 10, 11, 12 | Purview / Compliance suite | Bundled with E5; standalone available |
| 14 | Defender for Cloud Apps | Bundled with E5; standalone available |
For regulated entities, E5 licensing is usually the right answer once the controls above are factored in. For non-regulated SMB, E3 + selected add-ons (Defender for Office 365 P1, Entra ID P2) often produce a better cost-feature ratio than E5 across the board.
The implementation order we recommend
Week 1: Foundations
Settings 01 (legacy auth), 03 (number matching), 09 (block user consent), 14 (OAuth app review). Lowest user-impact, highest immediate risk reduction.
Week 2-3: Identity hardening
Settings 02 (phishing-resistant MFA for admins), 04 (PIM rollout), 05 (sign-in risk policies). Procure FIDO2 keys for admins, plan the PIM ritual.
Week 3-4: Email defence
Settings 06 (Safe Attachments / Safe Links), 07 (anti-phishing impersonation). Communicate the email-latency change to users.
Week 4-6: External + sharing
Settings 08 (external sharing scope), 13 (Conditional Access for guests). The user-experience change requires comms + training.
Week 6-10: Data protection
Settings 10 (sensitivity labels), 11 (DLP), 12 (audit retention). Slower rollout — labels need training, DLP needs audit-mode baselining.
Week 10-12: Continuous
Setting 15 (CAE). Generally low-impact; can be enabled toward the end of the rollout.
The post-implementation discipline
Settings deteriorate. New users get added to the wrong group. New apps request consent. New SharePoint sites bypass the sharing policy. The hardening pattern is recurring, not one-time.
The operating cadence we ship:
- Weekly: Conditional Access policy hit-rate review, anti-phishing false-positive list, OAuth consent requests
- Monthly: Secure Score drift, user risk + sign-in risk volumes, DLP policy effectiveness
- Quarterly: Sensitivity label adoption, audit log volume + retention, FIDO2 key inventory
- Annually: Full Conditional Access policy review, Defender policy review, complete posture audit
The 90-minute version, ranked by impact-per-minute
If you have 90 minutes today and can only do a subset:
- Setting 01 (block legacy auth) — 5 min
- Setting 02 (phishing-resistant MFA for admins, even if just enforced, FIDO2 procurement to follow) — 15 min
- Setting 09 (block user consent to OAuth apps) — 5 min
- Setting 08 (SharePoint external sharing to "Existing guests") — 10 min
- Setting 06 (Safe Attachments + Safe Links enable) — 15 min
- Setting 03 (number matching) — 5 min
- Setting 13 (Conditional Access for guests) — 15 min
- Setting 15 (Continuous Access Evaluation) — 5 min
- Document what you did + set calendar reminders for the remaining 7 — 15 min
Eight of fifteen done in 90 minutes. Secure Score moves 8-15 points. Most impactful changes are upstream of any breach you have not had yet.
The one paragraph version
Microsoft 365 defaults are not a security posture. Fifteen settings — five identity, four email + collaboration, three data-protection, three often-missed — close the largest attack surfaces in any M365 tenant. The implementation order matters (low-impact first, then identity, then email, then data protection, then continuous). Licensing reality: most settings work on E3 + Entra P2, with full E5 producing the cleanest experience for regulated entities. The post-implementation discipline (weekly / monthly / quarterly cadence) is what keeps the gains. An IT lead with 90 minutes can do 8 of 15 today and move the Secure Score 8-15 points before lunch.
If you want the full hardening + ongoing operate cadence, that is the engagement shape. Microsoft 365 Defender covers settings 01-09 + 12-14 with continuous tuning, while Microsoft 365 Management covers settings 04, 08, 10-11 + the Conditional Access stack as part of the standard baseline. The discovery call is free and we will tell you which of the 15 your tenant currently fails — for free, regardless of whether you engage afterward.