What Is Conditional access? Security Definition

Think of conditional access like a nightclub bouncer who doesn't just check IDs at the door. The bouncer looks at several things before letting someone in: is the person on the guest list, do they look sober, are they wearing appropriate shoes, is it a VIP night, and is the club already too full? Even if someone has a valid ID, the bouncer might still say no if the person seems too intoxicated or if the club is at capacity.

Conditional access works the same way for your online accounts and company data. It doesn't just check that you typed the right password. It looks at a bunch of extra clues to decide if letting you in is safe at that moment.

These clues include where you are logging in from, what device you are using, whether that device has the latest security updates, what time it is, and even whether your behavior looks suspicious. For example, if you usually log in from New York during business hours and suddenly a login attempt comes from a country you have never visited at 3 AM, conditional access policies can step in. The system might still let you log in but then ask for a second form of authentication, like a code sent to your phone.

Or it might block the attempt entirely and send an alert to your IT team. This is much smarter than just using a password because passwords get stolen all the time. Conditional access adds layers of protection that adapt to each situation.

It is like having a smart lock on your door that checks not only the key but also the time of day, your face, and whether someone is trying to break in. For IT professionals, setting up conditional access policies is a core part of keeping company data secure in the cloud. It allows organizations to define rules like: allow access only if the device is managed by the company, require multi-factor authentication if the user is accessing sensitive data, or block access entirely if the sign-in risk is high.

These policies work across many apps and services, so a single rule can protect email, file storage, and business applications at the same time. In short, conditional access is about making smart, real-time decisions about who gets in and how much they can do, based on the full picture of the access attempt.

Conditional access is a policy-based access control mechanism used in modern identity and access management (IAM) systems, most notably in Microsoft Entra ID (formerly Azure Active Directory). It acts as a decision engine that evaluates access requests against a set of conditions and then applies appropriate controls, such as granting access, requiring multi-factor authentication (MFA), enforcing device compliance, or blocking the request entirely. The core components of a conditional access policy are assignments, conditions, and access controls.

Assignments define which users, groups, or roles the policy applies to, as well as which cloud apps or actions are targeted. Conditions are the signals that trigger policy evaluation. Common conditions include user risk (calculated by Microsoft Entra ID Protection), sign-in risk, device platform (Windows, iOS, Android), location (based on IP address or named locations), client app type (browser, mobile app, legacy authentication), and time of day.

Access controls define what happens when the conditions are met. Grant controls specify what must be satisfied for access to be allowed, such as requiring MFA, requiring a device to be marked as compliant (via Microsoft Intune or another MDM), requiring a hybrid Azure AD joined device, requiring an approved client app, or requiring an app protection policy. Session controls limit the user's experience after access is granted, for example by controlling session lifetime, enforcing app-enforced restrictions (like blocking download of files in SharePoint), or using Conditional Access App Control (a feature of Microsoft Defender for Cloud Apps) to monitor and control user sessions in real time.

When a user attempts to sign in, the following flow typically occurs. The user authenticates with their credentials. The authentication request is intercepted by the identity provider (IdP).

The IdP evaluates any applicable conditional access policies by checking the user's attributes, device state, location, risk scores, and other signals. If the policy conditions are met, the IdP applies the specified access controls. If the access controls are satisfied, access is granted.

If they are not, the user is prompted to satisfy them (e.g., enroll in MFA) or access is blocked. Conditional access policies are evaluated before the user receives a token, meaning that blocked requests never get access to the resource.

Technically, conditional access relies on standards such as OAuth 2.0 and OpenID Connect for authorization and authentication flows. It integrates with Microsoft Entra ID Protection for risk detection, Microsoft Intune for device compliance, and Microsoft Defender for Cloud Apps for session control.

Policies are stored as JSON objects in the Microsoft Graph API and can be managed programmatically. Conditional access is also referenced in the NIST 800-53 framework for access control and is a key component of Zero Trust architecture. In a Zero Trust model, no user or device is trusted by default; every access request must be verified based on the current context.

Conditional access is the engine that enforces this verification in real time. Conditional access policies do not replace authentication; they add an additional layer of evaluation after authentication occurs. The policies are also not applied to service-to-service traffic; they only affect interactive user sign-ins.

In Microsoft 365, conditional access is available with Azure AD Premium P1 or P2 licenses. P1 allows basic conditional access policies like MFA based on location. P2 adds risk-based conditional access, integrating with Identity Protection for user and sign-in risk.

For other cloud providers, similar concepts exist, such as AWS IAM conditions in SCPs (service control policies) and Google Cloud context-aware access. However, the term conditional access is most heavily associated with Microsoft Entra ID and Microsoft 365 security. For the AZ-104 and SC-900 exams, understanding how to configure and troubleshoot conditional access policies is essential.

For the MS-900 exam, you need to know what conditional access is and its licensing requirements. For Security+ and CISSP, understanding policy-based access control and risk-based decisions is part of the broader IAM and security architecture domains. Conditional access can be thought of as the runtime engine that makes access decisions dynamic and context-aware, moving beyond static allow/deny lists to a risk-adaptive authorization model.

Conditional access matters because passwords alone are no longer sufficient to protect sensitive data. Cyber attackers constantly steal credentials through phishing, brute force, or data breaches. Once they have a username and password, they can impersonate a legitimate user and access company resources.

