Microsoft 365 Tenant Hardening in 30 Checkpoints

A freshly provisioned Microsoft 365 tenant is optimized for adoption, not security. Global Admin is handed to whoever created the account, Security Defaults are on but incomplete, legacy authentication protocols are tolerated, and SharePoint sharing is often open to anyone with a link. That configuration gets organizations to “working” quickly, and to a breach just as quickly once a credential is phished or a misconfigured app exposes data.

The 30 checkpoints below are the baseline we apply to every new M365 tenant before handing it to a client. Each checkpoint includes the real feature name, the setting or policy you configure, and a short explanation of the risk it closes. They’re grouped by domain so you can work through them in parallel across your identity, messaging, and endpoint teams. Nothing here requires a premium license tier that most organizations don’t already have, but we call out where Entra ID P1, P2, or Defender for Office 365 Plan 2 is needed.

Checkpoint	Mitigates
1, Enforce MFA for all users	Credential phishing / password spray
4, Block legacy authentication via CA	Auth protocols that bypass MFA entirely
14, Disable client-side external forwarding rules	Silent business email compromise exfiltration
15, Publish SPF, DKIM, and DMARC	Domain spoofing and email impersonation
26, Enable Unified Audit Log	Blind-spot forensics gaps after an incident

Identity & Access

Enforce MFA for all users, including administrators. In Entra ID (formerly Azure AD), create a Conditional Access policy requiring multi-factor authentication for all users across all cloud apps. “Security Defaults” turns on per-user MFA prompts but lacks the granularity needed for a mature environment, use CA policies instead. Every account without MFA is one phished password away from full compromise.
Require compliant or hybrid-joined devices and enforce risk-based sign-in policies via Conditional Access. Create a CA policy requiring that devices be Intune-compliant or hybrid Azure AD-joined before accessing Office 365 workloads, this prevents a stolen credential from being sufficient on an unmanaged device. In parallel, with Entra ID P2, enable the Identity Protection risk policies: require MFA step-up when sign-in risk is “medium or above” and force a password change when user risk is “high.” Entra’s risk engine flags impossible travel, anonymous proxies, and known-compromised credentials automatically, but those signals do nothing without an enforcing CA policy.
Disable Security Defaults once Conditional Access is in place. Security Defaults and Conditional Access are mutually exclusive; you cannot apply granular CA rules while Security Defaults is enabled. Once your CA policies cover MFA for all users, block legacy auth, and admin protections, disable Security Defaults under Entra ID > Properties > Manage security defaults. Leaving both active causes user-experience confusion and unpredictable policy enforcement.
Block legacy authentication protocols via Conditional Access. Create a CA policy that targets the “Other clients” and “Exchange ActiveSync clients” conditions and sets the grant control to Block. Legacy auth, IMAP, POP3, SMTP AUTH, and older ActiveSync, cannot perform modern MFA challenges, making any account using those protocols trivially vulnerable to password spray even with MFA enforced elsewhere. Check the Entra sign-in logs first to identify any service accounts still using legacy auth before you flip the block.
Implement Privileged Identity Management (PIM) for just-in-time role activation. With Entra ID P2, configure PIM for all privileged directory roles, Global Administrator, Exchange Administrator, SharePoint Administrator, and others. Set assignments to “Eligible” rather than “Active” so administrators must explicitly activate the role (with justification and optional approval) for a defined time window. Standing privileged access is one of the highest-risk states in any tenant; PIM eliminates it operationally.
Reduce Global Administrators to a maximum of four accounts. In Entra ID > Roles and administrators, audit current Global Admin membership and remove any accounts that don’t genuinely require tenant-wide control. Microsoft’s guidance is two to four Global Admins; more than that is almost always accumulated privilege from convenience, not requirement. Assign scoped roles (Exchange Administrator, Intune Administrator, etc.) where the narrower permission set is sufficient.
Create two cloud-only break-glass accounts excluded from all Conditional Access policies. Break-glass accounts are emergency accounts used only if your normal admin accounts or CA policies lock you out of the tenant, for example, if your identity provider federation breaks. Create two accounts, give each a random 128-character password stored in a physical sealed envelope or hardware secret vault, exclude them from every CA policy explicitly, and set alerts (see checkpoint 28) to fire the instant either account logs in. Never use these accounts for day-to-day work.

