Conditional Access 101 | Why you need it and how to use it

What is Conditional Access?

Conditional Access is a feature available within Azure AD and provides the ability to apply controls at the point of authentication. In its simplest form CA can be thought of as a workflow comprised of:

• Targeted identities (users and groups)
• Targeted services (Microsoft and 3^rd party, cloud and on-prem)
• Conditions that can “focus” the policy to ensure it only applies when appropriate (more on this in the examples below)
• Lastly, a set of controls are applied (also expanded upon in the examples below)

By leveraging these components together, we can rapidly improve the security posture of an organization while still enabling users to access services and data. And thanks to the massive number of natively integrated solutions, this service can often protect broad swaths of an environment with no additional configuration beyond the creation of the CA policies themselves.

Why would you use Conditional Access?

Without something like CA, many organizations are left applying access controls that can often be thought of as a "hammer-based approach." Rigid MFA enforcement, limited access to resources, and often dangerous exceptions that are neither easily managed nor tracked.

While this isn’t the worst position to be in it’s also far from perfect. Users can suffer from MFA fatigue and begin acknowledging prompts without thought of what triggered it.

An increase in support requests tied to access issues is often common with this methodology. And there are many cases in which a more nuanced approach is not only preferred but required to address things like differing levels of security for disparate services.

How do I use Conditional Access?

Now for the good stuff, some examples! I’ve laid out 3 policy examples with increasing levels of complexity but keep in mind that there is so much more to CA than what’s shown here.

Example #1: Disabling Legacy Authentication

Legacy Authentication is a major security gap as its use completely circumvents any MFA controls (among a plethora of other concerning weaknesses when compared to Modern Authentication).

This policy blocks any legacy authentication attempts before they ever reach the targeted service, reducing the threat to your organization.

Example #2: Basic MFA Control

This policy applies to all users, all apps, and is triggered by any access attempts from outside of the network boundaries (referred to here as trusted locations, which are excluded).

In effect, if a user is connected to the internal network, access is granted immediately. If they are not connected internally then an MFA challenge is triggered, access will not be granted until the MFA challenge is completed.

Example #3: Let’s get complex!

This one may be a bit specific, but it demonstrates the ability to tailor a policy to your specific needs. In this case, we have a user who can only access Salesforce when using their iOS device when it is both compliant AND they complete an MFA challenge, but they only need to complete the MFA challenge once a week.

Additional scenarios

Other realistic examples would include:

• Requiring MFA for all guest and external user access
• Restricting access to HR resources by the network location and compliance state of the user's device
• Blocking access to all resources from geographies you wouldn’t reasonably expect users to be in (such as North Korea).

While these examples are simple in nature, my hope is that they have demonstrated Conditional Access’s ability to improve your security posture through the intelligent targeting of highly granular controls. Conditional Access should be considered a cornerstone in your broader security suite.

Where to begin with Conditional Access

I would compare MFA without Conditional Access to placing a lock on every office, bathroom, and closet in your house or office. Much like having differing levels of physical access controls is often a requirement, your IT resources should be approached with a similar mindset.