Conditional Access baseline: a report-only-first runbook

Learn says Conditional Access needs Microsoft Entra ID P1, P2 or a trial licence. P2 is required to use ID Protection risk in policies. Risk-based policies are in Learn’s third rollout phase and are outside this baseline.

For roles, Security Reader can read policies. Conditional Access Administrator can create, modify or restore soft-deleted policies. Learn suggests activating these roles just in time with PIM.

If security defaults are on, a Conditional Access policy can’t be created alongside them. Learn’s route is to disable them at Entra ID > Overview > Properties > Manage security defaults, then enable Conditional Access policies immediately. Configuring security defaults needs at least the Conditional Access Administrator role.

Learn says Microsoft-managed Conditional Access policies exist to keep the same protections. Read what your tenant has before you disable anything.

For context on what you are replacing, Learn says security defaults block legacy authentication, require MFA for named admin roles, require MFA for Azure Resource Manager access, and block device code flow.

Learn’s guidance on emergency access accounts:

• Create two or more.
• Cloud-only, on the *.onmicrosoft.com domain, not federated or synchronised.
• Assign Global Administrator. In PIM, make the assignment active permanent rather than eligible.
• Use a passkey (FIDO2), which Learn recommends, or certificate-based authentication. Use a method that differs from your normal admin accounts.
• Validate them at least every 90 days and when IT staff or subscriptions change.
• Monitor sign-in and audit logs and alert on every use. Learn’s example is an Azure Monitor custom log search alert on SigninLogs with a threshold greater than 0. Take the exact query from the Learn page.

Put them in a dedicated security group. Learn’s example name is EmergencyAccess. Exclude that group from Conditional Access policies that block or restrict sign-in. Learn says report-only policies need no exclusion.

Learn’s mandatory MFA page says break-glass accounts are required to sign in with MFA once enforcement begins, and that they should move to a passkey (FIDO2) or certificate-based authentication. It also says exclusions in a Conditional Access MFA policy no longer apply to this enforcement, while stricter policies such as phishing-resistant MFA stay enforced. Workload identities are not affected.

Learn gives these dates and scope:

• Phase 1: the Azure portal, Entra admin center and Intune admin center from October 2024, and the Microsoft 365 admin center from February 2025.
• Phase 2: Learn describes it as starting gradually on 1 October 2025, covering Azure CLI, PowerShell, the mobile app, infrastructure as code and REST create, update and delete.
• A Global Administrator could postpone Phase 2 for their tenant until 1 July 2026. After enforcement begins, a Global Administrator can ask Microsoft Support to lift it temporarily.
• Only the Azure public cloud is enforced. Learn says sovereign clouds are not enforced at present.

Check where this stands for your tenant in the Message Center and sign-in logs. Do not rely on dates in a blog post.

Go to Entra ID > Conditional Access > Create new policy from templates and review the categories: Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats and AI Agents.

Learn says every template policy is created in report-only mode. A template that targets users excludes only the user who creates it. Add the EmergencyAccess group and any other exclusions straight after creation.

Learn also recommends excluding service accounts and service principals, such as the Entra Connect sync account, and replacing service accounts with managed identities where scripts use them.

Use a naming convention with a sequence number. Learn also recommends disabled “ENABLE IN EMERGENCY” contingency policies.

Learn says this needs at least Conditional Access Administrator to create.

First find who uses it. Learn’s route needs at least Reports Reader: Entra ID > Monitoring & health > Sign-in logs, filter on Client App, and check both the interactive and non-interactive tabs.

Then go to Entra ID > Conditional Access > Policies and create the policy:

1. Users: include All users. Exclude only accounts that must keep legacy authentication.
2. Target resources: All resources.
3. Conditions > Client apps: tick only Exchange ActiveSync clients and Other clients.
4. Grant: Block access.
5. Start in Report-only.

Remember the emergency group exclusion.

Learn says users must be enabled for combined registration. In Entra ID > Conditional Access > Policies > New policy:

1. Users: include All users. Exclude All guest and external users and the emergency access accounts.
2. Target resources > User actions: tick Register security information.
3. Conditions > Locations: include Any location, exclude All trusted locations.
4. Grant: Require authentication strength.
5. Create it in report-only first.

