Microsoft Entra Tenant Security Hardening: The 2026 Checklist

TL;DR

• Conditional Access baseline-scopes enforcement began 15 June 2026 (moved from 13 May). If you never touched the settings, it is already your tenant default.
• Passkey profiles are not a future project. GA in March 2026, auto-enabled for non-opted-in tenants between early April and late May 2026 — live in your directory whether you configured it or not.
• 1 September 2026 is the date that bites. Passkeys become Entra ID's default sign-in experience, and SMS/voice users are auto-enabled for passkeys.
• Fix break-glass first. The old "exclude emergency accounts from everything" advice now creates a blind spot.
• Microsoft's numeric targets: fewer than five Global Administrators, fewer than ten privileged role assignments.

What changed since this checklist was first published

This checklist went out in June 2026, when baseline-scopes enforcement was upcoming and passkey profiles read like a roadmap item. Both have landed, and one claim in the original — that passkey profiles "began rolling out automatically from March 2026" — was half right in a way that matters. March was general availability. Automatic enablement for tenants that never opted in ran early April to late May 2026 worldwide, and early to late June for GCC, GCC High, and DoD. If nobody has touched your tenant since spring, someone else set your passkey posture: the old tenant-wide FIDO2 settings were migrated into a Default passkey profile and passkeyType was derived from your attestation setting.

Change #1: Conditional Access now enforces baseline scopes

Microsoft's term for this is baseline scopes, and the Learn documentation is precise about what it covers:

OIDC scopes
  email  offline_access  openid  profile

Baseline directory scopes
  User.Read           User.Read.All       User.ReadBasic.All
  People.Read         People.Read.All     GroupMember.Read.All
  Member.Read.Hidden

Before the change, a sign-in requesting only those scopes slipped past any All resources policy carrying a resource exclusion. Now those sign-ins are evaluated as directory access, using Windows Azure Active Directory (Azure AD Graph) as the enforcement audience.

What breaks. Microsoft names the two apps most tenants will notice: the Visual Studio Code desktop client (openid, profile) and Azure CLI (User.Read). Both go from silently exempt to MFA-prompted. Confidential clients you excluded from an All-resources policy that request only baseline directory scopes are the second wave — and custom apps built never to see an interactive challenge may not survive one.

How to stage it. The settings live behind a direct link, https://aka.ms/BaselineScopesSettingsUX, and are not discoverable by browsing the portal. Enable enforcement turns it on immediately (test tenant first), Customize behavior retains legacy behaviour for named policies, and Disable enforcement turns it off tenant-wide — which Microsoft does not recommend, because it reopens the gap everywhere. Customize behavior works by indirection: register a single-tenant placeholder app, exclude it from the policy needing the old behaviour, then nominate it in the settings.

How to verify. That same placeholder app gives you the discovery mechanism. With enforcement enabled, sign-ins requesting only baseline scopes list it as a Conditional Access audience:

GET https://graph.microsoft.com/beta/auditLogs/signIns
  ?$filter=createdDateTime ge 2026-08-01T00:00:00Z
    and conditionalAccessAudiences/any(a:a eq '<your-custom-app-id>')
  &$select=createdDateTime,appId,appDisplayName,userPrincipalName,conditionalAccessStatus

Run it over several days for the real list of client apps requesting nothing but baseline scopes.

Change #2: passkeys, and the eight days that matter

Passkey profiles arriving is the smaller half of this story. The larger half: from 1 September 2026 passkeys become the default sign-in experience in Entra ID, users enabled for SMS or voice are auto-enabled for passkeys, and the registration campaign flips to Microsoft-managed. Microsoft-provided SMS and voice delivery is retired entirely on 1 February 2027. That reshapes what a hardening checklist should say about fallback methods, so this article does not try to summarise it. Two companion pieces cover it properly: Microsoft Is Retiring SMS and Voice MFA: Your Entra ID Migration Plan for the timeline, the temporary opt-out, and the discovery queries; and Entra ID Passkeys in 2026: What Changed and Why to Move Now for synced passkey support, AAGUID allow-lists, and the attestation trap that silently blocks synced-passkey registration.

