Your Microsoft 365 tenant is cloud infrastructure: hundreds of security-relevant settings across Entra ID, Exchange Online, SharePoint, and Teams, and they drift exactly like an unmanaged AWS account. An admin flips a setting during an incident and never flips it back. Microsoft changes a default in a service update. A vendor gets guest access for a pilot that ended two quarters ago. Nobody reviews any of it, because the tenant is "an IT thing," not "an infrastructure thing." Posture scanning is the boring, effective fix: continuously compare the tenant's actual configuration against a published security baseline and report the gaps. And in 2026 the practical way to run that scanner is as SaaS, which means you are checking cloud with cloud. This post is the 101, using Aether365 as the example. Full disclosure: Aether365 is my product.

One principle to hold onto: read-only is the default. Nothing gets write access to your tenant unless you explicitly consent to it, separately.

Treat the tenant like a production account

If someone ran production AWS with no config audit, no drift detection, and no change history, you would call it negligence. Most organizations run Microsoft 365 exactly that way, while it holds their identity provider, all their email, and most of their files. The tenant is the identity plane for everything else you run; a Conditional Access misconfiguration there is worth more to an attacker than a public S3 bucket.

The infrastructure mindset transfers directly. You want a declared baseline, a scheduled comparison of reality against it, and an alert when the two diverge. In AWS-land you would reach for Config rules or Security Hub standards. For Microsoft 365, the equivalents are posture benchmarks.

The three benchmarks worth knowing

Three baselines cover most of what matters, and every serious scanner maps to at least one of them:

  • CIS Microsoft 365 Foundations Benchmark: the broadest one, 800+ checks across the whole suite, from MFA enforcement to mailbox auditing to sharing policies. The default answer to "audited against what?"
  • EIDSCA (Entra ID Security Configuration Analyzer): focused entirely on Entra ID, the settings that decide who can authenticate, consent, and register applications. Small surface, highest blast radius.
  • CISA ScuBA (Secure Cloud Business Applications): the US federal government's baseline for M365. Stricter and more opinionated; useful even outside government as a "what would a hard target do" reference.

The benchmarks overlap, which is fine. Overlap on identity controls tells you where the consensus is, and consensus findings are the ones to fix first.

Scripts or SaaS: the real trade-off

You can absolutely run these checks yourself. The Graph API is right there, community tooling like Maester wraps a lot of it, and a scheduled PowerShell run against one tenant is a weekend project. I like that approach for learning what the checks actually do.

It stops scaling on three axes. Maintenance: benchmarks version, Graph endpoints change, and your script collection quietly becomes a product you own. History: a point-in-time script tells you today's state, but posture questions are trend questions, when did this control regress and what changed around it. Tenancy: the moment you manage more than one tenant, an MSP with thirty customers, say, per-tenant scripts and credentials become the risk.

A SaaS scanner inverts the trade: you grant it read-only Microsoft Graph consent, it runs compliance and exposure scans on a schedule, daily, weekly, or monthly, and it keeps the history. The consent model is the part to scrutinize, because you are wiring an external service into your identity plane. Read-only should be the default and anything beyond it should be a separate, explicit consent you can decline. That single property is what makes cloud-checking-cloud acceptable to a regulated EU tenant.

What Aether365 covers

Aether365 is my take on that scanner. The core is compliance scanning against all three benchmarks above plus exposure scanning, scheduled per tenant, with multi-tenant management for MSPs, Teams and email notifications, and a REST API plus a built-in MCP server if you want your AI assistant querying scan results. It is EU-based and GDPR-compliant, you pick your data region at sign-up, and scan data is never used to train any model.

Two capabilities go past the tenant's inside view. External Attack Surface checks what the tenant exposes from the outside in: SPF, DKIM, and DMARC records, which are load-bearing for M365 mail, certificate expiry with 90-day warnings, dangling DNS and subdomain takeover risk, legacy authentication endpoints left open, and public SharePoint and OneDrive shares. And AI Pilot, opt-in and Pro and Enterprise only, turns findings into concrete Microsoft Graph fixes that you approve per item before anything is applied, with a verified audit trail. Read-only remains the default; the write path is a separate Microsoft consent you enable only if you want it. There is a Free tier with monthly scans on one tenant, which is enough to see your first CIS score, and that first score is usually the motivator.

The takeaway

The 101 is simple: your Microsoft 365 tenant deserves the same posture discipline as your cloud accounts, the benchmarks to measure against already exist, and the operational question is only whether you run the scanner yourself or consent a SaaS to do it read-only on a schedule. Scripts teach you the controls; a service keeps you honest over time. Either way, the failure mode to avoid is the current default: nobody checking at all.

Read this next

For the AI side of the same platform, why remediation needs an approval gate and what AI-generated reporting is actually for, see M365 Security 101: AI Pilot and Business Impact Reports at ercan.ai. For consulting on cloud, security posture, and platform work, or just to say hello, start at ercanermis.com.