Investigate Sophos ITDR Directory and Identity Details

The Sophos ITDR Directory is the working inventory of identities, groups, devices, and apps that ITDR collects from connected identity providers. The metric cards show the number of monitored objects; clicking a card opens the corresponding view. To investigate an object, move from this overall inventory to its detailed data by selecting its display name.

Quick path: Under My Products > Identity > Directory, first select the correct tab, apply search and filters, and verify the data source. For a user, open Display Name, then test a specific hypothesis in each of Summary, Activity Log, Findings, Insights, Group Membership, and Dark Web Intelligence. A single tag, a high Risk Score, or an unusual sign-in is a prioritization signal, but it is not, by itself, proof of compromise.

Clarify product boundaries before the investigation

The ITDR Directory is not the Sophos Fusion (formerly Sophos Central) directory service. It shows the security context collected by the ITDR integration or ITDR sensor. By contrast, Global Settings > Platform > Directory service provides users and groups to shared Central functions and products. This distinction creates three important boundaries:

• A missing identity in the ITDR Directory is not fixed by running another Central Directory Sync. Check the ITDR integration, the provider inventory, and its collection status first.
• An object in the ITDR Directory is not automatically a managed Central user and does not represent a product assignment or Endpoint installation.
• Filters, tags, and merely opening detail pages in ITDR do not change Entra ID, Active Directory, Intune, or Central directory objects. Make technical corrections in the system of record, then validate them in ITDR. Separately, explicitly authorized response actions may be available through the designated Actions entry points.

Sophos XDR also serves a different purpose. The ITDR Directory provides inventory, posture, and identity context. An XDR query or XDR investigation, by contrast, correlates telemetry and events from supported data sources. The Activity Log in Identity Details is therefore not a complete XDR timeline, and an ITDR finding is not automatically an XDR detection. For a threat investigation that spans cases or data sources, correlate confirmed ITDR indicators with the available XDR, Endpoint, Entra, and network data. Do not interpret missing telemetry as a benign result.

Interpret the Directory inventory correctly

The entry point under My Products > Identity > Directory provides four functionally distinct tabs:

Search fields narrow the relevant view by name. Search and filters apply only to the data displayed and collected by ITDR. A search that returns no results therefore proves neither that the object does not exist at the provider nor that it has been deleted. Before escalating, verify the spelling, selected tab, active filters, provider tenant, and collection time.

Search, sort, and filter identities

Identities can be displayed as a card or list view. By default, users are sorted alphabetically. From the sort menu, you can select options such as descending Risk Score to identify the identities that should be investigated first. Search Identities filters by name.

Which filters are useful depends on the investigation. For initial prioritization, Status narrows the account status reported by the identity provider, while Risk Severity narrows the range of the calculated Risk Score. Is Admin represents admin context set by the provider or from detected privileged roles, Is VIP represents selection for VIP Monitoring, and Is Compromised represents the presence of active credential leaks. Is Dormant finds accounts for which no sign-in has been recorded for more than 90 days.

To classify the account, Department and Employee Type are available as organizational attributes if the provider supplies them. Is Guest identifies a guest account at the identity provider; Is Cloud Only identifies an account that exists only at the cloud identity provider and has no on-premises identifiers. Has MFA, Has Passwordless MFA, Primary MFA Method, and MFA Method provide MFA context. Country and Region filter on location attributes maintained at the provider.

An empty filter value is not a negative result. If the provider does not supply an attribute, the license limits API access, or Microsoft has not yet made updated data available, ITDR cannot populate the field reliably. This limitation applies particularly to MFA, admin, device, and activity data.

In the card view, the arrow at the bottom of a card reveals more information; only one card can be expanded at a time. In the list view, the arrow on the left expands a row. The column menu lets you pin columns, auto-size them, reset them, add them, or remove them. These display settings change neither the object nor its assessment.

If response actions were previously authorized, they are available for a user through Actions on the expanded card or through the Actions column in the list view. The availability of an entry point or action depends on identity status and configuration; execution also requires the necessary operator permission and the internal approval process. Filters, tags, and opening details remain separate, non-modifying functions. After an action has been executed, verify the result in the system of record and then check the updated state in ITDR.

