CyberHound 365
CyberHound 365

What is Conditional Access?

Conditional Access is a capability within Microsoft Entra identity management that controls user access to company apps and data based on other factors, such as device state, location, risk levels and other contextual signals. 


It is the centerpiece of Zero Trust security, a model that does not grant access just because a user knows their username and password. 


Instead Conditional Access ensures additional security checks are passed before access is granted, such as requiring that a user is signing in from a company managed device that is also security compliant, and enforcing MFA in particular circumstances.


There are two types of Conditional Access policies; Baseline policies that are active across a whole Microsoft Tenant for all users, and Persona based policies, that are targeted at a specific set of users based on their role within the company, for example corporate staff in a given country or managers of a retail environment.


Baseline policies are relatively easy to implement- there are a number of Microsoft templates straight out-of-the box that can be implemented with little or no configuration changes.


 Persona based polices, on the other hand, require more complex analysis and provide an enhanced layer of security.


It is important to remember that Conditional Access only has control over those resources to which Microsoft Entra is the Identity Provider (IdP) i.e. manages the users access to, including resources such as Browser access (via a url to the remote service), Desktop Clients (those applications running locally on a personal computer) and Mobile Apps.  Often Federation, enabling Single Sign On (SSO) is used to bring access under our control, through Microsoft Entra. 

The Persona approach

 Understanding and defining expected access requirements for the various roles in a business (Personas) is a foundational strategy in identity and access management, playing a critical role in supporting a Zero Trust security framework.

With a well defined approach, Personas can be directly mapped into Conditional Access policies.

Persona example

This example persona describes a UK retail store manager. They are:

  • issued with a corporate laptop that is Intune managed
  • able to use their personal phone to access company Microsoft O365 services
  • have access to a store manager App
  • able to log into the Point of Sale (POS ) device, an Intune managed iPhone
  • based in any UK store

 

We employ Microsoft's App Protection Policy with Grant actions to strengthen the security around using personal mobile devices to access corporate data, as well as hardening the security of the POS iPhone.


Each Persona is built by understanding business operations

and ensuring they align with best security practice.


