Microsoft 365 security assessment checklist (2026)

A Microsoft 365 tenant accumulates settings for years: policies someone created for a pilot, admin accounts nobody removed, sharing defaults that were never revisited. A security assessment is a structured look at those settings against current good practice, with a prioritized list of what to change.

This checklist is the one we use to design assessments. It's organized by service, and each item says what to look for and where. Links go to Microsoft's own documentation on Microsoft Learn, which is the authority on how each feature behaves.

Before you start: scope, access and evidence

• Use read-only access. An assessment should never need write permissions. The Global Reader role in Microsoft Entra ID can view settings across most admin centers without changing anything. See Microsoft Entra built-in roles.
• Know the licenses. What you can recommend depends on what the tenant owns. Conditional Access needs Microsoft Entra ID P1 (included in Microsoft 365 Business Premium, E3 and E5); risk-based policies and Privileged Identity Management need P2. See Microsoft Entra licensing.
• Write down the date, the tenant and who ran it. Settings change weekly. A finding is only useful with the context of when it was true.
• Capture numbers, not impressions. "27 users without MFA, 2 of them admins" can be re-checked next quarter. "MFA adoption is patchy" can't.

1. Identity and access (Microsoft Entra ID)

Authentication and MFA

• Every user who can sign in is registered for multifactor authentication. Check Authentication methods › User registration details in the Microsoft Entra admin center.
• MFA is actually required, either by security defaults or by Conditional Access policies, not by legacy per-user MFA alone.
• Weak methods are limited. SMS and voice calls are better than nothing but are the easiest to phish or intercept; plan a move to the Microsoft Authenticator app and phishing-resistant methods, starting with admins.
• The Authentication methods policy is where methods are managed. Methods enabled there but unused by anyone are candidates to switch off.
• Self-service password reset is enabled with strong methods, and Microsoft Entra Password Protection blocks common and company-specific weak passwords.

Conditional Access

• Legacy authentication is blocked. Old protocols can't do MFA, so they bypass it. See how to find and block legacy authentication.
• Admins are required to use MFA, ideally a phishing-resistant method, on every sign-in to admin portals.
• There are at least two emergency access (break-glass) accounts, excluded from policies that could lock everyone out, and monitored.
• Policies aren't left in Report-only mode indefinitely, and exclusions are small, named and documented.
• If the tenant has Entra ID P2, user-risk and sign-in-risk policies are in use. See our Conditional Access baseline.

Admin roles

• Global Administrator is held by a small number of people. Microsoft recommends fewer than five. See best practices for Microsoft Entra roles.
• Day-to-day work uses least-privileged roles (User Administrator, Helpdesk Administrator, Exchange Administrator and so on).
• Admin accounts are cloud-only, separate from people's everyday accounts, and not synchronized from on-premises Active Directory.
• With P2, roles are eligible through Privileged Identity Management rather than permanently active. More in Entra ID privileged access.

Guests, apps and consent

• Guest access is intentional: who can invite guests, what guests can see in the directory, and whether invitations are limited to specific domains. See external collaboration settings.
• Users can't consent to apps that request broad permissions. Either restrict consent to verified publishers and low-risk permissions, or require admin approval through the admin consent workflow.
• Enterprise applications with high-privilege permissions (mail, files, directory write) have a known owner and a reason to exist. See finding risky OAuth apps.
• App registrations don't have long-lived client secrets nobody tracks, and ordinary users can't register applications unless there's a reason.

Accounts and hybrid identity

• Enabled accounts that haven't signed in for months are reviewed; disabled accounts don't hold licenses or group memberships they no longer need.
• If Microsoft Entra Connect or Cloud Sync is used, the sync server is protected like a domain controller, and password hash synchronization is considered (it enables leaked-credential detection).

2. Devices (Microsoft Intune)

• Every platform in use (Windows, macOS, iOS/iPadOS, Android) has a compliance policy, and Mark devices with no compliance policy assigned as is set to Not compliant. See device compliance policies.
• Compliance is enforced: a Conditional Access policy requires a compliant device for at least the sensitive apps.
• Disks are encrypted (BitLocker on Windows, FileVault on macOS) and recovery keys are escrowed.
• Local administrator passwords are unique and rotated with Windows LAPS, and everyday users aren't local admins.
• Windows updates are managed with update rings or feature update policies, and devices that haven't checked in for 30+ days are investigated or retired.
• Personal phones that access company data have app protection policies, even if they aren't enrolled.

