A Microsoft 365 tenant does not arrive misconfigured: it arrives configured so that everything works immediately. That is not the same thing, and it is a defensible choice on Microsoft's part. The problem is that the settings opened for the initial rollout are almost never closed once the migration ends.
We scan more than 300 control points on a tenant. Six come back with a regularity that stopped being anecdotal a long time ago.
1. Privileged accounts without strong authentication
The absolute classic. Not because MFA is not deployed — it almost always is for users — but because the admin accounts were excluded during the migration, "just until we finish", and the exclusion stayed.
Add to that service accounts, breakglass accounts created and forgotten, and external providers' administrators.
What we look at: how many privileged roles are actually assigned, the real coverage of strong authentication on those accounts, and whether a documented, monitored emergency access exists — because locking yourself out of a tenant by closing this door badly is an incident in its own right.
2. Legacy authentication still accepted
Older protocols — IMAP, POP, basic SMTP AUTH, old Exchange clients — cannot present a second factor. As long as they are accepted, MFA can be bypassed: the attacker simply signs in through a path that never asks for it.
Microsoft has closed many of these doors by default on new tenants. Tenants created five years ago kept their permissions, and the exceptions added for a multifunction printer or an ERP were never reviewed.
3. External sharing that never expires
SharePoint and OneDrive allow "anyone with the link" sharing. By default, in many configurations, those links never expire.
A link created for a 2022 tender still works today, it may sit in a thread forwarded three times, and the file it exposes may well have been updated since.
The fix costs almost nothing: a maximum lifetime on anonymous links, plus a review of existing shares. It breaks no legitimate use — it simply forces people to recreate a link when they need one later.
4. Users allowed to register applications
By default, a standard user can consent to a third-party application accessing their data, and often register an application in the directory themselves.
This is the consent phishing vector: the user does not hand over a password, they authorize an application to read their mail. MFA does not stop it, neither does a password reset, and the grant survives everything — until somebody revokes it.
What we look at: how many applications hold broad permissions on mail or files, when those grants were made, and whether any approval workflow exists.
5. Forgotten transport rules
Mail flow rules accumulate: an exception for a partner, a filtering bypass for a test, a redirect set up during someone's leave.
Two categories always concern us:
- filtering exclusions by sender or domain, which create a trusted path an attacker can walk straight down by spoofing that very domain;
- automatic external forwarding, one of the most reliable markers of a compromised mailbox.
6. Incomplete logging
Not a flaw: the thing that will stop you answering on the day it matters. Without unified audit logging enabled and sufficient retention, a question as simple as "how long has this forwarding rule existed?" becomes unanswerable.
That is exactly the question an insurer, a customer auditing you, or an authority will ask. Logging is the only one of these six points that protects nothing in the moment, and without which the other five cannot be demonstrated.
What closing it costs
Most of this list is a few days' work, and much of it with no user-facing interruption. What takes time is not the change: it is checking that no legitimate use depends on it. Turning off legacy authentication without first inventorying the applications that use it means stopping a production line.
That is precisely why we apply remediation in batches, verifying at each step, rather than in a single switch.