CIS Benchmarks

CIS Microsoft 365 Benchmark v7.0.0: What Changed and Why Manual Controls Grew Faster Than Automated Ones

CIS Microsoft 365 Foundations Benchmark v7.0.0 contains 160 controls (143 automated, 17 manual), up from 140 controls (129 automated, 11 manual) in v6.0.1. Twenty-one controls were added and one was removed. Manual controls grew from 7.9% to 10.6% of the total, faster than automated controls grew. Microsoft has expanded the M365 attack surface (Copilot, agents, advanced Conditional Access) faster than it has exposed those surfaces through Graph API, so the share of controls that require an assessor to navigate an admin portal increased. Tooling-only assessments will see this gap widen rather than close.

Zack Jones ·
CIS BenchmarksMicrosoft 365complianceassessmentsConditional Access

The Center for Internet Security released v7.0.0 of the Microsoft 365 Foundations Benchmark this month. The headline numbers: 160 controls, up from 140 in v6.0.1. Twenty-one new controls, one removed. 143 automated, 17 manual.

The less-headlined number is the one that matters most for how organizations should think about M365 assessments going forward. Manual controls grew from 11 to 17, a 55% increase in the manual category alone. As a share of the total benchmark, manual controls went from 7.9% to 10.6%. That is the opposite of the direction tooling-vendor marketing has been promising for years, and the gap is going to keep widening for a structural reason worth understanding.

This post walks the v7.0.0 changes by theme, identifies the one removal, and explains why the manual share is growing and what that means for organizations choosing between automated tooling and practitioner-led assessment.

The Numbers

Metricv6.0.1v7.0.0Change
Total controls140160+20
Automated129143+14
Manual1117+6
Manual share7.9%10.6%+2.7 pp
New controlsn/a21n/a
Removed controlsn/a1n/a

Twenty-one additions, one removal, twenty net new controls. That is a meaningful expansion for a single version release.

What Was Added, By Theme

Copilot Governance (1 control)

3.2.3: Ensure DLP policies are published for Copilot users (Automated)

This is the first dedicated Copilot control in the benchmark. It requires Data Loss Prevention policies to cover Microsoft 365 Copilot as a location, including both prompts (user input) and grounded responses (content retrieved from SharePoint, OneDrive, and Graph connectors).

The control reflects a real gap. Most tenants have mature DLP policies for Exchange, SharePoint, OneDrive, and Teams, but zero coverage for Copilot. Without it, a user can paste a credit card number, an account ID, or a customer PII record into a Copilot prompt and no policy event will fire. Conversely, Copilot can retrieve and surface sensitive content in responses without invoking any DLP rule.

If your organization has deployed or is planning to deploy Microsoft 365 Copilot or custom agents, this is the first control you should validate. See our Copilot pre-deployment checklist for the broader governance context.

Conditional Access Expansion (5 controls)

The Conditional Access section received the largest concentrated expansion in v7.0.0:

  • 5.2.2.13: Ensure periodic reauthentication is required for all users (Automated)
  • 5.2.2.14: Ensure trusted ‘named locations’ are defined (Automated)
  • 5.2.2.15: Ensure exclusionary geographic access controls are utilized (Automated)
  • 5.2.2.16: Ensure Token Protection is enforced for session tokens (Automated)
  • 5.2.2.17: Ensure authentication transfer is blocked (Automated)

The throughline across these five is reducing the value of a stolen session. Periodic reauthentication shortens the useful life of a compromised token. Named locations and exclusionary geographic controls reduce the attack surface for adversary-in-the-middle phishing operations launched from outside expected geographies. Token Protection cryptographically binds session tokens to the device that received them, so a token stolen via Evilginx or similar tooling cannot be replayed from an attacker’s device. Authentication transfer blocking closes a more recent vector where attackers move a partial authentication session to a device they control.

Five new Conditional Access controls in a single release is unusual. It reflects how rapidly the token-theft and AiTM landscape has evolved since v6.x.

Application Credential Hardening (4 controls)

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

OAuth application secrets and certificates have been a persistent risk surface: long-lived, often shared, and frequently scoped beyond what the application needs. These four controls push tenants toward certificate-based authentication, system-generated credentials, and aggressive rotation. Combined with the existing controls on user consent and admin consent workflows, this section is now significantly stronger.

Account Lockout and Authenticator (3 controls)

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

The lockout controls codify reasonable defaults that many tenants leave at Microsoft’s higher thresholds. The Microsoft Authenticator companion application control closes a specific attack path where push notifications can be approved from a paired device the user is not actively monitoring.

Self-Service Password Reset Governance (4 controls)

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

These four are all manual. They cover the SSPR notification chain: the alert path when a password reset occurs, and the explicit notification to other admins when an administrator resets credentials. The notification chain is the early-warning mechanism for credential reset attacks where an attacker gains enough access to trigger a reset and then suppresses or absorbs the resulting notification.

All four of these are manual because the settings live in Entra ID configuration surfaces that Microsoft Graph does not fully expose. An assessor has to navigate the admin center to verify them.

Group Governance (2 controls)

  • 5.1.3.3: Ensure that ‘Owners can manage group membership requests in My Groups’ is set to ‘No’ (Manual)
  • 5.1.3.4: Ensure that ‘Users can create Microsoft 365 groups in Azure portals, API or PowerShell’ is set to ‘No’ (Automated)

