Microsoft 365 Security Hardening: The Baseline Controls Most Tenants Skip

When Microsoft ships an M365 tenant, the default configuration optimizes for frictionless user onboarding. Per-user MFA is not enabled by default; Security Defaults are not enabled in tenants created before October 2019. Legacy authentication protocols that bypass MFA entirely are available by default. User consent to third-party OAuth applications is permitted by default. These defaults reflect decisions made when cloud productivity adoption was the primary goal and security hardening was an afterthought.

Microsoft Secure Score (available in the Microsoft Defender portal at security.microsoft.com) provides a quantified view of how far a tenant's configuration is from Microsoft's recommended security baselines. The score aggregates dozens of security configuration checks into a single percentage, with each check assigned a score weight proportional to its estimated risk impact. A freshly provisioned M365 tenant typically scores in the 30 to 40 percent range. Most enterprise tenants settle around 60 to 70 percent after initial setup because the remaining improvements require configuration tradeoffs that no one wants to own.

The right way to use Secure Score is as a prioritized remediation queue, not as a metric to optimize. Microsoft's weighting generally reflects genuine risk prioritization, but not every recommended action is appropriate for every organization. Some Secure Score recommendations conflict with business requirements (blocking all legacy auth may break a legacy fax-to-email system someone depends on). Work through the Secure Score list as a checklist, evaluate each item against your organization's context, and document the rationale for any recommendations you choose to accept rather than remediate. This documentation is important for auditors and for future security reviews that would otherwise question why a Secure Score item is not addressed.

Secure Score has significant coverage gaps that practitioners should be aware of. It measures configuration, not behavior. A tenant can have a high Secure Score and still be compromised if an attacker uses a technique that Secure Score does not track, such as OAuth consent phishing to a legitimate-looking application or SIM swapping to defeat SMS MFA. Use Secure Score as a baseline hardening tool, not as a comprehensive security posture measure.

Conditional Access is the primary enforcement plane for identity security in M365. A Conditional Access policy evaluates attributes of a sign-in attempt (user, device, location, app, risk level) and applies a grant or block action based on policy conditions. The six baseline policies every M365 tenant should have represent the minimum viable Conditional Access configuration.

Require MFA for all administrators: any user in an Entra ID admin role (Global Administrator, Exchange Administrator, SharePoint Administrator, etc.) must complete MFA on every sign-in to cloud applications. This policy should use phishing-resistant MFA strength (FIDO2 security keys or Windows Hello for Business) rather than SMS or authenticator app push, because admin accounts are high-value targets for adversary-in-the-middle phishing attacks that can intercept one-time codes and push notifications.

Require MFA for all users: every non-admin user must complete MFA when signing in to cloud applications. This can use standard MFA methods including the Microsoft Authenticator app with number matching enabled. The rollout approach matters: deploy to a pilot group first, establish a self-service registration campaign for MFA enrollment, and give users two to four weeks to register before enforcing. Enforcing MFA against users who have not registered will lock them out.

Block legacy authentication: any sign-in attempt using a legacy authentication protocol (Exchange ActiveSync using basic auth, SMTP AUTH, IMAP, POP3, older Office clients using basic auth) should be blocked. This is a prerequisite for MFA policies to be meaningful, because legacy auth protocols bypass Conditional Access entirely.

Require compliant device for sensitive applications: access to applications containing sensitive data (SharePoint document libraries with sensitive classification, finance applications, HR systems) should require a device that is enrolled in Intune and marked as compliant. Compliant device requirements prevent credential theft from leading to data access from attacker-controlled devices.

Block high-risk sign-ins: Entra ID Identity Protection assigns risk scores to sign-in attempts based on signals including impossible travel, anonymous IP addresses, malware-linked IP addresses, and password spray patterns. A policy blocking sign-ins with high risk level stops the majority of automated credential stuffing attacks.

Require MFA for Azure management: any access to the Azure portal, Azure CLI, or Azure PowerShell should require MFA. Azure management operations can affect the infrastructure underlying M365, making this a distinct and important enforcement point from the general user MFA policy.

