Microsoft Zero Trust Assessment vs. CISA SCuBA: Which Should You Run?

Microsoft publishes extensive security guidance across Entra ID, Intune, Defender, Purview, and Azure. CISA maintains its own secure configuration baselines for Microsoft 365, while other industry frameworks provide additional recommendations.

For organizations managing these environments, the challenge is determining which recommendations apply, whether the corresponding controls have been implemented, and where remediation should begin.

Two tools worth considering are Microsoft’s Zero Trust Assessment and CISA’s Secure Cloud Business Applications (SCuBA) assessment, implemented through ScubaGear.

Both examine existing Microsoft cloud configurations and produce findings that administrators can use to identify security gaps. They also overlap in areas such as identity, authentication, and Microsoft 365 security controls.

However, they aren't interchangeable, and running both won't necessarily provide twice the insight. The choice depends on what you're trying to establish and how you intend to use the results.

Two assessments with different objectives

Microsoft's Zero Trust Assessment examines tenant configurations against checks based on Microsoft's security guidance, its Secure Future Initiative, and recommendations informed by industry frameworks such as NIST, CISA, and CIS.

Its scope covers identity, devices, data, networking, infrastructure, security operations, and AI. The assessment helps identify configuration gaps across the Microsoft security ecosystem, including areas where controls in different products depend on one another.

CISA's SCuBA assessment takes a more prescriptive approach. ScubaGear evaluates Microsoft 365 configurations against CISA's published Secure Configuration Baselines. These define specific security requirements, including controls that can be evaluated automatically and others that require manual verification.

Although SCuBA originated within the federal government, its baselines and tooling are publicly available to commercial organizations.

The distinction is straightforward. Microsoft's assessment examines alignment with a broad set of security recommendations, while SCuBA evaluates conformance to defined Microsoft 365 configuration requirements. Neither is inherently the more rigorous option across every scenario. They assess different things, and the depth of their findings depends on the controls being examined.

Supporting reference: Microsoft Zero Trust Assessment overview ↗

Supporting reference: CISA ScubaGear documentation ↗

How do they compare?

Both tools are open source and don't require a separate assessment product license. Individual checks may still depend on available Microsoft services, licensing, and administrative permissions.

This comparison reflects the documentation reviewed for this edition. The current Microsoft assessment also supports selecting pillars and configuring runs; ScubaGear provides explicit YAML configuration for applicability, annotations, and exclusions. Check the installed versions before relying on either tool’s coverage.

Supporting reference: Microsoft Zero Trust Assessment PowerShell instructions ↗

Supporting reference: CISA ScubaGear documentation ↗

Supporting reference: ScubaGear reports and structured outputs ↗

Where Microsoft's Zero Trust Assessment has an advantage

Microsoft's assessment is useful when the objective extends beyond Microsoft 365 configuration compliance.

Consider an organization that has introduced Entra ID, Intune, Defender, Purview, and Azure security services over several years. Different teams may have implemented policies within their respective products, but that doesn’t establish whether those controls are configured consistently.

Devices might be enrolled in Intune without compliance being enforced through Conditional Access. Defender may be deployed across endpoints, but certain protections remain disabled or configured in audit mode. Privileged identities may have MFA enabled without being required to use phishing-resistant authentication.

Microsoft's wider assessment scope provides an opportunity to examine these configurations together, rather than reviewing each product in isolation. It also covers areas that SCuBA doesn't assess as comprehensively, particularly devices, infrastructure, networking, and AI-related controls.

For an organization planning security modernization, that wider coverage can help identify configuration gaps before committing to additional products or licensing.

Where it falls short

Microsoft's recommendations are useful technical references, but they don't automatically satisfy independent audit or compliance requirements. The assessment also reflects Microsoft's security architecture and implementation guidance. Organizations using third-party controls or maintaining legacy applications may need to evaluate recommendations against their existing architecture.

A failed check doesn't always mean a control is absent. It may indicate that a configuration differs from Microsoft's preferred implementation, including where an organization has accepted a risk or implemented an alternative control.

The wider scope can also generate a substantial remediation backlog. Without a defined objective, teams may review recommendations unrelated to their immediate concerns.

Where CISA SCuBA has an advantage

SCuBA’s strength is the specificity of its requirements. CISA publishes expected configurations, identifies which controls can be tested automatically, and documents requirements that need manual verification.

This makes it easier to trace a finding to a particular baseline requirement. An organization examining Exchange Online, for example, can evaluate requirements covering authentication, mailbox access, and email security. Administrators can review individual controls rather than rely on a broad posture indicator.

ScubaGear also produces JSON and CSV results useful for reporting and comparing assessments over time. For federal agencies subject to applicable CISA requirements, the baselines serve a defined governance purpose. Commercial organizations can adopt them voluntarily as an internal standard.

Supporting reference: CISA ScubaGear documentation ↗

Supporting reference: ScubaGear reports and structured outputs ↗

Where it falls short

