How Entra Conditional Access Policies and Huntress Managed ITDR Work Together – Huntress Support

Team: Huntress Managed Identity Threat Detection and Response (ITDR)
Product: Huntress Managed Identity Threat Detection and Response (ITDR), Microsoft 365 Conditional Access
Environment: Microsoft 365 (Entra ID), Huntress Platform
Summary: This article explains how Microsoft Conditional Access Policies (CAPs) and Huntress Managed ITDR work together, what each system can and cannot see, and what actions you should take in each platform, especially when users are traveling.

Summary Table

The table below summarizes the key differences and responsibilities between Microsoft Conditional Access Policies and Huntress Managed ITDR.

Feature/Scenario	Microsoft CAPs (Entra ID)	Huntress Managed ITDR
Blocks login by location/device	Yes	No (detects after login)
Detects suspicious login activity	No (prevents only)	Yes (after successful login)
Alerts on failed logins	No	No (workaround is custom SIEM query)
Reads each other's rules	No	No
Requires manual travel exception	Yes	Yes

How Conditional Access and Managed ITDR Interact

Conditional Access Policies (CAPs) are rules set in Microsoft Entra ID (formerly Azure AD) to control access to your cloud resources. These policies can block or allow logins based on factors like user location, device compliance, or risk signals. For example, you might block all logins from outside your home country or require multi-factor authentication (MFA) for certain scenarios.

Huntress Managed Identity Threat Detection and Response (ITDR) is a managed security service that monitors Microsoft 365 identities for suspicious activity, such as unusual logins, risky inbox rules, or signs of account takeover. ITDR acts as a detective control, providing an additional layer of monitoring and response beyond what CAPs can prevent.

Huntress Managed ITDR and Microsoft Conditional Access Policies are complementary. CAPs prevent unauthorized access, while ITDR detects and responds to suspicious activity that gets through. You must manage exceptions and rules in both systems for scenarios like user travel.

Key Relationship
CAPs act as a preventive control, blocking access before a user can reach resources if they do not meet policy requirements.
Huntress Managed ITDR acts as a detective control, alerting you to suspicious activity that gets past preventive controls or signals that indicate compromise.

What Huntress Brings to the Surface

Successful logins

Huntress ITDR monitors and analyzes successful sign-ins to Microsoft 365, including location, device, and behavioral context.

Suspicious activity after login

ITDR detects actions like inbox rule changes, privilege escalation, and other post-login behaviors.

Unusual access patterns

ITDR can alert on logins from unexpected countries, use of anonymizers (VPNs, proxies) if the login is successful.

What Huntress Does Not Surface

Logins blocked by Conditional Access

If a login attempt is blocked by a CAP (for example, a user tries to sign in from a country that is not allowed), Huntress does not see this as a successful login and will not generate an alert or escalation for it.

Failed login attempts

Huntress does not alert on failed logins or login attempts that are stopped by CAPs. This is to avoid overwhelming you with noise, as there can be thousands of such events daily.

Conditional Access Policy configuration

Huntress does not read or interpret your CAPs when deciding whether to escalate an event.

If a threat actor has valid credentials but is blocked by a CAP, Huntress will not alert you unless the attacker later logs in from an allowed location or device. In that case, ITDR will analyze and potentially escalate the activity.

Planned Travel: What to Update

When a user is traveling or signing in from a new location, you may need to update both Entra Conditional Access policies and Huntress ITDR settings to prevent unnecessary blocks or alerts. Huntress doesn’t read or sync your Conditional Access policies, including travel exceptions, so changes in Entra won’t automatically carry over to ITDR. For a smooth experience, plan to update each system separately for the travel window.

In Microsoft Entra ID (Conditional Access)

Add a travel exception

Temporarily allow the user's new location (country or IP range) in your CAPs for the duration of their trip.

Remove the exception when travel ends

Restore your standard CAPs to maintain security.

In Huntress Managed ITDR

Create a temporary 'expected' rule

In the Huntress Platform, add an 'expected' rule for the user's travel location and set an expiration date. This prevents repeated unwanted access escalations for legitimate travel.

Dismiss existing escalations

After adding the rule, dismiss any current escalations related to the travel event. New alerts will not be generated while the rule is active.

Best Practices for Travel and Exceptions

Coordinate updates

When a user is traveling, update both your Conditional Access policies and Huntress ITDR expected rules at the same time.

Use expiration dates

Always set an end date for travel exceptions in both systems to avoid leaving open access unintentionally.

Communicate with users

Make sure users know to notify IT before traveling so you can make the necessary adjustments.

Review alerts

If you receive an escalation for a legitimate travel event, check if an expected rule or CAP exception is missing or expired.

For organizations with many frequent travelers, consider grouping users in Entra ID and applying group-based CAPs. In Huntress, bulk rules for multiple countries or a set of individual users is not currently available.

Frequently Asked Questions

If a login is blocked by Conditional Access, will Huntress alert me?
Attempts blocked by CAPs on their own do not generate ITDR alerts or escalations. These CAP‑blocked attempts can still appear in underlying log data (for example, via Huntress SIEM queries) and may be used by the Huntress SOC as supporting context during an investigation, but they are not surfaced as standalone alerts.

What if a threat actor logs in from an allowed location?
If an attacker successfully logs in from a location allowed by your Conditional Access policies, Huntress ITDR will see the sign‑in and evaluate it like any other login.

Can Huntress suppress alerts based on my Conditional Access policies?
No. Huntress does not read or interpret your CAPs. You must manage exceptions in both systems.

How do I handle repeated alerts for legitimate travel?
Create a temporary expected rule in Huntress for the travel location and set an expiration date. Dismiss any current escalations for that user and location.

What about failed logins or credential stuffing attempts?
Huntress does not alert on failed logins or logins blocked by CAPs. If you want to monitor these, you can use custom queries in Huntress SIEM to surface such events, but this may generate a high volume of noise. Here's a guide on ITDR queries in Huntress SIEM, and a guide for saved queries.

In This Article