Legacy authentication protocols are the most commonly exploited gap in M365 security. SMTP AUTH, IMAP, POP3, and basic authentication for Exchange ActiveSync do not support modern authentication flows, which means they cannot participate in Conditional Access policies. An attacker with a valid username and password can authenticate via IMAP from any IP address in the world, bypassing all MFA and Conditional Access controls, and read the user's email. This is the mechanism behind a large fraction of business email compromise attacks.

Before blocking legacy auth, audit which users and applications are actively using it. The Entra ID sign-in logs (filterable by Client App to legacy auth clients) show all recent legacy auth authentications. The Exchange Online PowerShell module provides the Get-MailboxStatistics and Get-CasMailboxPlan cmdlets for identifying mailboxes with legacy protocol access enabled. Expect to find some legitimate uses: a shared mailbox being polled by a monitoring tool, a print-to-email device using SMTP AUTH, an older accounting application that integrates with Exchange via IMAP. These need remediation paths (OAuth-capable alternatives or SMTP relay configurations) before you block.

Microsoft deprecated basic authentication for Exchange Online in October 2022, and by January 2023 had disabled it for most protocols in the majority of tenants. However, SMTP AUTH (used for application mail sending) was not fully deprecated in the same timeline, and some tenants still have per-mailbox SMTP AUTH enabled for specific service accounts. Audit these using Get-CASMailbox | Where-Object {$_.SmtpClientAuthenticationDisabled -eq $false} and disable SMTP AUTH for any mailbox that does not have a documented legitimate need.

The Conditional Access policy for blocking legacy auth targets the Client Apps condition. Set the condition to include Exchange ActiveSync clients and Other clients (which covers legacy auth clients), and set the grant control to Block access. Test this policy in report-only mode for two weeks before enforcing. Monitor the sign-in logs during report-only mode for any legitimate applications that would be blocked, and remediate those applications before switching the policy to enforcement mode.

M365 offers three different MFA enforcement mechanisms: per-user MFA (the legacy approach), Security Defaults, and Conditional Access policies. Understanding the differences is important for choosing the right approach and for explaining to stakeholders why a higher-friction option is necessary.

Per-user MFA is the oldest mechanism, configured through the legacy MFA portal (account.activedirectory.windowsazure.com/usermanagement/mfasettings.aspx). It enforces MFA on every sign-in for the enabled users but does not integrate with Conditional Access, does not support risk-based policies, and does not support phishing-resistant MFA methods. Organizations that have only per-user MFA enabled without Conditional Access have a materially weaker security posture than those using Conditional Access policies.

Security Defaults is Microsoft's preconfigured baseline for tenants that cannot or will not manage Conditional Access policies. It requires MFA for all users and all administrators, blocks legacy authentication, and requires MFA for Azure management. Security Defaults is better than nothing but is not appropriate for enterprise organizations because it does not support exclusions, cannot be customized, and uses a fixed MFA method (Microsoft Authenticator) rather than supporting phishing-resistant methods for administrators. If a tenant is currently using Security Defaults, it should migrate to Conditional Access policies before adding more complex requirements.

Conditional Access policies (requiring Entra ID P1 or P2 licenses) are the correct approach for enterprise environments. They support exclusion groups for break-glass accounts, risk-based controls that adjust MFA requirements based on sign-in risk, device compliance requirements, location-based policies, and named location exemptions for on-premises networks. The P2 license adds Identity Protection risk-based policies that are qualitatively more effective at stopping automated attacks.

For MFA method selection, the hierarchy from strongest to weakest is: FIDO2 security keys (phishing-resistant, no shared secret), Windows Hello for Business (phishing-resistant, device-bound), certificate-based authentication, Microsoft Authenticator with number matching (resistant to MFA fatigue attacks), TOTP authenticator apps, SMS one-time codes (weakest, vulnerable to SIM swap and real-time phishing). Admin accounts should use FIDO2 or Windows Hello. End user accounts should use Microsoft Authenticator with number matching enabled, with SMS as a fallback registration method only.

