This article consolidates the specific, tenant-wide settings that make up a defensible Microsoft 365 security baseline — the floor every tenant should meet before considering more advanced controls. Each recommendation links to the cluster article that explains the underlying reasoning in full.
Identity baseline
| Setting | Recommendation |
|---|---|
| MFA enforcement | Required for all users, no standing undocumented exceptions |
| Legacy authentication | Blocked entirely via Conditional Access |
| Password expiration | Disabled for cloud-only accounts, paired with breach screening |
| Entra Password Protection | Enabled, with a custom banned-password list |
| Break-glass accounts | Two, excluded from Conditional Access, monitored |
| Administrative role assignment | Just-in-time (PIM) rather than standing, where licensed |
See Microsoft Password Best Practices and Multi-Factor Authentication: Methods and Best Practices for the full reasoning behind each identity setting.
Email baseline
| Setting | Recommendation |
|---|---|
| SPF, DKIM, DMARC | Configured and enforced (not monitor-only) for the tenant's mail domains |
| Safe Links / Safe Attachments | Enabled tenant-wide (requires Defender for Office 365) |
| Anti-phishing / impersonation protection | Configured for executives and frequently-impersonated domains |
| Auto-forwarding to external domains | Blocked or requires explicit approval |
See Microsoft Defender for Office 365 for the reasoning behind email-specific controls.
Device baseline
| Setting | Recommendation |
|---|---|
| Device compliance policy | Defined and enforced for devices accessing sensitive applications |
| Conditional Access device requirement | Compliant or hybrid-joined device required for sensitive access |
| Mobile application management | Applied to unmanaged/BYOD devices at minimum |
Data protection baseline
| Setting | Recommendation |
|---|---|
| Sharing link defaults | Set to the most restrictive practical default (specific people, not "anyone"), reviewed periodically |
| Sensitivity labels | Defined for at least your most sensitive data categories |
| Audit logging | Enabled tenant-wide, retention period matched to compliance requirements |
How to use this baseline
This checklist is intentionally condensed — a starting audit tool, not a full implementation guide. For each row that isn't currently met, the linked cluster article explains the specific configuration steps and the reasoning behind the recommendation. Use Microsoft Secure Score Guide alongside this baseline — Secure Score's improvement actions overlap significantly with this list and provide step-by-step configuration guidance directly in the admin console.
A baseline is a floor, not a ceiling
This baseline reflects a reasonable minimum for most organizations. Regulated environments (HIPAA, PCI DSS) and organizations with elevated risk profiles should treat this as a starting point and layer additional controls from the compliance-specific articles in this Knowledge Center on top of it.
Common mistakes
- Implementing identity controls but skipping email and data protection settings, leaving a partial baseline that undersells the actual work already done.
- Treating this as a one-time setup task rather than a baseline to re-verify periodically as the tenant and threat landscape evolve.
- Not documenting which baseline items were deliberately not implemented and why, which is exactly the kind of gap an audit or incident review surfaces.
FAQ
How does this baseline relate to Secure Score? Secure Score's improvement actions cover much of this same ground with point-scored, prioritized guidance — use this baseline as the conceptual checklist and Secure Score as the step-by-step implementation tracker.
Is this baseline sufficient for HIPAA or SOC 2 compliance? No single generic baseline satisfies a specific compliance framework on its own. This baseline is a strong technical foundation; compliance readiness requires mapping it against the specific framework's requirements — see HIPAA Password Guidance and Compliance Readiness Assessment.
How often should this baseline be re-verified? At least annually, and after any significant tenant change (new licensing tier, new integrated application, merger or acquisition) — the same cadence recommended for the identity and password policies this baseline builds on.
Related reading
- Microsoft Secure Score Guide
- Microsoft 365 Security Architecture
- Building a Password Policy Template
- HIPAA Security Rule Explained — mapping this baseline to a specific framework's Technical Safeguards
- Microsoft 365 Copilot Readiness — why this baseline's permissions hygiene is a Copilot rollout prerequisite
- Download: Microsoft 365 Security Checklist
- Download: Microsoft 365 Hardening Checklist