How to Clean Up Conditional Access Without Locking Out Users

In this blog post How to Clean Up Conditional Access Without Locking Out Users we will explain how to simplify an untidy Microsoft 365 access environment while protecting staff productivity, administrator access and business continuity.

Conditional Access is the security decision engine within Microsoft Entra ID, the identity service behind Microsoft 365. It checks signals such as who is signing in, which device they are using, where they are connecting from and which application they want to access. It then decides whether to allow access, request multi-factor authentication, require a secure company device or block the attempt.

The problem is rarely a lack of policies. In many established businesses, the real problem is years of accumulated rules created by different IT providers, security projects and urgent requests. Nobody is completely sure which policies are still needed, so nobody wants to touch them.

Why Conditional Access clean-ups can go wrong

Conditional Access policies do not operate in isolation. Several policies can apply to the same sign-in, and the user must satisfy all applicable requirements. Two policies that look reasonable separately can create an unexpected block when combined.

For example, one policy might require multi-factor authentication outside the office. Another might require a device managed by Microsoft Intune, which manages and secures company computers and mobile devices. A contractor using a personal laptop could suddenly fail both requirements, even though neither policy was intended to stop approved contractors from working.

This is why simply deleting old policies or enabling a new baseline is risky. Our previous article on Conditional Access mistakes that put Microsoft 365 at serious risk covers the common design errors. Cleaning them up requires a controlled process rather than a series of portal changes.

Start with visibility rather than changes

The first step is to freeze non-urgent policy changes and build a complete inventory. For every policy, record its purpose, owner, status, targeted users, protected applications, exclusions and required security controls.

The policy name alone is not enough. A rule called “MFA policy” could cover all employees, only administrators or one legacy application. Its actual configuration is what matters.

Your IT team can retrieve a read-only policy list with Microsoft Graph PowerShell. PowerShell is an administration tool that can produce a consistent export instead of relying on screenshots.

Connect-MgGraph -Scopes "Policy.Read.ConditionalAccess"

Get-MgIdentityConditionalAccessPolicy -All |
 Select-Object DisplayName, State, CreatedDateTime, ModifiedDateTime |
 Sort-Object DisplayName

This command does not modify the policies. It provides a starting point for identifying unclear names, disabled rules, old test policies and configurations that have not been reviewed recently.

Protect emergency administrator access first

Before changing anything, confirm that the business has properly controlled emergency access accounts. These are dedicated administrator accounts used only when normal sign-in methods or security services are unavailable.

Emergency accounts should be excluded from Conditional Access policies that could cause a complete lockout. Their credentials must be securely stored, their use monitored and their ability to sign in tested regularly.

This is not permission for administrators to bypass security during normal work. It is a business continuity safeguard, similar to keeping a protected spare key for a building.

Group policies by business purpose

Once the inventory is complete, group policies by what they are trying to achieve. Common categories include protecting administrators, requiring multi-factor authentication, blocking outdated sign-in methods, controlling unmanaged devices, protecting sensitive applications and managing guest access.

This quickly reveals duplication. You may find three policies requiring multi-factor authentication for slightly different groups, or separate policies protecting Teams, Exchange and SharePoint even though these Microsoft 365 services depend on one another.

Do not combine policies purely to reduce the policy count. The goal is clarity and predictable outcomes. A small number of understandable policies is generally easier to test, but separate rules can still make sense when different teams, applications or risk levels require different treatment.

Build replacement policies in report-only mode

Microsoft Entra provides a report-only mode that evaluates a Conditional Access policy without enforcing it. Staff continue working normally, while the sign-in logs show what the proposed policy would have required or blocked.

Rather than editing a complicated live policy, it is often safer to create a clearly named replacement in report-only mode. Your team can then compare the new policy against real sign-in activity before switching anything on.

Report-only mode is powerful, but it is not a guarantee. It must be combined with the What If tool, which simulates specific sign-in situations, and with a review of actual sign-in logs. Testing should cover more than a standard employee on a company laptop.

• Executives travelling overseas
• Administrators performing privileged work
• Remote employees and home networks
• Contractors and guest users
• Shared or frontline devices
• Mobile phones and tablets
• Service accounts and automated business processes
• Windows 365 Cloud PCs and virtual desktops

The What If tool also has limitations. Microsoft 365 applications can depend on other services, so a simulation for one application may not expose every related requirement. Real sign-in evidence remains essential.

Use a pilot group before wider enforcement

After the report-only results have been reviewed, enable the replacement policy for a representative pilot group. Include people from different departments, locations, device types and working arrangements.

A pilot made up entirely of IT staff proves very little. IT users usually have newer devices, stronger authentication methods and a better understanding of security prompts than the broader workforce.

Agree on a rollback plan before enforcement. The team should know who can disable the new policy, how users will report problems and which signs would trigger a rollback. Rollout should then expand in controlled stages rather than moving immediately from ten pilot users to the entire company.

Retire old policies one at a time

When a replacement is working, disable the old policy before deleting it. Keep it disabled for an agreed observation period so it can be restored quickly if an overlooked application or user group experiences problems.

Change one major control at a time. If five policies are disabled on Friday afternoon and payroll access fails on Monday, identifying the cause becomes unnecessarily difficult.

Every change should have an owner, reason, approval record and review date. Microsoft Entra audit logs should also be retained so the business can see who changed a policy and when.

What a safer Conditional Access environment looks like

Consider a 200-person professional services business with 27 Conditional Access policies. Several are disabled, five have nearly identical names and nobody can explain why two executive groups are excluded from multi-factor authentication.

A structured review may reduce that environment to a smaller, documented policy set covering administrators, employees, guests, managed devices, outdated sign-in methods and sensitive applications. The immediate outcome is not simply a tidier portal.

The help desk receives fewer unexplained access calls. New employees receive consistent protection. Security exceptions become visible and approved. Leadership can also obtain clearer evidence that multi-factor authentication and administrative access controls support the Essential Eight, the Australian government’s baseline cybersecurity framework.

Conditional Access should also work with Microsoft Intune device management. Otherwise, the business may require a “compliant device” without having reliable processes to enrol devices, correct compliance problems or help employees regain access.

Keep the environment clean after the project

A clean-up is temporary unless governance improves. Review Conditional Access policies at least quarterly and after major application, device management or organisational changes.

Use a consistent naming standard that describes the users, applications and action. Add an owner and review date to the policy description. Temporary exclusions should always have an expiry date rather than remaining indefinitely.

The broader Conditional Access checklist for Microsoft 365 can help leadership confirm that the cleaned-up environment still covers the major security risks.

Reduce risk without disrupting the business

Conditional Access clean-up is not an administrative housekeeping exercise. Done properly, it reduces account takeover risk, lowers support costs, improves compliance evidence and gives employees a more predictable sign-in experience.

CloudProInc brings more than 20 years of enterprise IT experience to Microsoft 365, Azure, Intune, Defender and identity security projects. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we focus on practical improvements that work for the business, not simply what looks neat in an administration portal.

If you are unsure which Conditional Access policies are protecting your organisation and which are creating hidden risk, we are happy to review the current setup and explain the findings in plain English — no strings attached.