
The Hidden Risks of “All Users” in Conditional Access
Conditional Access is one of the most powerful security controls in Microsoft Entra ID. (Strengthening Security with Conditional Access in Microsoft Entra ID, 2024)
It’s also one of the easiest to misconfigure without realizing it.
One setting in particular seems harmless and might even look like a best practice at first:
Assignments → Users → Include → All users
On paper, this feels right.
But in reality, choosing “All Users” can be risky if you don’t fully understand what it does. Let’s break down why.
Why “All Users” Feels So Appealing
Most admins use “All Users” for good reasons:
- You want consistent security
- You don’t want to forget new users
- You want MFA enforced everywhere
- Microsoft docs often encourage broad coverage (Plan Your Microsoft Entra Conditional Access Deployment, 2025)
And yes, Conditional Access should cover a wide range of users. However, if you make it too broad without being precise, you can create blind spots and even cause outages.
Risk #1: You’re Probably Targeting Accounts You Should Never Touch
“All Users” does not mean “All Employees”.
It includes:
- Break-glass (emergency access) accounts
- Service accounts
- Automation identities
- Legacy app sign-in users
- Azure AD Connect sync accounts
- Vendor or temporary accounts you forgot existed
If your policy enforces:
- MFA
- Compliant device
- Sign-in frequency
- Session controls
You might accidentally lock yourself out of your own tenant.
Many real-world tenant lockouts start with:
“We just applied MFA to All Users…” (Plan Your Microsoft Entra Conditional Access Deployment, 2023)
Risk #2: Emergency Access Accounts Get Silently Broken
Emergency access accounts should never be subject to Conditional Access policies. (Manage emergency access admin accounts - Microsoft Entra ID, 2024)But when admins use “All Users” and forget exclusions:
- MFA policies break emergency access
- Device-based controls block login
- Session controls expire tokens
- Incident response access disappears
This defeats the entire purpose of having a break-glass account. (Block access for users with insider risk - Microsoft Entra ID, 2025)If you rely on Conditional Access as your safety net, using “All Users” can take that safety away.
Risk #3: Service Accounts Don’t Authenticate Like Humans
Many service accounts:
- Can’t perform MFA
- Don’t have devices
- Use legacy protocols
- Authenticate headlessly (Block legacy authentication with Conditional Access - Microsoft Entra ID, 2024)
When included in “All Users” policies:
- Scheduled jobs fail
- Sync services break
- Third-party integrations silently stop
- Logs show vague “Conditional Access failure?
- worst part?
These failures often surface days or weeks later, not immediately. (Troubleshoot Conditional Access policy changes - Microsoft Entra ID | Microsoft Learn, 2025)
Risk #4: You Lose Policy Intent Over Time
At first, “All Users” seems simple and tidy, but that changes as your tenant grows.
Over time, you add:
- New apps
- New automation
- New regions
- New contractors
- New security requirements
Now you’re forced to add more and more exclusions, and eventually:
- No one remembers why exclusions exist
- Policies become fragile
- Changes feel risky
- Admins avoid touching CA at all
This is how Conditional Access can shift from being a helpful control to becoming a liability. (Require remediation for risky users - Microsoft Entra ID, 2025)
Risk #5: “All Users” Hides Who You’re Actually Protecting
When everything is included, nothing is clearly defined.
You can’t easily answer:
- Which policies protect human users?
- Which protects admins?
- Which protects workloads?
- Which protects guests?
Good security architecture is explicit. (Secure By Design, n.d.)“All Users” is implicit — an“All Users” is an implicit approach, and security that isn’t explicit will eventually fail. Instead of “All Users”, design policies around identity intent.
Examples:
- Human users (employees, admins)
- Privileged roles
- Guest users
- Service accounts
- Automation identities
Use:
- Named groups
- Role-based targeting
- Separate admin policies
- Explicit emergency exclusions
It’s true that this approach takes more effort.
But it scales cleanly and safely.
The Rule of Thumb
“All Users” is acceptable only if:
- Emergency accounts are excluded
- Service accounts are excluded
- You understand every identity in the tenant
- You’ve tested lockout scenarios
Most tenants don’t meet those conditions.
Final Thought
Conditional Access isn’t about blocking as much as possible.
It’s about blocking the right things, for the right identities, at the right time.
“All Users” feel secure.
Precision is secure. (Plan Your Microsoft Entra Conditional Access Deployment, 2025)If you haven’t reviewed your Conditional Access assignments recently,
This is your sign to do it — before production reminds you the hard way.
Written by Jaspreet Singh — Microsoft identity & security practitioner. Author at ITBlogs.ca. Lab notes and testing at f11.ca.
References
(2024). Strengthening Security with Conditional Access in Microsoft Entra ID. ExamLabs. https://www.examlabs.com/certification/strengthening-security-with-conditional-access-in-microsoft-entra-id/
(2025). Plan Your Microsoft Entra Conditional Access Deployment. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access
(2023). Plan Your Microsoft Entra Conditional Access Deployment. Microsoft Learn. https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-framework
(2024). Manage emergency access admin accounts - Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
(2025). Block access for users with insider risk - Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-risk-based-insider-block
(2024). Block legacy authentication with Conditional Access - Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication
(2025). Troubleshoot Conditional Access policy changes - Microsoft Entra ID | Microsoft Learn. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-policy-changes-audit-log
(2025). Require remediation for risky users - Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-risk-based-user
(n.d.). Secure By Design. Microsoft. https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design
(2025). Plan Your Microsoft Entra Conditional Access Deployment. Microsoft Learn. https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-framework