ITDR frequently asked questions

Microsoft Entra ID is supported.

Yes, you can add multiple Entra ID tenants from the Identity Settings page. For more information, see Identity Settings.

ITDR requires Entra ID P1 or P2, which are available in standalone products, add-ons, or included with other Microsoft licenses such as Microsoft 365 E3 and E5, Microsoft Business Premium, and Microsoft 365 Frontline Worker F1, F3, and F5.

Microsoft Entra ID Free provides access to the Microsoft APIs, but limits some of the data that can be ingested and posture checks that can run. For this reason, some ITDR integrations using Entra ID Free show a Provisioning Failed status.

ITDR relies on the Microsoft APIs to collect account information. Microsoft also restricts access to certain APIs based on licensing, so information such as whether a user is an admin or has MFA registered may not show up right away after a license upgrade. Delays of up to a week can occur before Microsoft provides the updated user information after a customer upgrades their license. You can verify the information by viewing the activity report in the Microsoft Entra admin center. For more information, see Authentication Methods Activity. If the information contained within the user report isn't updated, ITDR will also be out of date until Microsoft refreshes the information.

The following are a few potential causes:

• You don't have the required Microsoft Entra ID license, such as P1 or P2.
• You recently upgraded your license and Microsoft hasn't made the data available yet. For details, see "How long does it take for ITDR to update after upgrading from Entra ID Free to a P1 or P2 license?"

• You're using a third-party MFA provider such as Okta or Duo with a legacy configuration. In this scenario, the MFA status won't report back properly as Microsoft Entra ID doesn't store the MFA information at the user level for external MFA providers. However, we can infer that an external provider is being used if you use the new Microsoft external authentication methods within your Entra ID tenant configuration.

  For more info, see the Microsoft Entra Blog. Additional setup details are available for Duo and Okta. For more info, see the Duo documentation and Okta documentation.

ITDR includes a suite of assessments, each responsible for running different checks, which are performed at the following intervals:

• Entra ID Posture Checks: Every 2 hours.
• Dormant Resource Checks: Every 2 hours.

Following initial setup, we collect the full catalog of data from Microsoft Entra ID. After that, we check for updates based on the type of data as outlined below:

• User Details: Every 10 minutes.
• Service Principals and Apps Details: Every 10 minutes.
• Groups: Every 10 minutes.
• Devices: Every 10 minutes.
• User MFA Configuration: Every 15 minutes.
• User Activity (Last Sign On): Every 6 hours.
• Domain Data: Every 24 hours.

The Identity Risk Posture score is updated daily based on changes from the previous day. The score either increases or decreases based on whether new findings were observed or existing findings were resolved or dismissed.

You can view the list of checks in the Posture Check Preferences tab on the Identity Settings page. For more information, see Identity Settings.

Yes, you can turn on and turn off the posture checks within the Posture Check Preferences tab on the Identity Settings page. For more information, see Identity Settings.

No, ITDR is software that you monitor. However, if you have the MDR service, the MDR Operations team will investigate identity-based threats in addition to what they already investigate.

The MDR Operations team primarily focuses on active identity threats and will look at a subset of critical or high findings that may indicate an active threat. However, it's your responsibility to monitor and manage findings.

The MDR Operations team uses the additional identity context collected from Microsoft Entra ID to better understand the users and associated risks, which helps accelerate the investigation and response processes across both identity and non-identity detections where the user has been correlated.

The admin flag in Entra ID is set to true for users assigned to roles recognized as administrative or privileged within Entra ID. These roles generally have significant control over directory resources, users, or security settings. The following is a list of the Entra ID roles that set the admin flag to true:

• Global Administrator: Full access to all administrative features in Entra ID.
• Privileged Role Administrator: Manages role assignments in Entra ID, including assigning other administrators.
• User Administrator: Manages user accounts, groups, and some user attributes.
• Security Administrator: Has full access to all security features and settings.
• Compliance Administrator: Manages compliance-related features such as eDiscovery and auditing.
• Application Administrator: Manages application registrations and settings in Entra ID.
• Authentication Administrator: Can view, set, and reset authentication methods and controls, including password resets.
• Exchange Administrator: Manages settings for Microsoft Exchange Online.
• SharePoint Administrator: Manages settings for SharePoint Online.
• Teams Administrator: Manages settings for Microsoft Teams.
• Intune Administrator: Manages device management settings and configurations in Microsoft Intune.
• Billing Administrator: Manages subscriptions, billing, and support tickets.
• Helpdesk Administrator: Limited to password resets and basic troubleshooting.
• Service Support Administrator: Manages service support-related settings.
• Directory Readers (if combined with other privileged roles): Can read directory information; usually combined with another role to elevate privileges.
• Global Reader (if combined with another admin role): Read-only access across Entra ID and Microsoft services; may set the admin flag to true when combined with another admin role.
• Reports Reader (if combined with another admin role): Access to reports and logs, often combined with other administrative responsibilities.
• Conditional Access Administrator: Manages conditional access policies.
• Identity Governance Administrator: Manages settings related to identity governance, access reviews, and entitlement management.
• Custom roles with administrative privileges: A custom role with administrative permissions comparable to any of the above roles may also set the admin flag to true.

This list covers the standard roles in Entra ID that impact the admin flag. However, if Microsoft updates these roles or adds new ones, the behavior of the admin flag could change accordingly.

If the last sign-in time is greater than 90 days, we flag a user as dormant.

We continuously monitor for leaked credentials and as soon as a match is identified within the data set, we process it and determine whether it's valid.

To make sure we generate actionable findings, we take the following processing steps to correlate and validate the data that we're collecting and analyzing:

1. Verify that an active identity exists within the configured identity providers.
2. Determine when the plaintext password or hash was first leaked based on the available historical data. This is important because newly published combolists often contain old data from previous breaches.
3. If it's a plaintext password value, we then compare this to the Microsoft Entra ID global password complexity requirements to weed out invalid values.
4. Finally, we compare the first leaked date of the password to the time of the last password change for the identity. If the leak first occurred after the last password change, we generate a finding.

If we've determined that a finding should be generated, we then check the associated account to see whether it has MFA enabled and at what strength. Below are the associated risk levels based on the type of user, type of leak, and MFA configuration:

No, we don't store any of the plaintext passwords or hash values. We also don't have the ability to capture these from the identity providers. When scanning for and collecting data, we apply a custom hash to the observed values and then categorize the record as either a plaintext or a hashed password. This allows us to determine the uniqueness of the passwords as well as calculate metrics without having to retain the underlying password values.

We use data from various Dark Web marketplaces like Russian Marketplace and Genesis market, TOR sites, public and hidden Telegram channels, and stealer log files.