The Microsoft 365 SCuBA Baseline: Secure Configuration Evidence for Regulated Organisations
What the Microsoft 365 SCuBA baseline and ScubaGear actually check across Entra ID, Exchange, Teams and Power Platform, and what it takes to turn those findings into NIS2 evidence.
Marc Dekeyser |
The Microsoft 365 SCuBA Baseline: Secure Configuration Evidence for Regulated Organisations
Nobody has ever checked.
That is the honest state of most Microsoft 365 tenants I get pointed at. Dozens of tenant-level toggles governing authentication, sharing and mail flow, every one of them assumed correct, not one of them measured. Somebody set them during a migration, under time pressure, and then left the company. The settings have been quietly load-bearing ever since.
SCuBA is a set of secure configuration standards published by the US Cybersecurity and Infrastructure Security Agency. It defines minimum security settings across the Microsoft 365 services, and there is an open-source tool, ScubaGear, that checks a tenant against them. For a regulated organisation in the EU the payoff is narrow but real: a reproducible configuration check whose findings can be tied to NIS2 and DORA control evidence.
Narrow is the word to hold onto. A baseline answers one question. Are the settings right? It says nothing about whether your architecture is sound.
TL;DR: SCuBA gives you a repeatable configuration floor for Microsoft 365. You still map the findings to NIS2 and DORA yourself, and it never touches architecture.
What is the Microsoft 365 SCuBA baseline?
CISA built SCuBA to give US federal agencies a concrete configuration floor. Secure Cloud Business Applications, if you unpack the acronym. The baselines are published openly, and here is the part that travels: the settings they reference are the same in any Microsoft 365 tenant, federal agency or not.
Each baseline is a document of numbered policies. A policy reads, in effect, this setting must be configured this way, for this reason. The Entra ID baseline requires legacy authentication to be blocked and phishing-resistant multifactor authentication to be available for privileged users. The Exchange Online baseline requires external sender warnings and anti-spoofing protections. Every one of them specific enough to check by machine.
The baselines are versioned, and they move as Microsoft 365 moves. That matters more than it sounds. A finding is a finding against a stated baseline version, which dates it and anchors it.
Which is exactly what an auditor wants.
What does ScubaGear check?
ScubaGear is an open-source PowerShell module, maintained by CISA. Point it at a live tenant with read access and it walks every baseline policy, marking each one pass, fail or warning against the configuration it actually observed. Out comes an HTML report plus structured results.
The coverage reaches products an Azure infrastructure scanner never touches:
| Service | What ScubaGear evaluates |
|---|---|
| Microsoft Entra ID | MFA, legacy auth, Conditional Access, privileged roles, risk policies |
| Exchange Online | Anti-spoofing, external warnings, mail-flow rules, auto-forwarding |
| Microsoft Teams | External access, guest policies, meeting and messaging controls |
| SharePoint and OneDrive | External sharing scope, link defaults, expiration |
| Microsoft Defender | Anti-phishing, Safe Links, Safe Attachments, audit logging |
| Power Platform | Environment creation, DLP for connectors, tenant isolation |
Go back and look at the Power Platform row. Most security teams do not assess that surface at all, and it is precisely where a low-code app can walk data out through a connector nobody governs. SCuBA puts a baseline on it.
That row alone earns the run.
Because the output is structured, you can run it again. A monthly cadence gives you a dated series, and a dated series is what shows configuration drift, the same property that makes the broader Microsoft 365 security posture assessment auditable rather than anecdotal.
How do SCuBA findings map to NIS2 and DORA?
The settings SCuBA checks are the technical controls the frameworks demand: authentication strength, access control, mail security, external exposure. Same substance, expressed as specific values instead of outcomes. So a failed SCuBA policy is usually a direct gap against a named NIS2 Article 21 clause.
Three come up constantly. Blocked legacy authentication lines up with Article 21(2)(j) on multifactor authentication, because legacy auth is how attackers walk around MFA in the first place. Restricted external sharing in SharePoint lines up with Article 21(2)(d) on supply chain and external exposure. Audit logging in Defender lines up with Article 21(2)(b) on incident handling. No retained logs, no investigation.
None of that mapping happens inside the tool. ScubaGear reports against the SCuBA baseline, not against NIS2. The regulatory evidence is a second step: take each finding, tie it to the clause it answers, date it, record why. That translation is the actual work, and it is what turns a configuration report into a compliance artifact.
It is also the part I got tired of doing by hand. The tool produces the finding in minutes and then I would spend an evening in a spreadsheet writing down which clause it answered, for the third client that quarter, in a format the next auditor would want restructured anyway. So I built the mapping into what I run, which is now Platform Architecture Authority. The judgment stays mine; the transcription does not.
For DORA, the access and resilience controls connect to DORA Article 11 and Azure architecture.
Why is a US baseline useful for EU organisations?
“But we’re in the EU. Why would we take a security baseline from an American agency?”
I get that one in the room, usually with the word American doing a lot of work. Here is the answer: blocking legacy authentication is the same control in Amsterdam as it is in Washington. The control surface is Microsoft 365 itself. The settings do not change based on where your tenant lives or which regulator you answer to. SCuBA does not encode US law. It encodes secure values for Microsoft settings.
The framing differs. The controls do not.
NIS2 and DORA describe outcomes: strong authentication, controlled external access, incident-ready logging. SCuBA describes the Microsoft 365 settings that produce those outcomes. So you can take the SCuBA baseline as your technical floor, evidence it against the EU frameworks, and inherit a mature control set somebody else maintains for free. If you are holding out for an EU-specific equivalent at the same level of specificity, I would not plan around it arriving.
One honest caveat, and it is the one people skip. SCuBA reflects CISA’s judgment of a sensible floor, not your organisation’s risk appetite. Some policies will not fit you. A baseline that assumes a particular operational model will happily flag a setting you chose deliberately, for good reasons, after an argument you won. Treat failures as findings to triage, never as automatic non-compliance.
What are the limits of SCuBA?
ScubaGear can hand you a fully passing tenant that is architecturally fragile.
That is the limit in one sentence. It checks whether settings match a baseline, not whether your design is sound, whether your data flows make sense, or whether the architecture holds against the threats specific to you.
Three boundaries worth naming. It evaluates settings against a fixed baseline, so it cannot reason about context; a “fail” may be a deliberate, well-justified exception. It covers the security pillar of configuration, not the reliability or operational-excellence concerns of the Microsoft Azure Well-Architected Framework. And it does not review architecture. It will never tell you your identity design has a single point of failure, or that your data is sitting somewhere it should not be.
A strong, repeatable floor. Not the whole assessment.
Run it, then look up
If you are a Microsoft 365 admin or a CISO reading this and you have never run ScubaGear against your own tenant, that is the next hour of your week. It is free, it is read-only, and the first report will tell you something you did not know. It told me things about tenants I had already reviewed by hand, which I have made my peace with, mostly.
Then do the part the tool cannot. Map each finding to the clause it answers. Decide which failures are gaps and which are exceptions you can defend out loud. Assess the architecture sitting above the settings, separately, because SCuBA is a good floor and a poor ceiling.
A baseline tells you the settings are right. It does not tell you the building is sound.
FAQ
Is ScubaGear free to use? Yes. It is open-source software, maintained and released publicly by CISA, and runs as a PowerShell module. No licence cost. You do need read access to the tenant, which means appropriate administrative permissions to read configuration.
Does SCuBA cover Microsoft Azure infrastructure? No. The SCuBA Microsoft 365 baselines cover the Microsoft 365 services: Microsoft Entra ID, Exchange Online, Microsoft Teams, SharePoint, OneDrive, Microsoft Defender and Power Platform. Azure infrastructure resources are a separate control plane, assessed through different tools such as Microsoft Defender for Cloud or an architecture review.
How often should I run ScubaGear? Monthly for a regulated organisation, plus a run after any significant tenant change. Configuration drifts every time an administrator adjusts a setting, so a point-in-time check ages fast. The dated monthly series is also the trend evidence auditors value over a one-off snapshot.
Does a passing ScubaGear report mean I am NIS2 compliant? No. It means your Microsoft 365 configuration meets the SCuBA baseline. That covers many NIS2 technical controls, but not the organisational measures, governance, incident processes or architecture review NIS2 also requires. Strong evidence for the configuration layer. Not a complete compliance statement.
