MFA for All…But Not the Same.

Last week I was recording some videos on pushing out Conditional Access policies and ran into something familiar: a missing service principal.

That failure forced me to revisit one of my foundational policies — the one I've used for years. And instead of just fixing it quietly, I decided to document it.

Because if you've worked in Microsoft Entra ID long enough, you've felt the pain:

A device failing to join Intune. A MAM policy breaking due to Defender. Passkey enrollment failing. A Conditional Access policy that looked perfect but didn't deploy. We've all discovered the hard way that identity is unforgiving.

The policy name tells the full story:

This is the baseline. Everything builds from here.

First stop: excluded groups.

Breakglass accounts are excluded. This is intentional and aligned with best practice — see Not Another Breakglass. This is one of a couple policies to include the CA — GlobalExclusions group. You have to be careful that you don't treat this like breakglass and end up adding one person to a group and then they bypass everything.

Next: directory synchronization accounts.

Most hybrid environments use Microsoft Entra Connect to sync on-prem identities to Entra. If that sync identity is forced through MFA, synchronization breaks. This approach was reinforced the first time I ran Maester — specifically test MT.1020, which recommends excluding service accounts like the Microsoft Entra Connect Sync Account from Conditional Access policies.

Instead of manually hunting sync accounts in every tenant, I standardized the exclusion. Is direct assignment cleaner? Possibly. Does this approach prevent human error across multiple tenants? Absolutely.

A great piece of feedback I received came from Jay:

That stopped me for a minute. Because for years, excluding the sync account from Conditional Access was considered standard practice. So what changed?

This means sync no longer relies on a username/password user account. It uses a service principal instead. Authentication is certificate-based, non-interactive, and not subject to user-targeted Conditional Access policies.

In other words: the original reason we excluded the directory sync user may no longer apply in modern deployments. This needs to be evaluated on a case-by-case basis.

The policy failed because one of four excluded service principals didn't exist in the tenant. That's when the troubleshooting began.

Here are the excluded apps — use aka.ms/AppNames to find app names by GUID:

// Excluded from ACME — GLOBAL — GRANT — MFA — All-Users
"excludeApplications": [
  "00000012-0000-0000-c000-000000000000", // Microsoft Rights Management Services
  "d4ebce55-015a-49b5-a083-c84d1797ae8c", // Microsoft Intune Enrollment
  "372140e0-b3b7-4226-8ef9-d57986796201", // Azure Windows VM Sign-In
  "0000000a-0000-0000-c000-000000000000"   // Microsoft Intune (Legacy — Removed)
]

If you're using Purview sensitivity labels, this exclusion is often required. Encryption and IRM flows authenticate through this service principal, and blocking it with MFA can break label enforcement silently.

Tony Redmond has an excellent breakdown: office365itpros.com — Conditional Access MFA & Email

This is the operationally necessary exclusion and the one that caused my failure. Intune Enrollment handles:

Azure AD Join · Autopilot · Company Portal enrollment · Initial MDM bootstrap

If MFA blocks this flow, enrollment fails. This was the missing service principal in my tenant. In my case, the principal had never been instantiated — it simply didn't exist.

I've previously excluded Intune Enrollment due to legacy workflows, hybrid join complexity, Autopilot edge cases, and troubleshooting scenarios. But guidance evolves. Platforms mature. And what once required exclusion may now deserve intentional hardening instead.

This handles post-enrollment traffic: device policy sync, compliance checks, app deployment, configuration updates. This exclusion is legacy in my environment. Honestly? I would remove this today unless absolutely necessary.

In hindsight, this was likely added during troubleshooting. I suspect many environments have similar historical exclusions that were never revisited. The more critical exclusion is Intune Enrollment above.

Used when RDP-ing into Entra-joined Azure VMs, using the Azure AD Login extension, or in certain AVD flows. Originally excluded after running into MFA issues when testing Entra-joined VMs. Microsoft documentation even suggests excluding it in some scenarios.

Was it architecturally ideal? Probably not. But it fixed the problem quickly.

Excluding an app is easy. But is it the right approach? I explored whether a device filter would be cleaner:

device.trustType -ne "AzureAD"

The idea: instead of excluding Azure Windows VM Sign-In from the policy, conditionally allow only trusted, Entra-joined devices and keep everything else enforced. Architecturally, that feels more mature than a blanket exclusion.

However, Microsoft documentation introduces an important limitation:

What looked like a cleaner alternative now has technical constraints. It's not just about what we want Conditional Access to enforce — it's about what the platform can realistically evaluate for that specific resource.

Fabian Bader wrote an excellent article on FOCI (Family of Client IDs): cloudbrothers.info — Conditional Access Bypasses

Some applications are part of token families. Excluding one can implicitly allow others. That creates a Swiss cheese effect in Conditional Access — each exclusion punches a hole, and holes compound.

For a deep dive on the topic, this video covers it well. I've also added the relevant links to my CA Repo on GitHub.

If any of the service principals above don't exist in your tenant, run the script below to instantiate them. I've included all potential apps just in case:

Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Microsoft Intune Enrollment
New-MgServicePrincipal -AppId "d4ebce55-015a-49b5-a083-c84d1797ae8c"

# Azure Windows VM Sign-In
New-MgServicePrincipal -AppId "372140e0-b3b7-4226-8ef9-d57986796201"

# Microsoft Rights Management Services
New-MgServicePrincipal -AppId "00000012-0000-0000-c000-000000000000"

"MFA for All Users" sounds simple. It isn't.

What this experience reinforced:

Global policies are foundations, not finished architecture. Exclusions accumulate over time. Service principals evolve. Documentation changes. And yesterday's quick fix can become today's blind spot.

Conditional Access isn't about making MFA universal. It's about making it contextual.

The real maturity in identity isn't enabling MFA everywhere. It's continuously reevaluating why you excluded something in the first place. Because in identity, every exception tells a story. And eventually, you have to revisit it.

With Audience Reporting in Conditional Access, we now have far better visibility into how policies affect users and workloads. That makes testing safer, analysis faster, and decisions more informed.

Every exclusion should be questioned. Every legacy workaround should be retested. Because in identity architecture, the right answer five years ago might not be the right answer today.