Group sprawl has been a quiet contributor to permission drift for years, and groups are the primary mechanism through which Copilot inherits access to data. Restricting who can create groups and who can manage membership requests reduces both the surface area and the audit burden.

AIR and Personal Email (2 controls)

  • 2.4.5: Ensure AIR remediation is enabled (Manual)
  • 6.3.2: Ensure the ability to add personal email accounts and calendars is disabled (Automated)

Automated Investigation and Response (AIR) remediation pushes Defender’s response capability from detection to action. The personal email control closes a long-standing data exfiltration path through Outlook’s add-account feature.

What Was Removed

7.3.2 (L2): Ensure OneDrive sync is restricted for unmanaged devices (Automated, removed)

This is the only removal in v7.0.0. The control’s function, preventing OneDrive sync from devices the organization does not manage, is now better covered through Conditional Access device-compliance policies. Conditional Access can evaluate managed-device state as part of a broader policy that also gates Exchange, SharePoint, and Graph access, where the standalone OneDrive setting only covered sync. The retirement is a cleanup rather than a relaxation.

Why Manual Controls Grew Faster

The manual share of the benchmark rising from 7.9% to 10.6% is not a CIS preference change. It is a function of how Microsoft is shipping new M365 capabilities relative to how it is exposing those capabilities through Microsoft Graph.

When Microsoft adds a major capability such as Copilot governance, advanced Conditional Access patterns, or SSPR notification configuration, the configuration surfaces ship in the admin centers (Microsoft 365 admin center, Entra admin center, Purview portal) before they ship in Graph. Sometimes the API exposure follows weeks or months later. Sometimes it never arrives. CIS, meanwhile, adds controls when the security setting is available, regardless of whether it can be checked programmatically. Controls land in “manual” status until the API catches up, and many never move.

This pattern is structural. As long as Microsoft prioritizes shipping capabilities over shipping Graph coverage, the manual share of the benchmark will grow. Tooling-only assessments will see the gap widen between what they check and what the full benchmark requires.

What This Means for Assessments

Re-assessment is warranted for most organizations that completed v6.0.1 work. Twenty-one new controls is a material delta, particularly given the Copilot, Conditional Access, and SSPR additions. Tenants assessed more than 90 days ago, tenants that have deployed Copilot since their last assessment, or tenants with advanced Conditional Access in scope all justify a v7.0.0 review.

The new Conditional Access controls require Entra ID P2 in many cases. Token Protection (5.2.2.16), exclusionary geographic controls (5.2.2.15), and some named-location patterns depend on licensing the tenant may not have. Assessment scoping should validate licensing before flagging these as failed controls. The gap may be a procurement decision rather than a configuration error.

Automated tooling will be even less sufficient against v7.0.0 than it was against v6.0.1. Six new manual controls cannot be checked by any API-driven tool. They require an assessor in the admin centers. Organizations relying on tooling-only outputs for compliance evidence will have a measurably larger gap to explain than they did three months ago.

Genesis Solutions delivers CIS M365 Foundations Benchmark assessments at 100% control coverage: every automated check plus every manual review, including the new v7.0.0 controls. We deliver direct to organizations and white-label to MSPs and vCISO practices.

If your organization has completed a CIS assessment in the past and wants a v7.0.0 delta review, or if you are scoping a new assessment under the latest benchmark, contact us.


Reference: CIS Microsoft 365 Foundations Benchmark v7.0.0, Center for Internet Security

FAQ

Frequently asked

How many controls are in CIS Microsoft 365 Benchmark v7.0.0?
Version 7.0.0 contains 160 controls: 143 automated and 17 manual. This is up from 140 controls (129 automated, 11 manual) in v6.0.1. Twenty-one new controls were added and one was removed, for a net increase of 20.
What is the new Copilot control in CIS M365 v7.0.0?
Control 3.2.3 (Ensure DLP policies are published for Copilot users) is the new Copilot-specific control. It requires that Data Loss Prevention policies extend to cover Microsoft 365 Copilot as a location, including prompts and grounded responses. Without it, sensitive content can enter Copilot prompts and appear in responses without producing policy events.
What was removed in CIS M365 v7.0.0?
Control 7.3.2 (Ensure OneDrive sync is restricted for unmanaged devices) was removed in v7.0.0. The function it served is now better covered through Conditional Access policies that gate device sync based on compliance and managed device state, which is why the standalone OneDrive setting was retired.
Why are there more manual controls in v7.0.0 than v6.0.1?
Manual controls grew from 11 (7.9%) in v6.0.1 to 17 (10.6%) in v7.0.0 because Microsoft has expanded the M365 attack surface, including Copilot governance, advanced Conditional Access patterns, and password reset flows, faster than it has exposed those surfaces through Microsoft Graph API. When CIS adds a control in an area Microsoft has not yet made programmatically accessible, the control gets categorized as manual. The share of controls requiring admin portal navigation will continue to grow as new M365 capabilities ship.
Do I need to re-assess against v7.0.0 if I completed a v6.0.1 assessment recently?
It depends on how recently the v6.0.1 assessment was completed and what changed between then and now. Twenty-one new controls is a material increase. If Copilot has been deployed, if advanced Conditional Access patterns are in scope, or if the prior assessment is more than six months old, a v7.0.0 re-assessment is usually warranted. For unchanged tenants assessed in the last 90 days, a targeted v7.0.0 gap review covering only the new and modified controls is typically sufficient.