Break-glass account security

Break-glass accounts must be excluded from Conditional Access, that is their entire purpose. This means they have no MFA requirement and no device compliance check. The compensating controls are: (1) a long, randomly generated password stored offline, (2) no one knows the password day-to-day, (3) an alert fires the moment either account signs in, and (4) the accounts are reviewed and password-rotated on a defined schedule. Treat sign-in to either account as an incident until proven otherwise.

Block user self-service app consent and configure an admin consent workflow. In Entra ID > Enterprise applications > User settings, set “Users can consent to apps accessing company data on their behalf” to No. Then enable the admin consent workflow so users can request access and an administrator approves or denies it. Without this control, any user can grant a malicious OAuth app full read access to their mailbox and OneDrive with a single click, a common initial-access vector in business email compromise campaigns.
Enforce phishing-resistant authentication methods and retire SMS OTP for admin accounts. In Entra ID > Authentication methods, enable Windows Hello for Business, FIDO2 security keys, and the Microsoft Authenticator app (with number matching and additional context enabled). Mark SMS and voice call as disabled or restricted to non-admin users only. SMS OTP is vulnerable to SIM-swapping attacks and real-time phishing proxies; privileged accounts should use phishing-resistant methods exclusively.
Restrict guest user default permissions in Azure B2B settings. In Entra ID > External identities > External collaboration settings, set “Guest user access” to “Guest users have limited access to properties and memberships of directory objects.” Ensure “Guest invite settings” restricts who can invite guests, at minimum, limit it to admins and users in specific “Guest inviter” roles. Default guest permissions allow enumeration of directory members and group membership, which is excessive for most use cases.

Email & Collaboration (Exchange / Defender for Office 365)

Configure anti-phishing policies with impersonation protection enabled. In the Microsoft 365 Defender portal (security.microsoft.com), under Email & collaboration > Policies & rules > Anti-phishing, create a custom policy that enables impersonation protection for your key executives and domains. Set the “If message is detected as an impersonated user” action to quarantine or move to Junk. The default policy exists but leaves impersonation protection off, enabling it is the single highest-value click in Defender for Office 365.
Enable Safe Links and Safe Attachments policies for all users. In Defender for Office 365, Safe Links rewrites and detonates URLs at click-time rather than at delivery-time, catching links that were clean at receipt but redirect to malicious sites later. Safe Attachments detonates unknown attachments in a sandbox before delivering them. Both are disabled in new tenants. Apply policies covering all recipients; for Safe Attachments, select “Dynamic Delivery” so mail delivery isn’t blocked while the attachment scans.
Enable the External Sender tag on messages from outside your organization. In the Exchange admin center, enable the external sender callout on email messages (or use the “FirstContactSafety” feature in Defender). This adds a visible “External” pill or banner to every inbound message originating outside your tenant’s accepted domains. It’s a low-effort social-engineering barrier, users are less likely to click a link from “[email protected]” when the banner indicates the sender is external.
Disable client-side mail forwarding rules to external addresses. In Exchange Online, use a Remote Domain setting (set “AutoForwardEnabled” to False on the Default remote domain) and additionally create a mail flow rule (transport rule) that rejects or notifies when a message matches “The sender is located: Inside the organization” and “The recipient is located: Outside the organization” via auto-forward. Client-side Inbox rules that forward mail externally are a silent exfiltration channel in BEC attacks; the user whose mailbox is compromised never sees it happening.
Publish a valid SPF record, enable DKIM signing, and set DMARC to at least p=quarantine. SPF (Sender Policy Framework) in DNS lists the IP addresses authorized to send mail as your domain. DKIM (DomainKeys Identified Mail) signs outbound messages with a private key verifiable via a DNS TXT record, enable it per domain in the Defender portal under Email authentication settings. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do with failures. Start at p=none to collect reports, move to p=quarantine, and ultimately p=reject. Without DMARC at enforcing, your domain can be spoofed by anyone.
Restrict auto-forwarding at the tenant level via outbound spam filter policy. In the Defender portal under Anti-spam policies, set the outbound spam policy’s “Automatic forwarding rules” setting to “Automatic, System-controlled” or explicitly to “Off.” This is a belt-and-suspenders control alongside checkpoint 14’s transport rule: the outbound spam policy catches forwarding configured through account settings or PowerShell rather than Outlook rules.
Control add-in installation and review over-permissioned add-ins in Integrated Apps. In the Microsoft 365 admin center under Settings > Integrated apps, disable user-driven add-in installation and instead deploy approved add-ins centrally through Centralized Deployment. Review the list of already-deployed add-ins for applications requesting mail read/write or full mailbox access, revoke any whose permissions exceed their stated purpose. Malicious or compromised add-ins are a growing initial-access vector because they operate inside the trusted M365 boundary.