Conditional access adds a critical safety net by evaluating the context of every sign-in attempt. Even if a password is compromised, a conditional access policy can block the attacker if they are logging in from an unusual location, using an unrecognized device, or signing in at a strange time. This dramatically reduces the risk of a data breach.

For IT administrators, conditional access provides a powerful tool to enforce security policies without disrupting user productivity. Instead of requiring MFA for every single login, which frustrates users, you can require MFA only when the sign-in appears risky. Users in the office on a managed device can have a seamless experience, while a login attempt from a coffee shop in another country triggers additional verification.

This balance between security and usability is essential in modern organizations. Conditional access also supports compliance requirements. Many regulations, such as GDPR, HIPAA, and PCI-DSS, require organizations to implement strong access controls.

Conditional access allows you to enforce policies like requiring compliant devices for accessing health records or blocking access from countries without adequate data protection laws. Finally, conditional access is a cornerstone of Zero Trust architecture. In a Zero Trust model, every access request is treated as potentially hostile, and access is granted only after verification of identity, device health, and context.

Conditional access is the engine that makes Zero Trust operational in a cloud-first world. For IT professionals, understanding conditional access is no longer optional, it is a core skill for managing modern identity and security.

Conditional access questions on exams typically fall into three patterns. The first pattern is scenario-based: you are given a business requirement and asked which conditional access settings to configure. For example: A company wants all users accessing financial data to use multi-factor authentication, but only when they are outside the corporate network.

Which conditional access assignments and conditions should you configure? You would need to select the correct app (financial app), users (all users), and conditions (locations: all untrusted networks), and then set grant control to require MFA. The second pattern is troubleshooting: a user reports they cannot access an app even though they typed the correct password.

The question provides details like the user is a contractor, using a personal device, and trying to access the app from home. You need to identify that a conditional access policy is blocking the request because the device is not compliant. You might then be asked how to fix it, such as by enrolling the device in Intune or excluding the user group from the policy.

The third pattern is conceptual: the question asks about the components of conditional access, the difference between grant and session controls, or the licensing required. For example: Which Azure AD license is required to use user risk as a condition in conditional access? The answer is Azure AD Premium P2.

Another variation asks about the order of evaluation: policies are evaluated after authentication but before a token is issued. A tricky question might display a policy with all conditions matched correctly but still not working because the policy is in report-only mode. Or a question about blocking legacy authentication because it does not support MFA, so you create a conditional access policy to block all legacy authentication protocols.

For the AWS SAA exam, the similar pattern uses IAM policies with conditions: allow access only if MFA is present or if the source IP is within a range. The question style is similar: you must pick the correct condition key and value. For Security+ and CISSP, the question might be something like: Which access control model evaluates user attributes before granting access?

The answer is attribute-based access control (ABAC), which is closely related to the concept of conditional access. Being able to map a scenario to the correct policy settings is key to passing these exam questions.

Conditional access is one of the most powerful tools in a Microsoft 365 administrator's security toolkit, but it requires careful planning and testing. In practice, before you ever create a conditional access policy, you should use the 'What If' tool in the Azure portal to simulate how a policy will affect a specific user, app, and condition. This tool helps you avoid accidentally blocking yourself or critical users.

When configuring a policy, always start with the assignments: who does this apply to? Typically, you will apply policies to specific user groups rather than all users, so you can test with a pilot group first. The 'Exclude' section is just as important as 'Include' because you must always exclude emergency access accounts that are not subject to MFA or location restrictions.

Next, select the target cloud apps. You can apply a policy to all cloud apps, but be careful because that may override other specific policies. It is better to target specific apps like Exchange Online or SharePoint.

For conditions, the most commonly used conditions are location and device platform. For location, you should define named locations for your corporate office IP ranges. For device platform, you can target policies for mobile devices that might need MFA even inside the office.

The sign-in risk and user risk conditions require Azure AD Premium P2 licenses, but they are extremely valuable for adaptive access. For example, you can create a policy that blocks all sign-ins with high risk and requires MFA for medium risk. For access controls, the most common grant control is 'Require multi-factor authentication'.

Another important control is 'Require device to be marked as compliant', which requires the device to be enrolled in Intune and meet compliance policies. For session controls, the 'Use app enforced restrictions' control works with SharePoint and Exchange to enforce limited access for unmanaged devices. The 'Use Conditional Access App Control' redirects the user session through Microsoft Defender for Cloud Apps, allowing real-time monitoring and blocking of sensitive actions like downloading a file.

One important trap: conditional access policies are not applied to guest users in the same way unless you target them specifically. You must also remember that policies are evaluated once at sign-in and again at token refresh intervals, so a user might be forced to re-authenticate if their device falls out of compliance mid-session. During testing, always set the policy to 'Report-only' mode first.

Report-only mode logs what would have happened without actually blocking users. You can then review the sign-in logs to see if the policy would have blocked legitimate users. Only after verifying the impact should you switch the policy to 'On'.

Another common real-world issue is legacy authentication. Many older apps use protocols that do not support modern authentication, so they cannot evaluate conditional access policies. You should create a separate policy that explicitly blocks all legacy authentication protocols, as they bypass conditional access entirely.

Finally, monitor the sign-in logs regularly for failed conditional access attempts. These logs show you which polices are being triggered and can help you fine-tune your rules. Conditional access is not a set-and-forget feature; it requires ongoing management as users, devices, and threat landscapes evolve.