The 2026 Entra hardening checklist

flowchart TD
    A[Start: harden the tenant] --> B[Fix break-glass accounts first]
    B --> C[Reduce standing privileged accounts]
    C --> D[Phishing-resistant strength for admins]
    D --> E[Audit All-resources CA policies + exclusions]
    E --> F[Control fallback sign-in methods]
    F --> G[Review the passkey profile you already have]
    G --> H[Track progress with Secure Score]
    H --> I[Re-review quarterly]

1. Fix break-glass before you tighten anything else

The original version of this checklist said to exclude break-glass accounts from policies that could lock you out. That advice is now wrong in two directions.

Microsoft's emergency access guidance is specific: keep two cloud-only accounts on .onmicrosoft.com with permanently active Global Administrator (not PIM-eligible — an eligible-only break-glass account cannot rescue you from a broken PIM), give them a different phishing-resistant method from your daily admins, and exclude them only from policies that block sign-in. Report-only policies need no exclusion. Validate every 90 days.

Blast radius. A blanket exclusion makes your two most powerful accounts the only identities nobody is watching. Mandatory MFA applies to them too — an emergency account on password-only is the softest target you own.

2. Get standing privileged accounts under Microsoft's documented limits

Microsoft's role best practices give you two numbers: fewer than five Global Administrators, fewer than ten privileged role assignments. Cross five and an alert card appears on the Entra ID Overview page; cross ten and a warning appears on Roles and administrators. Portal path is Entra ID → Roles & admins → All roles, but the scriptable version separates standing assignments from PIM activations, which the portal blurs:

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -All `
  -ExpandProperty "principal,roleDefinition" |
  Where-Object { $_.RoleDefinition.DisplayName -eq 'Global Administrator' } |
  Select-Object @{n='Principal';e={ $_.Principal.AdditionalProperties.displayName }},
                AssignmentType, StartDateTime, EndDateTime

AssignmentType is the column that matters: Assigned is standing access, Activated is a live PIM elevation. Anything permanent that is not one of your two break-glass accounts needs a justification.

Blast radius. Stripping standing Global Administrator from an account that quietly owns a runbook or legacy integration breaks it at the next run, not when you make the change. Stage it by making the principal eligible first, leaving the standing assignment for one full activation cycle, then removing it. Verify by rerunning the query and confirming only the emergency accounts show AssignmentType: Assigned. PIM requires P2 or Entra ID Governance — see Entra ID Privileged Identity Management: Rolling Out Just-in-Time Admin Access.

3. Move admin sign-in to phishing-resistant strength

Portal path: Protection → Conditional Access → New policy → Grant → Require authentication strength → Phishing-resistant MFA. Highest-value single control in the list; requires Entra ID P1.

The constraint that catches people: you cannot combine Require multifactor authentication and Require authentication strength in the same policy. Pick one grant control per policy and layer policies instead.

Stage it in report-only. Results land in the Conditional Access and Report-only tabs of the sign-in log detail, and the policy insights guidance shows how to compare a report-only copy against the enforced original before touching the real policy. One documented trap: report-only policies requiring a compliant device can still prompt macOS, iOS, and Android users to pick a device certificate — exclude those platforms, or you generate the tickets you were avoiding.

Verify by filtering sign-in logs to your admin group and confirming Report-only: Success rather than Report-only: User action required. The latter is your pre-enforcement ticket forecast.

4. Audit every All-resources policy that carries an exclusion

This is Change #1 turned into a task. Enumerate the affected policies rather than clicking through them:

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {
    $_.Conditions.Applications.IncludeApplications -contains 'All' -and
    $_.Conditions.Applications.ExcludeApplications.Count -gt 0
  } |
  Select-Object DisplayName, State,
                @{n='Excluded';e={ $_.Conditions.Applications.ExcludeApplications -join ',' }}

A State of enabledForReportingButNotEnforced is report-only. For each policy returned, ask whether the exclusion is still needed — Microsoft's recommended fix is usually to have the excluded app request OIDC scopes rather than directory scopes, which sidesteps the question entirely. Pair this with the What-If method in Conditional Access Gap Analysis; if your CA estate has never had a structured review, start from Azure AD Conditional Access Policies: The Complete Guide.

5. Control fallback sign-in methods — in all three policy surfaces

Weak fallbacks (SMS, voice) undermine strong primary methods, and the mechanism by which teams fail to remove them is worth stating plainly: authentication method policies are evaluated together, not in precedence order. A method enabled in any policy can be registered and used. Disabling SMS in the modern Authentication Methods Policy while leaving Call to phone enabled in the legacy MFA or legacy SSPR policy achieves nothing.

Check all three surfaces before declaring a cohort done. Both legacy policies became non-editable on 30 September 2025, so you are inspecting a frozen configuration, not one you can change.

6. Review the passkey profile you already have

Because auto-enablement has already run, the first task is inspection, not rollout: open Authentication methods → Passkey (FIDO2), read the Default passkey profile, and confirm the passkeyType and attestation values derived from your old configuration are the ones you would have chosen. Microsoft's recommended split is device-bound passkeys for privileged users, synced passkeys for everyone else — with attestation enforced only in the device-bound profile, because synced passkeys do not support attestation and a broad profile with it enabled fails registrations silently.

7. Drive the programme with Secure Score, and re-review quarterly

Secure Score turns "are we secure?" into a ranked worklist. Pull it as data so it lives in a dashboard rather than a browser tab — the secureScores endpoint is GA in Graph v1.0 and needs SecurityEvents.Read.All:

GET https://graph.microsoft.com/v1.0/security/secureScores?$top=1

The equivalent cmdlet is Get-MgSecuritySecureScore. Treat the score as a scoreboard, not a strategy — it has no opinion about which All-resources policies carry exclusions, and no view of the baseline-scopes setting you just changed.

Where to verify, and how long to wait

The most common hardening failure is not a wrong setting — it is checking the wrong surface too soon.

The licensing-and-people reality

The highest-impact controls are not the most expensive. Two of the top three cost nothing but attention.

The golden rule

The best policy is not the strictest one on paper; it is the one your tenant can enforce reliably without locking out legitimate users. A policy aggressive enough to generate a flood of help-desk tickets and emergency exceptions is less secure in practice than a slightly looser one that holds.

The bottom line

The 2026 Entra hardening agenda has moved from "prepare" to "verify." Baseline-scopes enforcement is on, passkey profiles are configured whether or not you configured them, and on 1 September the default sign-in experience changes for every user still on telephony. Three actions this week: open the baseline-scopes settings and see which state your tenant is in, read the Default passkey profile someone else wrote for you, and check your break-glass accounts against guidance that moved underneath them.

Further reading

• Enforcement for baseline scopes in Conditional Access (Microsoft Learn)
• Best practices for Microsoft Entra roles (Microsoft Learn)
• Emergency access accounts in Microsoft Entra ID (Microsoft Learn)
• Microsoft Entra ID security updates: what organizations need to do now (Microsoft Community Hub)
• Conditional Access enforcement change coming to Microsoft Entra (Help Net Security)
• Microsoft Entra Conditional Access overview (Microsoft Learn)

Related Articles

• Microsoft Is Retiring SMS and Voice MFA: Your Entra ID Migration Plan
• Entra ID Passkeys in 2026: What Changed and Why to Move Now
• Entra ID Privileged Identity Management: Rolling Out Just-in-Time Admin Access
• Conditional Access Gap Analysis: Finding and Fixing Coverage Holes with What-If
• Azure AD Conditional Access Policies: The Complete Guide
• Microsoft Intune Device Compliance Policies: A 2026 Configuration Guide

Image credit: jaydeep_ via Wikimedia Commons (CC0 / public domain).