Zero Trust sounds clean on a slide: never trust, always verify. In production it often looks different—help-desk tickets, angry executives, and Conditional Access policies left in report-only mode for months.
The gap isn’t usually missing Microsoft Entra features. It’s the same handful of misconfigurations that turn a strong control plane into something people work around. Here’s what breaks adoption and how to fix it so identity and access stop punishing the people who need to get work done.
1. The Break-Glass Account That Isn’t Actually Break-Glass
The failure
Most organizations create two “emergency” accounts, exclude them from every Conditional Access policy, give them Global Administrator, and never touch them again. When something does go wrong, the accounts are either:
- Forgotten (password rotated years ago, MFA registered to a phone that left the company)
- Shared and therefore effectively unmonitored
- Blocked by a new policy someone forgot to exclude them from
- Or, worse, used day-to-day so they’re no longer truly break-glass
The fix
Treat break-glass as a controlled capability, not a permanent exception.
- Two cloud-only accounts (no on-premises sync)
- Passwords stored in a sealed, offline process (or a password manager with strong break-glass procedure)
- Excluded from all Conditional Access policies—and that exclusion is reviewed monthly
- Strong, unique passwords + phishing-resistant MFA (or certificate-based) registered and tested quarterly
- Sign-in alerts and a dedicated workbook that pages someone the moment either account is used
- Explicitly documented “when to use” criteria so they aren’t the first thing people reach for
A break-glass account that has never been tested is not a break-glass account.
2. Device Compliance That Never Actually Blocks Anything
The failure
Teams enable “Require device to be marked as compliant” and then discover half the company is still on personal devices, unmanaged workstations, or hybrid-joined machines that never check in with Intune. The policy is either scoped so narrowly it does nothing, or so broadly it locks out contractors and executives. Compliance policies themselves are often set to “not evaluated” or ignore critical settings (encryption, OS version, firewall).
The fix
Make device state a first-class signal, not an afterthought.
- Deploy Intune compliance policies that check the things that matter: encryption, minimum OS, secure boot, firewall, and (where appropriate) antivirus/EDR
- Use filters or device platforms so Windows, iOS, Android, and macOS have appropriate requirements
- Combine “Require compliant device” with “Require Hybrid Azure AD join” or “Require Microsoft Entra hybrid joined or compliant” for corporate devices
- For BYOD, pair Conditional Access with app protection policies (MAM) instead of forcing full device enrollment
- Monitor the Intune compliance blade and the Conditional Access “What If” tool weekly until the numbers stabilize
When device compliance is real, you can safely reduce the number of times users see an MFA prompt on trusted, healthy machines.
3. MFA Everywhere = MFA Nowhere
The failure
“Require MFA for all users, all cloud apps, all locations” is the most common first policy. It produces MFA fatigue, users who approve prompts without looking, and a steady stream of “just exclude this VIP” requests. Service accounts and legacy auth still sneak through because someone added an exclusion and never removed it.
The fix
Move from blanket MFA to risk- and context-aware authentication.
- Require phishing-resistant methods (FIDO2, Windows Hello for Business, certificate-based, or Microsoft Authenticator with number matching + additional context) for high-value apps and admins
- Use sign-in risk and user risk policies so low-risk sessions on compliant devices skip extra prompts
- Named locations + trusted devices + continuous access evaluation reduce prompts for the normal work day
- Block legacy authentication outright instead of excluding it
- Scope MFA to “all users except break-glass and service principals that have been reviewed,” not the other way around
- Turn on MFA registration campaign and the Authenticator registration campaign so users are already set up before you enforce
The goal is not fewer MFA prompts at all costs. The goal is prompts that feel justified so people stop treating them as background noise.
4. Exclusion Groups That Become Permanent Backdoors
The failure
A dynamic group or a static “CA Exclusions” group grows every time someone complains. Six months later it contains service accounts, test accounts, executives, and three people who left last year. No one owns the membership review.
The fix
- Prefer filters and conditions over exclusion groups whenever possible
- If you must exclude, use a tightly controlled group with an access review every 30–60 days
- Document why each exclusion exists and an expiration date
- Alert on new members added to any exclusion group
5. Report-Only Mode That Lasts Forever
The failure
Policies stay in report-only because the team is afraid of lockouts and never builds the operational muscle to promote them. Sign-in logs fill up, no one looks at the Conditional Access insights workbook, and the organization stays in a permanent “we’re almost ready” state.
The fix
- Run every new policy in report-only for a defined window (usually 7–14 days)
- Review the insights workbook and “What If” tool daily during that window
- Promote in stages: pilot group → department → all users
- Keep one emergency break-glass path tested and ready
- Set a calendar reminder to either enforce or explicitly kill the policy—no zombies
Putting It Together: A Practical Starting Set
A minimal, adoptable baseline for most organizations looks like this:
- Block legacy authentication
- Require MFA for all users (with the risk- and device-based exceptions above)
- Require compliant or hybrid-joined device for access to sensitive apps
- Require phishing-resistant MFA for admin roles and high-value apps
- Protect break-glass accounts and monitor their use
- Apply stricter controls to guests and external collaboration
None of these policies should surprise users who already have a managed device and a registered authenticator. When they do surprise someone, the fix is usually a missing compliance policy or an uncommunicated change—not a reason to weaken the control.
The Real Success Metric
Conditional Access that actually gets used is the set of policies that stay enforced, produce few unexpected lockouts, and let most people work without thinking about identity. That only happens when break-glass is real, device signals from Intune are trustworthy, and MFA prompts are rare enough that people still pay attention to them.
Start there. The rest of Zero Trust becomes much easier once the control plane isn’t fighting the humans it’s supposed to protect.