Use icons and tags as context, not as a verdict

Icons identify User, MFA User, Deleted User, Locked User, Admin, Guest, or Service. The additional tags describe different attributes and must not be read as a single risk verdict: Admin means the account was identified as an administrator, Guest identifies a guest in the tenant, Deleted User identifies an account deleted at the provider, and Locked User identifies a disabled account.

MFA User represents enabled MFA, Compromised represents an active credential leak, and Dormant Account represents an identity with no recorded sign-in in the past 90 days. Cloud Only means that no on-premises identifiers are present; a Hybrid identity has on-premises identifiers that are synchronized between the cloud and on-premises environment. Human classifies the identity as a human user, while VIP indicates configuration for VIP Monitoring.

Human and Non-Human Identity (NHI) must not be conflated. A human account represents a person. NHIs include service principals, applications, and other machine identities. A Service icon provides corresponding context in the identity view; tenant-local Enterprise Applications are investigated on the Apps tab. A display name that sounds like a person or a service is not a reliable classification.

Distinguish an Application Object from a service principal

A Microsoft Entra Application Object is the global definition of a registered application in its home tenant. Among other things, it describes the application’s identity configuration and has an app or client ID. For a service principal of type Application, the service principal is the specific local instance of that application in a particular tenant. This type references the Application Object and determines what the app may do in that tenant, who can access it, and which resources it may access. This relationship does not apply to every service principal type: a service principal of type Managed identity has no associated Application Object; a Legacy service principal has no associated app registration.

The Apps tab shows the Enterprise Applications that ITDR retrieved from the monitored Entra tenant—that is, application-related tenant-local instances—not simply a second list of global app registrations. You must not infer either that every service principal type in Entra appears there or that every displayed NHI context has an app registration. A multitenant application can have an Application Object in its home tenant but its own service principal of type Application in each of several consuming tenants. For that reason, compare Display Name, tenant, app/client ID, object ID, owner, and permissions together. Identical names do not mean identical objects; different local service principals of this type can reference the same global application.

Select Display Name to open App Details. There, examine the metadata retrieved by ITDR as well as the tables for app owners, associated findings, and permissions. Validate a suspicious permission at the provider against the intended business purpose, publisher, consent, and responsible owner. The Directory display itself neither revokes consent nor removes a permission.

Investigate groups and devices

Under Groups, you can narrow the search with four filters: Deleted represents groups deleted at the provider, Mail Enabled represents groups that can receive email, and Security Enabled represents groups that can control access to resources. Assignable to Roles identifies groups to which roles can be assigned.

Clicking Group Name opens Group Details, with the retrieved group metadata and tables of assigned users, groups, and applications. During an access review, confirm the group type, owner, direct and nested relationships, and business need in the system of record. Mail Enabled does not indicate whether a group is used for permissions; Security Enabled is relevant for that purpose.

Under Devices, you can search for devices and filter by State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed, and Compliant. The view includes personal and corporate devices registered in Microsoft Entra ID. A device object is an identity at the provider; Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined are different registration or join contexts and are not equivalent to an installed Sophos Endpoint Agent.

Select Display Name to open Device Details. Depending on the device type, the page shows retrieved metadata, associated identities, relevant findings, and other available information. Managed, Compliant, Rooted, and Ownership are provider-supplied values. If they are absent, document the value as unavailable or unknown for the investigation. You must not infer “unmanaged,” “non-compliant,” “not rooted,” personal ownership, or corporate ownership from their absence. In addition, a missing value is not equivalent to a value explicitly reported as Unknown by the provider.

Investigate Identity Details systematically

In Identities, clicking Display Name opens the Identity Details page. Rather than reading every tab without a hypothesis, use the following process:

1. Confirm the object: Compare the display name, status, type, email addresses, and provider context with the expected user.
2. Understand the priority: Check the Risk Score, contributing factors, open findings, Compromised, Admin, MFA, and Dormant context. A score prioritizes the investigation; it does not replace it.
3. Validate the profile and assets: Compare the role, department, region, organizational structure, and assigned Intune devices with the expected profile.
4. Investigate activity: Set the time range and check successful and failed sign-ins, times, countries, IP addresses, and ASNs for deviations.
5. Open linked evidence: Investigate findings, detections, groups, and dark web records individually instead of inferring the cause from a summary.
6. Validate in the system of record: Cross-check Entra ID, on-premises AD, Intune, and, where applicable, XDR telemetry. Then make technical changes in the relevant system of record. If an explicitly approved ITDR response is intended instead, use an available Actions entry point.
7. Follow up on the result: After the correction or response, check the result again at the provider and in ITDR. Document which display has already been updated and which is still waiting for the next collection cycle.

Summary

Summary combines profile, priority, and recent activity. Under Details, the available Entra ID information includes role, department, status, country and region, creation and modification times, last password change, and other associated email addresses. Assets shows the user’s Intune devices assigned in Entra ID. Multi-Factor Authentication lists the MFA provider, primary MFA method, and other configured MFA types. Organization provides organizational context through managers, direct reports, and the organizational structure; clicking a person opens that person in a new tab.

For the security assessment, Recent Detections shows Open Detections from the past seven days and Closed Detections from the past 30 days; View All leads to Insights. Risk Score contains the current score and the main contributing factors. Top Sign-in Locations summarizes the most frequent sign-in locations with public and private IP activity. Where data is available, Commonly Used Entities groups successful authentications from the past 30 days by IP Addresses, Browser, Asset Name, and OS Version.

Under Top Sign-in Locations > View Details, the 30-day view shows geographic location, ASN, and the frequency of the top IP addresses. IP type and Login outcome are available there as filters; do not assume that they must appear as result columns. Private IP addresses cannot be interpreted geographically in the same way as public addresses. A frequently seen city can result from VPN or cloud egress; an unfamiliar country can justify investigation, but without time, device, and provider context, it is not yet an incident.

Activity Log

Activity Log shows authentication activity for the time range selected in the upper-right corner. Total Activities, Successful Logins, and Failed Logins first provide volume context. For geographic context, Top sign-in locations shows countries, IP addresses, counts, and the distribution between public and private IPs. Authentication locations shows the most frequent authentications from the past 30 days, grouped by IP address and ASN, and provides a search by location, IP, or ASN. Logins per day, with separate successful and failed sign-ins, and the Activity map, as a heatmap by day of the week and time of day, present the activity over time.

This ITDR view summarizes aggregates and patterns. It does not show an event table with all these attributes side by side for each sign-in. Instead, Browser, Asset Name, and OS Version must be assessed as 30-day profile aggregates of successful authentications under Summary > Commonly Used Entities and must not be attributed to an individual entry in the Activity Log. For event correlation with the exact time and time zone, outcome, source IP, ASN, country, device, browser, operating system, or adjacent detections, use the available Entra or XDR event logs. Frequent failures in the ITDR aggregates may represent user error, stale credentials, or an attack; only correlation with event evidence can determine which applies.

Findings, Insights, Group Membership, and Dark Web Intelligence

Findings lists findings for this identity by risk. The full text in Recommendation appears when you hover over it; clicking the finding name opens the details. Check the status, risk, category, affected evidence, and recommended remediation. Manually changing a status is not the same as technical remediation at the provider.

Insights shows Open Detections for the past seven days by default; you can change the period with the Date Picker. Closed Detections covers the past 30 days. An empty default period therefore does not rule out older activity.

Group Membership lists the user’s groups. The search field narrows the list; clicking Group Name opens the group and its other members. Unexpected privileged, role-assignable, nested, or no-longer-needed memberships are especially relevant. Make changes in the system of record.

Dark Web Intelligence shows leak records associated with the identity. Select Breach Source to open the relevant record. A record documents the exposure of credentials. To assess it, consider the time of the leak, publication or breach context, account status, and last password change together. The record does not automatically prove that the credentials currently in use are valid or that a sign-in occurred.

