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

Lesson 3 — Conditional Access Fundamentals

Conditional Access is Microsoft's Zero Trust policy engine.

It evaluates signals such as identity, target resource, device, location, client application and risk, then decides whether access should be blocked, granted with requirements or limited through session controls.

This lesson explains the structure of a Conditional Access policy, how multiple policies combine, why report-only mode is essential for testing and how to avoid creating either a security gap or an administrator lockout.

Conditional Access does not replace authentication. It decides what additional conditions must be satisfied after identity is evaluated.

Start Lesson Back to Microsoft Entra Academy

Agent Foskett Microsoft Entra Conditional Access Fundamentals lesson

What you will learn

This lesson introduces the logic, controls and safe deployment process behind Conditional Access.

Assignments and conditions

Grant and session controls

Policy evaluation and overlap

Report-only testing and safe rollout

Learning objectives

After completing this lesson, you should be able to explain and evaluate a basic Conditional Access policy.

Explain Conditional Access as a Zero Trust policy engine.
Identify assignments, conditions and target resources.
Differentiate grant controls from session controls.
Explain how multiple policies combine.
Plan a safe report-only and pilot rollout.

The problem this solves

A password alone cannot answer whether a sign-in should be trusted.

Conditional Access lets organisations use identity, device, application, location and risk context to enforce stronger access requirements or block unsafe access.

What is Conditional Access?

Conditional Access is Microsoft Entra's policy engine for applying access controls based on sign-in context.

Policies behave like if-then statements: if a sign-in matches the selected users, resources and conditions, then apply the configured grant and session controls.

IF ├── Selected users or identities ├── Selected applications or resources └── Selected conditions │ ▼ THEN ├── Block access ├── Require grant controls └── Apply session controls

Agent Foskett tip:

Conditional Access evaluates access context. It does not decide whether a password is correct, but it can require stronger proof or deny the request.

Assignments

Assignments define who or what the policy targets and which resources are protected.

They typically include users, groups, directory roles, workload identities, target resources and supported user actions or authentication contexts.

Target resources

A policy can target cloud applications, actions or authentication contexts.

Examples include Microsoft 365, Exchange Online, SharePoint, Microsoft Graph, Azure management and connected enterprise applications.

Conditions

Condition	What it evaluates
User risk	The probability that the identity itself is compromised.
Sign-in risk	The probability that the current authentication request is not legitimate.
Device platform	The operating system reported during the sign-in.
Locations	IP-based named locations, trusted networks, countries or regions.
Client apps	Browser, mobile and desktop clients, modern authentication or legacy authentication categories.
Device filters	Device properties used to include or exclude specific devices.

Named locations

Named locations group trusted IP ranges or geographic locations so policies can treat them differently.

A trusted location reduces one risk signal; it does not make every sign-in from that address automatically legitimate.

Client applications

Client-app conditions help distinguish browser and modern-authentication clients from older or less secure authentication flows.

Blocking legacy authentication remains an important baseline because those protocols may not support modern controls such as MFA.

Grant controls

Grant controls decide whether access is blocked or which requirements must be satisfied before access is granted.

Grant control	Purpose
Block access	Denies the sign-in when the policy applies.
Require multifactor authentication	Requires a valid MFA claim or supported multifactor authentication.
Require authentication strength	Requires one of the authentication method combinations allowed by the selected strength.
Require compliant device	Requires device compliance information from Intune or a supported partner.
Require Microsoft Entra hybrid joined device	Requires a supported hybrid-joined device identity.
Require terms of use	Requires acceptance of the selected terms before access.

Require one or require all

When several grant controls are selected, the policy can require one selected control or all selected controls, depending on configuration.

This distinction can significantly change the security outcome and user experience.

Block takes precedence

If an enabled policy that matches the sign-in uses the block grant control, the sign-in is blocked.

Satisfying MFA in another policy does not override a matching block policy.

Session controls

Session controls shape what happens after access is granted.

Session control	Example use
Sign-in frequency	Controls how often reauthentication is required.
Persistent browser session	Controls whether the browser session remains signed in.
App-enforced restrictions	Allows supported applications to restrict access on unmanaged devices.
Conditional Access App Control	Routes supported sessions through Microsoft Defender for Cloud Apps for real-time controls.
Continuous access evaluation	Supports near-real-time response to critical identity and policy events in supported services.

How policy evaluation works

1. Sign-in request begins 2. Microsoft Entra gathers session details 3. Enabled and report-only policies are evaluated 4. Matching assignments and conditions are identified 5. Any matching enabled block policy stops access 6. Required grant controls must be satisfied 7. Session controls are applied 8. Access is granted, limited or denied

Multiple policies can apply

Conditional Access policies are not normally processed as a simple first-match list.

One sign-in can match several policies, and the user must satisfy the combined requirements of all applicable enabled policies.