SCuBA's narrower scope means it won't provide the same coverage of endpoint security, Azure infrastructure, hybrid Active Directory, or broader Microsoft security architecture. An organization could conform to every applicable baseline and still have unmanaged endpoints, unpatched servers, or weak incident response practices.

ScubaGear can also be more demanding operationally than its PowerShell interface suggests. It relies on Windows PowerShell 5.1 and specific Microsoft authentication and administration modules. Dependency conflicts and authentication problems can interrupt individual service assessments.

During a September 2026 assessment using ScubaGear 1.8.0, I encountered difficulties authenticating through Windows Authentication with a passkey. I have not established that this specific behavior is a confirmed CISA defect, although CISA has documented compatibility problems involving Microsoft authentication components.

Historical ScubaGear 1.8.0 issue reports describe Exchange Online and Defender connections requiring additional troubleshooting in particular installations, with authentication failures potentially affecting output completeness. A completed run does not necessarily mean every intended service was assessed.

SCuBA can also flag configurations that reflect deliberate business decisions, such as Conditional Access exclusions or external collaboration requirements. These still need review and documentation against the baseline.

Supporting reference: ScubaGear dependencies ↗

Supporting reference: ScubaGear issue #2146: version 1.8.0 Defender and Exchange authentication failures ↗

Choosing the appropriate assessment

The decision becomes easier when there is a specific objective behind the assessment.

1. Understanding overall security posture or preparing for modernization

Recommendation: Start with Microsoft’s Zero Trust Assessment. This includes organizations reviewing existing Microsoft security investments, planning a move from Microsoft 365 E3 to E5, or examining control consistency across multiple products.

A licensing upgrade may provide access to additional Defender, Purview, or identity security capabilities, but doesn't establish whether those controls are deployed or integrated into existing policies. The broader assessment can highlight relevant gaps. SCuBA may be useful afterward for validating specific Microsoft 365 services, but not automatically.

2. Validating Microsoft 365 against a defined standard or preparing for an audit

Recommendation: Start with CISA SCuBA. When the requirement is to determine whether Microsoft 365 settings meet published security requirements, SCuBA provides a more direct approach.

This includes internal audits, configuration standards, and recurring evidence collection against CISA baselines. Its control-level results make it easier to demonstrate what was tested. Federal applicability depends on specific directives; commercial organizations can adopt the approach voluntarily. The Microsoft assessment can supplement broader questions, but is not necessary to establish SCuBA baseline conformance.

3. Preparing for Microsoft 365 Copilot or broader AI adoption

Recommendation: Start with Microsoft’s Zero Trust Assessment, then conduct targeted data security and access reviews. Copilot and AI agents increase the importance of identity protections, access control, information governance, and application permissions.

Microsoft's wider assessment offers a more useful starting point, but neither tool provides a complete AI readiness evaluation. Organizations still need to review SharePoint permissions, oversharing, sensitive information, data protection policies, and the permissions given to agents. SCuBA can validate some underlying controls, but cannot replace those reviews.

4. Deciding whether to run a second assessment

Recommendation: Review the existing findings first. A recent Zero Trust Assessment may already identify the principal Microsoft 365 gaps. Running SCuBA immediately may reproduce many findings unless independent baseline validation is needed.

The same applies in reverse. If SCuBA has just been completed, it may be more useful to remediate its findings before a broader review. Examine coverage, identify remaining questions, and use the second tool when it answers something the first could not.

When running both makes sense

An organization may need broad Microsoft security configuration visibility as well as evidence of conformance to CISA's Microsoft 365 baselines. In that case the assessments complement one another, but I would not manage their findings as separate remediation programs.

Both may identify the same underlying Conditional Access or authentication issue with different descriptions or risk labels. That does not make it two different weaknesses. Consolidate the results into one register while preserving references to the underlying checks.

These are illustrative overlaps, not claims that the tools execute identical checks. Remediation should address the actual configuration problem, not the number of reports mentioning it.

Validating the results before remediation

Whichever tool is used, verify which services were assessed, whether authentication succeeded, which checks failed to collect information, and which requirements need manual review. Examine exceptions before approving changes. A Conditional Access exclusion might be necessary, but its exposure still needs to be understood.

Tool and baseline versions also matter. Reports from different dates may not evaluate exactly the same controls. A lower failure count is not necessarily better if fewer checks completed. Retain versions, scope, configuration, and supporting evidence with each assessment.

Which would I recommend?

For a general Microsoft security posture review, I would normally begin with Microsoft’s Zero Trust Assessment. Its wider coverage is more appropriate when the organization needs to understand configurations across multiple Microsoft services.

For validation against published Microsoft 365 configuration requirements, I would favor CISA SCuBA. Its baseline-driven approach and structured results are better suited to that purpose.

I would run both where broad configuration visibility and independent baseline validation are required, or where the first assessment leaves important questions unanswered. I would not run both simply because they are available.

The choice should follow the question being asked. Once findings are available, the work is determining which configurations present meaningful exposure, which changes are practical, and who is responsible for implementing them.