Microsoft-managed policies

Policies Microsoft creates in your tenant, and the 45-day clock before they enable themselves.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Microsoft-managed Conditional Access policies

Source: Microsoft-managed Conditional Access policies

· doc date 2026-05-28 · retrieved 2026-07-28

This is the highest-impact operational fact in the whole knowledge base. Customers have

Conditional Access policies in their tenant that they did not create, and those policies

turn themselves on.

How they work

• Microsoft creates and deploys these policies directly into eligible tenants based on

licensing and feature eligibility.

• Each arrives in Report-only state with preconfigured conditions and controls.
• Microsoft enables them no less than 45 days after introduction if left in report-only.
• Customers are notified by email and Message center 28 days before enablement.
• In some cases they may be enabled faster than 45 days — flagged in the email, the

Message center post and the policy details in the portal.

• Microsoft may update these policies as threats evolve.
• Scope auto-expands: as new users, groups or workloads become eligible they are

automatically included. Settings, conditions and grant controls are not changed by

this, and admin-configured exclusions are always preserved.

What administrators can and cannot do

To make deeper changes, use the Duplicate button and configure the copy like any other

policy. Microsoft's caution: be careful not to lower your security posture when doing so.

**Exclude your break-glass accounts from managed policies exactly as you would any other

policy.** Microsoft states this explicitly.

Known UI quirk: editing the per-user-MFA managed policy via the top Edit pencil can

produce a failed to update error. Workaround — use Edit under the **Excluded

identities** section instead.

The policies

• Block all high risk agents from accessing all resources (Preview)
• Block legacy authentication (also a Baseline security mode policy)
• Block device code flow
• Multifactor authentication for admins accessing Microsoft Admin portals
• Multifactor authentication for all users
• Multifactor authentication for per-user multifactor authentication users
• Multifactor authentication and reauthentication for risky sign-ins
• Block access for high-risk users
• Require phishing-resistant authentication for admins (Baseline security mode policy)

Details worth knowing

MFA for admins accessing Microsoft Admin portals — covers **14 highly privileged admin

roles**. Applies to P1 and P2 tenants where security defaults aren't enabled.

MFA for per-user MFA users — targets tenants with P1/P2 licensed users, security

defaults off, and fewer than 500 per-user-MFA enabled or enforced users. To cover more

users, duplicate it and change the assignments.

MFA and reauthentication for risky sign-ins — P2 tenants, security defaults off.

Guest users are not included. Scoping depends on licence maths:

• If all active users are MFA-capable and P2 licences ≥ active users → policy covers

All Users, which could include service accounts or break-glass accounts, so

Microsoft advises excluding them.

• Otherwise Microsoft creates a security group named **"Conditional Access: Risky sign-in

multifactor authentication"**, capped to available P2 licences, populated with users who

can satisfy MFA, prioritising directly-assigned P2 licences. Scope by editing the group.

Also: Microsoft blocks risky users from registering for MFA, to stop account takeover.

Block access for high-risk users — P2 tenants, security defaults off. Blocks until the

risk is remediated through standard ID Protection processes.

Block device code flow — if the organisation uses Microsoft Teams devices that need

device code flow, there is dedicated guidance for scoping those exceptions while still

blocking device code flow for everyone else.

Baseline security mode (BSM) policies

Two settings from Baseline security mode in the Microsoft 365 admin center appear as CA

policies:

• Require phishing-resistant authentication for admins
• Block legacy authentication

They show Baseline security mode in the Created by column and are managed from the

Microsoft 365 admin center. **Important distinction: BSM policies are created by the

administrator, not by Microsoft.**

Upgrade-from-security-defaults policies

Available when moving off security defaults:

• Block legacy authentication
• Require MFA for Azure management — covers the Windows Azure Service Management API:

Azure portal, Microsoft Entra admin center, Azure PowerShell, Azure CLI

• Require MFA for admins — the 14 roles below
• Require MFA for all users

The 14 administrator roles covered

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 · User Administrator

**This list matches the benchmark guidance minimum role set except that benchmark guidance also includes Global

Reader.** When advising on admin scoping, use the benchmark guidance list — it is the superset.

MFA satisfaction edge cases

• External authentication methods satisfy the MFA requirement of managed policies.
• Federated IdP MFA may satisfy Entra MFA requirements depending on configuration.
• Certificate-based authentication depends on how CBA is configured — single-factor CBA

needs a second method; multifactor CBA satisfies MFA alone.

• Custom controls do NOT satisfy multifactor authentication claim requirements.

Organisations using custom controls should migrate to external authentication methods.

This is a real trap: a tenant can believe it has MFA coverage via a custom control and be

wrong.

How to find and monitor them

Portal: Entra admin center → Entra ID → Conditional Access → Policies, look for

Microsoft in the Created by column. Requires at least Conditional Access

Administrator to view.

Policy impact tab on the managed policy gives an environment-wide effect summary, and

works for report-only policies.

Audit log: Entra ID → Monitoring & health → Audit logs, Service filter =

Conditional Access. Managed policy names begin with Microsoft-managed: so they

filter easily. To track Microsoft's own changes, query the directory audit log for entries

initiated by Microsoft Managed Policy Manager in the Policy category:

GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits
  ?$filter=initiatedBy/app/displayName eq 'Microsoft Managed Policy Manager' and category eq 'Policy'

Requires AuditLog.Read.All and Directory.Read.

What the agent must do with this

1. Always ask whether Microsoft-managed policies are present before designing a

baseline. Half of a proposed baseline may already exist, in report-only, with a

countdown running.

1. Warn about the 45-day auto-enable. A customer who "hasn't done anything yet" may be

weeks from enforced MFA they did not plan for. Leaving a managed policy in report-only

is not a decision to defer — it is a decision to accept it on Microsoft's schedule.

Setting it to Off is the deferral.

1. Check break-glass exclusions on managed policies specifically. They are not covered

by whatever process the customer applies to their own policies.

1. Watch for duplication. A customer-built "Require MFA for all users" alongside the

managed one is redundancy that complicates troubleshooting — a Medium finding.

1. Flag custom controls if mentioned: they do not satisfy MFA.
2. Prefer duplication over fighting the constraints. If a managed policy is nearly right

but needs different conditions, duplicate it rather than trying to edit it.