No Microsoft 365 tenant is really secure out of the box. Over the past year I kept running into the same gaps in many environments. Admin MFA isn't applied consistently, emergency accounts have barely been tested, OAuth app controls are loose, and features like Copilot or the growing amount of sharing in SharePoint bring new risks. With 2024 coming to an end, I'm going back over my Microsoft 365 security baseline and tightening the configurations that tend to drift in day-to-day operations.

Admins and emergency accounts need phishing-resistant MFA

I don't compromise on strong authentication. I still come across tenants where admins can use SMS or a phone call for MFA, and that simply isn't good enough in 2025. For every privileged role, the baseline is a phishing-resistant method. That means FIDO2 security keys, certificate-based authentication (CBA), or Microsoft Authenticator with number matching plus anti-phishing. On top of that you need at least two emergency access accounts. They are secured with FIDO2 or CBA only, never synced from on-prem, and excluded from the regular Conditional Access policies (but tested regularly). I don't treat this as optional, especially after the lessons from Storm-0501 and Microsoft's Zero Trust overview.

If you haven't reworked your break-glass strategy yet, my approach is described in [/blog/emergency-access-accounts-entra-id-break-glass]. One rule matters more than the rest. A synced on-prem admin account has no business in a cloud privileged role, ever.

Conditional Access covers the essentials and blocks device code flow

Conditional Access (CA) carries every security baseline, provided someone actually configures it. I always start with the essentials. MFA is enforced for all users outside trusted locations, legacy authentication is blocked, emergency accounts get clearly defined exceptions, and device code flow is blocked. People tend to skip that last one. This OAuth grant scenario is still a common way in for attackers, as Midnight Blizzard showed. Blocking device code flow takes little effort and has a big effect. I wrote up the steps in [/blog/conditional-access-block-device-code-flow].

Pro tip: Run new Conditional Access policies in "report-only" mode first, watch what they would do, and only then switch to enforce. That way you avoid accidental lockouts and broken workflows.

If you want a practical CA starter set, have a look at my post [/blog/conditional-access-entra-id-getting-started] and Microsoft's Conditional Access planning guide.

OAuth app governance got more urgent after Midnight Blizzard

OAuth consent remains a weak spot in a lot of tenants. I find unused apps with high privileges, too much user consent and no policy guardrails. Every tenant I review has a few forgotten apps with far more access than they need, or legacy apps that should have been retired long ago. In my view, auditing Entra ID → Identity → Applications → Enterprise Applications on a regular schedule and setting consent policies is now mandatory. Defender for Cloud Apps (Defender XDR, Plan 2) adds another layer of visibility and control. My post [/blog/app-governance-defender-cloud-apps-oauth] covers the practical steps.

In workshops I use this simple diagram to show how the OAuth consent attack path works:

flowchart TD
Attacker["Attacker"] --> PhishLink["Phishing link"]
PhishLink --> User["User"]
User --> Consent["OAuth consent"]
Consent --> App["Malicious app"]
App --> DataAccess["Data access"]

Figure: How attackers abuse malicious OAuth consent to get at cloud data.

Defender for Office, external forwarding and tamper protection deserve a regular check

The Defender for Office 365 preset policies (Plan 1 and up) are the foundation, yet I still find them switched off or overridden by weaker rules. I always check that the preset security policies are active and not being bypassed (details in my post). Blocking external forwarding in Exchange Online belongs on the list too, because data exfiltration through mailbox rules is still a real threat (more on that here). On endpoints, Defender tamper protection should be enforced on all managed devices, through either Intune or the Defender portal (roll-out steps here).

BitLocker recovery keys need a close look as well. After rushed deployments I often find gaps, such as devices missing from escrow or keys that can't be retrieved in Entra ID or Intune. In a crisis (ransomware, for example), that oversight gets expensive. I collected some recovery tips in [/blog/crowdstrike-outage-bitlocker-recovery-lessons].

Backups and data loss protection decide whether you can recover

Microsoft 365 Backup is now generally available for Exchange, SharePoint and OneDrive (setup guide here), so I always check two things. Are the core data sources actually protected, and is there a real recovery plan beyond versioning and recycle bins? In Azure, I make sure backup vaults are set to immutable so they hold up against ransomware. It's a simple step, and an important one (more here).

The list is short, but without these points you aren't resilient. Out-of-the-box retention isn't enough, and I've seen too many companies find that out the hard way.

Copilot turns oversharing into a practical problem

As Microsoft 365 Copilot reaches more users, oversharing has become something I deal with in real projects. Many tenants still have SharePoint permissions that aren't scoped tightly enough, broad search boundaries, or DLP policies that don't reflect how people actually work. During pilots, the "Restricted SharePoint Search" feature is a lifesaver, because it keeps Copilot from surfacing sensitive data by default (see my guide).

Sensitivity labels in Purview now have to cover Copilot scenarios as well, and audit logs for Copilot interactions should be switched on early for compliance reasons (more here and [/blog/copilot-interactions-audit-retention-purview]).

I treat the baseline as work that never really ends

There's no perfect Microsoft 365 security baseline, because the target keeps moving. Still, the points above are fixed for me going into 2025. New attacks and new features will keep coming, but I won't give ground on these basics. Real risks stay under control when you review your baseline regularly, adjust it and keep it documented. Most of the gaps I find aren't technical at all. They come down to attention and follow-through. Baseline work is never really finished, and that's exactly what makes this job interesting and demanding at the same time.