CIS Microsoft 365 Foundations Benchmark

Administrative accounts that are cloud-only ensure that the compromise of on-premises environments does not extend to Microsoft 365. These accounts should not be synced from an on-premises directory using AD Connect or similar tools.

If an on-premises Active Directory is compromised, accounts synced to Entra ID are also at risk. Cloud-only administrative accounts isolate the cloud environment from on-premises attacks and ensure administrative access remains available even if on-premises infrastructure fails.

Administrators will need separate cloud-only accounts for M365 administration, which must be managed independently of on-premises AD. This may increase the number of credentials administrators must manage.

From the Entra Admin Center:

1. Navigate to Microsoft Entra admin center > Identity > Users > All users.
2. Filter by User type = Member and sort by On-premises sync enabled.
3. For each user with an administrative role assigned, ensure On-premises sync enabled is No.

Using Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "User.Read.All","RoleManagement.Read.Directory"
$adminRoles = Get-MgDirectoryRole
foreach ($role in $adminRoles) {
  $members = Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id
  foreach ($member in $members) {
    $user = Get-MgUser -UserId $member.Id `
      -Property DisplayName,OnPremisesSyncEnabled
    if ($user.OnPremisesSyncEnabled -eq $true) {
      Write-Host "FAIL: $($user.DisplayName) in $($role.DisplayName) is synced"
    }
  }
}

Create dedicated cloud-only administrative accounts in Microsoft Entra ID:

1. Navigate to Microsoft Entra admin center > Identity > Users > Create new user.
2. Create a new cloud-only account for administrative purposes.
3. Assign the appropriate administrative roles to the new account.
4. Remove administrative roles from any synced on-premises accounts.

By default, Microsoft 365 does not prevent synced accounts from holding administrative roles.

Emergency access accounts (also known as "break glass" accounts) are highly privileged accounts not assigned to specific individuals. They are limited to emergency scenarios where normal administrative accounts cannot be used — for example, if all administrators are locked out due to a Conditional Access misconfiguration.

Without emergency access accounts, an organization may be permanently locked out of their Microsoft 365 tenant if all administrator accounts are compromised, disabled, or blocked by Conditional Access. Two accounts are recommended for redundancy.

Emergency access accounts require special handling: extremely long and complex passwords stored securely (e.g., in a safe), excluded from Conditional Access policies, and monitored with alerts on any sign-in activity.

From the Entra Admin Center:

1. Navigate to Identity > Users > All users.
2. Verify at least two accounts exist that are: cloud-only, assigned Global Administrator, excluded from all Conditional Access policies, and not used for day-to-day administration.

1. Create two cloud-only user accounts with long, random passwords (minimum 16 characters).
2. Assign the Global Administrator role to both accounts.
3. Exclude these accounts from all Conditional Access policies.
4. Store credentials securely (e.g., split knowledge in a physical safe).
5. Monitor sign-in activity with alerts for any use of these accounts.

By default, no emergency access accounts are configured.

The Global Administrator role grants unrestricted access to all services and settings in Microsoft 365. The number of users assigned this role should be minimized — ideally between two and four (including emergency access accounts).

The principle of least privilege dictates that only the minimum number of administrators should hold the most powerful role. More Global Admins increases the attack surface and risk of account compromise. Use specific admin roles (e.g., Exchange Administrator, SharePoint Administrator) where possible.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
$globalAdminRole = Get-MgDirectoryRole | Where-Object {
  $_.DisplayName -eq "Global Administrator"
}
$members = Get-MgDirectoryRoleMember -DirectoryRoleId $globalAdminRole.Id
Write-Host "Global Administrators: $($members.Count)"
# Result should be between 2 and 4

Review all Global Administrator assignments and reassign to more specific admin roles where possible. Keep between 2–4 Global Admins (including emergency access accounts).

By default, group owners can approve requests to join their groups. This setting controls whether additional approval workflows are required when users request to join a group.

When group membership is used to control access to resources, unrestricted group owner approval can lead to unauthorized access. Requiring additional oversight for group membership changes ensures proper authorization.

Navigate to Microsoft Entra admin center > Identity > Groups > General settings and review group membership approval settings.

Configure group access reviews or implement approval workflows using Entra ID Governance entitlement management.

Guest users should have limited access to directory properties and memberships. This setting restricts guest users to limited access — they can view only their own profile and explicitly shared resources.

Unrestricted guest access allows external users to enumerate users, groups, and other directory objects, potentially exposing sensitive organizational structure to non-employees.

Navigate to Microsoft Entra admin center > Identity > External Identities > External collaboration settings.

Verify Guest user access restrictions is set to "Guest user access is restricted to properties and memberships of their own directory objects (most restrictive)".

1. Navigate to External Identities > External collaboration settings.
2. Set Guest user access restrictions to the most restrictive option.
3. Click Save.

A Conditional Access policy should require MFA for all users. This significantly reduces the risk of account compromise from credential-based attacks such as password spray, phishing, and brute force.

Passwords alone are insufficient. Requiring a second factor ensures that even if a password is compromised, the attacker cannot access the account without the additional factor.

1. Navigate to Microsoft Entra admin center > Protection > Conditional Access > Policies.
2. Identify a policy that targets All users (excluding emergency access accounts).
3. Verify the Grant control requires Require multifactor authentication.
4. Ensure the policy state is On.

1. Navigate to Protection > Conditional Access > Create new policy.
2. Under Users, select All users. Under Exclude, add emergency access accounts.
3. Under Cloud apps, select All cloud apps.
4. Under Grant, select Require multifactor authentication.
5. Set policy to On and save.

Configure a Conditional Access policy for administrative users that enforces a maximum sign-in frequency (e.g., 4 hours) and disables persistent browser sessions to force periodic re-authentication.

Persistent admin sessions increase the window of opportunity for session hijacking. Frequently re-authenticating administrators limits the duration a compromised session token remains valid.

1. Navigate to Protection > Conditional Access > Policies.
2. Identify a policy targeting administrative roles.
3. Verify Session controls set Sign-in frequency to ≤ 4 hours and Persistent browser session to Never persistent.

Create or modify a Conditional Access policy targeting all Directory Roles, setting session controls for sign-in frequency and non-persistent browser sessions.

Legacy authentication protocols (e.g., IMAP, POP3, SMTP, ActiveSync with basic auth) do not support MFA and are common vectors for brute force and password spray attacks. Block legacy authentication for all users via Conditional Access.

Legacy protocols bypass MFA entirely, making them the preferred attack vector. Microsoft reports that more than 99% of password spray attacks and more than 97% of credential stuffing attacks use legacy authentication.

1. Navigate to Protection > Conditional Access > Policies.
2. Locate a policy with Conditions > Client apps set to Exchange ActiveSync clients and Other clients.
3. Verify the Grant control is Block access.

1. Create a new Conditional Access policy targeting All users.
2. Under Conditions > Client apps, select Exchange ActiveSync clients and Other clients.
3. Under Grant, select Block access.
4. Enable the policy.

Configure regular access reviews for guests using Entra ID Governance. Reviews should occur at least quarterly and automatically remove access if the review is not completed.

Guest accounts often accumulate over time and retain access long after their business need has ended. Regular reviews ensure stale guest accounts are identified and removed.

Navigate to Identity Governance > Access Reviews and verify at least one review targeting guest users is configured with a recurring schedule.

1. Navigate to Identity Governance > Access Reviews > New access review.
2. Scope to Guest users only, set frequency to Quarterly.
3. Set auto-apply results and configure Remove access if reviewers don't respond.

Set organizational passwords to never expire. NIST SP 800-63B guidance recommends against periodic password changes as they lead to weaker passwords. Combined with MFA and conditional access, non-expiring passwords provide better security.

Requiring periodic password changes encourages users to choose weak, predictable passwords or make trivial modifications to existing passwords. Modern guidance focuses on long, unique passwords protected by MFA rather than frequent rotation.

Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Select-Object Id, PasswordValidityPeriodInDays
# PasswordValidityPeriodInDays should be 2147483647 (never expire)

Navigate to Microsoft 365 admin center > Settings > Org settings > Security & privacy > Password expiration policy. Check "Set passwords to never expire".

Disable sharing calendar details with external users to prevent disclosure of meeting subjects, attendee lists, and organizational activity patterns to unauthorized parties.

Leaving Calendar Details Sharing with External Users enabled when it is not required unnecessarily expands the attack surface. An attacker could leverage this feature to gain unauthorized access or escalate privileges on the Microsoft 365 cloud platform.

Connect-ExchangeOnline
Get-SharingPolicy | Where-Object {$_.Default -eq $true} |
  Format-List Name, Domains, Enabled
# Verify no external domains are configured or sharing is disabled

Navigate to Exchange admin center > Organization > Sharing and modify the default sharing policy to remove external calendar sharing or restrict to Free/Busy only.

Disable the ability for users to consent to third-party applications accessing organizational data. All app consents should go through an administrator approval process.

Illicit consent grant attacks trick users into granting permissions to malicious third-party apps. By restricting user consent, organizations prevent unauthorized data exposure through phishing-based OAuth consent attacks.

Navigate to Microsoft Entra admin center > Applications > Enterprise applications > Consent and permissions > User consent settings.

Verify "Do not allow user consent" is selected.

1. Navigate to Enterprise applications > Consent and permissions.
2. Under User consent settings, select "Do not allow user consent".
3. Configure the Admin consent workflow for users to request app access through administrators.

Configure Exchange Online to tag emails from external senders with a visual indicator (e.g., "[EXTERNAL]" prepended to subject or an external sender callout in Outlook) to help users identify potential phishing emails.

Failure to external Senders are Identified with a Warning Tag may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Connect-ExchangeOnline
Get-ExternalInOutlook | Format-List Enabled, AllowList
# Enabled should be True

Set-ExternalInOutlook -Enabled $true

Review mail transport rules to ensure no rules bypass spam filtering or other protections for specific sender domains. Domain-based whitelisting allows attackers to spoof trusted domains and bypass security controls.

Failure to mail Transport Rules Do Not Whitelist Specific Domains may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Get-TransportRule | Where-Object {
  $_.SetSCL -eq -1 -or
  $_.SetHeaderName -eq "X-MS-Exchange-Organization-SkipSafeLinksProcessing"
} | Format-List Name, State, SenderDomainIs

Remove or modify any transport rules that whitelist domains by setting SCL to -1 or skipping filtering. Use the allow lists in anti-spam policies only when strictly necessary.

DomainKeys Identified Mail (DKIM) allows the receiving mail system to verify that messages were not tampered with in transit and originated from the authorized mail system for that domain.

Failure to dKIM is Enabled for All Exchange Online Domains may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Connect-ExchangeOnline
Get-DkimSigningConfig | Format-List Domain, Enabled
# All domains should show Enabled = True

1. Publish DKIM CNAME records for each domain in DNS.
2. Enable DKIM signing: Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

Sender Policy Framework (SPF) DNS records should be published for all domains used for email. SPF records authorize specific mail servers to send email on behalf of the domain.

Failure to sPF Records are Published for All Exchange Domains may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

# For each domain:
nslookup -type=TXT yourdomain.com
# Should include: v=spf1 include:spf.protection.outlook.com -all

Add a TXT record to DNS: v=spf1 include:spf.protection.outlook.com -all

Use -all (hard fail) rather than ~all (soft fail) for strict enforcement.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM to provide domain-level email authentication. A DMARC policy instructs receiving servers on how to handle messages that fail SPF/DKIM checks.

Failure to dMARC Records are Published for All Domains may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

nslookup -type=TXT _dmarc.yourdomain.com
# Should include: v=DMARC1; p=reject; (or p=quarantine at minimum)

Add a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100

Start with p=none for monitoring, then progress to p=quarantine and finally p=reject.

Modern authentication (based on OAuth 2.0) must be enabled for Exchange Online. This is required for MFA and Conditional Access to function with mail clients.

Without Modern Authentication for Exchange Online enabled, the Microsoft 365 cloud platform may lack critical protections against known attack vectors. Enabling this control mitigates risk and aligns the deployment with industry-accepted security baselines.

Get-OrganizationConfig | Format-List OAuth2ClientProfileEnabled
# Should be True

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Configure SharePoint Online external sharing to allow sharing only with authenticated external guests (at minimum). Disable anonymous sharing links unless a specific business need exists.

Failure to sharePoint External Sharing is Managed may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Connect-SPOService -Url https://yourtenant-admin.sharepoint.com
Get-SPOTenant | Format-List SharingCapability
# Should be ExistingExternalUserSharingOnly or ExternalUserSharingOnly
# Should NOT be ExternalUserAndGuestSharing (Anyone links)

Set-SPOTenant -SharingCapability ExternalUserSharingOnly

This restricts sharing to authenticated guests who must sign in before accessing shared content.

Configure a maximum expiration period for external sharing links (guest access links). Links should expire within 30 days or fewer.

Misconfiguration of Expiration of External Sharing Links can lead to security gaps that may be exploited by attackers. A properly configured Microsoft 365 cloud platform reduces exposure to both known vulnerabilities and configuration drift.

Get-SPOTenant | Format-List RequireAnonymousLinksExpireInDays,
  ExternalUserExpireInDays, ExternalUserExpirationRequired

Set-SPOTenant -ExternalUserExpireInDays 30 -ExternalUserExpirationRequired $true

OneDrive sharing settings should be at least as restrictive as the SharePoint tenant-level settings. Restrict OneDrive sharing to existing external users or internal only.

Unrestricted OneDrive Content Sharing could allow unauthorized users or processes to perform actions beyond their intended scope. Applying least-privilege principles to the Microsoft 365 cloud platform is essential for defense in depth.

Get-SPOTenant | Format-List OneDriveSharingCapability
# Should be ExistingExternalUserSharingOnly or Disabled

Set-SPOTenant -OneDriveSharingCapability ExistingExternalUserSharingOnly

Enable the ability for users to report suspicious messages in Teams, similar to the report message functionality in Outlook. This feature should route reports to the security team for review.

Failure to users Can Report Security Concerns in Teams may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Navigate to Microsoft Teams admin center > Messaging policies > Global (Org-wide default). Verify Report a security concern is set to On.

In the Teams admin center, edit the Global messaging policy and enable Report a security concern.

Disable anonymous (unauthenticated) users from joining Teams meetings. All attendees should be required to authenticate before joining.

Anonymous join allows unidentified users to participate in meetings where sensitive information may be discussed. Requiring authentication ensures accountability and allows meeting organizers to control access.

Connect-MicrosoftTeams
Get-CsTeamsMeetingPolicy -Identity Global |
  Format-List AllowAnonymousUsersToJoinMeeting
# Should be False

Set-CsTeamsMeetingPolicy -Identity Global `
  -AllowAnonymousUsersToJoinMeeting $false

Configure the default meeting policy so only organizers and co-organizers can present, preventing external attendees or unintended users from sharing content.

Failure to only Organizers and Co-organizers Can Present may leave the Microsoft 365 cloud platform vulnerable to attack or non-compliant with organizational security policies. This control helps establish a consistent, hardened configuration baseline.

Get-CsTeamsMeetingPolicy -Identity Global |
  Format-List DesignatedPresenterRoleMode
# Should be OrganizerOnlyUserOverride

Set-CsTeamsMeetingPolicy -Identity Global `
  -DesignatedPresenterRoleMode OrganizerOnlyUserOverride

External access controls communication with users outside the organization. This should be restricted to specific allowed domains rather than open to all external organizations.

Unrestricted external access allows any external Teams/Skype user to message internal users, enabling social engineering and phishing via Teams chat.

Get-CsTenantFederationConfiguration |
  Format-List AllowFederatedUsers, AllowedDomains
# AllowFederatedUsers should be True only with specific AllowedDomains
# Or AllowFederatedUsers should be False

Navigate to Teams admin center > Users > External access. Set to "Allow only specific external domains" and add required domains.

Safe Attachments scans email attachments for malware by detonating them in a virtual environment. Enable this with a Block or Dynamic Delivery action.

Traditional anti-malware may miss zero-day threats. Safe Attachments uses sandbox detonation to detect previously unknown malware in attachments before they reach user mailboxes.

Connect-ExchangeOnline
Get-SafeAttachmentPolicy | Format-List Name, Enable, Action
# Should have at least one policy with Enable=True and Action=Block or DynamicDelivery

Navigate to Microsoft Defender portal > Policies & rules > Threat policies > Safe Attachments. Create or edit a policy with action set to Block.

Extend Safe Attachments protection to files in SharePoint, OneDrive, and Teams. Malicious files detected are blocked from being opened or downloaded.

Without Safe Attachments for SharePoint, OneDrive, and Teams enabled, the Microsoft 365 cloud platform may lack critical protections against known attack vectors. Enabling this control mitigates risk and aligns the deployment with industry-accepted security baselines.

Get-AtpPolicyForO365 | Format-List EnableATPForSPOTeamsODB
# Should be True

Set-AtpPolicyForO365 -EnableATPForSPOTeamsODB $true

Safe Links provides URL scanning and rewriting of inbound email messages and time-of-click verification of URLs in email, Teams, and Office documents.

Without Safe Links Policy enabled, the Microsoft 365 cloud platform may lack critical protections against known attack vectors. Enabling this control mitigates risk and aligns the deployment with industry-accepted security baselines.

Get-SafeLinksPolicy | Format-List Name, EnableSafeLinksForEmail,
  EnableSafeLinksForTeams, EnableSafeLinksForOffice,
  ScanUrls, DeliverMessageAfterScan, TrackClicks

Navigate to Microsoft Defender portal > Policies & rules > Threat policies > Safe Links. Create or edit a policy enabling URL scanning for email, Teams, and Office applications.

Configure anti-phishing policies with user and domain impersonation protection enabled. This protects against attackers impersonating key users (C-suite, finance) or trusted domains.

Business email compromise (BEC) attacks frequently use impersonation of executives or trusted partners. Impersonation protection uses mailbox intelligence and AI to detect these attempts.

Get-AntiPhishPolicy | Format-List Name, Enabled,
  EnableTargetedUserProtection, TargetedUsersToProtect,
  EnableTargetedDomainsProtection, EnableOrganizationDomainsProtection,
  EnableMailboxIntelligence, EnableMailboxIntelligenceProtection

1. Navigate to Microsoft Defender portal > Anti-phishing.
2. Enable user impersonation protection and add key users (executives, finance).
3. Enable domain impersonation protection for organizational and custom domains.
4. Enable mailbox intelligence and mailbox intelligence protection.
5. Set actions to quarantine for impersonation detections.

The unified audit log records user and admin activity across Microsoft 365 services. This must be enabled to capture exchange, SharePoint, Entra ID, and other service events for security monitoring and incident response.

Without audit logging, security teams cannot investigate incidents, detect suspicious behavior, or satisfy compliance requirements that mandate activity logging.

Connect-ExchangeOnline
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
# Should be True

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Mailbox auditing captures mailbox access operations (read, send, delete, move) for owner, delegate, and admin logon types. While enabled by default since 2019, verify this setting has not been disabled.

Without Mailbox Auditing for All Users enabled, the Microsoft 365 cloud platform may lack critical protections against known attack vectors. Enabling this control mitigates risk and aligns the deployment with industry-accepted security baselines.

Get-OrganizationConfig | Format-List AuditDisabled
# Should be False
# Also check individual mailboxes:
Get-Mailbox -ResultSize Unlimited | Where-Object {$_.AuditEnabled -eq $false} |
  Select-Object DisplayName, AuditEnabled

Set-OrganizationConfig -AuditDisabled $false

Data Loss Prevention (DLP) policies help prevent inadvertent or intentional sharing of sensitive information. At minimum, configure DLP policies for common sensitive data types (PII, financial data, health records).

Without DLP policies, users may inadvertently share sensitive data such as credit card numbers, Social Security numbers, or health information via email, Teams, or SharePoint, violating regulatory requirements.

Navigate to Microsoft Purview compliance portal > Data loss prevention > Policies. Verify at least one DLP policy exists and is enabled, covering Exchange, SharePoint, OneDrive, and Teams.

1. Navigate to Data loss prevention > Policies > Create policy.
2. Select a template (e.g., U.S. PII, Financial Data) or create a custom policy.
3. Apply to Exchange, SharePoint, OneDrive, Teams, and Devices as appropriate.
4. Configure policy tips to educate users and set actions for violations.
5. Enable the policy in enforcement mode.