Investigate and manage Sophos ITDR Findings

Under My Products > Identity > Findings, Sophos ITDR shows the results of checks against the connected identity infrastructure. By default, the table is sorted by risk. A Finding is neither automatic proof of active compromise nor an XDR Detection or XDR Case. It is an ITDR work item that must be assessed, addressed in the responsible identity system, and then checked again.

The safe workflow is:

1. Prioritize open Findings by Risk and use filters to create a manageable work queue.
2. Read Finding Details, Description, Definition, and Recommendation; if necessary, review raw data under Result and changes under History.
3. Evaluate the impact and dependencies in your own environment before changing a configuration.
4. Remediate the root cause in the affected identity system or service rather than merely changing the ITDR status.
5. Validate the state first at the provider and then in ITDR.
6. Set a Finding to Resolved or Dismissed only as a deliberate decision. Manually changing it to Resolved is not remediation.

Interpret statuses, risk levels, and categories correctly

Status

ITDR no longer counts Resolved and Dismissed Findings as risks to the environment. They remain operationally distinct: Resolved represents a corrected cause or reduced risk, whereas Dismissed represents a deliberate risk decision.

Risk

The risk level comes from the underlying check and supports prioritization. Within the same level, investigate exposed privileged identities, indications of compromised credentials, and Findings with a broad impact first. The specific Recommendation remains more important than a generic action.

Category

ITDR uses the following categories. The names remain unchanged in the English Sophos interface:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

The category describes the type of check and may align with the MITRE ATT&CK model where appropriate. It does not replace detailed analysis or verification that an observed configuration is intentional in your environment.

Filter Findings and create a work queue

The collapsible filter menu to the left of the Identity Findings table combines the following filters:

• Risk: Risk level of the Finding.
• Status: Open, Resolved or Dismissed.
• Reference Type: Type of affected object.
• Category: Category of the Finding.
• Is New: Findings first seen within the last seven days.
• Finding: Title of the Finding.
• First Seen: Time of first observation.
• Last Seen: Time of last observation.
• Last Modified: Time of last change.

These exact values are available for Reference Type:

• User Object
• Application
• Group Object
• Device Object
• Tenant Configuration

Selected filters appear above the table. Use X to remove one filter and Clear All to remove all filters. The table and URL update dynamically with the selection. You can therefore save a filtered URL as a working view or share it with colleagues. Before sharing, verify that the recipients have access to the same Central tenant and that the URL may be included in the intended ticket.

A useful initial work queue is Status = Open, followed by Risk = Critical or High. Then narrow it by Category, Reference Type, or Is New. This keeps new critical identity risks visible without losing older open items.

Investigate a Finding thoroughly

Clicking the link in the Findings column opens the details panel. It shows the associated object, risk, First Seen, Last Seen, Last Modified, and the recommendation. Use the New Tab icon to open the full page in a new tab.

The panel and full view include:

• Finding Details: Summary with risk level, status, comments, timestamps, and tags.
• Description: Description of the Finding.
• Definition: Information about the associated identity check and its references.
• Recommendation: Sophos recommendation for reducing the specific risk.

For a reliable triage, you should answer at least the following questions:

1. Which object is affected and does Reference Type match the expected object?
2. Does the identity provider still have the condition described in Description and Definition?
3. What is the scope of the permissions, dependencies, and possible effects of a change?
4. Does the Recommendation fit your own environment and is the change authorized internally?
5. Do First Seen, Last Seen and Last Modified indicate a new, recurring or already resolved issue?

Finding Details shows comments and tags. However, the Sophos documentation for the Findings page describes neither an assignment function nor controls for creating or changing comments and tags. Responsibility and evidence of changes therefore belong in the approved change or ticketing system; comments replace neither a change ticket nor evidence of the change in the source system.

Review Result as raw data

The Result tab shows the raw output of the executed check in JSON format. It is particularly helpful when the summary does not reveal which attribute, object or result led to the evaluation.

Treat JSON keys and values as the output of the specific check; do not infer a general schema from them. Compare relevant object identifiers, states, and timestamps with the current information at the identity provider. Sensitive raw data belongs only in approved tickets or investigation notes.