Account for provider boundaries and update intervals

Sophos ITDR supports Microsoft Entra ID and on-premises Active Directory, but not every provider supplies the same objects and fields. Cloud-specific data such as Intune assets, Entra service principals, MFA methods, or Entra sign-in activity may be missing from an integration with on-premises AD only. Conversely, the local ITDR sensor collects additional AD object types for posture checks; this does not automatically make the cloud tabs complete.

After the initial full Entra retrieval, ITDR checks for updates at different intervals for each data type: user, service principal, app, group, and device details approximately every ten minutes; MFA configuration approximately every 15 minutes; last user sign-in approximately every six hours; and domain data approximately every 24 hours. These are collection intervals, not a guarantee that Microsoft already supplies changed source information through its API.

Entra ID P1 or P2 is required for the intended range of ITDR data. With Entra ID Free, APIs and posture checks are limited, so an integration may show Provisioning Failed. After a license upgrade, admin or MFA information can remain stale at Microsoft for up to a week. In that case, check the corresponding Microsoft Entra activity report first. If the provider display itself has not been updated, ITDR cannot yet show a newer state.

Third-party MFA in an older Okta or Duo configuration can also appear unprotected because Entra does not store the MFA information at user level. A display of Has MFA = false must not then be treated in isolation as proof that MFA control is absent. The provider configuration, Conditional Access, current External Authentication Methods, and a controlled sign-in test must align.

Validation and troubleshooting

Object is missing or appears on the wrong tab

1. Reset active search and filters, then check the spelling and any alternative display name.
2. Verify whether Identities, Groups, Devices, or Apps is the correct object type.
3. Confirm the tenant and system-of-record identity provider; for apps, distinguish the Application Object, service principal, app/client ID, and object ID.
4. Search for the object directly at the provider and check its status, deletion, and guest, cloud, hybrid, or service context.
5. In the ITDR integration settings, check the status and the last successful retrieval. Do not restart Central Directory Sync as a substitute.
6. Check again only after the data-type-specific collection window, and document the relevant times.

Filter, MFA, admin, or device field is empty or unexpected

• Remove filters and check the raw attribute at the provider.
• Check the Entra license, API availability, and integration status.
• For MFA, also check the provider, primary and additional methods, and third-party configuration.
• For devices, distinguish registration or join, Intune management, compliance, and Sophos Endpoint protection.
• After license or attribute changes, validate the updated provider display first, not only ITDR.
• Document “empty,” No data, or a missing tag as unknown, not as “no.”

Sign-in location or activity pattern appears suspicious

In the Activity Log, first compare the time range, sign-in volume, success and failure aggregates, countries, IP addresses, ASN, and day/time patterns. Under Top Sign-in Locations, you can use IP type and Login outcome as filters.

Assess Browser, Asset Name, and OS Version separately under Commonly Used Entities as 30-day aggregates. Then correlate the exact event time and time zone, as well as the outcome, device, browser, and operating system of an individual sign-in, in the available Entra or XDR event logs. Also check the associated Findings and Insights.

NAT, VPN, mobile networks, cloud egress, and travel can change the displayed location. If risk is confirmed, perform response steps only in accordance with the internal incident process and with the required permissions.

Verify the display after remediation

Confirm the technical change in the system of record first. Then wait for the expected ITDR collection time, reset filters, and reopen the same identity or object. Check the corrected field, dependent tags, associated findings, and the relevant investigation period. Risk Score, findings, and provider attributes can have different update cycles; a score that has not yet changed does not disprove a successful source change. If the display remains incorrect beyond the expected window, preserve provider evidence, tenant, object ID, change time, integration status, and screenshots for escalation.

Close the investigation with an auditable record

At the end of the investigation, document the object, tenant, provider, and identity type. Also record the search and filters used, investigation period, detail areas reviewed, missing provider data, and the results of validation in the system of record and in ITDR. Keep Human and NHI context, as well as Application Object and service principal, distinct throughout.