Policy exclusions

Exclusions are commonly used for emergency-access accounts, specific identities or controlled exceptions.

Broad exclusions create security gaps, so every exclusion should have an owner, justification and review date.

Report-only mode

Report-only mode evaluates a policy and records what would have happened, but it does not enforce grant controls or session controls.

Users are not blocked, challenged for MFA or required to satisfy the report-only controls.

Policy in Report-only │ ├── Assignments evaluated ├── Conditions evaluated ├── Grant result calculated ├── Session result calculated └── Nothing enforced

Critical point:

A report-only policy can look healthy in logs while providing no real protection.

What If tool

The Conditional Access What If tool helps model which policies would apply to a supplied user, resource and sign-in context.

It is useful for design and troubleshooting, but it should complement—not replace—report-only testing and real sign-in analysis.

Insights and reporting

The Conditional Access insights and reporting workbook helps administrators understand policy impact over time.

Use it to compare applied, not applied, failure and report-only outcomes across users, applications and policies.

Safe rollout workflow

1. Define the threat or control objective 2. Choose clear users and target resources 3. Exclude emergency-access accounts 4. Configure the minimum required conditions 5. Start in Report-only 6. Review sign-in logs and reporting 7. Test expected and unexpected scenarios 8. Enable for a pilot group 9. Expand in controlled stages 10. Monitor failures, exclusions and user impact

Emergency-access accounts

Organisations should maintain emergency-access accounts that are protected, monitored and excluded from policies that could cause a tenant-wide lockout.

These accounts require strong operational governance and alerting because their exclusions make them highly sensitive.

Policy naming

Clear names make troubleshooting and investigation easier.

A useful name should communicate state, target, resource and control—for example, CA-PROD-AllUsers-AllApps-RequireMFA.

Example access decision

1. Finance user signs in to Exchange Online 2. The user is included in an all-users MFA policy 3. The application is in scope 4. The location is outside the trusted office range 5. The device is unmanaged 6. One policy requires MFA 7. Another policy requires a compliant device 8. MFA succeeds but the device requirement is not met 9. Access is denied

Agent Foskett investigation principle:

Do not ask only which policy applied. Ask which combined requirements the sign-in had to satisfy.

Example risk-based block

High-risk sign-in │ ├── User and application match ├── Sign-in risk condition matches └── Block access control applies │ ▼ Access denied

Example report-only gap

Policy designed to require MFA │ ├── Sign-in matches policy ├── Report-only result says MFA required └── Policy is not enabled │ ▼ User receives no MFA challenge from that policy

Common mistakes

Mistake	Why it creates risk	Better practice
Leaving important policies in Report-only	The policy records outcomes but enforces nothing.	Complete testing, approve the change and move deliberately to enabled.
Targeting all users without emergency access planning	A policy mistake can lock administrators out of the tenant.	Maintain and monitor emergency-access accounts.
Creating broad exclusions	Large groups of users or applications bypass intended protection.	Use narrow, documented and reviewed exclusions.
Building too many overlapping policies	Troubleshooting becomes difficult and unexpected combined requirements appear.	Use a clear baseline design and consistent naming.

Key takeaways

Conditional Access is Microsoft's Zero Trust policy engine.
Policies use assignments, conditions, grant controls and session controls.
Multiple enabled policies can apply to the same sign-in.
A matching block policy takes precedence.
Report-only evaluates but does not enforce protection.
Safe rollout requires emergency access, testing, pilots and continuous monitoring.

Related Agent Foskett resources

Continue developing Conditional Access, sign-in analysis and identity investigation skills with these connected resources.

Lesson 2 — Understanding Sign-in Logs Lesson 1 — What is Microsoft Entra? The Conditional Access Policy Was in Report-only Mode The Login Was Successful but the Risk Was High Investigating IdentityLogonEvents Hunting Risky Sign-ins Identity and Access Services

Continue learning

Continue through Module 1 — Entra Foundations, or return to the Microsoft Entra Academy roadmap.

⬅ Previous lesson

Lesson 2 — Understanding Sign-in LogsReview authentication status, device context, Conditional Access results and identity risk.

🏠 Academy home

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

📘 Next lesson

Lesson 4 — MFA and Authentication MethodsLearn how Microsoft Authenticator, passkeys, FIDO2, Windows Hello for Business and Temporary Access Pass strengthen authentication.

Microsoft Entra Conditional Access Fundamentals

Microsoft Entra Conditional Access evaluates identities, target resources, devices, locations, client applications and risk before blocking access, requiring grant controls or applying session controls.

Microsoft Entra Academy Lesson 3 — Conditional Access Fundamentals

This Agent Foskett Microsoft Entra Academy lesson explains policy assignments, conditions, grant controls, session controls, report-only mode, multiple-policy evaluation and safe rollout.