Why AD360
 
Solutions
 
Resources
 
 

Components of conditional access

Shreya Iyer

Apr 206 min read

Book Demo

Table of Content

Read more
  • 5 pain points you can overcome in AD user account management  
    Manual vs. automated identity life cycle management  
    Active Directory clean-up: Should you automate it?  
  • Maintain confidentiality of critical information by implementing the POLP  
    6 essential capabilities of a modern UBA solution  
    How can SSO help in reinforcing password security?  
  • Authentication vs. authorization  
    5 simple steps to HIPAA compliance  
    Smart strategies to provision and de-provision Active Directory  

The term "conditional access" speaks for itself here—it basically means granting access to resources based on specific factors and conditions. It works on the if-else approach, and it isn't as simple as it sounds.

The Zero Trust approach is also made use of in conditional access to avoid even the smallest chances of a data breach or unauthorized access from happening. This makes conditional access complex but for all the good reasons. You can tick most boxes with it: compliance, centralized management, enhanced security, and more.

Speaking of the complexity, conditional access isn't just one component where if a condition is met by an access request, access is granted. For instance, you can't just invest in expensive coffee because the barista claims to be an expert or the coffee sounds particularly delicious. The coffee has to be made from freshly roasted beans and brewed in a clean machine. Not to mention, it has to hit the right spots in your taste buds, and figuring that out is complex.

Coffee debates aside, conditional access does comprise multiple components that make it complex. Let's talk about them below.

Assignments

With assignments, you can define and assign who the conditional access policies apply to and specify users and groups. For example, you can target specific users or roles within your organization. There are a few reasons for doing this. First, the right entities will have access to only the resources that are required to perform their tasks. Second, they're also subject to security measures according to their functions.

Assignments in conditional access comprise three main components:

  • Users and groups: You can specify the users and/or groups that are to be included or excluded from the policies you design and implement. For instance, for users that need elevated access for temporary tasks, you can have them authenticated with MFA or just-in-time access.
  • Roles: Apart from user and group assignments, you can assign policies based on the roles within your organization. Some policies can apply to all employees, while some apply only to admins or executives.

Access controls

We've covered the who in conditional access. Next is the what. What actions should be taken when the access request meets the conditions you have specified? This is what access controls take care of. Like a leader or big brother—again, for all the good reasons—access controls determine if access should be granted or blocked.

There are only two actions, as we discussed above: grant or block access. However, these controls depend on certain requirements, which are implemented through the following methods:

  • To grant access:
    • MFA: This requires users to verify their identity with a second factor, such as a code in a mobile app or an SMS code. To take the security up a notch, it can require the user to authenticate through a biometric (fingerprint or facial recognition). The cherry on top is the additional factor, which aims to avoid even questionable-but-not-so-harmful access requests.
    • Device compliance: With this, access can be granted only if the device being used to make the access request complies with certain security standards, such as having the latest antivirus software installed or having incorporated a mobile device management solution. Devices need health checks too, and they have to be secure—no vulnerabilities or security incidents associated with them.
    • Terms of use: Before you install an application, you typically have to check a box to agree with the terms of use. In an organization, users also have to read these terms before accessing certain applications or data. This enforces compliance and compels users to acknowledge specific security policies, which should also be mandated.
  • To block access:
    • Sign-in risk: You can block access based on the risk level of a sign-in attempt. For example, if a sign-in is detected from an unfamiliar location, device, or even outside business hours, it is considered to be high risk. Even if a request is made from a previously authorized device at an unusual time, access can be blocked or require an additional authentication method, such as MFA.
    • Location-based restrictions: As mentioned earlier, access can be blocked from unfamiliar areas, from IP ranges deemed high risk, or from locations where your organization does not function. This makes it easier to avoid threats from cybercrime-heavy areas.
    • Legacy authentication: Older authentication protocols, such as IMAP, SMTP, and POP3, were once secure, only requiring usernames and passwords to gain access. Now, these credentials can be used to let anyone gain unauthorized access. That's why there are methods to prevent this, like MFA and the concept of Zero Trust. With that in mind, blocking legacy authentication does help keep unauthorized access at bay.

Cloud apps or actions

It's important to identify which application or action the conditional access policies target to enable precise access control. We've mentioned Zero Trust multiple times, but for the purpose of security, conditional access helps minimize access to applications as well. Some applications might be developed in your organization, but you still need to have conditional access policies apply to them.

After identification and fixation of your policies, you need to implement the policies. Some considerations before you do include deciding if you're going to target all apps or just specific ones, which will depend on your organizational policies.

Conditions

Conditions are additional criteria you can add to access requests that the policies can apply to. Apart from location and device health, you need to consider other equally crucial conditions and factors, such as:

  • User risk level: Policies can be based on the assessed risk level of the user, such as assessing if their credentials have been compromised or if their account is exhibiting any unusual behavior. An example would be accessing data previously authenticated at 3am instead of doing it the next day.
  • Sign-in risk level: This considers the risk associated with the sign-in attempt, such as unusual sign-in behavior or a sign-in from an unusual location. Apart from signing in outside of business hours, signing in from unfamiliar or blocked locations is also considered high risk. To assess and authenticate such requests, you can make use of methods like MFA or adaptive authentication (i.e., context-aware MFA or multi-step authen tication).
  • Client apps: You can also target the type of application used to access resources, such as web browsers, mobile apps, or specific clients. Conditional access policies can implement different controls based on the client app. For instance, you can block access to clients with legacy authentication (usernames and passwords—a big red flag without MFA).

Now that you know what components make up conditional access, you can leverage its granular approach to create and implement nuanced conditional access policies to strengthen the security of your resources while maintaining a convenient user experience. Not to mention, you can modify the policies according to evolving threats and changes in your organization or industry.

 
Chat now
   

Hello!
How can we help you?

I have a sales question  

I need a personalized demo  

I need to talk to someone now  

E-mail our sales team  

Book a meeting  

Chat with sales now  

Back

Book your personalized demo

Thanks for registering, we will get back at you shortly!

Preferred date for demo
  •  
    • Please choose an option.
    • Please choose an option.
  •  
  •  
    This field is required.

    Done

     
  • Contact Information
    •  
    •  
    •  
    •  
  • By clicking ‘Schedule a demo’, you agree to processing of personal data according to the Privacy Policy.
Back

Book a meeting

Thanks for registering, we will get back at you shortly!

Topic

What would you like to discuss?

  •  
  • Details
  •  
    • Please choose an option.
    • Please choose an option.
    Contact Information
    •  
    •  
    •  
    •  
  • By clicking ‘Book Meeting’, you agree to processing of personal data according to the Privacy Policy.