## Conditional Access Without Admin Lockouts
Microsoft Entra Conditional Access is one of the most powerful controls available to organizations using Microsoft 365, Azure, and SaaS applications integrated with Entra ID. It can require phishing-resistant authentication for administrators, block risky sign-ins, restrict access from unmanaged devices, and enforce location-aware controls.
It can also lock out the people responsible for fixing it.
That risk is why many small and midsize businesses, nonprofits, and even mature enterprises hesitate to enforce stronger identity policies. They know multifactor authentication and Zero Trust access rules are necessary, but they have seen poorly planned Conditional Access deployments interrupt payroll, email, finance systems, line-of-business applications, or emergency response work.
This article explains how to design Microsoft Entra Conditional Access policies that materially improve security without creating a single point of administrative failure. The goal is not just to turn on MFA. The goal is to build an identity control plane that is secure, observable, recoverable, and practical for real organizations.
## Why Conditional Access Design Matters
For many organizations, Entra ID is now the front door to email, files, Teams, ERP systems, VPN access, endpoint management, cloud infrastructure, and third-party SaaS applications. If attackers compromise an identity with broad privileges, they may not need malware to do serious damage. They can create inbox rules, register rogue applications, exfiltrate SharePoint data, reset passwords, modify MFA methods, or tamper with backups.
Conditional Access helps reduce this risk by evaluating sign-in context before granting access. Common signals include:
– User or group membership
– Application being accessed
– Device compliance state
– Network location
– Sign-in risk or user risk
– Authentication strength
– Client application type
– Platform or device type
The challenge is that Conditional Access policies are evaluated at sign-in time. A policy mistake can immediately affect administrators, help desk staff, automation accounts, and executives. A secure design must therefore include controlled rollout, exclusions, monitoring, and emergency access.
## Start With a Policy Architecture, Not a Single Policy
A common mistake is creating one large policy named something like Require MFA for Everyone. It may work briefly, but it becomes difficult to troubleshoot as exceptions accumulate. A better approach is to build smaller policies with clear intent.
A practical baseline architecture often includes:
1. Require strong authentication for administrators
2. Require MFA for all users accessing cloud apps
3. Require compliant or hybrid-joined devices for sensitive applications
4. Block legacy authentication
5. Block or challenge high-risk sign-ins
6. Restrict administrative portals from untrusted locations where appropriate
7. Exclude emergency access accounts from normal enforcement, while monitoring them aggressively
Each policy should answer four questions:
– Who does it apply to?
– Which applications does it protect?
– What conditions trigger it?
– What control is enforced?
If the answer is not clear from the policy name and settings, the policy is probably doing too much.
## Build Emergency Access Before Enforcement
Emergency access accounts, often called break-glass accounts, are highly privileged cloud-only accounts intended for use when normal administrative access fails. They are not daily-use accounts. They are a recovery mechanism.
Examples of situations where emergency access may be needed include:
– Conditional Access misconfiguration
– MFA provider outage
– Federation outage
– Hybrid identity synchronization failure
– Compromised administrator accounts
– Lost or unavailable security keys
– Network controls blocking legitimate admin access
### Recommended Break-Glass Account Characteristics
At minimum, maintain two emergency access accounts. They should be:
– Cloud-only accounts, not synchronized from on-premises Active Directory
– Assigned the Global Administrator role, preferably permanently only if your recovery model requires it
– Excluded from standard Conditional Access policies
– Protected with very strong credentials stored offline
– Not used for daily administration
– Monitored with alerting on every sign-in attempt
– Reviewed and tested on a controlled schedule
Use long, randomly generated passwords stored in a sealed physical process, such as a secure safe with documented access controls. If your organization uses phishing-resistant authentication for emergency accounts, ensure the authenticators are available during an outage and that more than one trusted person can access the recovery procedure.
There is a tradeoff here: excluding break-glass accounts from Conditional Access creates risk, but including them in every policy can defeat their purpose. The safer pattern is exclusion plus strong monitoring, restricted knowledge, and operational discipline.
## Use Groups to Control Scope
Avoid assigning Conditional Access policies directly to All users during initial deployment. Instead, use staged groups so you can test, validate, and expand safely.
A simple rollout group model might look like this:
– CA-Pilot-Users
– CA-Pilot-Admins
– CA-Standard-Users
– CA-Privileged-Admins
– CA-Excluded-Emergency-Access
– CA-Excluded-Service-Accounts
This does not mean exclusions should be broad. Exclusion groups should be small, reviewed often, and justified. In many incidents, attackers succeed because exception groups become permanent hiding places.
### Example Naming Convention
Use names that describe intent and enforcement state:
– CA001-Require-Phishing-Resistant-MFA-Admins
– CA002-Require-MFA-All-Users
– CA003-Block-Legacy-Authentication
– CA004-Require-Compliant-Device-Finance-Apps
– CA005-Block-High-Risk-Signins
Numbering policies makes documentation, troubleshooting, and change control easier. It also helps help desk teams correlate a user impact report with the exact control involved.
## Deploy in Report-Only Mode First
Report-only mode is one of the most important safety features in Conditional Access. It lets you evaluate what a policy would do without enforcing it.
Before enabling a new policy, run it in report-only mode long enough to capture normal business patterns. For some organizations, a week is enough. For others, especially those with shift work, travel, seasonal contractors, or international operations, two to four weeks may be more appropriate.
During report-only testing, review:
– Users who would be blocked
– Applications affected
– Legacy client usage
– Service accounts mistakenly included
– Device compliance gaps
– Sign-ins from unexpected countries or networks
– Admin accounts that would lose access
### Useful KQL for Sign-In Review
If Entra sign-in logs are sent to Log Analytics, queries like the following can help identify policy impact and risky patterns.
“`kusto
SigninLogs
| where TimeGenerated > ago(14d)
| where ConditionalAccessStatus in (‘reportOnlyFailure’, ‘failure’)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ConditionalAccessStatus, ConditionalAccessPolicies
| order by TimeGenerated desc
“`
To find legacy authentication attempts:
“`kusto
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed !in (‘Browser’, ‘Mobile Apps and Desktop clients’)
| summarize Count=count() by UserPrincipalName, ClientAppUsed, AppDisplayName
| order by Count desc
“`
Legacy authentication is a frequent source of confusion. SMTP AUTH, older Office clients, basic authentication scripts, scanners, and line-of-business applications may fail once modern controls are enforced. Finding them before enforcement prevents surprise outages.
## Prioritize Administrator Protection
Privileged accounts should receive stronger controls than standard users. If an attacker compromises a Global Administrator, Privileged Role Administrator, Exchange Administrator, SharePoint Administrator, or Intune Administrator, the blast radius can be enormous.
A strong administrator policy should require phishing-resistant authentication where licensing and operational readiness allow. In Microsoft terminology, this often means using authentication strengths such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication.
### Administrator Policy Pattern
A typical administrator-focused policy might be structured as follows:
– Users: Include directory roles with administrative privileges
– Exclusions: Emergency access accounts only
– Cloud apps: All cloud apps
– Conditions: Any location, any device platform
– Grant control: Require phishing-resistant MFA
– Session control: Sign-in frequency appropriate to risk and usability
Be careful with location-based admin exclusions. Allowing administrators to bypass MFA from the office may feel convenient, but it assumes the office network cannot be abused. In modern environments with VPNs, remote access tools, guest Wi-Fi mistakes, and compromised endpoints, that assumption is often weak.
## Block Legacy Authentication Deliberately
Legacy authentication does not support modern MFA challenges and remains a common target for password spray and credential stuffing attacks. Blocking it is one of the highest-value Conditional Access controls.
However, blocking legacy authentication can break real workflows if old dependencies exist. Examples include:
– Multifunction printers using SMTP AUTH
– Old mail clients
– Scripts using basic authentication
– Third-party applications that have not been modernized
– Archived systems that still send reports by email
Before enforcing a block, identify usage and replace or isolate dependencies. For printers and applications that send email, consider authenticated SMTP alternatives, application-specific relay connectors, or a dedicated internal mail relay with controlled outbound access.
A legacy authentication block policy usually includes:
– Users: All users
– Exclusions: Emergency access accounts and documented service exceptions only
– Cloud apps: All cloud apps
– Client apps condition: Legacy authentication clients
– Grant control: Block access
Keep service exceptions temporary where possible. If a device or application requires legacy authentication indefinitely, document the business owner, technical owner, compensating controls, and review date.
## Treat Service Accounts as an Engineering Problem
Service accounts are often where clean Conditional Access designs become messy. Some automation identities are interactive user accounts created years ago. Others are app registrations, managed identities, or workload identities.
The best solution is to reduce interactive service accounts. Where possible, replace them with:
– Managed identities in Azure
– App registrations with certificate credentials
– Workload identity federation
– Purpose-built vendor integrations
– Least-privilege delegated permissions
If an interactive service account must remain, do not simply exclude it from everything and forget it. Apply compensating controls such as:
– Dedicated account naming and ownership
– No mailbox unless required
– No administrative roles unless absolutely necessary
– Restricted sign-in locations if feasible
– Strong random password rotation process
– Monitoring for interactive sign-ins
– Conditional Access policy limited to its expected application path
### Example: Find Potential Service Accounts
Using Microsoft Graph PowerShell, you can export users with password policies or naming patterns that may indicate service accounts:
“`powershell
Connect-MgGraph -Scopes ‘User.Read.All’,’Directory.Read.All’
Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled,UserType |
Where-Object { $_.UserPrincipalName -match ‘svc|service|automation|scanner|backup’ } |
Select-Object DisplayName,UserPrincipalName,AccountEnabled,UserType |
Export-Csv .\potential-service-accounts.csv -NoTypeInformation
“`
This is not a complete inventory, but it is a useful starting point for cleanup and ownership review.
## Use Device Compliance Carefully
Requiring compliant devices for sensitive applications can significantly reduce risk. For example, finance systems, HR files, admin portals, and privileged access workstations may deserve stronger device controls than general email access.
But device-based Conditional Access depends on reliable endpoint management. If Intune enrollment is inconsistent or compliance policies are too fragile, users may be blocked for reasons unrelated to actual compromise.
Before requiring compliant devices broadly, verify:
– Devices are enrolled and reporting correctly
– Compliance policies match operational reality
– Windows, macOS, iOS, and Android rules are tested separately
– BYOD expectations are documented
– There is a process for new device onboarding
– Help desk staff can interpret compliance failures
For many organizations, a phased approach works best:
1. Require MFA for all users
2. Require strong authentication for administrators
3. Require compliant devices for administrative portals
4. Require compliant devices for high-risk business applications
5. Expand only after endpoint management is mature
## Monitor Emergency Access Aggressively
Because emergency access accounts are excluded from many policies, every sign-in attempt should generate an alert. In a healthy environment, these accounts are almost never used.
A simple Log Analytics query can identify activity:
“`kusto
SigninLogs
| where TimeGenerated > ago(90d)
| where UserPrincipalName in (‘[email protected]’, ‘[email protected]’)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated desc
“`
In production, connect this detection to your SIEM, ticketing system, or alerting workflow. The response should be immediate: confirm whether the use was authorized, record the reason, rotate credentials if required, and review related sign-in activity.
Also test emergency access periodically. A break-glass account that nobody has validated in two years may not work when it matters. Testing should be controlled, documented, and communicated to the security team to avoid unnecessary incident escalation.
## Document the Recovery Procedure
Conditional Access recovery should not depend on tribal knowledge. Document the exact steps required to regain access if a policy causes an outage.
At minimum, include:
– Who is authorized to access emergency credentials
– Where credentials or authenticators are stored
– How to sign in with emergency accounts
– Which policies may need to be disabled first
– How to contact Microsoft support if needed
– How to notify stakeholders
– How to preserve logs for incident review
– How to rotate emergency credentials after use
Store the procedure somewhere accessible during an identity outage. A SharePoint document protected by the same tenant may not be enough. Maintain an offline or out-of-band copy under appropriate physical and administrative controls.
## Validate With Change Control
Conditional Access changes deserve the same discipline as firewall, routing, or production server changes. Even small edits can have wide impact.
A practical change checklist includes:
– Business reason for the change
– Policy name and expected behavior
– Users, groups, applications, and exclusions affected
– Report-only evidence reviewed
– Rollback plan
– Help desk notification
– After-hours support owner if risk is elevated
– Post-change validation steps
For larger environments, consider exporting policy configuration before major changes.
### Export Conditional Access Policies
Microsoft Graph PowerShell can help capture policy state for review and rollback documentation:
“`powershell
Connect-MgGraph -Scopes ‘Policy.Read.All’
Get-MgIdentityConditionalAccessPolicy |
Select-Object Id,DisplayName,State,CreatedDateTime,ModifiedDateTime |
Export-Csv .\conditional-access-policy-inventory.csv -NoTypeInformation
“`
For deeper backups, export full policy objects to JSON:
“`powershell
Connect-MgGraph -Scopes ‘Policy.Read.All’
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | ConvertTo-Json -Depth 20 | Out-File .\conditional-access-policies.json -Encoding utf8
“`
Treat these exports as sensitive configuration data. They reveal security architecture and should be protected accordingly.
## Common Mistakes to Avoid
### Excluding Too Many Users
Exclusions should be rare, documented, and reviewed. If a large percentage of users are excluded from a policy, the policy may be poorly scoped or operationally unrealistic.
### Combining Block and Grant Logic Carelessly
A block policy always wins. If one policy blocks access and another grants access with MFA, the sign-in will be blocked. This is useful when intentional, but painful when misunderstood.
### Forgetting Guest Users
External users may access Teams, SharePoint, or applications. Decide whether guests need separate controls, especially for sensitive collaboration sites.
### Ignoring Mobile and Desktop Clients
Browser testing is not enough. Outlook, Teams, OneDrive, Office desktop apps, mobile apps, and PowerShell modules can behave differently depending on token state and client capabilities.
### Relying Only on Trusted Locations
Named locations are useful, but they are not a complete security boundary. Public IPs can change, VPNs can be abused, and attackers may operate from allowed networks after compromising a device.
## A Practical Baseline for Many Organizations
While every environment is different, the following baseline is a reasonable starting point for many SMBs and nonprofits with Microsoft 365:
– Maintain two monitored emergency access accounts
– Require phishing-resistant MFA for privileged administrators where feasible
– Require MFA for all users
– Block legacy authentication after discovery and remediation
– Require compliant devices for admin portals and sensitive applications
– Use report-only mode before enforcement
– Send Entra sign-in logs to a central logging platform
– Review exclusions monthly
– Test emergency access quarterly
– Document rollback and recovery procedures
This baseline is not the final destination. It is a stable platform for more advanced controls such as Privileged Identity Management, risk-based access, application-specific session policies, and privileged access workstations.
## Summary and Key Takeaways
Conditional Access is not just an MFA switch. It is a policy engine that controls access to the applications and data your organization depends on. Designed well, it reduces account takeover risk, limits administrative exposure, and supports Zero Trust security. Designed poorly, it can interrupt operations or lock out the very people responsible for recovery.
Key takeaways:
– Build emergency access before enforcing broad Conditional Access policies.
– Use small, purpose-built policies instead of one oversized policy.
– Roll out changes through pilot groups and report-only mode.
– Protect administrators with stronger authentication than standard users.
– Block legacy authentication, but discover dependencies first.
– Treat service accounts as technical debt to reduce, not exceptions to ignore.
– Monitor break-glass accounts and review exclusions regularly.
– Document recovery steps outside the systems that may be affected by an outage.
For organizations that rely on Microsoft 365 and Entra ID, careful Conditional Access design is one of the highest-return security investments available. It improves protection without requiring a full infrastructure redesign, but it does require planning, testing, and operational discipline.
