Conditional Access and Identity Protection

Authentication establishes who a user is, but modern access security often needs to consider more than identity alone.

An organization may also want to consider factors such as the resource being accessed, the authentication strength required, device-related conditions, location-related signals, or detected risk.

Microsoft Entra Conditional Access helps organizations bring these signals together and apply access controls according to organizational policy.

In this lesson, you’ll learn the fundamental logic behind Conditional Access and how identity risk can influence access decisions.

What You’ll Learn

By the end of this lesson, you should be able to:

Explain the purpose of Conditional Access
Understand the basic structure of a Conditional Access policy
Recognize common signals used in access decisions
Distinguish conditions from access controls
Understand the concept of identity-related risk
Explain why organizations should test access policies carefully
Apply Conditional Access concepts to basic scenarios

Why Conditional Access Matters

Consider two authentication attempts involving the same employee.

In the first, the employee accesses a normal business application under expected conditions.

In the second, the employee attempts to access a sensitive application under circumstances that the organization considers higher risk.

Simply asking whether the password is correct may not provide enough information for an appropriate access decision.

Organizations may want access requirements to change according to the circumstances.

This is the fundamental idea behind Conditional Access.

What Is Conditional Access?

Conditional Access is Microsoft’s policy-based approach for controlling access using identity-driven signals and organizational requirements.

A useful simplified model is:

Assignments + Conditions → Access Controls

In other words:

Who or what is requesting access?

What resource are they trying to access?

What conditions or signals apply?

What should happen before access is granted?

This allows organizations to move beyond a simple allow-or-deny approach based only on a username and password.

Assignments

A Conditional Access policy needs a defined scope.

Depending on the policy, administrators can determine which identities and resources the policy applies to.

For example, a policy could target particular:

Users
Groups
Roles or identity categories
Applications or resources

Careful targeting is important.

A policy intended to protect administrators may not need to apply identically to every user, while a broader organizational policy may have a much wider scope.

Conditions and Signals

Conditional Access can evaluate relevant conditions and signals when determining how a policy applies.

Examples can include factors related to:

User or identity
Target resource
Device platform
Location
Client application
Sign-in risk
User risk

Not every policy needs every condition.

The organization should use conditions that support the security requirement it is trying to address.

Access Controls

After evaluating the policy scope and applicable conditions, Conditional Access can enforce controls.

Depending on the configuration and supported capabilities, a policy might require measures such as:

Multifactor authentication
A particular authentication strength
A device meeting specified requirements
Other supported grant controls

A policy can also block access when appropriate.

The important distinction is:

Conditions help determine when a policy applies.

Access controls determine what must happen as a result.

A Simple Conditional Access Scenario

Suppose Contoso wants stronger protection for users accessing a sensitive finance application.

The requirement is:

Users accessing the finance application must satisfy stronger authentication requirements.

Rather than changing authentication requirements for every application in the organization, administrators can create an access policy targeting the appropriate users and finance resource and require the desired control.

Conceptually:

Users: Finance application users

Target resource: Finance application

Requirement: Satisfy the configured authentication control

This demonstrates why Conditional Access is useful: security requirements can be applied according to context.

Identity Protection and Risk

Some identity environments can use risk information to help identify potentially suspicious activity.

Two concepts you’ll encounter are user risk and sign-in risk.

User Risk

User risk relates to the possibility that an identity may be compromised.

Think:

“How likely is it that this user’s identity has been compromised?”

Sign-In Risk

Sign-in risk relates to a particular authentication attempt.

Think:

“How likely is it that this sign-in was not performed by the legitimate user?”

Although the concepts are related, they are not identical.

One concerns the state of the identity, while the other concerns a particular sign-in attempt.

Risk-Based Access Decisions

Risk information becomes particularly useful when combined with access policies.

Suppose an organization normally allows an employee to access a resource after standard authentication.

If an access attempt presents a level of risk covered by organizational policy, additional controls may be required.

Depending on the organization’s configuration and licensing, administrators can use supported risk signals and policies to respond appropriately.

The broader principle is:

Higher-risk access can justify stronger controls.

Conditional Access and MFA

Conditional Access and MFA are closely related, but they are not the same thing.

MFA is an authentication control requiring multiple authentication factors.

Conditional Access is a policy system that can determine when particular access requirements should apply.

For example, Conditional Access can be used to require MFA under defined circumstances.

Remember:

MFA = authentication mechanism/control

Conditional Access = policy-driven access decision system

This distinction is important when analyzing identity scenarios.

Don’t Lock Everyone Out

Conditional Access is powerful, which also means incorrect configurations can cause significant disruption.

Imagine creating a policy that blocks access broadly and accidentally includes the administrators who would normally fix the policy.

Organizations therefore need careful deployment practices.

Administrators should consider:

Policy scope
Exclusions where appropriate
Testing
Emergency-access planning
Monitoring policy results
Gradual deployment

Microsoft Entra provides capabilities that can help administrators evaluate policies before fully enforcing them.

The important operational lesson is simple:

Test access policies before relying on them broadly.

Practical Scenario

Contoso has an administrative portal containing sensitive configuration capabilities.

The organization wants administrators to use stronger authentication when accessing it.

Ask four questions:

1. Who?
Administrators.

2. What resource?
The sensitive administrative resource.

3. Under what conditions?
According to the organization’s defined policy.

4. What control should be required?
The stronger authentication requirement selected by the organization.

Thinking about Conditional Access scenarios using this structure can make complicated questions easier to analyze.

Another Scenario: Risk

Suppose an employee’s sign-in triggers a risk level covered by the organization’s access policy.

Instead of treating the attempt exactly like every normal sign-in, the organization can use its configured identity-security controls to respond according to that risk.

The exact response depends on the organization’s policies and available capabilities.

The important concept is that risk can become an input into an access decision.

SC-300 Exam Focus

When you encounter a Conditional Access scenario, break it into components.

Ask:

Who?
Which users, groups, roles, or identities are affected?

What?
Which application or resource is being accessed?

When?
Which conditions or signals cause the policy to apply?

Then what?
What access control should be enforced?

Also distinguish carefully between:

Authentication → verifying identity

MFA → using multiple authentication factors

Conditional Access → deciding when access requirements apply

User risk → risk associated with the identity

Sign-in risk → risk associated with a particular sign-in

These distinctions can help you reason through scenario-based questions.

Quick Review

Before continuing, make sure you understand:

Conditional Access uses policies to make contextual access decisions.
Policies can target specific identities and resources.
Conditions and signals help determine when policies apply.
Grant controls determine requirements for receiving access.
MFA and Conditional Access are related but different concepts.
User risk and sign-in risk represent different types of identity-security risk.
Risk information can contribute to access decisions.
Poorly designed access policies can disrupt legitimate access.
Conditional Access policies should be planned and tested carefully.

Continue to Lesson 6

You’ve now moved from basic authentication into contextual access control.

Next, we’ll examine how applications and non-human workloads obtain identities and access resources, including the foundational concepts behind application registrations, service principals, and managed identities.

Next: Applications and Workload Identities →