Track changes via History

The History tab shows previous actions on the Finding. Select View Diff to open the exact changes. Status changes and other processing steps can be traced there, making it possible to distinguish an unexpected reopening from a new Finding.

Remediate the cause and validate the outcome

⚠️ Review before making changes: A Sophos recommendation must fit your environment, risk tolerance and change approval. Changes to roles, authentication, conditional access, applications, or other identity objects can affect users, applications, and access. Therefore, clarify dependencies and fallback plans before implementation.

Remediation takes place in the system where ITDR detected the problem, such as the connected identity provider or responsible application service. The status in ITDR controls only the Findings workflow. It does not change the provider configuration.

A controlled closure consists of four steps:

1. Check provider state: Confirm that the authorized change has been saved and is effective for the affected object.
2. Check the Finding again: Review the associated object, Last Seen, Result, and History. An outdated or unchanged result is not evidence of success.
3. Wait for automatic behavior: If the Finding no longer appears during a recheck, ITDR will automatically resolve it and add a comment to it. The Entra ID posture checks and dormant resource checks usually run every two hours; the organization-wide Risk Posture Score is updated daily.
4. Document the result: Record provider evidence, Finding status, timestamp, and, where applicable, View Diff in the approved work record. If the Finding remains open after an expected check interval, compare the provider state, affected object, and JSON result again rather than repeatedly changing the status manually.

A Finding manually set to Resolved can be set back to Open by the system as soon as ITDR observes the same condition again. This is not an error in the status model, but an indication that the cause still exists, has reoccurred, or is still visible in the data evaluated by ITDR.

Use Dismissed only as a deliberate risk decision

⚠️ Dismissed suppresses further Findings: If a Finding is dismissed, ITDR does not create new Findings for this problem on the affected object. The Finding remains in the table but is excluded from the dashboard and the organization-wide Risk Posture Score. Premature dismissal can therefore hide a risk that still exists or becomes relevant again from the normal view.

Dismissed is appropriate only when the condition is expected, remediation is demonstrably impossible or operationally unjustifiable, and the responsible party accepts the residual risk. At minimum, document the object, rationale, compensating controls, approval, and review date outside ITDR. A technically unresolvable Finding can instead remain Open, keeping the risk visible in the score and ongoing monitoring.

Prioritize Credential Compromise

Findings for compromised accounts are generated only for active identities. Among other factors, ITDR checks whether an active identity exists, when a plaintext password or hash was first leaked, and whether that date is later than the last password change. A plaintext value is also checked against the global password-complexity requirements of Microsoft Entra ID. The raw data may still be visible under Dark Web Intelligence, regardless of whether a Finding is generated.

When a Finding is generated, ITDR determines the risk level by account type, leak type and MFA strength:

For prioritization, address Critical first and then High; within the same level, investigate privileged accounts and plaintext leaks first. A lower rating when MFA is enabled or phishing-resistant does not mean that the Finding can be ignored. Carry out approved protective and remedial measures in the responsible identity system and according to your incident-response process. Then validate the provider state, Finding, and history as described above. The status alone does not confirm a secure identity.

Separate customer, MDR, and XDR responsibilities

Sophos ITDR is a customer-monitored solution. Even with a separately licensed Sophos MDR service, routine triage and management of Findings remain with the customer. The MDR Operations Team focuses on active identity threats and may include individual critical or high Findings in its investigation if they indicate an active threat. This does not result in the automatic adoption of all Findings or the implementation of changes to the identity provider.

For each escalated Finding, the following should therefore be clearly documented:

• who is responsible for triage and risk decisions,
• who authorizes and executes changes in the identity system,
• whether an indication of an active threat has been passed to the agreed MDR process,
• who performs the final validation of the technical effect and ITDR status.

ITDR Findings remain separate from XDR Detections and XDR Cases. Identity context may support further investigation. However, status, comments, and closure of the ITDR Finding remain part of the ITDR workflow and are not the same as the XDR or MDR workflow.