Breaking down EMS Conditional Access: Part 1
Published Sep 08 2018 09:23 AM 10.8K Views
First published on CloudBlogs on Oct 31, 2016
This post is the first in a 3-part series detailing Conditional Access from Microsoft Enterprise Mobility + Security. The way your employees interact with their devices, apps, and corporate data has changed with the adoption of mobility and cloud services. While users have become more productive, the new norm of mobile productivity requires innovative tools that flex and flow to protect corporate data while giving your end users the best possible experience across their devices, wherever they are. In a recent post , we kicked off a discussion about how conditional access from Microsoft Enterprise Mobility + Security  helps you safeguard your sensitive corporate data in this mobile-first environment. Today, we’ll take that conversation one step deeper and explore the conditional parameters that can be used at the application, user, and location layers. We’ll cover device and risk-based conditional access in an upcoming post. Before getting started, it’s important to note that these layers are deeply connected and work together to deliver on our larger identity-driven security vision – for this discussion, though, we will assess them separately.


Cloud apps are gateways to lots of different types of information. While you may want to allow easy access to some apps, there are likely others which contain highly sensitive information – where you want to control access to them with more rigor. When you consider the various scenarios that exist when accessing applications, it’s clear you need more than a one-size-fits-all approach to app-level control. That’s why we’ve designed our application-based conditional access in a way that allows you to choose which policies to apply to which apps. You can set a policy that defines the conditions of an app’s access based on the sensitivity you define for it. For example, you can block access to an application from unknown locations, or require Multi-Factor Authentication, which can be required every time an app is accessed or required based on the location it’s being accessed from. These policies can be applied to any cloud (SaaS) or on-premises app protected by Azure Active Directory, including their rich, mobile or browser-based clients.


Azure Active Directory Premium’s advanced capabilities in identity and access management are at the heart of EMS’s identity-driven security story, and are the foundation that all our conditional access capabilities are built on. When setting conditional access policies, you’ll typically want to define which group of users you want various policies to apply to. EMS’ conditional access approach leverages the power of Azure AD Premium to make it easy for you to assign multiple conditions (at the location, application, device, and risk levels) to all users or multiple security groups. You can also specifically exclude groups from being affected by conditional access policies.


Location-based conditions allow you to define a set of trusted IP addresses, and allow access only from them. If a user attempts to access corporate assets from an unknown network, you can define what happens next by setting specific controls that either challenge the user with Multi-Factor Authentication (MFA) or block access entirely. And of course, you can define which user groups these polices will affect.

Bringing it all together

Now let’s check out a scenario that shows conditional access policy working at the user, location, and application layers. [caption id="attachment_42535" align="aligncenter" width="1024"] Because this app provides access to highly sensitive data, IT has applied a location-based conditional access policy that blocks users when they are working from an untrusted location. Marketing is one of the many security groups this policy is applied to.[/caption] For more scenarios that show conditional access in action, visit our new conditional access web experience .

Next up

Over the next month we’ll take a closer look at two other vital layers of our conditional access story: device- and risk-based conditions. Be sure to visit our blog regularly, or follow us on Twitter to make sure you don’t miss these upcoming installments of this series on conditional access. In the meantime, here are three important resources that will tell you more about what we’re delivering with conditional access:
Version history
Last update:
‎Sep 08 2018 09:23 AM