Securing Microsoft 365: Checklist for Entra ID, Exchange, SharePoint, and Teams

In the SCuBA project, CISA publishes secure baseline configurations for Microsoft 365. For US federal agencies, the mandatory requirements (SHALL) are binding through BOD 25-01; CISA makes the baselines available to other organizations as a reference. The baselines assume at least a Microsoft 365 E3 license and only name licenses that go beyond it. With ScubaGear, CISA provides a free tool that checks a tenant against the baselines. Items from the baselines show the identifier, such as MS.AAD.1.1, and whether the baseline requires the item (shall) or recommends it (should); items without an identifier come from Microsoft Learn or are TOMORIS recommendations.

This checklist is a TOMORIS recommendation based on the CISA baselines; not every item suits every company. Test changes in advance so that you do not lock anyone out. Multifactor authentication and Conditional Access are covered in detail in the separate checklist "Introducing MFA in Microsoft 365", and SPF, DKIM, and DMARC in the email security guide.

Microsoft recommends blocking sign-ins with legacy protocols because they do not support multifactor authentication. According to Microsoft's analysis, more than 97% of credential stuffing attacks and more than 99% of password spray attacks use such protocols.

• Legacy authentication blocked (MS.AAD.1.1, shall).
• Phishing-resistant MFA for all users (MS.AAD.3.1, shall), such as device-bound passkeys, FIDO2 security keys, Windows Hello for Business, or certificate-based authentication; as a minimum, MFA for all users, for example as long as phishing-resistant methods are not yet possible (MS.AAD.3.2, shall); always phishing-resistant for highly privileged roles (MS.AAD.3.6, shall).
• SMS, voice call, and email one-time passcode disabled as methods (MS.AAD.3.5, shall); sign-in context shown in Microsoft Authenticator (MS.AAD.3.3, shall).
• Device code sign-in blocked (MS.AAD.3.9, should).
• High-risk users and high-risk sign-ins blocked (MS.AAD.2.1 and 2.3, shall; requires Entra ID P2).
• Passwords do not expire (MS.AAD.6.1, shall); details in the password policy.
• At least two emergency access accounts, cloud-only with a *.onmicrosoft.com domain, not synchronized, protected with a passkey (FIDO2) or certificate (Microsoft Learn).
• Without a license for Conditional Access: security defaults enabled (Microsoft Learn).

• Two to eight people with the Global Administrator role (MS.AAD.7.1, shall); Microsoft recommends fewer than five, CISA allows additional accounts, for example for emergency access.
• Finer-grained roles instead of Global Administrator for administrative tasks (MS.AAD.7.2, shall).
• Privileged accounts cloud-only, separate from on-premises Active Directory (MS.AAD.7.3, shall).
• No permanently active assignments of highly privileged roles, Global Administrator activation only with approval, alerts on assignment and activation (MS.AAD.7.4 to 7.8, shall; alert for other highly privileged roles 7.9, should; Entra ID P2 or another PAM solution).
• Only administrators register applications (MS.AAD.5.1, shall).
• User consent for applications restricted (MS.AAD.5.2, shall); Microsoft recommends allowing it at most for apps from verified publishers.
• Admin consent workflow configured (MS.AAD.5.3, shall).
• Guests with restricted access to directory objects (MS.AAD.8.1, should); only people with the Guest Inviter role may invite (MS.AAD.8.2, should), only to approved domains (MS.AAD.8.3, should).
• New in v2.0.0: risky AI agents blocked (MS.AAD.9.1, shall; according to CISA with Entra ID P2 and Microsoft Agent 365 or Microsoft 365 E7).

As a baseline list of highly privileged roles, to be extended with further roles as needed, CISA names: Global Administrator, Privileged Role Administrator, User Administrator, SharePoint Administrator, Exchange Administrator, Hybrid Identity Administrator, Application Administrator, and Cloud Application Administrator.

• Automatic forwarding to external domains disabled (MS.EXO.1.1, shall): CISA implements this through the remote domain "Default", for which automatic forwarding is not allowed. In addition, select "Off – Forwarding is disabled" in the outbound spam policy: the default value "Automatic – System-controlled" behaves differently depending on the tenant.
• SPF rejecting unauthorized senders, DKIM for all domains, DMARC with p=reject (MS.EXO.2.2, 4.1, 4.2, shall; DKIM MS.EXO.3.1, should).
• SMTP AUTH disabled organization-wide (MS.EXO.5.1, shall); allowed as an exception only for individual mailboxes that demonstrably need it. If security defaults are active, SMTP AUTH is already disabled.
• Contact and calendar details not shared with all domains (MS.EXO.6.1 and 6.2, shall).
• External sender warning for messages enabled (MS.EXO.7.1, shall).
• Mailbox auditing active (MS.EXO.13.1, shall); according to Microsoft enabled by default in all organizations, but check it anyway.

