This blog is written by Jan Bakker.

When organizations have implemented Azure Active Directory Conditional Access, the real game is on. How to make sure that you stay in control of your configuration? Very often, there is more than one administrator managing Azure Active Directory, so there is a lot to think of. Even when you have fully automated the creation and versioning of your policies, there are a lot of indirect factors that have an effect on Conditional Access policies.

Example of CA policy

Conditional Access policies

Of course, there is the policy itself. Changing or deleting a policy, can have a major impact on your security posture. Imagine someone changes the device filters, or grant access controls on your policy for example. You don’t want that to happen without being notified.

Azure Active Directory groups

The core of a Conditional Access policy is often the group where it is targeted to. This can be either a include or exclude group. Both are very important because adding or deleting users from that groups could potentially have a large impact. Most organizations use existing groups and combine them with licensing for example. That’s fine, but keep in mind that contradictory opinions can come into play. Removing someone’s license will also remove this user’s security baseline. Make sure the most important groups are monitored, especially when large mutations happen to them.

Named Locations & MFA Trusted IPs

A lot of organizations use a location-based strategy (sometimes combined with others) to protect their Microsoft 365 and Azure Active Directory resources. They block specific apps for certain locations, and often there is a distinction between working at the office, and remote work. Named Locations can be marked as trusted. MFA Trusted IPs are trusted by default. Trusted locations can then be used within the policies. These locations are also used by other Microsoft security features. Changes to these locations are definitely something you would cover in your monitoring.

Using named locations in CA


Conditional Access policies can be triggered on specific applications. This can be native apps like Office 365, the MyApps portal, or Graph Explorer. You can also select Enterprise applications that are present within your Azure Active Directory tenant. When applications are added or deleted, this can have an impact on your Conditional Access policies. You might keep an eye on your Enterprise Applications, to make decisions for your current configuration.

Break-glass emergency accounts

Microsoft recommends excluding specific accounts that are used for emergency access. For example, when Azure MFA has a major outage, or when Intune suddenly reports all your devices as non-compliant. These accounts are often protected with additional measurements, such as FIDO2 security keys or alternative MFA methods, but you want to keep a very close eye on these accounts. Accounts like this are not used very often, so you want to be alerted on any activity. Both sign-in and audit logs are important here. Because these accounts are excluded from some security policies, group membership changes are often leading to unwanted scenarios. Other activities that you want to be alerted on are password changes and sign-in activities for example.


This might be like an open door, but changes in licensing could potentially have an impact on your policies. For example, if you use risk-based access (using Privileged Identity Protection), this feature is based on Azure AD Premium P2 licenses. When something changes in these licensing, you might become incompliant, or unprotected in the worst-case scenario.  So make sure you keep a good eye on your licenses as well!

Wrapping things up

As you can see, there is a lot to think of when monitoring Conditional Access. A minor change in Azure Active Directory can end up in a disaster for your end-users. While all these changes can be monitored through the Azure Active Directory audit log, Senserva provides a additional benefits that can help you to better secure your environment:

  • Faster ingestion of logs into Log Analytics than the default export ability
  • No need to create complex queries
  • Change events are enriched with data through the Senserva engine.

In a future blog, we will share the exact Senserva queries that can be used to identify the changes to Conditional Access policies.

Blog written by Jan Bakker.