What's New - CIS Microsoft 365 Foundations Benchmark v7.0.0

If v6.0.0 was sharpening, v7.0.0 is a re-foundation. The Center for Internet Security released version 7.0.0 of the Microsoft 365 Foundations Benchmark on 19th May 2026. This is the largest update to the benchmark in over a year, with 21 new controls, around 55 controls updated, and a structural overhaul that introduces a new identifier scheme and rehomes 12 recommendations from the Azure Foundations Benchmark.

For anyone managing a Microsoft 365 tenant, this is a release worth setting time aside for. Below I'll walk through what's changed and call out the top three new controls every Microsoft 365 administrator should be implementing.

What is the CIS Microsoft 365 Benchmark?

CIS (Center for Internet Security) benchmarks are consensus-driven security configuration guidelines built by industry practitioners. The CIS Microsoft 365 Foundations Benchmark (v7.0.0) provides a prescriptive set of recommendations for hardening a Microsoft 365 tenant across Entra ID, Exchange Online, SharePoint, Teams, Purview, Intune, and Microsoft Fabric.

Each recommendation is mapped to a Level 1 (core baseline) or Level 2 (may affect functionality) profile, and most can be audited and remediated via PowerShell or Microsoft Graph.

What's changed in v7.0.0?

Version 7.0.0 introduces 21 new controls, around 55 updated controls, and 2 removed controls compared with v6.0.1. Two structural changes are also worth flagging up front:

• (L1) and (L2) prefix tags have been removed from control titles. Profile levels still exist, you'll find them under each recommendation's Profile Applicability section instead of within the title.
• Global Recommendation IDs (GRIDs) have been introduced. Each recommendation now carries a unique GRID alongside its numbered identifier, making cross-benchmark mapping consistent and stable across future benchmark updates.

New controls

Twelve of the 21 new recommendations have been relocated from the CIS Microsoft Azure Foundations Benchmark. This brings identity, Conditional Access, and password reset controls under the M365 umbrella where they more naturally belong. Here's the breakdown by service area.

Microsoft Defender

2.4.5 Ensure 'AIR' remediation is enabled (L1)

Automated Investigation and Response (AIR) clusters malicious messages and produces remediation actions. With auto-remediation enabled, identified threats are contained immediately without waiting for SecOps approval. This closes the window during which users can interact with malicious content. This control requires a Defender for Office 365 plan 2 license (which is included in the Microsoft 365 E5 license).

Microsoft Purview

3.2.3 Ensure DLP policies are published for Copilot users (L1)

Requires at least one DLP policy scoped to Microsoft 365 Copilot and Copilot Chat interactions. Without it, there is no technical control stopping Copilot from surfacing PII, financial data, or other sensitive content in AI-generated responses to users who would not otherwise have direct access to the source material.

Microsoft Entra (Groups)

Three new controls tighten group governance and self-service:

• 5.1.3.2 Ensure 'Restrict user ability to access groups features in My Groups' is set to 'Yes' (L1)
• 5.1.3.3 Ensure 'Owners can manage group membership requests in My Groups' is set to 'No' (L1)
• 5.1.3.4 Ensure 'Users can create Microsoft 365 groups in Azure portals, API or PowerShell' is set to 'No' (L1)

Microsoft Entra (Enterprise apps)

A new 5.1.5 sub-section addresses application credential hygiene. This arguably is the most impactful cluster in this release:

• 5.1.5.3 Ensure password addition is blocked for applications (L2)
• 5.1.5.4 Ensure password lifetime for applications does not exceed 180 days (L2)
• 5.1.5.5 Ensure new application passwords are system-generated (L2)
• 5.1.5.6 Ensure maximum certificate lifetime for applications does not exceed 180 days (L2)

Together these force every new application towards certificate-based authentication or workload identity federation and put a hard expiry on existing credentials.

Microsoft Entra (Conditional Access)

Five new Conditional Access controls expand coverage:

• 5.2.2.13 Ensure that periodic reauthentication is required for all users (L1)
• 5.2.2.14 Ensure trusted 'named locations' are defined and applied (L2)
• 5.2.2.15 Ensure exclusionary geographic access controls are utilized (L1)
• 5.2.2.16 Ensure Token Protection is enforced for session tokens (L2)
• 5.2.2.17 Ensure authentication transfer is blocked (L1)

Microsoft Entra (Authentication methods)

• 5.2.3.8 Ensure that Account 'Lockout threshold' is '10' or less (L1)
• 5.2.3.9 Ensure that Account 'Lockout duration in seconds' is at least 60 seconds (L1)
• 5.2.3.10 Ensure Microsoft Authenticator on companion applications is disabled (L1)

Microsoft Entra (Password reset)

Four new SSPR controls round out the password reset story:

• 5.2.4.2 Ensure that 2 methods are required for password reset (L1)
• 5.2.4.3 Ensure SSPR registration and authentication re-confirmation are required (L1)
• 5.2.4.4 Ensure that users are notified on password resets (L1)
• 5.2.4.5 Ensure all admins are notified when other admins reset their password (L1)

Exchange Online

6.3.2 Ensure the ability to add personal email accounts and calendars is disabled (L1)

Blocks users from connecting personal Outlook.com, Gmail, or Yahoo accounts inside New Outlook for Windows and Outlook on the web.

Removed controls

Two controls have been retired in this release:

• 5.1.3.1 Ensure a dynamic group for guest users is created

The dynamic guest group recommendation has been retired. With guest access reviews (5.3.2) and the new My Groups controls, the dynamic group recommendation is no longer required for guest governance.

• 7.3.2 Ensure OneDrive sync is restricted for unmanaged devices

Now handled through Conditional Access App Control and Intune device compliance policies rather than the standalone OneDrive admin setting, so the control has been removed as redundant.

Updated controls

With around 55 controls updated, most changes are PowerShell audit procedure additions to bring more recommendations into the Automated profile. The substantive changes worth flagging:

Profile level changes (L2 to L1):

• 4.1 Ensure devices without a compliance policy are marked 'not compliant'
• 4.2 Ensure device enrollment for personally owned devices is blocked by default

This is a meaningful elevation for Intune. Both controls were previously discretionary; they are now core baseline expectations.

Tightening:

• 5.1.4.2 Ensure the maximum number of devices per user is limited

Recommended limit reduced from 20 to 10 devices per user.

Loosening (worth being aware of):

• 5.3.4 / 5.3.5 PIM approval controls

Required approvers count has been changed from 2 to 1 for Global Administrator and Privileged Role Administrator activations. This is a noticeable relaxation; if your policies require two approvers, the benchmark no longer mandates it, but you may want to keep the stricter setting.

• 5.2.3.1 Ensure Microsoft Authenticator is configured to protect against MFA fatigue

The number-matching requirement has been removed from the control. Worth verifying your stance on Authenticator features going forward.

Top 3 new controls to implement

Of the 21 new recommendations, three stand out as high-impact additions that close real, exploited attack paths in modern tenants. All three address the token-theft and session-hijacking threat landscape that has dominated cloud identity attacks over the past 18 months.

1. 5.2.2.17 Ensure authentication transfer is blocked (L1)

Authentication transfer is a relatively new Microsoft feature that lets users seamlessly hand off their authenticated state from one device to another. The classic example: a user signed into Outlook desktop sees a QR code, scans it with their phone, and is now signed into Outlook mobile with no password or no MFA prompt.

It's a slick user experience. It's also a token theft enabler. A threat actor with access to a victim's desktop session can use authentication transfer to silently establish their own authenticated session on a different device, completely bypassing device compliance checks and any per-device Conditional Access policies. From that point on the attacker has a parallel authenticated session that doesn't require any additional credential compromise to maintain.

The new control recommends a Conditional Access policy that blocks the authentication transfer flow tenant-wide.

Why prioritise this one:

• It's a single Conditional Access policy and applies to all users.
• The feature is recent enough that most administrators haven't heard of it, let alone considered the threat model. This means most tenants are currently exposed by default.
• It pairs naturally with Token Protection (the next control below): one stops the token being silently transferred, the other stops it being usable if stolen.

Audit and remediation summary:

Create a Conditional Access policy targeting All users (excluding break-glass accounts), All resources, with the condition Authentication flows set to Configure = Yes and Authentication transfer checked, and the grant control set to Block access.

Watch-outs:

• As with every CA policy, exclude break-glass accounts before enabling.
• Pilot in report-only mode first to identify any internal use of the QR-code sign-in flow you weren't aware of.
• Users who currently use the desktop-to-mobile QR sign-in will need to sign in to mobile clients interactively from now on, you should communicate the change before flipping the switch.

2. 5.2.2.16 Ensure Token Protection is enforced for session tokens (L2)

Token theft has been the standout cloud identity threat vector of the past 18 months. Once an attacker exfiltrates a valid session token they bypass MFA entirely, because the token already represents an MFA-completed authentication.

Token Protection is a Conditional Access session control that ties session tokens cryptographically to the device that issued them. With it enforced, a stolen Primary Refresh Token (PRT) is useless on any device other than the one it was bound to.

The control recommends enforcing Token Protection for the three highest-value workloads: Office 365 Exchange Online, Office 365 SharePoint Online, and Microsoft Teams Services.

Why prioritise this one:

• It directly defeats the most common cloud identity attack chain in 2026.
• It's a single Conditional Access policy and applies to all users.
• Token Protection is generally available for Windows, in preview for macOS and iOS.

Watch-outs:

• Token Protection currently supports native applications only. Browser-based access is not in scope and is not covered by this control.
• Pilot this in report-only mode first and exclude break-glass accounts (as with every Conditional Access policy).
• Review Microsoft's known-limitations list before broad enforcement as there are a few specific application scenarios that aren't yet supported.

3. 6.3.2 Ensure the ability to add personal email accounts and calendars is disabled (E3/E5 Level 1)

This control closes a quietly significant data exfiltration and malware ingress path. New Outlook for Windows and Outlook on the web both allow users to add personal email accounts (Outlook.com, Gmail, Yahoo etc.) and personal calendars alongside their corporate mailbox.

Personal accounts aren't subject to Safe Links, Safe Attachments, DLP, audit logging, or any other tenant-level protection. The corporate mailbox and the personal one sit side by side in the same client. This creates two problems.

• The first is side-channel exfiltration. A user (malicious or careless) can drag-and-drop content from the corporate mailbox into the personal account in seconds, completely outside any DLP control.
• The second is bypass of inbound filtering. A phishing payload sent to the personal account renders in the same Outlook client the user trusts for corporate mail, with none of the protective wrapping applied to tenant-bound mail.

The control sets PersonalAccountsEnabled and PersonalAccountCalendarsEnabled to False on the default OWA mailbox policy.

Watch-outs:

• The control applies only to New Outlook for Windows and Outlook on the web. Classic Outlook for Windows, Outlook for Mac, and Outlook mobile are not in scope and need to be handled separately if broader coverage is required.
• OWA mailbox policy changes can take up to 60 minutes to propagate.
• Users who have previously added a personal account will see it disabled with a prompt to remove it. Expect a small ticket spike on the day of rollout. Communicate the change before flipping the switch.

In summary

Version 7.0.0 is the most consequential M365 benchmark release since v4.0.0. The structural changes, GRIDs, the title cleanup, and the absorption of 12 Azure-side identity controls make this a benchmark that finally treats the Microsoft 365 control surface as one estate rather than several. If your tenants are already aligned to v6.0.1, there is a substantial uplift from the previous baseline.

Need additional support? 

OneAdvanced's relationship with Microsoft goes back over 30 years, over which our Digital Workplace experts have helped numerous organisations digitally transform and embrace a better way of working. Get in touch with our team today to see how we can help!