Learn says Temporary Access Pass lets admins issue time-limited credentials so new users can register from any device or location, and that it satisfies MFA requirements in Conditional Access. It does not work for guest users, so guests need a separate registration policy. Learn says that policy can block registration outside trusted locations.

Learn’s page says that from 6 July 2026, policies that target Register security information also apply during Windows Hello for Business and macOS Platform SSO credential registration, and users must satisfy the grant controls. Learn says to review such policies and test them in report-only mode.

Learn’s report-only page says report-only does not cover items in the User actions scope. The registration page still says to create this policy in report-only. Confirm in your tenant what the report-only tabs show for this policy, and pilot with a test user before enforcing.

Learn says Microsoft recommends a baseline policy that targets all users and all resources, with no app exclusions, and requires MFA through the built-in Multifactor authentication strength.

Exclusions: the emergency access accounts, and the Directory Synchronization Accounts role if you use Entra Connect or Cloud Sync.

If you use external authentication methods, use the Require multifactor authentication grant control instead of authentication strength.

Do the registration first. Learn says enabling this policy without registered phishing-resistant methods risks locking you out of your tenant. Learn says Temporary Access Pass or passkey (FIDO2) registration can be used to register the methods. The policy can be combined with PIM, which can require MFA at role activation.

Learn lists 14 roles as a minimum: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator and User Administrator.

Learn says policies that target directory roles apply only to built-in roles. They are not enforced for administrative-unit-scoped roles or custom roles. Plan other controls for those.

Then, signed in as at least Conditional Access Administrator:

1. Go to Entra ID > Conditional Access > Policies > New policy.
2. Under Users, include Directory roles and exclude the emergency access accounts.
3. Set Target resources to All resources.
4. Under Grant, choose Require authentication strength, then Phishing-resistant MFA strength.
5. Create it in Report-only.

Before you create it, check the cross-tenant access inbound MFA trust setting. Learn says that if MFA trust is enabled, the home-tenant MFA claim is accepted. If it is disabled, the guest completes MFA in your tenant.

Then in Entra ID > Conditional Access > Policies > New policy, include Guest or external users, exclude the emergency access accounts, and use Require authentication strength.

Learn says this applies only to external users who authenticate with Entra ID. For email one-time passcode, SAML/WS-Fed, Google federation and Microsoft personal account users, use the Require multifactor authentication grant control.

Learn says report-only evaluates policies at sign-in without enforcing them. Results appear in the Conditional Access and Report-only tabs of sign-in log details.

For a wider view, Learn describes a policy impact view. It needs at least Security Reader and shows 24 hours, 7 days or 1 month of interactive sign-ins. The Insights and Reporting workbook needs Entra ID P1 and a Log Analytics workspace receiving sign-in logs.

When you are happy, change the Enable policy toggle from Report-only to On.

Learn’s phased plan is a useful order. Phase 1 (week 1-2): block legacy authentication, secure MFA registration, phishing-resistant methods for privileged roles. Phase 2 (week 2-3): strong authentication for all users and guests, approved apps or app protection, MFA for device join. Phase 3 (week 3-4): risk-based policies (P2), token protection, device code flow restriction and others.

Learn recommends protected actions, so that creating, changing or deleting Conditional Access policies needs fresh MFA or another grant control. They need Entra ID P1 or P2 and the Conditional Access Administrator or Security Administrator role.

1. Create an authentication context at Entra ID > Conditional Access > Authentication context.
2. Create a policy that uses the context.
3. Assign the context to permissions at Entra ID > Roles & admins > Protected actions > Add protected actions.

The Conditional Access permission Learn names is microsoft.directory/conditionalAccessPolicies/delete, among others.

Learn says the policy used must be set to On, not Off or Report-only, or users are asked to reauthenticate repeatedly. Learn’s page includes a recovery link for that case. Learn also says to use Microsoft Graph PowerShell, as Azure PowerShell doesn’t support step-up authentication. Test with an admin session open and the emergency account to hand.