What Access Does a CIS Microsoft 365 Assessment Actually Need?

Every Microsoft 365 assessment stalls at the same meeting. Not the technical work — the access review. Someone in security asks what the scanning tool will actually be able to see inside the tenant, and if the answer is vague, the project waits.

It is a fair question, and it deserves a precise answer rather than a reassuring one. This guide covers exactly what access a CIS Microsoft 365 Foundations Benchmark v7.0.0 assessment needs, why admin consent on its own does not cover all nine sections of the benchmark, and how to verify afterwards that nothing more was granted than you intended.

What the assessment reads: configuration, not content

The distinction that matters most in an access review is between configuration and content. The CIS Microsoft 365 Foundations Benchmark v7.0.0 defines 160 controls across 9 top-level sections, and every one of them is a question about how the tenant is configured, not about what is inside it.

A control asks whether modern authentication is enabled, whether Safe Links policies exist, whether external sharing defaults are restricted, whether privileged roles are assigned permanently or through Privileged Identity Management. None of those questions require reading a mailbox, opening a document, or inspecting a Teams message. They require reading settings.

That is why ConfigCobra operates on read-only Microsoft Graph permissions, with no agents installed anywhere in the environment and no administrator passwords shared. There is nothing to deploy to endpoints, and nobody hands over credentials to a human being. The access is granted to an application identity, and it is scoped to read.

Why admin consent alone is not the whole story

This is the part most access reviews get wrong, usually by assuming the opposite: that one consent click covers everything, or that anything beyond consent means someone is asking for more than they should.

Microsoft 365 is not a single API. Admin consent to the ConfigCobraAPI application covers the Microsoft Graph checks, which is the bulk of the benchmark. But three product areas expose their configuration through their own administrative interfaces rather than through Graph:

• Exchange Online — section 6 of the benchmark, 13 controls covering mailbox auditing, mail flow and anti-phishing, Outlook add-ins, and Exchange modern authentication
• Microsoft Purview — section 3, 5 controls covering audit log search, Data Loss Prevention, and Information Protection
• Microsoft Fabric and Power BI — section 9, 12 controls covering tenant settings

Those 30 controls cannot be evaluated through Graph consent alone. They need a directory role and, in the Fabric case, a security group. This is not a larger ask disguised as a smaller one — it is the same read-only posture expressed through three different Microsoft admin surfaces, because Microsoft never unified them.

Global Reader: the role, and what it cannot do

The directory role the assessment uses is Global Reader. It is a built-in Microsoft Entra role, not a custom one, and the name is literal: it can read configuration across Microsoft 365 and it cannot change anything. There is no write path through it.

Assigning it is a short job in the Microsoft Entra admin center — Identity, then Roles & admins, find Global Reader, add the ConfigCobraAPI application as an assignment. Two details are worth knowing before the meeting:

• The person doing it needs to be a Global Administrator or Privileged Role Administrator. If the Add assignments button is greyed out, that is the reason.
• The application only appears in the member picker after admin consent has been granted during onboarding. If you cannot find it, consent is the missing step, not the role.

For teams that would rather script it than click through it, the same assignment can be made with the Microsoft Graph PowerShell SDK. The full walkthrough, both paths, is in the tenant permissions documentation.

The Fabric exception: why a security group appears

Microsoft Fabric is the one place where the pattern breaks, and it surprises people who have already approved the Global Reader assignment and expect to be finished.

Fabric does not grant admin API access to an application directly. It grants it to security groups. So the setup creates a security group whose only purpose is to hold the ConfigCobraAPI application, and then enables the Fabric tenant setting Service principals can access read-only admin APIs for that group specifically — not tenant-wide.

Two things are worth noting for the reviewer. The Fabric setting is read-only by design; there is no equivalent write toggle being enabled alongside it. And scoping it to a named group rather than to all service principals means the grant is auditable and reversible: remove the application from the group, and the access is gone. Changing Fabric tenant settings requires a Fabric Administrator or Global Administrator.

What a partial grant actually looks like

You do not have to grant everything at once, and some organisations deliberately stage it — consent first, run a scan, then decide about the directory role.

That works, and the output is honest about it. Controls that cannot be evaluated because the access is not there are tagged Missing Permissions rather than being reported as passing or failing. This matters more than it sounds: a scanner that silently marks an unreadable control as a pass produces a posture score that is wrong in the most dangerous direction. A staged rollout gives you a smaller assessment, not an inflated one.

The practical consequence of stopping at consent is that the 30 controls in sections 3, 6, and 9 stay unevaluated — you get a real result for the other 130 and a clear list of what you chose not to grant.

Verify, then re-run

Role assignments and Fabric tenant settings are not instant. They can take up to an hour to propagate, and a scan started too early will report Exchange Online, Purview, or Fabric checks as errors even though the grants are correct. This produces a predictable false alarm, usually surfacing as a message that the role assigned to the application is not supported in this scenario.

The right move is to verify rather than guess. Query the directory role assignments and group memberships of the service principal directly, confirm that Global Reader and the security group both show up, and only then start a new assessment. The documentation includes a verification script that does exactly this, along with a troubleshooting table mapping each common symptom to its cause.

The same queries are what you would use for a periodic access review months later, which is the more useful habit: the grant should be as easy to confirm, and to revoke, as it was to make.

What you get once access is in place

With the grants in place, a full assessment runs in 20–25 minutes. Of the 160 controls, 143 are classified Automated in the benchmark itself and are evaluated by reading configuration state; the remaining 17 are Manual and need a person to confirm something the APIs do not expose.

The output is a PDF report with findings, evidence, and a timestamped tenant snapshot, plus an audit-ready evidence export and copy-paste remediation scripts generated per finding — PowerShell or admin portal steps, depending on the control. For organisations assessing subsidiaries or client tenants, the same read-only pattern repeats per tenant from a single workspace.

Where to start

If you are preparing for the access review rather than recovering from one, the useful sequence is: read the benchmark scope first so you know what the access is buying, then walk the permissions guide with whoever holds Global Administrator, and book the hour of propagation time into the plan rather than discovering it mid-scan.

Start with the CIS Microsoft 365 Benchmark overview for what the 160 controls cover section by section, and the tenant permissions guide for the four-step grant itself.

To see the collection and reporting flow end to end before committing to anything, the free trial runs for 14 days with full access to all 160 controls.