Microsoft 365 hardening: a security checklist for businesses
By Kike Gandia · Co-Founder & CEO, OSCP
Microsoft 365's default configuration prioritizes ease of use. This checklist, aligned with the CIS Microsoft 365 Benchmark, walks through the settings that most reduce your attack surface, ordered by impact. Start with identity: Entra ID is where an attacker looks first.
Protect and limit global admins
Reduce the number of global admins to the bare minimum and protect them with phishing-resistant MFA. Use Privileged Identity Management (PIM) to grant privileged roles only when needed (just-in-time) and keep admin accounts separate from day-to-day ones.
Enforce phishing-resistant MFA and conditional access
Enable MFA for all users and, for critical accounts, require phishing-resistant methods (FIDO2, passkeys, Windows Hello). Define conditional access policies that block legacy authentication, restrict by device and location and cover all users without gaps.
Control OAuth app consent
Disable user consent for unverified apps and require admin approval for sensitive permissions. Review existing app registrations and service principals and their permissions: illicit consent is one of the most used vectors against Microsoft 365.
Secure Exchange, SharePoint and logging
In Exchange Online, disable external automatic forwarding and review mailbox permissions. In SharePoint and OneDrive, restrict external sharing and anonymous links. Enable the Unified Audit Log, configure alerts and, if you have Defender and Purview, apply DLP and retention.
Block legacy authentication, then check nobody is still using it
Blocking legacy authentication is a single conditional access policy, but it is also the step that breaks the most operations if enabled blind: there is usually a multifunction printer sending over SMTP, a scanner, an old application or a shared mailbox depending on it.
The order that works is the reverse of what it looks like. First, filter sign-in logs by legacy authentication clients —Exchange ActiveSync, IMAP, POP, SMTP AUTH and the other-clients category— and note which accounts and applications show up. Second, migrate each case to modern authentication or, if that is not possible in the short term, create an explicit, narrow exclusion with an expiry date. Only then move the policy from report-only to on. An exclusion with no owner and no date is the usual reason legacy authentication is still alive years after being "blocked".
Roll out every policy in report-only mode before enabling it
Conditional access policies support a report-only mode that records what would have happened without blocking anyone. It is the difference between discovering the impact in the logs and discovering it on the phone, with half the company locked out.
There is one condition you cannot skip: break-glass accounts must be explicitly excluded from every single conditional access policy, and their use must raise an alert. A badly written policy that does not account for that exclusion can lock you out of your own tenant, and recovery from there runs through Microsoft support, which is not where you want to be.
Verify that each setting is actually in place
A checklist is worth nothing if nobody checks the result. These are the checks that close out each point.
| Setting | Where to verify it | Sign something is wrong |
|---|---|---|
| MFA for all users | Authentication methods report in Entra | Users with no method registered, or only SMS |
| Legacy authentication blocked | Sign-in logs filtered by legacy client | Successful sign-ins over IMAP, POP or SMTP AUTH |
| Conditional access without gaps | The What If tool and each policy’s exclusions | Exclusion groups with no owner and no expiry date |
| App consent | User consent settings in Entra | User consent allowed for sensitive permissions |
| External forwarding | Outbound spam policy in Defender | Mailboxes with external forwarding enabled |
| External sharing | SharePoint and OneDrive settings | Anonymous links allowed, or with no expiry |
| Audit logging | Search in the unified audit log | The search returns no events for the expected period |
FAQ
Is the Secure Score and the CIS Benchmark enough?
They're an excellent configuration baseline, but they don't replace an offensive audit: they review settings one by one, but they don't chain vectors or reproduce what a real attacker would do (illicit consent, AiTM, token theft).
What should I harden first?
Identity: phishing-resistant MFA, conditional access without gaps (including blocking legacy authentication) and protecting global admins with PIM. That's where an attacker looks first.
In what order do I apply all this without breaking operations?
Identity first, always in report-only mode: MFA, conditional access and the legacy authentication block, with an observation window before switching on. Then app consent, which rarely bothers anyone. And last Exchange and external sharing, which generate the most friction with daily work and are worth communicating in advance.
How long does it take to harden a tenant?
The configuration itself is quick. What sets the calendar is the preparation: inventorying what still uses legacy authentication, migrating those cases, identifying accounts that cannot carry conventional MFA and agreeing the external sharing policy with the people who work with clients. That inventory defines the real timeline, not the number of settings.
What do I do with accounts that cannot have MFA?
Do not simply exclude them. The reasonable options are removing interactive sign-in and granting access by delegation to named people, replacing them with a service principal holding narrow permissions, or —if there is no alternative— scoping the exclusion by source IP and giving it an expiry date with a named owner.
Do break-glass accounts also fall under the policies?
Quite the opposite: they must be explicitly excluded from every conditional access policy, precisely so that a configuration error or an MFA provider outage does not leave you without administration. In exchange, any use of those accounts must raise an immediate alert, because under normal conditions they should never sign in.