Agent Foskett Academy • Microsoft Entra • Module 3 • Lesson 39

Lesson 39 — Microsoft Entra Conditional Access Grant Controls

Microsoft Entra Conditional Access Grant Controls define what a user, device or application must satisfy before access is granted.

After a policy matches its users, resources and conditions, Grant Controls can require multi-factor authentication, a specific authentication strength, a compliant device, a hybrid Microsoft Entra joined device, an approved client application or an app protection policy.

This lesson explains Grant Control processing, authentication and device requirements, mobile application controls, ALL versus ONE logic, policy overlap and troubleshooting.

Conditions determine when a policy applies. Grant Controls determine what must be satisfied before access is granted.

Start Lesson Back to Microsoft Entra Academy

Agent Foskett Microsoft Entra Conditional Access Grant Controls lesson

What you will learn

This lesson explains how Grant Controls convert policy matches into enforceable authentication, device and application requirements.

MFA and authentication strength

Device grant requirements

Approved apps and protection

ALL versus ONE logic

Learning objectives

After completing this lesson, you should be able to design, test and troubleshoot Conditional Access Grant Controls.

Explain the purpose of Grant Controls.
Require MFA and authentication strengths.
Require compliant or hybrid joined devices.
Use approved apps and app protection policies.
Understand ALL versus ONE logic.
Investigate failed controls.

The problem this solves

A policy match does not by itself define the assurance needed for access.

Grant Controls turn the policy decision into specific authentication, device and application requirements.

Conditional Access decision flow

User requests access ↓ Assignments and conditions evaluated ↓ Policy matches ↓ Grant Controls evaluated ↓ Requirements satisfied? ┌────────────┴────────────┐ ↓ ↓ Yes No ↓ ↓ Access continues Challenge or block ↓ Session Controls may apply

What are Grant Controls?

Grant Controls define what must be satisfied before Microsoft Entra grants access to the protected resource.

Where they fit

Assignments define who and what. Conditions define when. Grant Controls define what must happen before access.

Grant Controls versus Session Controls

Control	When	Purpose
Grant	Before access	Require authentication, device or application assurance
Session	After access	Limit session behaviour and duration
Block	At grant decision	Deny access entirely

Block access

Block access denies the request whenever the policy applies. It must be tested carefully because no other control in that policy can override it.

Require multi-factor authentication

This control requires an acceptable Microsoft Entra MFA claim. A new prompt may not appear when the current token already satisfies MFA.

MFA evaluation flow

Policy requires MFA ↓ Existing authentication contains acceptable MFA? ┌────────────┴────────────┐ ↓ ↓ Yes No ↓ ↓ Claim accepted User challenged ↓ Success or denial

Authentication strengths

Authentication strengths require a defined class of methods instead of accepting any method that satisfies MFA.

Phishing-resistant access

Privileged and sensitive access can require phishing-resistant methods such as supported passkeys, FIDO2 security keys or certificate-based authentication.

MFA versus Authentication Strength

Requirement	Validates	Typical use
MFA	An acceptable MFA claim	Broad workforce protection
Authentication strength	A permitted method class	Higher assurance access
Phishing-resistant strength	A phishing-resistant method	Administrators and sensitive resources

Require compliant device

The device must be reported as compliant by the supported management service at sign-in time.

Require hybrid joined device

The device must have the required hybrid Microsoft Entra join relationship. Join state does not itself prove compliance.

Compliant versus hybrid joined

Control	Proves	Does not prove
Compliant device	Current management compliance	Hybrid join
Hybrid joined device	Required join state	Current health
Both	Join state and compliance	User authentication assurance

Require approved client app

This control restricts supported access scenarios to approved client applications, primarily in supported mobile environments.

Require app protection policy

This requires the application to receive and enforce an applicable app protection policy, supporting protected BYOD access.

Approved app versus App Protection Policy

Control	Assurance	Scenario
Approved app	Approved client is used	Supported mobile access
App protection policy	Data controls apply inside the app	BYOD and MAM
Compliant device	Whole-device management compliance	Fully managed access

Combining controls

When multiple controls are selected, the policy must specify whether all selected controls or only one selected control is required.

Require all selected controls

Every selected requirement must succeed. MFA plus compliant device means both must be satisfied.

Require one selected control

Any one selected control can satisfy access. This can create a weaker path when alternatives do not provide equivalent assurance.

ALL versus ONE logic

