Why Microsoft 365’s Baseline Security Mode Is a Migration Target, Not a Flip Switch

Microsoft 365’s new Baseline Security Mode is an opt-in, secure-by-default bundle of 18 configuration settings across authentication, files, and room devices, exposed in Org settings → Security & privacy. It’s a better attempt at secure-by-default than Security Essentials.

But this convenience hides some judgment calls you can’t outsource to a wizard. Don’t get me wrong here, I love a good wizard.

Baseline Security Mode is a sensible direction for most Microsoft 365 tenants, but it is not something I would enable blindly. If your environment still depends on legacy authentication, overlapping Conditional Access policies, old Office workflows, or special-case meeting room devices, the real work starts before you switch anything on.

That is why I see Baseline Security Mode as a migration target, not a shortcut. Microsoft is right to centralize controls that admins have historically managed across Entra, Exchange, SharePoint, Office, and Teams, and features such as simulation mode and impact reporting should make adoption easier. But those tools do not replace the need to map dependencies, remove duplicated policy logic, and decide where exceptions are genuinely justified.

The biggest deployment mistakes will not come from misunderstanding the settings. They will come from assuming the wizard has already done the thinking for you.

Legacy authentication is where Baseline Security Mode breaks first

Authentication is where the baseline does most of its work, especially on legacy protocols and app‑to‑app authentication. Recommendations include blocking new password credentials for app registrations, turning on restricted user consent, blocking Exchange Web Services and basic authentication prompts, and shutting down legacy browser auth paths to SharePoint and OneDrive.

The problem is not the goal; it is the order of operations. Many tenants still have scanners, backup tools, or internal apps using Exchange Web Services (EWS), basic SMTP, or old SharePoint protocols. Not taking these into account in advance of deploying these policies is a common mistake. I’m consulting with an MSP now where I found a bunch of apps still registered in Entra with passwords. All of these things have to be dealt with first.

Microsoft-managed Conditional Access can leave you with two sources of truth

Security Baseline conditional access policies are mostly implemented by Microsoft‑managed Conditional Access policies that sit alongside your existing CA strategy. You can usually only switch them On or Off and define exclusions; all the interesting bits—the conditions and controls—are locked.

This is fine in a greenfield tenant, but you probably already have “block legacy auth,” “require MFA for admins,” or “restrict high‑risk sign‑ins” policies, if you implement these you now have two sources of truth. Duplications are never a good idea.

Office hardening will expose workflow debt you have been carrying for years

The Files portion of the baseline leans on the Office security baselines for Microsoft 365 Apps: opening ancient formats in Protected View, blocking editing of older formats, disabling ActiveX and some OLE objects, and turning off DDE server launch in Excel. These settings are there to kill off entire classes of Office‑based attacks, and they’re aligned with the long‑standing Windows and Office security baselines. You need these policies and I’m happy to see them here because a lot of MSPs don’t protect office from abuse.

Where it gets interesting is the long tail of “weird” Office use. Departments that still rely on complex Excel models with DDE links, embedded legacy charts, or macros built against older file formats often discover the baseline when their workbook stops working. Not to mention users who are using old .xls files as templates thus saving new files with old file types.   

Meeting room exceptions can quietly undo the security benefit

Baseline Security Mode also includes protections for meeting room devices, such as blocking unmanaged Teams Rooms devices and tightening how they connect. Those controls matter now that meeting devices are effectively dedicated endpoints with cameras, microphones, and access to internal meetings. These are popular targets and absolutely need to be protected.

The implementation problem for admins is how you handle exceptions like partner‑provided rooms, executive boardrooms with bespoke AV gear, or legacy room systems that do not fit neatly into Teams Rooms management. We have all gotten those emergency calls where users can’t seem to log into Teams in the conference room and somehow that meeting is always going to end the company if it doesn’t start on time. It is very easy to carve out permanent exceptions for these “special” cases and end up with exactly the kind of unmanaged, unmonitored meeting endpoints the baseline was trying to fix. Beware of your exceptions.

How I’d actually use Microsoft 365 Baseline Security Mode

I might trigger the haters for this, but I would switch up my policies to align with Microsoft’s vision here, even with the gotchas. Why? Because Microsoft managed policies are the future and unlike Security Essentials which was fixed, the Security Baseline is going to continue to grow, change and be aligned with modern threats.

First remove legacy dependencies, rationalize overlapping Conditional Access policies, and define which exceptions are truly temporary. If you cannot explain why a workload needs to sit outside the baseline, that is usually a sign the dependency needs to be fixed before rollout.