If automatic forwarding is disabled, user inbox rules and administrator forwarding that redirect messages to external addresses also stop working; the sender receives a non-delivery report (Microsoft Learn).

With the Standard and Strict preset security policies, Microsoft applies recommended settings for email protection; they are practically not configurable. The Built-in protection preset policy gives users without another assignment baseline protection through Safe Attachments and Safe Links from Defender for Office 365.

• Standard preset security policy assigned to most users, Strict to selected, particularly at-risk accounts (Microsoft Learn).
• Attachments that can be executed with a click blocked, at least .exe, .cmd, and .vbe (MS.SECURITYSUITE.1.1, shall).
• Emails also scanned after delivery, malware quarantined or dropped (MS.SECURITYSUITE.1.2 and 1.3, shall).
• Attachments in SharePoint, OneDrive, and Teams scanned for malware (MS.SECURITYSUITE.1.4, should).
• Impersonation protection for particularly at-risk accounts, your own domains, and important suppliers and partners (MS.SECURITYSUITE.2.1 to 2.3, should; Defender for Office 365).
• Spam and phishing not delivered to the inbox, no allowed domains in anti-spam protection (MS.SECURITYSUITE.6.1 and 6.2, shall).
• Links in emails, Teams, and Office documents checked against blocklists, clicks logged (MS.SECURITYSUITE.7.1 and 7.3, should; Defender for Office 365).
• No IP allow lists and no safe lists (MS.SECURITYSUITE.8.1 and 8.2, should).
• Data loss prevention policy configured for your sensitive data types (MS.SECURITYSUITE.3.1, shall; 3.2 to 3.5, should).

• External sharing for SharePoint and OneDrive limited to "Existing guests" or "Only people in your organization" (MS.SHAREPOINT.1.1 and 1.2, shall), or set more openly in a deliberate and documented way.
• External sharing restricted to approved domains or security groups (MS.SHAREPOINT.1.3, shall).
• Default link "Specific people" with view permissions (MS.SHAREPOINT.2.1 and 2.2, shall).
• Where "Anyone" links are allowed: expiration after at most 30 days, view permissions only (MS.SHAREPOINT.3.1 and 3.2, shall).
• Guests using a verification code sign in again after at most 30 days (MS.SHAREPOINT.3.3, shall).

According to Microsoft, all external domains are allowed by default for external access in Teams. With an allow list, you restrict chats and meetings to the organizations you actually work with; all other domains are then blocked.

• External access only for approved domains (MS.TEAMS.2.1, shall).
• Unmanaged Teams accounts cannot contact internal users (MS.TEAMS.2.2, shall); internal users do not contact them on their own initiative (MS.TEAMS.2.3, should).
• Anonymous users cannot start meetings (MS.TEAMS.1.2, shall); anonymous participants and dial-in users wait in the lobby (MS.TEAMS.1.3 and 1.5, should).
• External participants cannot request control of shared screens (MS.TEAMS.1.1, should).
• Meeting recording according to your own rules; CISA recommends disabling it (MS.TEAMS.1.6, should).
• Teams email integration disabled (MS.TEAMS.4.1, shall).
• Only approved Microsoft, third-party, and custom apps can be installed (MS.TEAMS.5.1 to 5.3, should).

Caution with Business plans: According to Microsoft, audit logging is not enabled by default for Microsoft 365 Business Basic, Business Standard, and Business Premium and must be turned on manually.

• Unified audit log enabled (MS.SECURITYSUITE.5.1, shall) and status checked in the Microsoft Purview portal.
• Logs searchable for at least 3 months and retrievable for 12 months (MS.SECURITYSUITE.5.2, shall); according to CISA, longer than 180 days in Microsoft 365 requires E5, Microsoft Purview Suite, or the E5 eDiscovery and Audit add-on.
• Security alerts enabled and sent to a monitored mailbox or a SIEM (MS.SECURITYSUITE.4.1, shall; 4.2, should).
• Entra ID sign-in and audit logs forwarded to the team that evaluates security events (MS.AAD.4.1, shall).
• Microsoft Secure Score recorded as a baseline and reviewed regularly.
• ScubaGear assessment carried out and deviations documented with reasons.

Which of these features are included in your plan, such as Microsoft 365 Business Premium, is stated in Microsoft's service descriptions; check this before implementation. Prices and license bundles change constantly and are not part of this checklist.