Our Intune compliance baseline for SMBs covers the settings and rollout order in detail.

3. Email (Exchange Online and Defender for Office 365)

• Every sending domain has SPF, DKIM signing is enabled, and a DMARC record exists and is moving toward enforcement. See SPF, DKIM and DMARC for Microsoft 365.
• Automatic forwarding to external addresses is blocked or tightly controlled in the outbound spam policy. Attackers use forwarding rules to keep reading mail after a password reset.
• No mailbox has inbox rules that forward, redirect or delete mail in suspicious ways, especially admin and finance mailboxes.
• If Defender for Office 365 is licensed, the Standard or Strict preset security policies are applied, including Safe Links and Safe Attachments.
• Mailbox auditing is on and unified audit log ingestion is enabled (both are on by default for most tenants, but worth confirming).
• SMTP AUTH is disabled for the organization and allowed only on the specific mailboxes that need it.

4. SharePoint, OneDrive and Teams

• The organization-level external sharing setting is no more permissive than the business needs, and sensitive sites are set more strictly than the default. See manage sharing settings.
• The default link type is Specific people or People in your organization, not Anyone, and any "Anyone" links expire.
• Guest access to sites expires or is reviewed on a schedule.
• Teams external access (chat with other organizations) and guest access match policy, and anonymous users can't bypass the meeting lobby.
• Teams and Microsoft 365 groups have at least two owners, and ownerless groups are cleaned up.

Details and recommended settings: safe external sharing and guest access.

5. Threat protection (Microsoft Defender)

• Every Windows and macOS device is onboarded to Defender for Endpoint or Defender for Business, and onboarding coverage matches the Intune device count.
• Tamper protection is on, attack surface reduction rules are at least in audit mode, and real-time protection can't be turned off by users.
• If there's on-premises Active Directory and the license allows it, Defender for Identity sensors are installed on domain controllers.
• Alerts go somewhere a person reads them, with an agreed response time.
• Microsoft Secure Score is reviewed regularly, as a to-do list rather than a target. See improving Secure Score without breaking users.

6. Data protection and audit (Microsoft Purview)

• Audit logging is on, and the team knows how long logs are kept on the tenant's license. See auditing solutions in Microsoft Purview.
• Sensitivity labels exist, are published to the people who need them and are actually used on sensitive content.
• Data loss prevention policies cover the data types that matter to the business (for example, financial or health information), starting in test mode.
• Retention policies reflect legal and business requirements, rather than keeping everything forever or nothing at all.
• Before a Microsoft 365 Copilot rollout, oversharing has been reviewed. See getting a tenant ready for Copilot.

7. Licensing and usage

• Purchased licenses are assigned. Unassigned seats are either planned for or reduced at renewal.
• Licenses aren't assigned to disabled or long-inactive accounts.
• Security features the tenant already pays for are switched on. Business Premium and E5 tenants often own capabilities (Defender, Intune, Conditional Access) that were never configured. See Business Premium vs E3 vs E5.
• Usage reports show which workloads are adopted, which informs where security effort pays off first.

How to prioritize what you find

A long list of findings is not a plan. Sort them before you present them:

1. Fix this week: anything that lets an attacker in with just a password, such as admins without MFA, legacy authentication allowed, or external forwarding open.
2. Plan this quarter: controls that need testing and communication, such as device compliance enforcement, phishing-resistant MFA and sharing changes.
3. Tidy up: hygiene items like stale accounts, unused apps and unassigned licenses.

For each item, note who it affects and how you'll roll it out. Most "we can't turn that on" objections are really about rollout, and report-only modes, pilot groups and clear communication answer them.

How M365Assessments helps

M365Assessments runs much of this checklist for you. The Core module reads identity (Entra ID), device (Intune) and licensing configuration with read-only Microsoft Graph permissions, and early-access modules add Exchange Online, Defender, Purview, SharePoint and OneDrive, and Teams. Each run produces a prioritized, plain-English report with a recommended fix for every finding, and run history shows what changed since last time. See how it works, the modules explained, or the exact permissions each module requests.