This is the critical tier: the controls I will not hand a tenant to a client without. If one of these is missing I consider the environment unfinished and I say so in writing. I walk them in the order the estate actually depends on them, which means privileged access first, because everything else you configure is only as trustworthy as the accounts allowed to change it. Each item carries the reasoning, the exact thing to set, and the way you prove it is set.
A word on what “critical” means here, because the word is abused. It does not mean hard, and it does not mean advanced. It means the cost of getting it wrong is a breach or a lockout, and there is no reasonable environment where I would leave it undone. The recommended and optional tiers, which the next article covers, are where judgment and licensing and appetite come into play. Here there is very little to debate. There is only whether it is done and whether you can show it.
Privileged access comes first
Before you enforce a single sign-in control you have to answer a prior question: who is allowed to turn these controls off, and what happens if you lock yourself out doing it. That is why privileged access leads. The two failure modes it guards against are opposite and equally fatal. One is the attacker who reaches a standing Global Administrator and owns the tenant. The other is the administrator who builds a flawless Conditional Access baseline, applies it to everyone, and discovers there is no account left that can sign in to fix it.
Emergency access accounts are the answer to the second failure, and their design changed in 2026. The pattern many of us learned, a long password printed and sealed in a safe and excluded from every policy, is no longer viable, because multifactor authentication on the administrative portals is now mandatory and carries no exception you can configure. The account that can only present a password cannot sign in when it matters. So the credential is now a passkey or a certificate, and the account is otherwise unchanged in intent: it exists to survive the failure of everything else.
| Setting | Value | Why |
|---|---|---|
| Account count and type | Two or more, cloud-only, on the tenant’s onmicrosoft.com domain | Survives federation, directory-sync, and custom-domain failures that would take down a normal account |
| Role assignment | Global Administrator, permanent and active (not eligible through PIM) | An eligible role behind an activation path you cannot reach is not emergency access |
| Credential | FIDO2 passkey or certificate-based authentication | Mandatory portal MFA allows no password-only path; the credential must be phishing resistant |
| Conditional Access | Dedicated group, excluded from blocking policies only | Report-only policies need no exclusion; a blanket exclusion from all policies is a standing hole |
| Monitoring | Alert on every sign-in | These accounts are used almost never; any sign-in is a drill or an incident |
With the safety net in place, the standing privilege comes down. Keep the number of Global Administrators small, in the range Microsoft itself warns about in the portal, meaning at least two so you are never locked out and fewer than five so the blast radius stays contained. Every one of those accounts is cloud-only, never a synchronized on-premises identity, because a privileged account that is synced inherits the on-premises directory’s compromises. And no privileged role holds a standing active assignment where Privileged Identity Management can make it eligible instead. Just-in-time activation is the difference between an attacker finding a live Global Administrator and finding an account that can request the role, with approval and an audit trail, if it can get past the activation controls at all.
Standing privilege is the thing attackers look for. Eligible-but-not-active is the thing they cannot use.
# Verify the privileged-access floor (Microsoft Graph PowerShell, read-only)
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"
# Global Administrator count should be >=2 and <5, all cloud-only
$ga = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
$members = Get-MgDirectoryRoleMember -DirectoryRoleId $ga.Id
$members | ForEach-Object {
$u = Get-MgUser -UserId $_.Id -Property userPrincipalName,onPremisesSyncEnabled
[pscustomobject]@{ UPN = $u.UserPrincipalName; Synced = [bool]$u.OnPremisesSyncEnabled }
}
# Expected: 2 to 4 rows, Synced = False on every one. A synced admin is a finding, not a footnote.Identity and access: the front door
With privilege contained, the baseline turns to how ordinary users prove who they are. The single most important control in the entire tenant is multifactor authentication for every user, and in 2026 the bar has moved from “any second factor” to “a factor that cannot be phished.” A one-time code delivered by text message satisfies the letter of MFA and fails its purpose, because it can be relayed to an attacker in real time by any competent phishing kit. Require MFA for all users, and where you can, require it through an authentication strength that names phishing-resistant methods, so the policy demands a passkey or a certificate rather than accepting whatever weak method a user happens to have. One caution on that strength: the built-in phishing-resistant preset does not include Temporary Access Pass, so a registration policy built on it locks out first-time enrollment. Build a custom authentication strength that includes passkeys and Temporary Access Pass for the bootstrap, and keep the stricter preset for steady-state access.
Say plainly what “all users” means, because the target architecture and the first policy you switch on are not the same object and conflating them is how this control gets rolled back in week two. Phishing resistance across the whole population is the end state and I do not soften it. The policy you enable first will meet the parts of the estate that cannot satisfy it yet: frontline and shared-device workers with nothing enrolled, guests whose credentials are governed by somebody else’s identity provider, service accounts that should have become workload identities years ago, and the enrolment path itself. Every one of those is an exclusion with a named owner and an expiry date, recorded where the next administrator will find it. That is the difference between a phased rollout and an abandoned one, and the test is simple: if an exclusion has no owner, it is not a phase, it is the architecture you ended up with.
This is also why the credential portfolio itself belongs in the critical tier now, not as a future aspiration. Microsoft is making passkeys the default authentication method as of September 2026, and it is retiring its own delivery of text-message and voice-call codes as of February 2027. An estate that has not enabled passkeys and moved its users off telephony-based methods before those dates is not merely behind on best practice, it is heading for an authentication outage on a schedule Microsoft has published. A temporary opt-out exists only for the window between those two dates, and none after the February 2027 retirement, so this is a dated migration to finish, not an improvement to consider. One nuance belongs here so that nobody meets it later and mistakes it for an escape hatch: a tenant that configures a customer-managed telecom provider through the Microsoft Security Store can keep using text message and voice past that date. It is a supported path and it is not the target state. Paying a second vendor to keep a phishable factor alive is a position you will have to defend to whoever asks, and the same effort spent on passkeys ends the conversation instead of renewing it annually. So enable the passkey method, disable text message and voice call as usable methods, and treat email one-time passcode as the narrower case it is, a self-service reset method for members whose use by guests is governed by a separate external-users setting and whose state cannot be turned off while that guest setting is on. Then complete the migration to the authentication methods policy so these choices live in one place rather than in the deprecated legacy settings.
The same policy engine has to close the oldest door in the building. Legacy authentication, the pre-modern protocols that cannot perform MFA at all, must be blocked, because a single account reachable over one of them is an MFA bypass for the whole tenant. Basic authentication follows it into the ground. And where the licensing reaches Entra ID P2, the risk engine earns its place, though the right action is more considered than a blanket block. Microsoft’s own current guidance is to remediate rather than block, and it is the more defensible default: a high-risk sign-in should be forced through a phishing-resistant MFA challenge with a fresh sign-in frequency, and a high-risk user should be required to change their password securely, so a legitimate user who trips the control recovers on their own while a genuinely compromised credential is stopped. In a passwordless estate a password change no longer remediates anything, so the right mechanism is Microsoft’s Require risk remediation control, which forces a secure password change where a password exists and revokes the user’s sessions and forces reauthentication where one does not. That is where our baseline lands: remediate by default, and let that control resolve the passwordless case rather than reaching for an outright block.
| Policy | Applies to | Control |
|---|---|---|
| Require MFA for all users | All users, all resources | Grant requires MFA through a phishing-resistant authentication strength, with named and dated exclusions where a population cannot yet meet it |
| Require phishing-resistant MFA for admins | Directory role holders | Grant requires the phishing-resistant strength, no softer fallback |
| Block legacy authentication | All users | Block for the legacy and other-client app types |
| Remediate high risk (P2) | All users | Risky sign-in requires phishing-resistant MFA; risky user uses Require risk remediation (secure password change, or session revocation and forced reauthentication when passwordless) |
All of this rests on Entra ID P1 for Conditional Access and P2 for the risk policies. If the tenant genuinely has neither, the free floor is Security Defaults, and the next article treats that honestly. But for any licensed estate, this set is the front door, and it is not optional.
# Verify the identity floor (read-only)
Connect-MgGraph -Scopes "Policy.Read.All","UserAuthenticationMethod.Read.All"
# Security Defaults should be OFF once a Conditional Access baseline exists
(Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy).IsEnabled # Expected: False (CA present)
# Passkey enabled, phone-based methods disabled
$amp = Get-MgPolicyAuthenticationMethodPolicy
$amp.AuthenticationMethodConfigurations |
Where-Object Id -in 'Fido2','Sms','Voice','Email' |
Select-Object Id, State
# Expected: Fido2 = enabled; Sms and Voice = disabled. Email cannot report disabled while the
# external-users email-OTP setting is on, so check that setting rather than the method state alone.
# Conditional Access baseline present and enforcing (not report-only)
Get-MgIdentityConditionalAccessPolicy |
Select-Object displayName, state |
Sort-Object displayName
# Expected: the MFA-all-users and block-legacy-auth policies show state = enabledApplication trust: the consent you never think about
The attack that bypasses every authentication control you just built is the one that never touches a password. An OAuth application that a user is tricked into consenting to holds a token that survives password resets and, depending on the permission, does not re-prompt for MFA. This is the illicit consent grant. Microsoft has tightened the consent default, so an un-customized tenant now uses its recommended policy, which already restricts user consent to lower-risk permissions, but application registration is still open to every user by default and the consent posture is still worth owning rather than inheriting. Two settings make it explicit, and both belong in the critical tier because the exposure is silent and directory-wide.
Restrict application registration so that ordinary users cannot create app registrations, which removes an entire class of tenant-resident foothold. Then restrict user consent so that users can consent only to applications from verified publishers and only for low-impact permissions, or not at all, with anything beyond that routed to an administrator through the consent request workflow. The effect is not to stop the business from adopting software. It is to move the decision to consent to real data access from every individual user to a small number of people who are equipped to judge it.
# Verify application trust (read-only)
Connect-MgGraph -Scopes "Policy.Read.All"
$authz = Get-MgPolicyAuthorizationPolicy
$authz.DefaultUserRolePermissions.AllowedToCreateApps # Expected: False
$authz.PermissionGrantPolicyIdsAssignedToDefaultUserRole # Expected: a low-impact grant policy, or empty (consent off)External trust: the guests already in the building
Every tenant that collaborates has guests, and the default guest can read more of your directory than most administrators realize. A guest cannot pull a list of everyone, but they can look up an individual user’s details and read the membership of non-hidden groups, which is still useful reconnaissance and free to any guest unless you close it. The single critical control here is to restrict guest access to the most limited level, where a guest can see their own profile and the specific objects shared with them and nothing else. It costs the business nothing, because legitimate collaboration works on shared resources, not on browsing your directory, and it removes a mapping capability that attackers value.
The wider external-trust posture, who may invite guests, which domains are permitted, and how cross-tenant access is defaulted, is important and belongs in the recommended tier the next article covers. But the guest access level itself is critical, because it is on by default in the permissive direction and its cost to close is zero.
Tenant governance: deciding what Microsoft already decided
The last critical item is not a switch, it is a decision you have to make consciously because Microsoft is making it for you if you do not. On a licensed tenant, Conditional Access replaces Security Defaults, and the two should not run in a confused overlap; once your Conditional Access baseline exists, Security Defaults comes off. More importantly, Microsoft now deploys its own managed Conditional Access policies into your tenant in report-only mode and enables them automatically after a notice period. That is a genuine improvement in the floor, and it is also a set of enforcing controls arriving on a date you did not choose.
The critical action is to review each managed policy before it flips to enforcing, decide deliberately whether its scope matches your estate, and, above all, confirm your emergency access accounts are excluded from the ones that block. This is where the privileged-access work at the top of this article closes the loop: the managed policies are exactly the kind of blanket enforcement that can lock you out, and the break-glass exclusion is what keeps that from happening. Accepting Microsoft’s baseline is a legitimate decision. Letting it enforce on your tenant without having read it is not.
The critical settings, in brief
Every item above, as a list you can set against. This is the critical tier only. The recommended and optional settings are in the next article, and the whole wave is gathered in the Quick Checklist.
| Domain | Setting | Set it to |
|---|---|---|
| Privileged Access | Emergency access accounts | Two or more, cloud-only on onmicrosoft.com, FIDO2 or certificate, excluded from blocking CA only, sign-in alert |
| Privileged Access | Global Administrators | Two or more and fewer than five, all cloud-only |
| Privileged Access | Privileged role assignments | Eligible through PIM, no standing active (P2) |
| Identity & Access | MFA | Required for all users (P1) |
| Identity & Access | Authentication strength | Phishing-resistant for all users; a custom strength that includes TAP for registration |
| Identity & Access | Admin authentication | Phishing-resistant MFA for directory roles |
| Identity & Access | Passkey (FIDO2) method | Enabled |
| Identity & Access | SMS and voice methods | Disabled |
| Identity & Access | Authentication methods migration | Complete |
| Identity & Access | Legacy and basic authentication | Blocked |
| Identity & Access | High risk | Require risk remediation (P2) |
| Application Trust | User application registration | Disabled, admins only |
| Application Trust | User consent | Verified publishers and low-impact only, or off |
| External Trust | Guest access level | Most restrictive |
| Tenant Governance | Security Defaults | Off once a CA baseline exists (P1) |
| Tenant Governance | Microsoft-managed CA policies | Reviewed, decided, break-glass excluded |
That is the critical tier. None of it is exotic, and that is the point. The difference between a tenant I would sign off on and one I would not is rarely some advanced capability. It is whether these unglamorous controls are present, correct, and provable. The next article takes up the recommended and optional tiers, where the same domains reappear with more room for judgment, and where the work shifts from what you must do to what a careful architect does by default.
Best Practices
‹ Previous: [BP 1] Best Practices, Owned: What a Baseline Is For
Next: [BP 1.2] The Entra ID Baseline: Recommended and Optional Tiers ›
