M365 Assessment: Where Tenants Are Really Vulnerable

In most companies, Microsoft 365 is the single biggest attack vector: identities, email, files and collaboration all converge in one tenant. That makes a structured assessment correspondingly worthwhile, and the findings correspondingly similar.

In short: A Microsoft 365 security assessment systematically checks the configuration of a tenant against known attack paths: identities, access rules, email protection, sharing and logging. It is not a penetration test and not a product pitch, but a prioritised list of the gaps an attacker would actually use after the first phishing click.

What gets checked

An assessment works through the layers of the tenant:

• Identities (Entra ID): MFA coverage, truly for everyone, including admins and service accounts? Conditional Access rules, privileged roles, guest accounts.
• Legacy authentication: old protocols like IMAP or SMTP auth that simply bypass MFA, the classic among open doors. Microsoft’s own telemetry has shown for years that a large share of password-spray attacks runs over legacy protocols.
• Email security: anti-phishing policies, forwarding rules (a popular persistence tool after account takeovers), SPF/DKIM/DMARC of your own domains.
• Sharing: SharePoint and OneDrive settings: what may be shared anonymously, what organisation-wide?
• Defender configuration and logging: are the signals you will need in an incident even switched on and retained long enough?

Identity, communication, data: each layer has its own controls, and the one overlooked item is almost always on the identity layer.

How an assessment runs

A clean assessment needs no intervention in operations. The sequence I consider sensible:

1. Clarify the scope. Which tenants, which domains, which licences? A tenant with Business Premium has different options from one with E5, and different excuses.
2. Set up read access. A role like Global Reader or Security Reader is enough for almost all checks. Nobody needs Global Admin to read.
3. Collect automatically. Tools like Maester or ScubaGear (more on these below) deliver hundreds of checkpoints with evidence in minutes. That is the factual basis, not the result.
4. Classify manually. Every deviation is read against the concrete context: is the legacy auth exception for the scanner really necessary? Is there a compensating control?
5. Prioritise and re-test. The result is a list ordered by attack relevance, not alphabetically, and after implementation the same check runs again so that “fixed” is proven.

For a mid-sized tenant this is an effort of two to four working days, not counting the implementation of the findings. The report should be readable for management on one page and for IT on twenty, both from the same data. A report only IT understands changes no budget.

The usual suspects

After a few assessments the patterns repeat. The findings that almost always appear:

• MFA applies “to everyone”, except for the three oldest admin accounts or a few service accounts that “otherwise do not work”.
• Legacy auth is “disabled”, except for that one exception for the multifunction printer, which leaves the whole tenant open.
• Conditional Access exists, but as a grown collection of individual rules with gaps in between, and nobody remembers why rule seven has an exception for the executive board.
• The break-glass accounts have had the same password for years and nobody monitors their sign-ins.
• More global admins than necessary, often with their everyday account. Each of them is a direct path to a complete takeover.
• Users may grant arbitrary apps access to their data (app consent), so phishing via OAuth apps does not even need a password.
• Guest accounts from projects three years ago are still active.
• The audit log is switched on, but nobody has ever looked into it.

The point is not that these things are exotic. The point is that they occur in almost every tenant at the same time, and an attacker only needs one of them.

Which licence allows which control

Many findings share the same cause: the setting would be there, but the licence is missing, or it is there and nobody knows. The short version:

• Business Basic / Standard: only Security Defaults (MFA for all, legacy auth blocked), no Conditional Access rules.
• Business Premium / E3: Entra ID P1 with Conditional Access, authentication strengths, device conditions; Defender for Office P1 with Safe Links and Safe Attachments; Intune.
• E5 / Entra ID P2: plus risk-based policies (Identity Protection), Privileged Identity Management for time-limited admin rights, Access Reviews for guests.

An assessment therefore checks not only “is the setting set?” but also “is the best this licence offers being used?”. Surprisingly often Business Premium is in place and is run like Business Standard.

What to test with

You do not have to do this by hand. Besides the built-in Secure Score there are now very good free tools: Maester bundles several test catalogues (EIDSCA, CISA ScuBA, CIS) into one Pester-based PowerShell test framework. Every test has an explanation, a severity and a link to the setting, and because they are tests, they can run recurringly as a pipeline. Hardening thereby becomes testable like code: if someone changes a Conditional Access rule, the test fires the next morning. CISA’s ScubaGear checks the tenant against the American baseline requirements and produces a report per service (Entra, Exchange, SharePoint, Teams, Defender). Both deliver concrete, traceable findings instead of an abstract score.

Why Secure Score is not enough

Microsoft’s Secure Score is a usable starting point, but it rates configurations, not attack paths. A tenant with a decent score can still leave open a trivial escalation from a compromised user account to global admin rights. On top of that, the score partly rewards settings that require licences the company does not even have, and weights points by Microsoft’s yardstick, not by your own risk. An assessment thinks from the attack: what happens after the first phishing click? How such a click comes about is shown by the phishing simulation with eight realistic examples.

The score rates points, the attacker looks for paths: from the first compromised account there is often a short chain to the highest privileges.

Ten measures with the biggest impact

If I had to prioritise (and in assessments you have to), the list would look like this:

1. Phishing-resistant MFA for all admin roles
2. Block legacy authentication via Conditional Access
3. Two break-glass accounts: long passphrases, excluded from CA, sign-ins alerted
4. Conditional Access baseline: MFA for all users, block on high sign-in risk
5. Disable external auto-forwarding
6. SPF, DKIM and DMARC for all your domains
7. Deliberately restrict anonymous sharing and guest access
8. Clean up privileged roles, with as few global admins as possible
9. Enable audit logging and check retention
10. Test recurringly instead of hardening once, for example automated with Maester

None of this is exotic, most of it costs no licence, only care. That is exactly why these are the points where almost every tenant has something to gain first. What the individual settings look like in concrete terms, with portal path, licence requirement and pitfalls, is in Hardening Microsoft 365: 12 settings.

What an assessment does not do

Honesty is part of it: a configuration assessment finds no compromised accounts. That takes log analysis and threat hunting. It does not evaluate the endpoints on which the tenant is used; an unpatched laptop with a valid token is a problem that is not visible in Entra ID. And it replaces no process: the finest report is useless if the findings sit unchanged in a folder a year later.

If you want to track the findings as measures afterwards instead of losing them in a spreadsheet, CISO Assistant is a fitting open-source tool. And how much budget security needs overall is what the security budget check shows as a guide value for Swiss companies.