Rolling out Conditional Access without locking out your staff
Key takeaways
- Microsoft Entra Conditional Access is where the decision is made about who may access company data and under which conditions. Without it, MFA coverage has gaps.
- The fear of locking people out is justified, but a fixed sequence keeps it under control: inventory, two emergency access accounts, report-only mode, the What If tool, a pilot group, then one policy at a time.
- Exceptions belong in named groups with an expiry date and an owner.
- For the audit, what counts is the policy export, sign-in logs and documented exceptions. A clean rollout produces this evidence along the way.
Many management teams have decided on MFA and assume the topic is closed. In practice, it is Conditional Access that determines whether MFA is actually required at every sign-in, whether legacy protocols without MFA still work, and whether an administrator may sign in from a personal laptop. This article shows how to introduce Conditional Access without the managing director, the only administrator or a production line facing an error message on Monday morning.
Why does a company need Conditional Access if MFA is already enabled?
Because MFA without rules only applies where it happens to be requested. Conditional Access is the policy engine of Microsoft Entra ID: it combines signals such as user, device, location and application with a decision, for example “require MFA”, “managed device only” or “block”. For management, this means that without Conditional Access you cannot demonstrate to auditors, cyber insurers or customers that every sign-in is protected.
For IT: Conditional Access requires Microsoft Entra ID P1, which is also included in Microsoft 365 Business Premium. Risk-based policies require Entra ID P2. Conditional Access enforces the sign-in methods you choose; it does not provide them.
What are companies afraid of when introducing it?
Being locked out, and rightly so. A badly scoped block policy can lock out all administrators at once. Typical scenarios: the managing director is travelling and cannot reach her mailbox, the only administrator has lost his phone, or a scanner that sends mail over an old protocol suddenly stops working.
All three are avoidable. Four steps come before any policy: exclude emergency access accounts, test with a pilot group, make sure users have registered their authentication methods, and communicate the change.
In what order should Conditional Access be introduced?
The safe order is: first know what is connected, then build the emergency exit, then observe, and only then enforce.
1. Inventory of applications, users, locations and devices
Establish which applications sign in through Entra ID, which user groups exist (staff, administrators, guests, service accounts), from which locations people work and which devices are managed in Microsoft Intune. The Entra ID sign-in logs show which clients and protocols are actually in use. They also reveal devices that still rely on legacy authentication, meaning older sign-in methods without MFA support.
2. Set up two emergency access accounts
Emergency access accounts, also called break-glass accounts, are cloud-only accounts with the Global Administrator role that are used only in an emergency. You should have at least two, using phishing-resistant authentication (for example FIDO2 security keys), excluded from all policies that block or restrict sign-in, and with an alert on every sign-in. Validate them at least every 90 days. Put the accounts in a dedicated group and exclude that group from every policy.
3. Report-only mode and the insights workbook
Every new policy starts in report-only mode. It is evaluated at each sign-in but not enforced, and the result appears in the sign-in log under the “Report-only” tab. The “Conditional Access insights and reporting” workbook summarises the impact across all sign-ins. It requires sign-in logs to be streamed to a Log Analytics workspace. Run each policy in report-only mode for at least two weeks.
4. The What If tool for edge cases
The What If tool lets you simulate a sign-in, such as “managing director, iPhone, abroad, Outlook”, and shows which policies would apply. This helps with rare combinations that report-only data may not cover.
5. Pilot group, then one policy at a time
Start with a pilot group from IT and a few technically confident staff from the business. Then extend one policy at a time. A proven sequence:
- Block legacy authentication. Old protocols do not support MFA and therefore bypass it.
- MFA for all users. Excluding the emergency access accounts.
- Compliant device for administrators. Admin portals only from devices that Intune reports as compliant.
- Phishing-resistant MFA for administrators. Using the “Phishing-resistant MFA” authentication strength. Our webinar recording explains why codes and push approvals are not enough. We describe the migration in Conditional Access and passkeys.
How should exceptions be handled?
Exceptions need a process. Create a named exclusion group for each policy, record a reason, an owner and an expiry date for every member, and review the group regularly. Microsoft Entra access reviews can automate this review and make it auditable. This requires Entra ID P2 or Entra ID Governance.
For service accounts, check whether they can be replaced by managed identities or service principals. Service principals are not covered by user-scoped policies anyway and need their own rules for workload identities.
What should you watch during the first 14 days?
After switching a policy to “On”, we recommend reviewing the sign-in logs daily for two weeks. Look for failed sign-ins related to Conditional Access, users who repeatedly fail on the same policy, and any sign-in by the emergency access accounts.
Announce the change to staff in good time, explain the reason briefly and name a channel for problems.
Which mistakes do we see most often?
- Security defaults are still on. Security defaults and Conditional Access are not meant to be combined. Switching off security defaults before the replacement policies are running creates a gap. Plan the switch so that both happen on the same day.
- All guests excluded by accident. To avoid questions from partners, “guest or external users” are excluded from the MFA policy wholesale. Protection is then missing exactly where you have the least control over the accounts.
- Service accounts forgotten. An account used by a scanner or an interface fails on the new policy and operations stop.
- No named exceptions process. Exceptions are added directly to individual policies, and a year later nobody knows why.
What evidence will the auditor expect?
Auditors and insurers typically ask for three things: an export of the active policies with a date, extracts from the sign-in logs that show their effect, and the list of exceptions with justification. If you follow the rollout described above, you will already have these documents at the end. Keep the report-only analyses as well: they show the rollout was planned and controlled.
Frequently Asked Questions
Which licence do I need for Conditional Access?
Conditional Access requires Microsoft Entra ID P1. This licence is included in, among others, Microsoft 365 Business Premium and Microsoft 365 E3 and E5. Risk-based policies and access reviews for exclusion groups require Entra ID P2 or Entra ID Governance.
Do emergency access accounts also need to be excluded from report-only policies?
No. Report-only policies do not block sign-in and therefore do not need an exclusion. By the time you switch a policy to “On”, however, the emergency access group must be excluded.
How long should a policy run in report-only mode?
Two to four weeks. If month-end closing or shift changes create particular sign-in patterns, the observation period should include them.
What happens if someone is locked out despite all this?
Sign in with an emergency access account, set the affected policy back to report-only and analyse the sign-in in the log. Every use of an emergency access account should then be documented and reviewed.
The next step
If you would like to know where your current policies have gaps, we review this in our fixed-price Gap Assessment, including emergency access accounts, exceptions and the state of your evidence. If you wish, we take over day-to-day operation and sign-in log analysis as part of Managed Security.