Microsoft Entra Conditional Access blocks legitimate users when their sign-in fails a policy requirement, even if their password and multifactor authentication (MFA) are correct. Common causes include missing device-compliance information, unsupported authentication methods, unexpected network locations and overlapping policies.
A valid account does not automatically satisfy every access condition. The correct response is to identify the failed requirement before changing policy scope or adding an exclusion.
Start with the sign-in evidence, then distinguish a configuration problem from a control operating as intended.
What Microsoft Entra Conditional Access evaluates
Conditional Access is a policy-based feature in Microsoft Entra ID, formerly called Azure AD Conditional Access. It evaluates signals such as identity, device health, location and risk in real time when making access decisions.
Policies can allow access, block it, or require additional controls such as MFA or device compliance. That does not mean every existing session is reassessed continuously; behaviour depends on the application, token and supported session controls.
These 5 components explain what a policy targets and requires.
| Component | What it determines |
|---|---|
| Users and Groups | Which employees, administrators or guests are included or excluded. |
| Cloud Apps and Services | Which resources are protected, shown as target resources in the editor. |
| Conditions | When the policy applies, including platform, location, client type and risk. |
| Access Controls | Whether access is blocked or requires controls such as MFA or compliance. |
| Session Controls | How supported sessions behave after access, including reauthentication requirements. |
The important distinction is between authentication and authorisation. Proving identity does not establish that the device, connection or authentication method meets the resource’s requirements.
Why a legitimate sign-in can fail
Device ownership does not establish compliance
A company-owned laptop can fail a compliance requirement. Microsoft Intune assesses configured standards, which can include encryption, antivirus protection and supported operating-system versions, depending on the platform.
Entra then uses the reported compliance state. An enrolled device may still be non-compliant, while a browser or application may fail to present the device identity needed for evaluation.
Review the Intune finding and the sign-in’s device details together. Repeated password resets will not repair an encryption failure or missing device identity.
Personal-device access needs a separate design. Our guidance on Microsoft 365 BYOD security distinguishes mobile app protection from unrestricted access on personal computers.
Location and authentication requirements can change the result
Location rules normally use the connection’s public IP address, not the employee’s physical presence. VPNs, corporate proxies and mobile networks can therefore produce unexpected results against configured named locations.
Country restrictions reduce some unwanted access, but do not prove that an allowed connection is trustworthy.
Authentication strength introduces another distinction. Completing SMS-based MFA does not satisfy a policy requiring phishing-resistant authentication. Register and test supported methods before enforcing the stronger requirement.
Identify the policy that caused the failure
A sign-in error establishes that access failed; it doesn’t identify the correct remedy. Review the affected event, its authentication details and every evaluated policy before changing a grant control or exclusion.
Open the actual failed sign-in
In Microsoft Entra ID, open the user’s sign-in logs in the Entra admin center and locate the event using its timestamp, application and correlation ID where available.
Review the resource, client application, IP address, device information, risk level, authentication details and results for each Conditional Access policy together. Error AADSTS53003 indicates that Conditional Access blocked token issuance, but the policy results establish which requirement needs investigation.
Include non-interactive sign-ins where background access fails. An Outlook token request can produce a different result from an interactive browser sign-in.
Evaluate every applicable policy
Applicable policies combine their requirements. Passing an MFA policy doesn’t override a separate policy blocking the location or requiring a compliant device.
An exclusion affects only the policy containing it. Another applicable policy can still block the same account.
A result of “Not applied” establishes that the particular policy didn’t apply. It doesn’t prove that MFA or another authentication requirement was unnecessary.
Use the Conditional Access What If tool to evaluate policy targeting, but retain the actual sign-in event as evidence of what happened.
Create and test policies without a tenant-wide lockout
Define the business requirement before opening the policy editor. Record the protected resources, intended users, acceptable devices and recovery arrangements.
Use this deployment sequence:
- Establish emergency access before enforcement. Exclude at least 1 administrator account during testing to reduce lockout risk; maintain the stronger emergency-account arrangements described below.
- Open the Entra admin center, then Entra ID > Conditional Access > Policies. Select + New policy and give it a descriptive name.
- Configure users, target resources, conditions and controls. Where multiple grant controls are selected, distinguish requiring all selected controls from requiring any 1.
- Select report-only mode and review evaluated sign-ins. Microsoft’s report-only guidance explains how to assess policy impact before enforcement.
- Enable the policy for a pilot group, resolve failures and expand in stages. Retain a documented rollback route.
Include iPhones, Android devices, contractors, travelling staff and people using multiple work accounts. A successful test on an administrator’s managed laptop does not establish that those workflows will work.
Report-only evaluation cannot demonstrate every user interaction. An enforced pilot remains necessary before wider deployment.
Choose controls that match the business task
Foundational policies follow zero trust by evaluating identity and context rather than trusting a connection by default. They normally address MFA, privileged access, legacy authentication and access from unmanaged devices. Each requires a defined purpose and deployment sequence that preserves essential work.
Microsoft strongly recommends blocking legacy authentication. Its published analysis attributes more than 97% of credential-stuffing attacks and more than 99% of password-spray attacks to legacy authentication protocols.
Inventory dependencies first, then block those protocols for most users. Unsupported clients and older integrations may stop working; that doesn’t justify a permanent, organisation-wide exception.
For devices, use Intune compliance where the task requires managed endpoints. Maintain a consistent baseline across office, home and travelling users, as discussed in our endpoint security guidance.
For guest access, decide whether to accept authentication and device claims from a guest’s home tenant. Otherwise, a compliant-device requirement may demand evidence the guest can’t supply.
Session controls can restrict supported browser downloads or require reauthentication. Download restrictions reduce local storage but can’t prevent every form of information capture.
Keep exclusions narrow and recovery independent
Give exclusions ownership and review
Excluding a user means that policy’s intent cannot be enforced for that user. Individual exclusion lists also make the combined bypass population harder to review.
Use a cloud security group as an exclusion group, with a named owner, documented justification and review process. Microsoft recommends using Microsoft Entra access reviews to reassess exclusion membership.
Access reviews require an eligible Microsoft Entra ID P2, Microsoft Entra ID Governance or Enterprise Mobility + Security E5 licence. Licensing doesn’t establish that reviews are configured or that removal decisions are applied.
Record why each exception exists and what must change before it can be removed. An exclusion without an owner can outlast the problem it was intended to resolve.
Protect emergency access without removing authentication
Maintain at least 2 cloud-only emergency accounts, each used as a break-glass account, with permanent active Global Administrator assignments and phishing-resistant MFA. Their authentication and recovery arrangements should remain independent of normal administrator access.
Exclude them from policies that could create lockout dependencies, including inappropriate managed-device requirements. Conditional Access exclusions don’t remove Microsoft’s separate mandatory MFA requirements for administrative access.
Monitor successful and failed sign-ins, protect credential custody and test recovery. A password stored securely is insufficient if the required authentication method is unavailable.
Use policy plans to reduce configuration drift
Conditional Access policy plans group rules by persona or security goal. Shared conditions and assignments are defined once and inherited by the rules, rather than repeated across separate policies.
This reduces duplicated configuration, but a mistake in shared targeting can affect multiple rules. Review the resulting scope before deployment.
Microsoft’s preview policy-plan migration experience analyses existing policies and proposes a consolidated structure. Original policies remain unchanged and enforced until cutover.
Migration does not establish that the original rules were correct. Our Microsoft 365 security assessment can support a wider review of authentication, device access and permissions before consolidation.
Key takeaways
- Identify the failed sign-in and every applicable policy before changing access requirements.
- Repair missing authentication or compliance prerequisites where the policy reflects a valid business requirement.
- Treat exclusions as controlled exceptions, with independent emergency access and accountable review.
Frequently asked questions
Which licences are needed?
Conditional Access generally requires Microsoft Entra ID P1; risk-based policies require P2. Microsoft 365 Business Premium includes P1 and Intune, but protected users still need suitable licensing for the controls used. A product licence does not configure those controls.
Why does MFA keep appearing after a successful sign-in?
Sign-in frequency settings, separate applications and authentication-strength requirements can trigger further authentication. Registration requirements can also interrupt access. Review the event and authentication details rather than assuming every prompt was caused by the same Conditional Access policy.
Resolve the failed condition before weakening the policy
Legitimate users can be blocked because a requirement is unmet, incorrectly targeted or dependent on unavailable infrastructure. Establish which explanation applies before removing protection.
Use report-only evaluation, representative pilots and controlled exceptions to address access failures without creating permanent bypasses.
Speak to our team about business IT security support to review Conditional Access, Intune dependencies and recovery arrangements across your Microsoft environment.
