A best practice you cannot defend is just a setting you copied from someone else’s tenant. This series is my attempt to fix that. Every item in it carries the reasoning, the exact object to create, and the way you prove it stayed true, because a baseline is not a list of switches. It is a set of decisions about who holds each control, and those decisions are the only part worth writing down.
The problem with “best practices”
The phrase has decayed. Somewhere in the last decade “best practices” stopped meaning a considered position and started meaning a spreadsheet, passed between consultants, applied to tenants that share nothing but a license SKU, and defended by no one. I have inherited these lists. They are recognizable by their symptoms: a setting is enabled because the checklist said so, nobody in the building can tell you what breaks if it is off, and half the entries describe a portal that Microsoft moved two quarters ago. The list ages in silence. It is treated as authoritative precisely because no one remembers deciding anything.
I want to be careful here, because the reaction to that failure is usually worse than the failure. People conclude that best practices are a myth, that every environment is a snowflake, that judgment cannot be written down. That is an excuse for never committing to a position. Environments differ in their constraints, not in their physics. The same threats, the same identity platform, and increasingly the same defaults apply whether the tenant has two hundred seats or twenty thousand. What differs is what you are willing to own, what you are willing to delegate, and what you are willing to break. Those are decisions, and decisions can absolutely be documented and defended. The document just has to be honest about being a set of decisions rather than a set of commandments.
A baseline is not the settings. It is the record of which controls you decided to own, which you handed to Microsoft, and which you consciously refused.
The question inverted while we were arguing
For years the complaint about Microsoft’s cloud was that it shipped nothing opinionated. The platform gave you a thousand switches and no stance, and the entire cottage industry of tenant hardening existed to fill that vacuum. That era is over, and a lot of published guidance has not noticed. Microsoft now ships opinionated baselines of its own, several of them, layered and occasionally overlapping, and the interesting work has moved from “what should I configure” to “what has Microsoft already configured on my behalf, and do I agree with it.”
Consider the layers a new tenant now arrives with or acquires quickly. Security defaults, the free baseline, has been switched on for new tenants since 2019 and enforces multifactor registration and blocks the oldest authentication protocols without anyone lifting a finger. Above that sit the Microsoft-managed Conditional Access policies, which the platform now deploys into your tenant in report-only mode and then enables automatically after a notice period unless you intervene. Above that again is Baseline Security Mode, a newer construct in the Microsoft 365 admin center and wider than identity because it reaches Exchange, SharePoint and Teams as well, which lets you enforce phishing-resistant authentication for admins, block legacy authentication flows, and restrict application consent, each turned on deliberately with its own impact report rather than by Microsoft on your behalf, and available across the subscription tiers. Where two of its controls surface as Conditional Access policies in Entra they are attributed to Baseline Security Mode rather than to Microsoft, which is the tell that you created them and can therefore be asked to defend them. And running underneath all of it, mandatory multifactor authentication on the admin portals is no longer a recommendation you may adopt. It is enforced, and there is no opt-out to configure.
This changes the job. A tenant is no longer a blank slate you harden. It is a slate that Microsoft has already begun writing on, in pencil that turns to ink on a schedule, and your responsibility is to read what is there, decide item by item whether Microsoft’s position matches yours, and take ownership of the difference. Sometimes their default is exactly right and adopting it is the correct, unglamorous answer. Sometimes it is close but scoped wrong for your estate. Sometimes it will actively break a workload you cannot move yet, and you need to know that before the report-only policy flips to enforcing on a date you did not choose. Accepting a Microsoft default is a legitimate decision. Accepting it without knowing you did is not.
Accepting a Microsoft default is a legitimate decision. Accepting it because you never noticed it was made for you is an abdication.
Three references, and why I trust them differently
I anchor this work to three external reference points, and I use each of them for a different reason. Being explicit about which one carries authority and which one carries convention matters, because they are not interchangeable and treating them as one blurred mass of “the guidance” is how you end up defending settings you never chose.
The doctrinal spine is CISA’s Secure Cloud Business Applications baseline, the one born out of the federal response to the identity attacks of the early decade. I lean on it because it is opinionated in the way a baseline must be, it is versioned and product-specific rather than aspirational, it is mandatory for United States civilian agencies and therefore carries real institutional weight rather than a vendor’s marketing preference, and it is placed in the public domain, which means I can quote it, map my own tiers onto its control identifiers, and hold my recommendations against it in the open. When I say a setting belongs in the critical tier, I want to be able to point at where a government that got attacked decided the same thing.
The second reference is the CIS Microsoft 365 Foundations Benchmark, and I use it differently. It is the language auditors and cyber-insurance questionnaires speak, so it is the lingua franca for the conversation you will actually have with a risk committee. But its license is restrictive, so you will never see me reproduce its text. I cite it by recommendation number and paraphrase the intent in my own words, and so should you. Its value is as a cross-reference and a translation layer, not as source material to be copied.
The third is not a document at all. It is Maester, the open-source test framework that turns a tenant’s configuration into something you can run assertions against, on a schedule, with an alert when it drifts. I treat it as the reference for a claim that most published guidance quietly avoids: that a baseline you cannot continuously verify is not a baseline, it is a memory of how the tenant looked the afternoon you finished. This is the piece the checklists leave out, and it is the piece I will not.
You will notice a reference I do not anchor to. Microsoft Secure Score is a useful daily signal and a genuinely bad target. It is an optimization and measurement tool rather than a control baseline, it can be moved by marking a control as handled elsewhere, and two tenants with identical scores can have wildly different real postures, one of them carrying unmanaged exceptions and a recovery procedure nobody has ever tested. I read it. I do not design to it, and neither should you.
Three tiers, meaning three levels of obligation
Every article in this pillar sorts its items into three tiers, and the tiers are about obligation, not difficulty. The critical tier is the set of controls I will not hand a tenant to a client without. If one of them is missing, I consider the environment unfinished, and I will say so in writing. These are the settings where the cost of being wrong is a breach, and where I am prepared to argue the point rather than soften it. The recommended tier is the professional default: the configuration a competent architect reaches for unless a specific, named constraint says otherwise. Deviation here is allowed, but it is deviation, and it should be deliberate and recorded rather than accidental. The optional tier is genuine posture and preference, the settings where reasonable practitioners differ based on culture, tolerance, and appetite, and where my job is to lay out the trade rather than pick your side.
The point of the tiers is to stop the flattening that ruins most checklists, where the requirement to enforce phishing-resistant authentication for administrators sits in the same undifferentiated list as a preference about session lifetime, both marked with the same checkbox, both carrying the same implied weight. They do not carry the same weight. Telling you which is which, and being willing to defend the placement, is most of the value I have to add.
How these articles are built
A few conventions hold across the whole pillar, and they are deliberate reactions to how the existing material fails. I name durable things, never screen positions. I will tell you the exact policy type, the setting as it is actually labeled, and the values it takes, because those survive. I will not tell you which blade it lives under this month, because that decays before the ink dries and it trains you to click rather than to understand. Where a setting has a real branch, I show it as a small table of setting, value, and reason, so the reason travels with the choice. And where the work can be automated, each article carries one consolidated block of Graph or PowerShell that reproduces the section, rather than a scatter of one-liners, because the reader who wants to script it wants a thing they can lift, and the reader who wants to understand it is better served by prose anyway.
Every item also ends in a way you can verify. Not “this is now secure,” which is unfalsifiable and therefore worthless, but the specific observation, command, or test that proves the control is present and behaving. This is where Maester earns its place in the series rather than as a footnote. The honest end state of a baseline is not a configured tenant. It is a configured tenant plus the running check that tells you the day it stops being configured, because it will, and the only question is whether you find out from your own alert or from someone else’s incident report.
This pillar does not re-teach the deep material. The identity series already covers the architecture of Entra ID, and the Conditional Access work already covers policy design in depth. Where a baseline item rests on that foundation, I point at it rather than repeat it. What this series adds is the layer above the deep dives and above the raw checklists: a prioritized, defended position on what to actually set, why it sits in the tier it sits in, and how to know it held. We start where every tenant starts, with identity, because identity is the control plane the rest of the estate hangs from, and a baseline that gets identity wrong is not a baseline with a gap. It is a baseline with a front door left open.
Best Practices
Next: [BP 1.1] The Entra ID Baseline: The Critical Tier ›
