Microsoft 365 security: 10 settings to start with
Microsoft 365 is the heart of most companies — and the top target of account attacks. Ten configurations that close common takeover paths.
In most companies we audit, Microsoft 365 is no longer “email in the cloud” but the operational centre: identity (Entra ID), documents (SharePoint/OneDrive), communication (Teams, Exchange) and increasingly automation. That makes the M365 tenant target number one — why break into the network when you can take over an account that has access to everything? The good news: most real attacks on M365 exploit the same well-known configuration weaknesses. Below are the ten settings we start every review with — and which you can check in your tenant in a single day.
What M365 attacks look like in practice
Three scenarios dominate the post-incident cases that reach us:
- Phishing → account takeover → mailbox rule. The victim signs in on a fake page, the attacker gets the session (increasingly together with the MFA code, via adversary-in-the-middle techniques), sets up a forwarding rule and reads correspondence for weeks, waiting for the right moment to swap an invoice (BEC).
- Legacy authentication. Old protocols (password-based IMAP/POP3/SMTP) bypass MFA — the attacker simply logs in with a leaked password where modern controls don’t apply.
- Consent for malicious apps (consent phishing). Instead of stealing a password, the attacker asks the user to approve an “innocent” OAuth app that gains persistent access to mail and files — resistant to a password change.
All three are closed by configuration, not purchases.
Ten settings that make the difference
1. MFA for everyone, phishing-resistant for key accounts. The baseline: enforce MFA via conditional access policies (not per-user). The target state: passkeys/FIDO2 for admins, the board and finance — we’ve explained why SMS codes and push prompts aren’t enough against targeted attacks.
2. Disable legacy authentication. One conditional access policy blocking legacy protocols closes an entire attack class. Before enabling, check the sign-in logs for what still uses them (most often: old scanners/printers sending email — give them a dedicated solution, not a company-wide exception).
3. Sensible conditional access. The minimum useful set: block countries you don’t operate from; require a compliant/managed device for administrators; block high-risk sign-ins (if your licence includes Identity Protection).
4. Restrict app consent. Disable users’ ability to self-approve apps from unverified publishers; enable the admin consent workflow. Review existing grants — in every second tenant we find forgotten apps with mailbox access.
5. Separate admin accounts. A global administrator has no mailbox and isn’t used for daily work. Number of global admins: 2–4, all on FIDO2. Everything else through lesser roles (and with P2 licences — just-in-time elevation via PIM).
6. Alerts on mailbox rules and forwarding. External auto-forwarding: block it by default and alert on attempts. It’s the cheapest “intrusion sensor” in all of M365 — a mailbox rule is the first thing an attacker sets up after taking over an account.
7. Lock down SharePoint/OneDrive sharing. Change default links from “anyone with the link” to “specific people”; restrict anonymous and personal-domain sharing; set expiry dates on external links. Leaks via “the link that was meant to be temporary” are everyday reality.
8. Email protection: SPF, DKIM, DMARC + anti-phishing policies. DMARC at reject protects your domain from spoofing; impersonation protection policies in Defender catch “CEOs” writing from Gmail. Tag external mail.
9. Logging and retention. Make sure the unified audit log is enabled and that sign-in and activity logs flow to a SIEM/archive for at least 90–180 days. Without this, incident analysis ends with “we don’t know” — more in our piece on monitoring for SMEs.
10. Back up your M365 data. Microsoft ensures service availability, not recovery of your data in every scenario (malicious/accidental deletion, ransomware encrypting files through a sync client, a hijacked account purging SharePoint). Retention and the recycle bin are not a backup — the 3-2-1 strategy applies to the cloud too.
How to approach it organisationally
The rollout order that works in practice: first measure (Microsoft Secure Score plus a review of sign-ins and app consents), then quick wins with no user impact (alerts, forwarding block, separate admin accounts), then changes that need communication (disabling legacy auth, new MFA policies) — piloted on the IT team before the company-wide rollout. Document everything: for NIS2 or an ISO audit you’ll need the evidence.
If you want external verification, our security audit reviews M365 tenant configuration against exactly these points — including testing whether the existing policies can be bypassed.
Frequently asked questions (FAQ)
We’re on Business Standard without Entra ID P1. What can we do? Quite a lot: enforce MFA via security defaults, disable legacy auth at the service level, restrict app consents, configure DMARC, alerts and SharePoint sharing. Conditional access and Identity Protection require P1/P2 — and that alone often justifies the upgrade for privileged accounts.
Are security defaults enough instead of conditional access? For a small company without an IT department — they’re a good start (they enforce MFA and block legacy auth). More mature organisations need conditional access, because security defaults allow no exceptions, per-app policies or device requirements.
How do we check whether someone is already inside our tenant? The quick minimum: review sign-in logs for unusual countries and clients, mailbox rules on key people’s accounts, OAuth app consents (especially with mail permissions), and devices and MFA methods recently added to VIP accounts. Found something suspicious? Treat it as an incident — we can help as part of incident response.
What about service accounts and automations that “must” have a password without MFA? Replace them with managed identities or app registrations using certificates instead of passwords, restrict permission scopes and source addresses. An MFA exception for a broadly privileged service account is attackers’ favourite side door.
How long does it take to clean all this up? The review and quick wins: 1–2 days of work. A full rollout with communication, a pilot and exceptions: usually 2–6 calendar weeks. It’s one of the best effort-to-risk-reduction ratios we know.
Summary
M365 security is 90% configuring what you already pay for: MFA with conditional access, legacy protocols disabled, app consent under control, alerts on mailbox rules, sane sharing defaults and logs that someone actually reads. These ten points close the paths attackers really use. Want to know how your tenant scores against this list? Book an M365 configuration review — within days you’ll get a gap map and a plan to close them.
