Microsoft 365 Security Best Practices: Protecting Your Organization's Cloud Identity
Microsoft 365 is the backbone of enterprise productivity—and a prime target for attackers.
Microsoft 365 powers over 345 million paid commercial seats worldwide, making it the world's most widely deployed enterprise productivity platform. This ubiquity makes it an irresistible target for attackers. From consent phishing campaigns like ConsentFix to sophisticated business email compromise schemes, threat actors have developed extensive toolkits specifically designed to compromise Microsoft 365 environments.
The challenge for security teams is that Microsoft 365 security isn't a single setting—it's a complex web of identity controls, application permissions, conditional policies, and monitoring capabilities spread across multiple admin portals. Default configurations prioritize usability over security, leaving organizations vulnerable until they implement deliberate hardening measures.
This guide provides a comprehensive, actionable framework for securing Microsoft 365 environments. We'll cover identity security fundamentals with Microsoft Entra ID (formerly Azure Active Directory), building effective Conditional Access policies, controlling OAuth application consent, implementing robust monitoring, and defending against token-based attacks. Whether you're hardening an existing deployment or building security into a new tenant from day one, these practices will significantly reduce your attack surface.
The strategies outlined here align with Microsoft's own security recommendations and Zero Trust principles. They're designed to be implemented incrementally—you don't need to do everything at once, but each control you enable closes attack vectors that threat actors actively exploit.
Understanding Microsoft 365 Identity Security
In Microsoft 365, identity is the security perimeter. Unlike traditional on-premises networks protected by firewalls, cloud services are accessible from anywhere—making the user's identity the primary gate that controls access to corporate data.
Microsoft Entra ID: The Identity Foundation
Microsoft Entra ID (formerly Azure Active Directory) is the identity provider that authenticates users and authorizes access to Microsoft 365 services. Every sign-in to Outlook, Teams, SharePoint, or OneDrive goes through Entra ID. This centralization is both a strength (single place to enforce policy) and a risk (compromise Entra ID, compromise everything).
Entra ID offers three license tiers with progressively stronger security features:
Most of the advanced security features covered in this guide require at least Entra ID P1. Organizations with high-value targets or regulatory requirements should strongly consider P2 for risk-based controls.
The M365 Attack Surface
Attackers target Microsoft 365 through multiple vectors:
Essential Entra ID Configuration
Before implementing advanced features, ensure these foundational settings are properly configured.
Security Defaults vs. Conditional Access
Security Defaults is Microsoft's baseline security configuration, available to all tenants for free. When enabled, it requires MFA registration for all users, challenges admins with MFA on every sign-in, blocks legacy authentication protocols, and protects privileged actions.
Recommendation: Organizations without Entra ID P1 should enable Security Defaults immediately. Organizations with P1 or P2 should disable Security Defaults and implement Conditional Access policies for more granular control.
Protect Administrative Accounts
Global Administrators have complete control over your tenant. Protect these accounts with extreme diligence:
Block Legacy Authentication
Legacy protocols like POP, IMAP, and SMTP AUTH don't support modern authentication or MFA, making them perfect for password spray attacks. Block them with Conditional Access or Security Defaults. Before blocking, audit current usage via Sign-in logs to identify apps that need migration to modern authentication.
Conditional Access Policies
Conditional Access is the cornerstone of Zero Trust in Microsoft 365. These policies evaluate sign-in context (who, what, where, how) and enforce appropriate controls (allow, block, require MFA, require compliant device).
Essential Conditional Access Policies
Every organization should implement these baseline policies:
1. Require MFA for All Users
The single most impactful security control. Microsoft reports that MFA blocks 99.9% of account compromise attacks. Create a policy targeting All Users, All Cloud Apps, requiring multifactor authentication as a grant control. Exclude your emergency access accounts.
2. Block Legacy Authentication
Target All Users, All Cloud Apps, with a condition filtering for legacy authentication clients. Set the access control to Block. This closes a major attack vector.
3. Require Compliant Devices for Sensitive Access
For sensitive applications (SharePoint, Exchange), require devices be Intune-managed and compliant. This ensures devices have proper security configurations, current patches, and endpoint protection.
4. Block High-Risk Sign-ins
With Entra ID P2, create policies that block sign-ins detected as high risk by Identity Protection. For medium-risk sign-ins, require MFA or password change. This provides adaptive, risk-based security.
5. Protect Admin Portals
Create a policy targeting admin roles (Global Admin, Security Admin, etc.) that requires phishing-resistant MFA (FIDO2 key or Windows Hello) and blocks access from non-compliant devices. Consider location restrictions to trusted networks.
Location-Based Policies
Named locations allow you to define trusted IP ranges and countries. Common use cases include blocking access from countries where you don't operate, requiring MFA for access outside trusted corporate networks, and blocking sign-ins from anonymizing proxies and VPNs (unless you use corporate VPN).
Pro tip: Always test Conditional Access policies in Report-only mode before enforcing. This shows what would be blocked without actually disrupting users.
OAuth App Governance and Consent Controls
Consent phishing attacks like ConsentFix exploit OAuth application permissions. Controlling what apps can access your tenant is critical for defense. Learn more about how these attacks work in our guide to OAuth Security.
Configure User Consent Settings
Navigate to Entra ID > Enterprise Applications > Consent and permissions > User consent settings. Choose one of these options based on your risk tolerance:
Implement Admin Consent Workflow
If you disable user consent, enable the Admin consent request workflow so users can request access to apps they need. Admins receive requests and can evaluate whether apps are legitimate before granting tenant-wide or user-specific consent.
Deploy App Governance
App Governance (part of Microsoft Defender for Cloud Apps) provides advanced OAuth app monitoring and control:
Regularly Audit Existing Consents
Review currently authorized apps quarterly. Look for apps with excessive permissions (Mail.ReadWrite, Mail.Send, Files.ReadWrite.All), apps from unverified publishers, apps with no business justification, and apps authorized by users who have since left the organization. Revoke access for any suspicious or unnecessary applications.
Monitoring and Alerting
Security controls are ineffective without visibility. Microsoft 365 provides extensive logging—but you need to enable, retain, and actually monitor these logs.
Enable Unified Audit Log
The Unified Audit Log is not enabled by default. Enable it in the Microsoft Purview compliance portal. This log captures user and admin activities across Exchange, SharePoint, OneDrive, Teams, Power BI, and more. Retention is 90 days by default; consider extending with Audit (Premium) or exporting to external SIEM.
Critical Events to Monitor
Create alerts for these high-risk activities:
Microsoft Sentinel Integration
For enterprise environments, Microsoft Sentinel provides cloud-native SIEM capabilities with built-in M365 connectors, pre-built detection rules for common M365 attacks, automated investigation and response playbooks, and long-term log retention.
Protecting Against Token-Based Attacks
OAuth token theft is increasingly common because tokens bypass MFA—if an attacker steals your refresh token, they don't need your password or second factor. Understanding these attacks is crucial; see our guide to OAuth Security for a deep dive.
Enable Continuous Access Evaluation (CAE)
Continuous Access Evaluation enables near real-time token revocation. Without CAE, access tokens are valid until expiry (typically 1 hour)—even if you disable the user account, revoke sessions, or the user's risk level changes. CAE allows Entra ID to push critical events to applications, invalidating tokens within minutes rather than hours.
CAE responds to user disabled/deleted, password changed, MFA required by admin, session revoked, and high user risk detected (with P2).
Token Protection (Preview)
Token Protection binds tokens to specific devices using cryptographic proof-of-possession. Even if a token is stolen, it cannot be used from a different device. This significantly mitigates token theft attacks. Enable via Conditional Access by requiring token protection as a session control.
Configure Sign-in Frequency
Conditional Access can require periodic reauthentication. For high-risk applications or sensitive admin portals, consider requiring fresh authentication every 4-8 hours rather than allowing persistent sessions.
MFA Best Practices: Beyond Basic MFA
Enabling MFA is step one. Optimizing it for security and usability requires more nuance.
MFA Method Hierarchy
Not all MFA is equal. From strongest to weakest:
Enable Number Matching and Context
If using Microsoft Authenticator, enable number matching (users must enter a displayed number rather than just tapping Approve) and additional context (shows app name and location). These features combat MFA fatigue attacks like the one used in the Uber breach.
Disable Weak Methods for Admins
Use Authentication methods policies to disable SMS and voice for administrative accounts. Require these high-value accounts to use phishing-resistant methods only.
Zero Trust Implementation in Microsoft 365
Zero Trust operates on the principle "never trust, always verify." Instead of assuming everything inside the corporate network is safe, Zero Trust verifies every access request as if it originates from an untrusted network.
Zero Trust Pillars in M365
Microsoft Secure Score provides a measurement of your organization's security posture and recommendations for improvement. Review it regularly and prioritize actions that address high-impact risks.
Security Checklist for Administrators
Use this checklist to assess and improve your Microsoft 365 security posture:
Immediate Actions (Do Today)
This Week
This Month
Quarterly
Conclusion
Microsoft 365 security is not a destination—it's a continuous process of configuration, monitoring, and adaptation. The threat landscape evolves constantly; attacks like consent phishing and MFA fatigue didn't exist a few years ago but are now significant risks.
The controls outlined in this guide—strong Conditional Access policies, restricted OAuth consent, comprehensive monitoring, phishing-resistant MFA, and Zero Trust architecture—significantly reduce your attack surface. More importantly, they position your organization to adapt as new threats emerge.
Start with the immediate actions on the checklist, then systematically work through the rest. Each control you implement closes doors that attackers actively try to open. Your users may not notice the security measures working silently in the background—but you'll notice the absence of incidents that might have succeeded otherwise.
Related Reading
For technical details on OAuth attacks targeting Microsoft 365, read our guide on Understanding OAuth Security. To understand the social engineering tactics used to trick users into granting malicious app permissions, see Social Engineering Attacks Explained. For the latest news on threats affecting Microsoft environments, check our coverage of the ConsentFix phishing kit and other security alerts.