Beyond Conditional Access, Entra ID has several configuration settings that are set to permissive defaults and need deliberate hardening for enterprise use.

User consent for applications is enabled by default in most tenants, meaning any user can authorize a third-party OAuth application to access their Microsoft Graph data (email, files, calendar, contacts). This is the mechanism behind OAuth consent phishing attacks: an attacker sends a link that requests access to the victim's mailbox data, the user clicks "Allow," and the attacker's application receives a persistent OAuth token without requiring the user's password. Disable user consent entirely (set "Users can consent to apps" to "Do not allow user consent") and require admin consent for all third-party applications. Configure the admin consent workflow so that users can request access to applications, and designated reviewers can approve or deny. This does add friction for SaaS application adoption but eliminates the OAuth consent phishing vector.

External collaboration settings control whether and how guest users can be invited to the tenant. The defaults allow any internal user to invite external guests, allow guests to invite other guests, and allow collaboration with any external organization. For most enterprises, the correct settings are: restrict guest invitations to a specific set of roles (Guest Inviter role at minimum), disable guest-to-guest invitations, and restrict collaboration to specific trusted partner domains if business requirements allow. These settings are in Entra ID under External Identities > External collaboration settings.

App registrations and service principals deserve periodic auditing. Any developer in the tenant can register an application by default, creating a service principal that can be granted access to tenant resources. Apps registered by employees who have since left the organization may retain permissions and active secrets indefinitely. Run a quarterly audit of all app registrations using Get-MgApplication from the Microsoft Graph PowerShell module, identify apps with expiring-soon or never-expiring secrets, identify apps registered by departed users, and review the permissions each app has been granted.

Exchange Online Protection (EOP) is the email security layer included in all M365 subscriptions. The default EOP configuration provides basic spam filtering and malware scanning, but several critical settings require explicit configuration to be effective against modern phishing and spoofing attacks.

Anti-phishing policies in EOP and Defender for Office 365 include impersonation protection and mailbox intelligence. Impersonation protection defends against emails that impersonate your key executives and domains. Configure the high-value impersonation protection list to include the CEO, CFO, and other executives whose names are commonly used in business email compromise attacks. Enable mailbox intelligence, which learns the user's typical communication patterns and increases the sensitivity of impersonation detection for contacts the user communicates with frequently. Set the action for detected impersonation to "Move message to recipients' Junk Email folders" initially, then escalate to "Quarantine" once you have calibrated the false positive rate.

SPF, DKIM, and DMARC are foundational email authentication controls for your outbound domain that EOP cannot configure for you; they require DNS record management. SPF specifies which mail servers are authorized to send as your domain. DKIM adds a cryptographic signature to outbound messages that receiving servers can verify. DMARC specifies what receiving servers should do with messages that fail SPF and DKIM checks, and provides aggregate reporting on mail flow that is critical for discovering unauthorized senders using your domain. Configure all three in order: SPF first (as it is required for DMARC), then DKIM (enable in Defender for Office 365 via the DKIM page in the Email & collaboration settings), then DMARC starting at p=none for reporting.

Safe Links replaces URLs in email messages with Microsoft-scanned proxy URLs that are checked at click time against a reputation database. This provides protection against URLs that were benign at delivery time but became malicious after the fact, a pattern used in delayed-activation phishing attacks. Enable Safe Links for email messages and Microsoft Teams messages. Configure it to track user clicks (important for incident investigation) and to not allow users to click through to the original URL if it is blocked.

Administrative accounts used for day-to-day productivity tasks are the highest-risk combination in M365. An admin reading email in the same browser session where they are managing Entra ID is one malicious attachment or phishing link away from full tenant compromise. Admin account separation is the structural control that breaks this attack chain.

The correct architecture is dedicated cloud-only admin accounts that are not licensed for productivity applications (no Exchange mailbox, no Teams access, no SharePoint access). These accounts are used exclusively through the Microsoft 365 admin center, Entra ID portal, Exchange admin center, and PowerShell. They are not used to read email, browse the web, or access any non-administrative application. The human administrator has a separate regular account for productivity and uses their admin account only when an administrative task requires it.

