The critical tier is where there is nothing to debate. This is where judgment returns. The recommended tier is what a careful architect sets by default, and deviating from it is allowed as long as the deviation is deliberate and written down rather than accidental. The optional tier is genuine preference, the settings where reasonable people differ on culture and appetite, and where my job is to frame the trade rather than make the call for you. I walk the same domains as the critical tier, because the point of the control-plane structure is that each domain reappears at every level of obligation.
Privileged access, past the floor
The critical tier put standing privilege behind just-in-time activation. The recommended tier makes that activation mean something. Require approval to activate the Global Administrator role, so that reaching the most powerful role in the tenant leaves a second person’s fingerprint on the decision. Require a phishing-resistant method at the moment of activation, not merely at sign-in, because the gap between signing in and elevating is exactly where a hijacked session tries to escalate. Turn on the alerts that Privileged Identity Management can raise on assignment and activation, and route them somewhere a human reads. And put the privileged roles under a recurring access review, because the population of people who should be able to become an administrator is not static, and the only way it stays correct is to recertify it on a schedule rather than to discover it during an incident.
All of this assumes Entra ID P2, which is where Privileged Identity Management lives. If the estate is licensed for it and not using it, that is not a gap in a nice-to-have. It is paying for a control and leaving it in the box.
Identity and access, the hygiene layer
The critical tier required strong authentication. The recommended tier makes it pleasant enough that people do not fight it, and durable enough that it does not quietly decay. Configure Microsoft Authenticator to show the application name and the sign-in location on the prompt, because a prompt that carries context is a prompt a user can reason about, and reasoning is what defeats fatigue-based approval attacks. Keep system-preferred authentication on so the platform steers each user to their strongest registered method automatically. Enable Temporary Access Pass so that onboarding a new user, or recovering one who has lost their credential, does not require falling back to a password. And run a registration campaign that nudges users onto the Authenticator app and passkeys, so the estate is drifting toward phishing-resistant methods as a matter of course rather than waiting for a project.
On the Conditional Access side, the recommended additions are about session and device rather than the initial factor. Set a sign-in frequency and turn off persistent browser sessions for administrators, so a privileged session does not live indefinitely on a machine you do not control. Where Intune is in the picture, require a compliant or managed device for access, which turns the device itself into part of the grant decision. And adopt the Microsoft-managed Conditional Access policies deliberately, moving each from report-only to on once you have confirmed its scope, rather than letting the clock decide for you.
Password policy is the part of this domain that most estates get exactly backwards. Set cloud passwords to never expire, because forced rotation is the single most reliable way to drive users toward weak, predictable, incrementing passwords, and the modern guidance from Microsoft and the standards bodies alike is to stop expiring them. Then put the strength where it belongs: turn on Entra Password Protection in enforced mode with a custom banned-password list seeded with your organization’s obvious guesses, and tune smart lockout so that password spray is slowed without locking out the humans. Those two numbers, ten attempts and sixty seconds, are Microsoft’s own defaults rather than a house preference, and the guidance is to hold or tighten them rather than to loosen. The trap is hybrid. Where pass-through authentication is in play the cloud lockout has to trip before Active Directory’s does, which means the Entra threshold must be lower than the on-premises one, with the domain threshold set two to three times higher and the domain duration shorter than the cloud duration. Set the two independently and you get the hardest lockout to diagnose there is: an account locked in Active Directory by attempts the cloud absorbed silently. Enable self-service password reset with at least two strong methods and a protected registration path, and treat security questions as do-not-use rather than a fallback, since they retire as a self-service reset method in March 2027, so recovery does not become the weak link you spent all this effort avoiding.
| Setting | Value | Why |
|---|---|---|
| Password expiration | Never expire | Forced rotation drives weak, predictable passwords; the standards now advise against it |
| Entra Password Protection | Enforced mode, custom banned list populated | Blocks the organization-specific passwords an attacker guesses first |
| Smart lockout | Threshold 10, duration 60 seconds or more | Slows password spray without locking out real users |
| Self-service password reset | Enabled, two or more strong methods, protected registration | Recovery without a helpdesk call, as long as the registration itself is protected |
Finally, close out the risk domain the critical tier opened. Turn on the notification that emails administrators when Identity Protection flags high-risk users, so the signal reaches someone. And migrate any legacy standalone risk policies into Conditional Access, so risk is evaluated in one engine alongside every other condition rather than in a separate, aging surface, which the platform will force in any case when those legacy risk policies retire on October 1, 2026.
Application trust, and the credentials apps carry
The critical tier stopped ordinary users from registering and consenting to applications. The recommended tier governs the applications that legitimately exist. Stand up the admin consent request workflow so that when a user needs an app that exceeds the low-impact bar, the request routes to a reviewer instead of dying silently or, worse, being worked around. Restrict the consent that group owners can grant on behalf of their groups, which is a quieter version of the same user-consent hole. And treat application credentials as the secrets they are: block the addition of new password credentials to applications where you can, prefer certificates, and put the enterprise applications and their service principals under periodic review so that stale, over-permissioned, or forgotten app identities are found and removed rather than accumulating as a shadow attack surface.
A service principal nobody remembers creating, holding a secret nobody rotates, is the calmest way into a tenant. Review is the only thing that finds it.
External trust, the collaboration perimeter
The critical tier closed the guest’s ability to read your directory. The recommended tier decides who gets in and from where. Limit guest invitations to specific administrative roles rather than leaving every user able to invite the outside world, so that bringing a guest into the tenant is a governed act. Allow-list the external domains you actually collaborate with where the business permits it, which turns an open door into a known set of doors. Set the default cross-tenant access posture to block inbound and outbound and then permit specific partner tenants deliberately, so a new external relationship is a decision rather than a default. Two consequences are worth knowing before you set it, because both produce tickets that look like faults. Blocking inbound access does not stop an invitation being sent or redeemed; it stops the token, so the guest signs in perfectly well and then finds nothing they can open. And entitlement management’s connected organizations depend on inbound collaboration being permitted for the tenants they represent, so an allow list that omits one breaks access requests rather than merely narrowing them. Note also what you are not deciding here: business-to-business direct connect, the mechanism behind Teams shared channels, is already blocked in both directions for every external tenant by default, so a deny-by-default posture is not the thing that closes it. And put guest accounts under a recurring access review, because guests are the population most likely to outlive their reason for existing, and the leaver process that covers your employees rarely covers someone else’s.
The sequence matters here, and the sequencing article takes it up in full: tightening cross-tenant defaults after partners are already onboarded carries real blast radius, because every relationship that relied on the old default is affected at once. On a new tenant you set this posture before the first guest arrives. On an existing one you audit before you tighten.
Devices, self-service, and the sprawl you inherit
Two device settings belong in the recommended tier. Scope who may join devices to Entra ID rather than leaving it open to everyone, noting that join offers only All or Selected and that the None people go looking for belongs to device registration, and require multifactor authentication to register or join through the Conditional Access user action, which is the current mechanism and has superseded the old device-settings toggle that many guides still cite. Alongside it, do not let the joining user become a standing local administrator; remove that default and manage local administrator credentials with Windows LAPS, so a compromised user is not automatically a compromised machine.
The self-service and directory defaults are where a tenant quietly sprawls. By default, ordinary users can create tenants, create security groups, create Microsoft 365 groups, and read the entire directory. Turn off user creation of tenants and security groups, and scope Microsoft 365 group creation to an approved group rather than the whole company, remembering that this last one lives in the Microsoft 365 groups directory setting and not in the general authorization policy, a distinction that trips up automation. Restrict non-administrators from the Entra administration portal, and stop group owners from adding and approving their own members. None of these are dramatic on their own. Together they are the difference between a directory you govern and one that governs itself in directions you did not choose.
# Verify the self-service and directory defaults (read-only)
Connect-MgGraph -Scopes "Policy.Read.All"
$p = (Get-MgPolicyAuthorizationPolicy).DefaultUserRolePermissions
$p.AllowedToCreateApps # Expected: False (also a critical-tier item)
$p.AllowedToCreateSecurityGroups # Expected: False
$p.AllowedToReadOtherUsers # Default True; restrict only with a specific reason
# Microsoft 365 group creation is a DIRECTORY SETTING, not the authorization policy:
# directorySetting 'Group.Unified' -> EnableGroupCreation = false + GroupCreationAllowedGroupId set
Get-MgBetaDirectorySetting | Where-Object TemplateId -eq '62375ab9-6b52-47ed-826b-58e47e0e304b' # requires the Microsoft.Graph.Beta module; v1.0 has no Get-MgDirectorySettingMonitoring and response
A baseline that cannot be seen cannot be defended. Stream the Entra sign-in and audit logs to wherever your security operations actually look, whether that is Microsoft Sentinel, a Log Analytics workspace, or an event hub feeding a third-party platform, because the default retention in the portal is too short to investigate anything that matters. Export the categories that carry signal: interactive and non-interactive sign-ins, audit, risky users, service principal sign-ins, and provisioning. Confirm the unified audit log is on, which is easy to assume and occasionally false, because it ships on for enterprise tenants but not for the Business SKUs or trial tenants, so on a smaller estate this is a real check rather than a formality. Keep Continuous Access Evaluation enabled so that a revoked session or a risky change is acted on in near real time rather than at the next token refresh. And build a small number of high-signal alerts, on the creation of a Conditional Access policy, a change to a privileged role, a new credential added to an application, and any break-glass sign-in, so that the events most worth knowing about reach a person quickly.
Tenant governance, and who owns the drift
The critical tier forced the conscious choice between Security Defaults and Conditional Access and the deliberate review of Microsoft’s managed policies. The recommended tier adds the newest of Microsoft’s baselines and, more importantly, adds an owner. Work through Baseline Security Mode setting by setting, adopting what fits and consciously declining what does not, rather than accepting or ignoring it wholesale. Then name a person accountable for identity posture and its drift, because a baseline with no owner is a baseline that was true on the day it was built and has been decaying quietly ever since. And commit to testing the baseline on a schedule, which is where the verification article that closes this wave takes over: the honest end state is not a configured tenant, it is a configured tenant plus the running check that tells you the day it stops being configured.
One more piece of governance belongs here, because it is easy to assume the platform already does it for you. Entra ID Backup and Recovery is on by default on the paid tiers, and its scope is narrower than the name suggests. It takes one snapshot a day, keeps seven days of history, and covers rather more than “directory objects” suggests: users, groups, applications and service principals, but also Conditional Access policies, named locations, and selected properties of the authentication method and authorization policies. It does not recover hard-deleted objects, it does not cover identities synchronized from on-premises, and it reaches none of the mailbox, OneDrive, or SharePoint data most people mean when they say backup. Treat it as a fast undo for accidental directory changes, run a difference report before you restore anything, assign Backup Reader and Backup Administrator deliberately rather than leaving the capability sitting inside Global Administrator, and keep a separate, deliberate process for hard-deletes, hybrid objects, and workload data, whether that is a third-party or multi-tenant backup or a documented manual runbook. Knowing exactly what the built-in protection does and does not cover is the control here, because the failure mode is discovering the gap during a recovery.
The optional tier: posture and preference
Everything above is what I would set by default. The optional tier is where I lay out choices and let the environment decide. Some estates will require device-bound passkeys and Windows Hello for Business rather than accepting synced passkeys, which is the right call for regulated and high-assurance populations and an unnecessary friction for others. Some will block the authentication transfer flow outright, cap application secret and certificate lifetimes to aggressive windows, and deploy the on-premises Password Protection agents to extend the banned-list enforcement to domain controllers. Some will trust a partner’s multifactor or device claims to smooth a specific collaboration, which is a convenience worth its risk only when the partner is genuinely trusted. Others will reach for tenant restrictions to control what their users can reach in other tenants, set a maximum device count per user, restrict who can recover a BitLocker key, disable the LinkedIn account connection and self-service trial sign-ups, or put an expiration and naming policy on Microsoft 365 groups.
There is one optional setting I will name specifically because it is a trap dressed as hardening. Restricting ordinary users from reading other users in the directory sounds like an obvious tightening, and it breaks a surprising number of applications and experiences that assume a readable directory. Leave it at its default unless you have a concrete requirement to hide the directory and have tested what that does to the estate. That is the shape of the optional tier in general: real levers, each with a cost, none of them a default I would impose on an environment I had not met.
The recommended settings, in brief
The recommended tier as a list you can set against. The optional tier stays in the prose above, because it is preference rather than a default I would impose. The whole wave, both tiers and the critical one, is gathered in the Quick Checklist.
| Domain | Setting | Set it to |
|---|---|---|
| Privileged Access | Global Admin activation | Requires approval (P2) |
| Privileged Access | PIM activation | Requires phishing-resistant MFA (P2) |
| Privileged Access | PIM alerts and role reviews | Alerts routed; recurring access reviews (P2) |
| Identity & Access | Authenticator prompt | Show application name and location |
| Identity & Access | System-preferred MFA | On |
| Identity & Access | Temporary Access Pass | Enabled |
| Identity & Access | Registration campaign | On, Microsoft-managed |
| Identity & Access | Admin sessions | Sign-in frequency set, persistent browser off (P1) |
| Identity & Access | Microsoft-managed CA policies | Adopted deliberately, report-only to on |
| Identity & Access | Compliant or managed device | Required for access, with Intune (P1) |
| Identity & Access | Device code flow | Blocked |
| Identity & Access | Per-user MFA | Retired in favor of Conditional Access |
| Identity & Access | Password expiration | Never |
| Identity & Access | Entra Password Protection | Enforced, custom banned list (P1) |
| Identity & Access | Smart lockout | Threshold 10, duration 60 seconds or more |
| Identity & Access | SSPR | Enabled, two or more strong methods, no security questions |
| Identity & Access | Risk notifications | On; legacy risk policies migrated to CA (P2) |
| Application Trust | Admin consent workflow | Enabled with reviewers |
| Application Trust | Group-owner consent | Restricted |
| Application Trust | App password credentials | Blocked; prefer certificates |
| Application Trust | Enterprise apps and service principals | Reviewed periodically |
| External Trust | Guest invitations | Limited to specific admin roles |
| External Trust | External domains | Allow-listed |
| External Trust | Cross-tenant default | Block, permit partners deliberately |
| External Trust | Guest access reviews | Recurring (P2) |
| Device Trust | Device join | Scoped to Selected; None exists on device registration, not on join |
| Device Trust | MFA to join or register | Via the CA user action, legacy toggle off (P1) |
| Device Trust | Local admin on join | Removed; Windows LAPS |
| Self-Service and Groups | User tenant creation | Off |
| Self-Service and Groups | Security-group creation | Restricted to admins |
| Self-Service and Groups | Microsoft 365 group creation | Approved group only |
| Self-Service and Groups | Entra admin center | Restricted (portal-only; pair with a CA policy) |
| Self-Service and Groups | Group owners adding own members | Prevented |
| Monitoring and Response | Diagnostic settings | Stream sign-in and audit logs to the SIEM |
| Monitoring and Response | Unified audit log | On (verify on Business SKUs) |
| Monitoring and Response | High-signal alerts and CAE | Alerts on; Continuous Access Evaluation on |
| Tenant Governance | Baseline Security Mode | Decided setting by setting |
| Tenant Governance | Posture and drift owner | Named |
| Tenant Governance | Baseline conformance testing | Scheduled (Maester) |
| Tenant Governance | Entra ID Backup and Recovery | Understood, with a separate process for its gaps |
That completes the Entra identity baseline across all three tiers. What it does not yet answer is the order in which to establish any of it on a tenant that does not exist yet, and which of these decisions you can never take back. That is the next article, on standing up a new tenant in the right sequence and recognizing the one-way doors before you walk through them.
Best Practices
‹ Previous: [BP 1.1] The Entra ID Baseline: The Critical Tier
Next: [BP 1.3] The New Tenant: Sequencing and One-Way Doors ›
