Over the past few weeks, I've had a steady stream of admins asking me about new Conditional Access policies in their Entra ID tenant. Nobody created them, and they're marked as managed by Microsoft. At first glance these Microsoft-managed policies look like any other Conditional Access rule. The differences are that they sit in report-only mode and can't be deleted. So people want to know what the policies actually do, why they showed up, and what to do about them.

Microsoft-managed policies set a security baseline in your tenant

In November 2023, Microsoft started rolling out Microsoft-managed policies to eligible Entra ID tenants. The idea is a security baseline that enforces strong controls automatically, such as Multi-Factor Authentication (MFA) on admin portals and extra requirements for risky sign-ins. The policies arrive in report-only mode, so they log what they would do without enforcing anything. If the admin hasn't acted after at least 90 days, Microsoft turns them on. The rollout was quiet. Many tenants only notice now, often by chance or because a support ticket about a blocked sign-in leads back to one of these policies.

These are the main policies being deployed right now:

  • MFA enforcement for admin portals
  • Transition from legacy per-user MFA to Conditional Access-based MFA
  • MFA and reauthentication required for risky sign-ins

You can't delete these rules, but you can turn them off or duplicate them and adjust the copy. Microsoft keeps its documentation on Microsoft-managed policies up to date.

Report-only mode shows the impact before anything is enforced

In report-only mode, the policies record which sign-ins they would have affected. That gives you a good picture of the impact before you change anything. The Conditional Access Insights workbook and the sign-in logs are the tools I use here, because they let you drill down to the individual users and apps that would have matched. I usually go through the workbook looking for break-glass or service accounts that could end up stuck behind a new MFA requirement. For step-by-step instructions, see Microsoft's guidance on Conditional Access insights and reporting.

If your tenant has a lot of custom Conditional Access rules, let report-only mode run for several weeks. You're then far less likely to hit policy conflicts or strange side effects when you later enforce or disable the policies.

Break-glass accounts belong on the exclusion list

You can configure exclusions on Microsoft-managed policies. The first thing to exclude explicitly is your break-glass admin accounts, since they're your last resort when everyone else is locked out. Each policy's configuration exposes the full exclusion settings, so you can also exempt service accounts, automation identities or specific applications. The policies themselves cannot be deleted, but if you'd rather take ownership, a single click disables them completely.

My practical tip: Don't wait for the auto-enforcement deadline. Go through the report-only results early. The default policies are strict, and if you haven't planned the critical exceptions up front, you'll be dealing with support tickets.

Every tenant needs to decide whether to enable, replace or disable them

You have three options. Keep the Microsoft-managed policies as they are, enable them early, or stay with your own Conditional Access set and disable the managed ones. I regularly see tenants with carefully built rules that go further than the defaults. There, disabling the Microsoft-managed rules and maintaining your own often makes more sense. In tenants with weak security or hardly any Conditional Access work so far, these policies are a real improvement.

They also differ from the familiar "security defaults". Microsoft-managed policies are more flexible, allow targeted exclusions, and don't replace security defaults. The two run side by side. I cover baselines and best practices in more detail in my earlier post on getting started with Conditional Access in Entra ID.

The policy lifecycle has only a few decision points

The Mermaid diagram below shows the lifecycle of a Microsoft-managed policy: how it lands in the tenant and where you actually get to decide.

flowchart TD
    Start["Microsoft creates policy"] --> ReportOnly["Report-only in tenant"]
    ReportOnly -->|"Admin reviews report"| AdminAction["Admin enables or disables"]
    ReportOnly -->|"no action taken"| AutoEnable["Enabled after 90 days"]
    AdminAction -->|"enable early"| Enabled["Policy enabled"]
    AdminAction -->|"disable"| Disabled["Policy disabled"]
    AutoEnable --> Enabled

Figure: Lifecycle of a Microsoft-managed policy in Entra ID

I never let these policies switch themselves on

I'd strongly advise against letting these policies activate on their own. In a production tenant, an unexpected policy change from Microsoft can lock out users or break important processes in no time. Here's what I normally do. I check the report-only impact carefully and set up the exclusions I need, above all for break-glass and service accounts. Only after that do I deliberately enable or disable the managed policy. If you already run a well-designed Conditional Access setup, look closely for overlaps or unintended interactions. Keep the decision in your own hands, and the next automatic rollout won't catch you out.