Cloud-only accounts (accounts created directly in Entra ID, not synced from on-premises Active Directory) are important because they are not affected by on-premises Active Directory compromises. If an attacker compromises on-premises Active Directory and attempts to use pass-the-hash or pass-the-ticket techniques against synchronized accounts, cloud-only admin accounts are immune to this attack path.

Privileged Identity Management (PIM) is available with Entra ID P2 and provides just-in-time activation for privileged roles. Instead of permanent Global Administrator assignment, administrators are eligible for the role and request activation when they need it. Activation requires MFA, can require a justification, and triggers an alert to the security team. The elevated role is automatically revoked after a configured window (typically one to eight hours). PIM dramatically reduces the time window during which admin credentials, if compromised, are usable for high-impact operations. PIM activation requests and approvals are logged and create an audit trail of when elevated access was used and for what stated reason.

Microsoft Defender for Office 365 (MDO, formerly Advanced Threat Protection) adds Safe Attachments, Safe Links, and advanced anti-phishing capabilities on top of Exchange Online Protection. MDO comes in two plans: Plan 1 adds Safe Attachments and Safe Links, Plan 2 adds Threat Explorer, automated investigation and response (AIR), attack simulation training, and advanced hunting.

MDO provides two preset security policies: Standard protection and Strict protection. Standard protection is designed to provide a good security baseline with moderate false positive risk; it is appropriate for most users in most organizations. Strict protection is more aggressive, catching more threats at the cost of more false positives; it is appropriate for high-risk users such as executives, finance team members, and others who are likely targets of targeted phishing attacks.

The practical approach is to assign Strict preset policies to the high-risk user population and Standard preset policies to all other users. This is configured in the Defender portal under Email & collaboration > Policies & rules > Threat policies > Preset security policies. The preset policies cover anti-spam, anti-malware, anti-phishing, Safe Links, and Safe Attachments in a coordinated configuration that Microsoft updates as the threat landscape evolves. Using preset policies is generally preferable to maintaining custom policies for most organizations because Microsoft maintains them; custom policies require manual updates to stay current with new threats.

Custom policies remain appropriate for specific use cases that preset policies do not cover: specific attachment type filtering rules, custom external sender tagging (adding a banner to emails from external senders), or integration with third-party security tools via connectors. Review any custom policies you have configured and verify they are still necessary and not duplicating or conflicting with the preset policies.

M365 and Entra ID generate rich telemetry that can surface active credential attacks. The key is having specific queries defined in advance rather than investigating ad hoc when something is already wrong.

Credential stuffing attacks against M365 produce a characteristic pattern: high volumes of failed sign-in attempts from a distributed set of IP addresses, targeting many different user accounts with a small number of attempts per account per IP (typically one to three attempts, below most per-account lockout thresholds). In the Entra ID sign-in logs, query for resultType == "50126" (invalid credentials) grouped by ipAddress over a 24-hour window. A large number of unique IP addresses with failed attempts against many different user accounts is a strong credential stuffing indicator.

Impossible travel detections appear in the Entra ID Identity Protection risky sign-ins report. These are sign-ins where the same account authenticates from two geographically distant locations within a time window that makes physical travel impossible. Not all impossible travel detections are malicious (VPNs, corporate proxies, and geographic IP database inaccuracies produce false positives), but a pattern of impossible travel detections for an account that does not typically use VPNs warrants investigation. Review the sign-in details for the flagged sign-ins and look for differences in user agent, device, and application access patterns.

Token replay attacks are a more sophisticated pattern where an attacker obtains a valid session token (through a browser extension compromise, adversary-in-the-middle proxy, or token theft from a compromised endpoint) and replays it from a different IP. Entra ID token protection (currently in preview for specific application types) binds tokens to specific devices and network paths. For tenants without token protection, correlate the IP address from sign-in logs with the IP address from Exchange and SharePoint audit logs; a significant discrepancy for the same user in the same time window suggests token theft.