Data Protection

Set SharePoint and OneDrive external sharing to the least-permissive level your business requires. In the SharePoint admin center under Policies > Sharing, move the organization-level slider from “Anyone” (anonymous links) down to “New and existing guests” at minimum, or “Only people in your organization” if external sharing isn’t a business requirement. If external sharing is needed, enforce expiration dates on sharing links (checkpoint 21) and require guests to authenticate. Anonymous “Anyone” links bypass authentication entirely and are indexed by search engines when embedded in other content.
Deploy Microsoft Purview sensitivity labels for classification of confidential content. In the Microsoft Purview compliance portal, create at least a basic label taxonomy, Public, Internal, Confidential, Highly Confidential, and publish labels to users via a label policy. Configure auto-labeling rules for high-value patterns such as credit card numbers or Social Security Numbers. Sensitivity labels are the foundation for enforcing rights management (encryption, access restrictions) and for making DLP policies meaningful rather than theoretical.
Create Microsoft Purview DLP policies for PII and financial data. In the Microsoft Purview compliance portal under Data loss prevention, create policies that detect and restrict sharing of high-confidence sensitive information types: U.S. Social Security Numbers, credit card numbers, bank account numbers, and HIPAA-relevant identifiers if applicable. Set policies to notify users on violation and escalate to quarantine or block for high-confidence matches sent externally. The built-in sensitive information types are ready to use, you don’t need to write custom regex to get started.
Set expiration dates on anonymous sharing links and default link type to “Specific people.” In the SharePoint admin center under Policies > Sharing, set “Choose expiration and permissions options for Anyone links” to expire after 14–30 days. Change the default link type from “Anyone with the link” to “Specific people” so users must deliberately choose to create an anonymous link rather than accidentally defaulting to one. Links that never expire are effectively permanent public disclosures for any content shared even once.

Endpoint & Device