When conducting a Persona assessment, the following, as a minimum should be taken into account:

  • Microsoft licenses assigned to users
  • Groups assigned to users
  • User types, such as Member, Guest, Federated, External
  • Resources and resource types accessed by users
  • Platforms / hardware assigned to the users 
  • Device enrollment mechanisms / if the devices are company or personally owned
  • On-prem Entra hybrid joined devices that may be in use
  • Locations / network the users will be working in
  • Client types that are used, such as browser, client and mobile apps
  • Compliance of the devices that should be achieved
  • App Protection Policies that may be deployed
  • Password policies relevant to the user types
  • The type and strength of MFA that is required
  • Session security requirements, such as periodic authentication
  • Global Secure Access (Microsoft's new secure cloud access)


A risk based approach can also be added, that determines access based on a user's activity risk or sign-in risk, adding another layer of security.

Implementing Persona based Conditional Access policies

The complexity of implementing a persona based Conditional Access policy is due to the operation of Conditional Access itself; and although it's tempting to think of Conditional Access as a kind of 'Zero-Trust firewall', it's operation has a number of quite specific differences which have far reaching implications:


  • ALL conditions must be met for the policy to result in the desired action.
  • If ANY of the conditions in the policy are not met, the policy is ignored, and the user is granted basic authentication i.e. username and password only.
  • All policies operate in parallel, there is no ordering of polices.
  • No policy is exclusive, i.e. different policy conditions may overlap, and multiple polices may be in force simultaneously
  • For multiple policies in force simultaneously, the Grant options are ALL enforced, i.e. AND together; excepting where a Block policy is in force, in which case the Block policy ALWAYS wins.
  • There is the no specific 'default block' policy; multiple policies must be created to block the unwanted scenarios, bearing in mind ALL of the above rules also apply to block policies too.


Scratch beyond the surface, and we find that these rules open up a pandoras box of 'the unexpected' when creating Conditional Access policies.

Cyber resilience

It's clear that we need to think like the threat actor to secure our Conditional Access policies. 

In particular the second and last items in the above list are alarming, and will clearly create gaps for threat actors to exploit, unless we are careful in our Conditional Access design.

Conditional Access logic

To understand Conditional Access, we need to understand the logic it is built on.

Note that the Actions are only performed if ALL of Users, Resources and Conditions, that have an entry in their corresponding blue box, are matched TRUE; otherwise the policy has no effect.

This is the key to understanding Conditional Access.

Furthermore, all policies act as logic AND. There is no ordering; all policies act in parallel

Example persona - The solution

The above logic dictates that we will frequently require a range of block polices for each Persona grant policy. 

This is practically unmanageable using Microsoft's native interface, as we need to compare the configuration of each group of policies side by side to perform gap analysis.

Here is the full set of Conditional Access policies required to secure the example Persona of UK Store Manager:

Threats mitigated with this policy set

Ten Conditional Access policies for a single Persona, might seem like overkill on the face of it, but we need to be sure that every policy is necessary for the precision result we desire.


Here is a summary of the implementation:


Persona based security segmentation

By targeting this policy set to the UK Store Managers only, we segment security policy to business requirements.

  • Aligns security controls with the least privilege principle of Zero Trust
  • Allows us to make changes that affect just one Persona type, for precision security and a layered approach
  • Makes testing and fault finding much easier as policies are defined against a specific set of users


Risky access from untrusted geographic locations:

Policy 22,25 and 27 block access from undesired locations and mitigate against:

  • Preventing stolen credential from being used outside the UK
  • Access through stolen POS devices by restricting their use to store locations
  • Unauthorized access to the Store Manager application by restricting it to the UK only


Data leakage from unmanaged or non-compliant devices

Policy 20,24 and 26 require a compliant device, the latter two also require an App Protection policy. Policy 29 blocks access to the POS device should the device become non-complaint and Policy 25 blocks non-compliant mobile access from outside the UK. This mitigates against:

  • Exfiltration of data from personal devices
  • Lost or stolen devices without device security controls (including encryption, PINs)
  • Use of UK Store Managers personal devices outside the UK from accessing corporate data


App-specific security enforcements

Access to O365 and the Manage Store application is blocked from the POS device. This mitigates against:

  • Phishing attacks via email and Teams to the store sales POS devices
  • Unintended IT usage, such as use of Teams and Facetime on the POS devices
  • Prevents other members of staff accessing the Manage Store application through the POS devices


OS/Platform specific risk management

Policy 21 blocks unsupported platforms accessing O365 and the Manage Store application, as well as blocking unknown platforms including, for example, Raspberry Pi which has been used in a number of high profile cyber attacks. Threats mitigated:

  • Prevents access from OS that can be purpose built for cyber attacks, such as Raspberry Pi and Linux.
  • Protects systems by blocking unknown OS with the 'All platforms except Windows, iOS and Android' Conditional Access rule


Weak authentication and Conditional Access evasion

Policy 20 and 24 requires the stronger protection of Password-less MFA. Policy 21 and 22 together prevent the blind-spot that would otherwise been created with Policy 20, of evading Conditional Access (and hence MFA) by accessing either from a non-windows device or from outside UK. Policy 25 prevents the blind-spot of Policy 24, and Policy 27 prevents the blind-spot of Policy 26. Policy 29 prevents POS access should the device become non compliant, such as when an OS update has not been implemented in line with the compliance policy. Threats mitigated:

  • Enforces strong MFA policy
  • Eliminates Conditional Access blind-spots
  • Prevents POS devices from being used if the OS becomes non-compliant

Conclusion

Achieving this high degree of precision is virtually impossible using the native Microsoft interface, but with CyberHound365 software we make it surprisingly easy.


High Definition Conditional Access.


It's not AI, it's just I.


My wife read this, and she commented "Well, it's all very interesting (at least that's what I think she said), but where's the 'BUY' button?"


So here it is.

If you're implementing Microsoft Conditional Access (or planning to) as part of your cyber security strategy, and you'd like a complete strategy or policy review, get in touch, and we can make that happen.

Louis’ background is electronic engineering, a Master’s degree in telecommunications, and is a CISSP certified cybersecurity professional.

With experience of large-scale telecoms environments at Orange Telecommunications, the American cyber security companies BreakingPoint and Ixia Technologies (now part of KeySight), together with Cyber Security Lead at C&J Clarks, he has first-hand experience spanning a diverse range of roles within the cyber security landscape.

Get in Touch

Attach Files
Attachments (0)

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Cancel

CyberHound 365 screenshots


Easily compare different Conditional Access policies, side by side.


Search and order columns in Conditional Access policy data instantly.

 
Split screen to see both Conditional Access policies compared side by side, and edit view (below) at the same time. 





Easily create Persona policies- complete visibility of all Conditional Access configuration settings in one pane-of-glass.


Example here: Group: UK Store Managers excluding a user, accessing Office365, Location: UK, Platform: Windows: Action: Grant access and require compliant device





Manage users at scale.


Enable / disable/ delete users in bulk.

Password reset users in bulk.

Search last login date and account age.

View and search last error code for all users

View and search MFA options for all users.

Search privileged roles over all users.





View and edit details on any user.


Password reset, revoke session.

Update contact, job information.

View all MFA options enabled.

View licensing.

View all assigned roles.


Video

CyberHound 365 Entra user management overview.

Copyright © 2025 CyberHound 365 - All Rights Reserved.

  • Privacy Policy

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

DeclineAccept