ScubaGear: the tool CISA uses to audit Microsoft 365 — and how to read it
ScubaGear is the PowerShell module the US Cybersecurity & Infrastructure Security Agency publishes to assess Microsoft 365 tenants against the baselines federal agencies must meet. Free, MIT-licensed, read-only. What it evaluates, the policy IDs it uses (MS.AAD.3.1v1, MS.EXO.2.2v2…), and how it sits inside the compliance ecosystem.
What ScubaGear is
ScubaGear is the technical component of the SCuBA — Secure Cloud Business Applications project CISA launched in 2022 to produce a uniform Microsoft 365 (and Google Workspace) baseline for US federal civilian agencies. SCuBA has two pieces: the Secure Configuration Baselines — per-product policy documents (Entra ID, Defender for Office 365, Exchange Online, SharePoint, Teams, Power Platform, Power BI) — and ScubaGear, the open-source PowerShell module that evaluates a tenant against those baselines and produces a report.
Primary sources:
- Project page: cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
- Source: github.com/cisagov/ScubaGear
- Microsoft 365 baselines: github.com/cisagov/ScubaGear/tree/main/PowerShell/ScubaGear/baselines
It runs read-only — delegated global-reader permissions, no writes to the tenant.
The ID convention (matters for audit)
Each SCuBA policy carries a stable identifier: `MS.<PRODUCT>.<SECTION>.<RULE>v<VERSION>`. For example:
- `MS.AAD.3.1v1` — phishing-resistant MFA required for all users
- `MS.AAD.7.4v1` — break-glass emergency access accounts configured
- `MS.EXO.2.2v2` — SPF configured with hard fail (`-all`)
- `MS.EXO.1.1v1` — auto-forwarding to external domains blocked
- `MS.SHAREPOINT.1.1v1` — external sharing restricted to allow-listed domains
When an auditor or a prospect asks "what baseline did you evaluate this control against?", the correct answer is the policy ID — not "best practices" or "international standards." The ID traces to a CISA document with the rationale, severity, and exact compliance condition.
What it covers — and what it doesn't
SCuBA covers Microsoft 365 only. Published baselines at time of writing: AAD (Entra ID), Defender for Office 365, Exchange Online, SharePoint / OneDrive, Teams, Power Platform, Power BI. Purview is in the pipeline.
Not in SCuBA's scope:
- Azure Resource Manager (Azure VMs, networking, databases). That falls under CIS Azure Foundations Benchmark and Microsoft Cloud Security Benchmark.
- Defender XDR end-to-end (Sentinel, Defender for Endpoint integrations).
- Local-regulation requirements — LFPDPPP, CNBV, NOM-024. SCuBA is a US federal framework; translation to the Mexican context has to come from elsewhere.
How it relates to CIS Benchmark and Microsoft Secure Score
Three distinct layers:
| Framework | Publisher | Question it answers |
|---|---|---|
| Microsoft Secure Score | Microsoft | "What percentage of Microsoft's security recommendations have you enabled?" |
| CIS Microsoft 365 Benchmark v3.0 | Center for Internet Security | "Does your configuration meet the controls the industry consortium considers minimum defensible?" |
| CISA SCuBA / ScubaGear | CISA (US federal) | "Does your tenant meet the baseline applied to US federal civilian agencies?" |
Not substitutes. A tenant can hit 80% Secure Score and fail SCuBA, because Secure Score rewards enabling features while SCuBA requires specific configurations within each feature. CIS is closer to SCuBA in intent but broader in scope (it includes operational practices, training, documentation review) while SCuBA stays strictly technical.
How simiriki uses it
simiriki publishes the rule-by-rule mapping against SCuBA policies in docs/SCUBAGEAR_MAPPING.md. Of the 23 critical rules in simiriki's catalog, 14 map directly to a published SCuBA policy. The remaining 9 cover controls outside SCuBA's scope (Defender XDR, Sentinel, Azure RM) — mapped to CIS Azure Foundations and Microsoft Cloud Security Benchmark instead. The free scan evaluates the 155 Microsoft Graph rules of the 201-rule library; the Azure Resource Manager controls are added when you connect with admin consent and Reader access.
The extension to the Mexican context that SCuBA doesn't cover — CNBV Art. 168 Bis 11 VIII log-retention, Art. 168 Bis 11 IX immutable incident archive, LFPDPPP personal-data transfer controls — lives in rules `AUD-014`, `AUD-015`, and the `DLP-*` family of the catalogue.
If your team wants to run ScubaGear directly
ScubaGear runs on Windows with PowerShell 7+. Requires `Microsoft.Graph`, `MicrosoftTeams`, `ExchangeOnlineManagement`, `PnP.PowerShell` modules. Connect with `Connect-MgGraph -Scopes ...` (read-only). Install instructions in the repo README.
Output is HTML + JSON. The JSON is the audit artefact — persistent, indexable, comparable across runs to detect drift. If your MSP only hands you the HTML as a screenshot, you're not receiving the operational artefact, you're receiving marketing.
Bottom line
ScubaGear is not the only tool to audit Microsoft 365 — but it is the only one signed by a US federal publisher, with auditable source on GitHub, and stable policy identifiers. For a Mexican mid-market company evaluating Microsoft 365 security providers, the right question is not "what's your methodology?" but "what baselines do your controls map to, and where is that mapping published?" If the answer doesn't include SCuBA, a layer of the evidence chain is missing.
Related reading:
Is your business protected?
A free Microsoft 365 audit—the automated scan delivers a preview in 90 seconds. Find risks before they become incidents.