Create Intune compliance policies for Windows, macOS, iOS, and Android. In the Intune admin center (intune.microsoft.com) under Devices > Compliance policies, create platform-specific policies that define minimum OS version, require a device PIN or password, and mark devices non-compliant after a defined inactivity period. Pair these policies with the CA device compliance requirement in checkpoint 2: a device that fails compliance is denied access to M365 until it self-remediates or is reviewed.
Require BitLocker encryption on Windows devices and FileVault on macOS via Intune. In Intune under Endpoint security > Disk encryption, create policies that enforce BitLocker (Windows) and FileVault (macOS) with key escrow back to Intune. Mark devices without encryption as non-compliant. Disk encryption is the primary control that makes a stolen laptop a hardware problem rather than a data-breach incident, without it, physical access equals data access.
Onboard endpoints to Microsoft Defender for Endpoint via Intune. In the Intune admin center, configure the Defender for Endpoint connector under Tenant administration > Connectors and tokens, then deploy the onboarding configuration profile to all managed devices. Defender for Endpoint provides EDR (Endpoint Detection and Response), vulnerability management, and attack surface reduction rules. It also feeds the device risk signal into the Entra Identity Protection and CA risky-device conditions.
Deploy Intune App Protection Policies for managed apps on mobile devices. App Protection Policies (APP) in Intune enforce data-handling rules, prevent copy/paste to unmanaged apps, require PIN, block screenshot, for apps like Outlook Mobile and Teams without requiring full device enrollment. This is the key control for BYOD (bring-your-own-device) scenarios: corporate data in managed apps is isolated from personal apps even though IT does not manage the underlying device.

Logging, Monitoring & Governance

Verify the Unified Audit Log is enabled and set the retention period appropriately. In the Microsoft Purview compliance portal under Audit, confirm that auditing is on (it defaults to on for most tenants, but can be disabled). Set audit log retention: E3 licenses retain logs for 180 days; E5 and the Audit (Premium) add-on extend this to one year. If you are in a regulated industry or an incident-response scenario, 90 days of logs is rarely enough, understand your retention before you need it.
Enable mailbox auditing for all users and verify admin actions are captured. Mailbox auditing is on by default in modern tenants, but the default action set logged for non-owner access (delegates, admins) is minimal. Use Exchange Online PowerShell to verify auditing is enabled for all mailboxes (Get-Mailbox -ResultSize Unlimited | Select-Object UserPrincipalName,AuditEnabled) and expand the audited actions to include HardDelete, SendAs, SendOnBehalf, and UpdateFolderPermissions for admin and delegate access. These are the actions most often relevant in a BEC post-incident investigation.
Configure alert policies for high-risk events in the Defender and Purview portals. In the Microsoft Purview compliance portal under Policies > Alert policies, enable or create alerts for: sign-ins from break-glass accounts (checkpoint 7), mass file download or deletion in SharePoint, elevation to Global Administrator, creation of new mail-forwarding rules, and successful logins after multiple failed attempts. Route these alerts to a security mailbox or your SIEM rather than burying them in the individual administrator’s inbox.
Integrate Microsoft 365 audit logs and Defender signals into a SIEM or MDR platform. Raw logs in the Defender portal and the Purview audit search are useful for ad-hoc investigation but insufficient for continuous monitoring. Connect M365 logs to your SIEM via the Microsoft Sentinel data connectors (Microsoft 365, Entra ID, Defender for Office 365, Defender for Endpoint) or export via the Office 365 Management Activity API if you use a third-party SIEM. Without a correlation layer, alert fatigue and missed signals are inevitable, this is why managed detection and response coverage of M365 is a core part of our cybersecurity service.
Review Secure Score monthly and audit enterprise app registrations and OAuth permission grants quarterly. In the Microsoft 365 Defender portal (security.microsoft.com/securescore), review Secure Score on a monthly cadence, score drops indicate configuration drift, and recommended actions are mapped to real attack techniques. On a quarterly cadence, audit Entra ID > App registrations and Enterprise applications: flag any application holding Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All permissions that cannot be attributed to an approved integration and revoke it. Adversaries who compromise a developer account and register a persistent OAuth app can silently retain mailbox and file access long after the original account’s password is reset.

How we apply and maintain this baseline

We apply this checklist as a structured deployment task for every new M365 tenant we manage, and we monitor configuration drift against it on an ongoing basis as part of our managed cloud service. Secure Score regression alerts, Sentinel detection rules for the high-risk events in checkpoint 28, and monthly configuration reviews are all included, so the hardening you start with is the hardening you keep. If you are concerned about your current tenant’s posture, our cybersecurity team can perform a configuration audit against this baseline and prioritize the gaps by risk. Get in touch to schedule one.