Logic	Example	Outcome
ALL	MFA + compliant device	Both must succeed
ONE	MFA OR compliant device	Either can grant access
ALL	Authentication strength + compliant device	Strong method and healthy device

ALL versus ONE decision tree

Multiple controls selected ↓ Operator configured? ┌────────────┴────────────┐ ↓ ↓ Require ALL Require ONE ↓ ↓ Every control succeeds Any one succeeds ↓ ↓ Combined assurance Alternative access path

Browser behaviour

Browsers can satisfy authentication requirements, but device and app controls depend on whether the session presents the necessary device context.

Mobile behaviour

Mobile policies can combine approved apps, app protection, compliance and authentication requirements.

Guest access

External users may not be able to satisfy internal device requirements. Cross-tenant trust and guest testing are essential.

Administrator policies

Privileged users should normally satisfy stronger Grant Controls, including phishing-resistant authentication and managed-device assurance.

Policy overlap

Multiple policies can apply to one sign-in, producing stricter combined requirements than any single policy.

Block precedence

If one applicable policy blocks access, successful controls in another policy do not override the block.

Agent Foskett investigation: “The policy wasn't wrong… the logic was.”

1. Privileged policy selected MFA and compliant device ↓ 2. Administrators expected either requirement ↓ 3. MFA users with non-compliant devices were blocked ↓ 4. Compliant devices without MFA were also blocked ↓ 5. Sign-in Logs showed both controls evaluated ↓ 6. Policy required ALL selected controls ↓ 7. Conditional Access behaved exactly as configured ↓ 8. Design intent and configured logic did not match ↓ 9. Documentation and testing were corrected

Conditional Access does not assume how multiple Grant Controls interact. The administrator explicitly chooses whether one or every selected control must be satisfied.

Investigation evidence

Sign-in Logs
Conditional Access results
Grant Control details
Authentication method and strength
Device compliance and join state
Client application
All applicable policies

Troubleshooting workflow

Identify failed sign-in ↓ Review every applicable policy ↓ Confirm selected Grant Controls ↓ Confirm ALL or ONE operator ↓ Inspect authentication, device and app signals ↓ Identify failed requirement ↓ Retest with fresh sign-in

Common mistakes

Confusing conditions with Grant Controls.
Misunderstanding ALL versus ONE.
Assuming every MFA method satisfies every strength.
Using join state as proof of compliance.
Ignoring guest and mobile limitations.
Reviewing only one applicable policy.

Best practices

Document every selected control.
Use authentication strengths for high-risk access.
Combine MFA and device assurance where appropriate.
Use ALL when every requirement is essential.
Use ONE only for equivalent alternatives.
Test browser, mobile, guest and admin scenarios.

Key takeaways

Grant Controls determine how access is granted.
Conditions determine when policies apply.
Session Controls act after access.
MFA and authentication strength are not identical.
Compliance and hybrid join prove different device properties.
Approved apps and app protection support mobile access.
ALL and ONE produce very different outcomes.
Overlapping policies can create stricter requirements.
Grant Controls are central to Zero Trust enforcement.

Related Agent Foskett resources

Continue developing Microsoft Entra Conditional Access, authentication and Zero Trust access skills.

Lesson 38 — Conditional Access Device Conditions Lesson 37 — Named Locations and Trusted Networks Lesson 36 — Conditional Access Best Practices Lesson 35 — Conditional Access Design Lesson 16 — Authentication Strengths Microsoft Identity and Access Services

Continue learning

Continue through Microsoft Entra Conditional Access controls, or return to the academy roadmap.

⬅ Previous lesson

Lesson 38 — Microsoft Entra Conditional Access Device ConditionsUse device platform, compliance, join state and filters to strengthen access decisions.

🏠 Academy home

Microsoft Entra AcademyReview the roadmap and continue through the identity security learning path.

📘 Next lesson

Lesson 40 — Microsoft Entra Conditional Access Session ControlsControl sign-in frequency, persistent browser sessions, application behaviour and continuous access evaluation.

Microsoft Entra Conditional Access Grant Controls

Microsoft Entra Conditional Access Grant Controls require MFA, authentication strengths, compliant devices, hybrid join, approved applications or app protection before organisational resources are opened.

Microsoft Entra Academy Lesson 39 — Conditional Access Grant Controls

This Agent Foskett lesson explains Grant Control processing, ALL versus ONE logic, authentication, device and mobile application requirements, policy overlap and troubleshooting.