Manage Sophos ITDR Identity Settings and decommission integrations safely

Under Identity Settings, you manage configured ITDR integrations, domains monitored for credential leaks, VIP users, and active posture checks. During decommissioning in particular, you must distinguish between deactivation as a preliminary step and the final Delete Integration action. Deactivation does not, however, guarantee that you can return to the previous state.

The safe principle is to record the current state and all dependencies first, then make only the smallest necessary change and verify its effect. According to the product interface, Delete Integration removes the identity provider and all findings and cannot be undone. This action is neither a test nor a rollback step.

Opening Identity Settings

The direct path is:

My Products > Identity > Settings

The settings are also available in the product area under Global Settings > Products and Services > Identity. The page has three tabs that are relevant to operations:

1. Integrations for an integration’s status, health, editing, deactivation, and deletion.
2. Dark Web Monitoring for monitored domains and VIP Monitored Users.
3. Posture Check Preferences for search, filters, details and status of individual posture checks.

Before making a change, document the tenant, identity provider, integration name, owner, reason, maintenance window, and expected result in the ticket. Where multiple tenants or integrations exist, do not rely on the display name alone to identify the correct one.

Maintain integrations in operation

Under Integrations, the Configured Integrations table shows the identity-provider integrations from which ITDR collects data and which ITDR evaluates with security assessments. It can represent Microsoft Entra ID and on-premises Active Directory.

A Microsoft Entra ID row can be expanded to display its Child Integrations and their Health Status. Under Parent Name, the most severe error state among the child entries is shown. Therefore:

• A healthy status for one Child Integration does not rule out an error in another Child Integration.
• Investigate an error on the parent entry by expanding the row down to the affected Child Integration.
• Compare the integration name, Status, and Health Status before and after each maintenance operation.
• Do not approve a change based solely on the summary under Parent Name.

Use the Edit icon in the Actions column to edit the integration configuration. Record the existing values before saving and change only the fields approved in the ticket. Do not combine this step with an untested deactivation or deletion.

Deactivate an integration safely

To deactivate an integration, turn off the toggle in the Status column and confirm the action. The documented effect is that this disables the integration and the posture checks for this identity provider.

The documented effect does not establish:

• how provider objects that have already been collected are displayed in each view;
• which existing findings remain visible or change status;
• how dark web data and manually configured domains are handled;
• whether and in what state a subsequent reactivation continues all functions;
• whether external applications, permissions or other objects are changed at the identity provider;
• how long data are retained after deactivation.

Do not infer any effects from these open questions. In particular, do not treat switching the toggle off as data deletion or provider cleanup.

Controlled deactivation sequence

1. Match the correct tenant, provider and integration name with the change ticket.
2. Record the expanded integration, including Child Integrations, Status, and Health Status.
3. Record a functional baseline: visible identities, open findings, monitored domains, and active posture checks. Traceable counts and timestamps are sufficient; do not put sensitive content in tickets unnecessarily.
4. Inform the owners of ITDR, the identity provider, DNS, and incident management.
5. In the Status column, turn off the switch for this integration and read the confirmation.
6. Verify that the displayed Status of the intended integration matches the expected disabled state. Other integrations must remain unchanged.
7. Then open Directory, Findings, Dark Web Intelligence, Dark Web Monitoring and Posture Check Preferences as applicable and record the actually visible or unavailable state. No statement about deletion or retention can be derived from visibility, unavailability or an initially missing change.
8. If the result differs from the approved scope or remains unclear, do not proceed to deletion. Stop the change and escalate it to Sophos Support.

Deactivation provides an appropriate observation point before planned decommissioning, but it does not guarantee that the previous state can be restored. Before reactivation, also define the owner, expected outcome, and validation criteria.

Managing domains for dark web monitoring

Under Dark Web Monitoring, the Domains section lists all domains available for credential-leak monitoring. A domain’s source determines how it is managed.

Automatically recorded domains

Automatically discovered domains are synchronized from the Microsoft Entra ID tenant. Domain data is synchronized every 24 hours, so these domains may not appear immediately after the initial ITDR setup.

Provider synchronization proves ownership of the domain. Automatically discovered domains therefore have no Delete action in this table; they are managed through the identity-provider sync. A missing Delete icon is not an error and must not be bypassed by adding a manual copy.

Manually added domains

A domain added manually has not already been confirmed by a provider sync, so it must be verified through a DNS TXT record before monitoring is possible, and for an on-premises Active Directory environment, this is currently the only way to add domains.

The statuses mean:

For a domain with Pending status, Monitored is switched off. ITDR does not collect leak data for the domain until verification is complete.

Add domain and verify it via DNS

1. Under Dark Web Monitoring > Domains click on Add domain.
2. Check the full domain name again against the approved scope, enter it and confirm it with Add.
3. In Domain verification setup, use the relevant Copy icon to copy the generated Record Name and Value.
4. Create a TXT record with exactly these values at the authoritative DNS provider, and do not reuse values from another tenant, domain or previous attempt.
5. Document the change time, DNS zone, Record Name, responsible person and ticket. Collect the Value only where it is required for controlled implementation.
6. Schedule up to 24 hours for DNS propagation.
7. As soon as the TXT entry should be reachable, click on Verify in ITDR.
8. Only when the status is Verified, turn Monitored on.

If the verification fails, ITDR will ask you to check the TXT record and DNS propagation. Do not add the domain again: open the verification area again with the Retry icon in the Actions column.

In the event of an error, at least these points are compared:

• Record Name and Value match the values under Domain verification setup exactly, character for character.
• The entry is in the correct authoritative DNS zone.
• The DNS provider did not accidentally add the zone name twice to the hostname.
• The change had time to propagate within the documented window.
• Retry through Retry without creating a second domain entry.

If the correct TXT record is still not verified after up to 24 hours, escalate the domain, Record Name, time of the DNS change, result of a query to the authoritative DNS server, and error message to the DNS owners and Sophos Support.

Switching on or off monitoring

The control in the Monitored column can be used only for a domain with Verified status. After a change, document the domain, previous and new settings, time, and administrator who made the change.

Turning off Monitored is not the same as deleting a domain or an integration. The verified domain remains in the list. This setting does not document how long historical leak data is retained, so do not make assumptions about retention.

Delete the manually added domain

Only manually added domains offer the icon Delete under Actions. The deletion must be confirmed. If a currently monitored domain is deleted, its monitoring also stops.

Before deletion, it is checked that the domain is no longer part of the approved monitoring scope and should not be removed only because of a temporary DNS problem. Do not devise an alternative deletion method for automatically captured domains; their management remains with the identity provider sync.

Configure VIP Monitored Users

In the VIP Monitored Users pane, Microsoft Entra ID users are selected that ITDR tags with the VIP tag. VIP Monitoring uses additional personal attributes to search for possible business-related leaks, mentions or campaigns. It does not replace a solution for personal identity monitoring.

VIP status is also a profile factor in the Identity Risk Score. A VIP-monitored identity is treated as a higher-value target and may therefore receive a higher score. Selection must not be based on seniority alone; it requires a documented business reason and approval to use the personal attributes concerned.

Fields and boundaries

After Add User, a user is selected in Configure VIP Monitoring under Name, after which the following values can be recorded:

Select Configure to save the selection. ITDR monitors these attributes together with company names and domains to identify possible business-related leaks or mentions from the past year.

Only include attributes that are required for the approved purpose, are up-to-date and assigned to the right person. Private email addresses, phone numbers, Zip Code and Social Media Username are not approved simply because the interface accepts them.

Use the Pencil icon to change the attributes. The Delete icon removes the user’s VIP status. Document the previous scope, approval, and result. Removing VIP status does not establish that previously discovered data or findings have been deleted.

Managing Posture Check Preferences

Under Posture Check Preferences, all posture checks are enabled by default. The table shows the following information for each check:

• Title;
• Category;
• Provider Type;
• Tags;
• Published Date;
• Last Modified Date;
• Status.

Checks published within the last seven days are labeled New. Multiple tags appear as individual labels; additional tags are summarized under +N and displayed on hover.

Search and assess checks

• Search: Search for text in Title.
• Filter: Filter by Category, Tags, Status, Provider Type, Auto Resolution Disabled, Published at or Last modified.
• Sort: Sort using the Title, Category, Published, or Last Modified columns.
• The counter above the table shows the number of results for the current filters.
• Use X to remove an individual filter or Clear All to reset the table view.

Clicking Title opens the details panel with Description, Risk Narrative, Details, Recommendations, and References. Use the Previous and Next arrows to move between checks.

Before a status change, at least Title, Category, Provider Type, Tags, current Status, Published, Last Modified, reason, responsible person and check date are recorded. A new or recently changed check is not deactivated solely because of unusual findings; first, detailed description and Recommendations are checked.

Deactivate a check in a controlled manner

The switch in the Status column or in the detail area turns a single Posture Check on or off, and in the case of a deactivated check, the detail area shows who last turned it off and when.

The product documentation does not describe the specific effects that disabling a check has on existing findings, automatic reopening, scores, or historical results. Therefore:

1. Clearly identify the check and the associated provider.
2. Record current relevant findings and visible scores as a baseline.
3. Obtain operational approval for the exception and set a review date.
4. Only turn off the intended check.
5. In the detail area, check that the deactivated status together with the administrator and time are displayed.
6. Do not make any further changes until the observed result has been evaluated against the approved purpose.
7. Re-enable the check or escalate to Sophos Support if the effect is unclear or broader than planned.

Disabling a check does not correct the underlying misconfiguration. It must not be treated as a substitute for remediation or as an assurance that particular findings will be deleted, closed, or not created again.

Decommission an integration in a controlled manner

A decommissioning does not start with Delete Integration. It needs a decision between three different actions:

These actions are not interchangeable. In particular, deleting a domain does not automatically prepare the integration for deletion, and a disabled integration has not yet been removed.

Mandatory checkpoint before Delete Integration

⚠️ Stop: Do not run Delete Integration until the permanent removal of the correct identity provider and all findings has been approved in writing. The action cannot be undone.

Before proceeding, you must be able to answer yes to every point below:

• Tenant, integration, parent entry and relevant Child Integrations are clearly identified.
• The owners of Incident Response and Security Operations, as well as the business owner, confirm that no open findings are still needed for an investigation.
• Information required for internal evidence or retention obligations has been preserved in a controlled manner outside the integration. This step does not imply that ITDR provides an export function.
• Those responsible for Microsoft Entra ID or on-premises Active Directory, DNS and ITDR know the maintenance window.
• The effect “the identity provider and all findings are removed” is stated verbatim in the approval.
• There is no open support case for which the current integration state is still required as proof of error.
• The administrator knows that Sophos does not document an undo path for this action.

Executing Delete Integration

1. Open Identity > Settings > Integrations.
2. Expand the correct row and compare Parent Name, Child Integrations, Health Status and Status one last time against the approval.
3. In the Actions column, click the three-dot menu.
4. Select Delete Integration.
5. Read the confirmation dialog completely and confirm it only if the scope remains unchanged.
6. After that, check that the approved integration no longer appears in Configured Integrations.
7. Check the ITDR views for the documented effect: the identity provider and all findings have been removed. Record the visible state of other integrations without assuming any undocumented effect.
8. Record the time, administrator, approved integration, and result in the change ticket.

What Delete Integration Does Not Document

The documented effect is narrow: removal of the identity provider from ITDR and removal of all findings. It does not support any reliable conclusions about further steps. In particular, the documentation does not state:

• how to uninstall an on-premises ITDR sensor;
• whether or how to remove a sensor service, local files, logs or credentials;
• whether Microsoft Entra applications, consent, permissions or other provider objects are automatically cleaned;
• whether DNS TXT records are automatically removed;
• the retention period applicable to previously collected identity, domain, dark web or other ITDR data;
• whether and how a deleted integration with earlier data can be restored.

Such steps must not be invented or derived from the disappeared integration entry. For sensor uninstallation, provider cleanup, contractual data deletion or retention, a product-specific instruction will be obtained from Sophos Support or the responsible provider before the intervention. Until then, do not remove applications, permissions, secrets, services, files, or DNS records based on assumptions.

Validation and transfer to support

Maintenance is complete only when the planned state has been verified and any unresolved questions have been escalated.

Acceptance after ongoing maintenance

• Integrations: Verify the correct parent row and Child Integrations, Status, and Health Status.
• Domains: For each domain, verify its source, Verified or Pending status, and Monitored setting.
• VIP Monitored Users: Verify the correct user, approved attributes, and VIP tag.
• Posture Check Preferences: Reset filters with Clear All, find the changed check, and verify its Status and details panel.
• Check other integrations, domains, VIP users and checks against the baseline to detect unintended side effects.

Acceptance after decommissioning

• The deleted integration is missing in Configured Integrations.
• The approved identity provider and all findings have been removed according to the documented deletion effect.
• The visible state of further integrations is checked against the initial state; an effect on their data is not assumed.
• Manually managed domains and VIP entries are assessed separately; no automatic cleanup is assumed.
• For open provider, sensor, DNS and retention tasks, a responsible person is named, and as long as a robust instruction is missing, the tasks are not marked as completed.

Evidence for Sophos Support

If status, domain verification, check behavior or removal do not match the expected value, the handover includes:

• Tenant and data region;
• Identity provider type and integration name;
• parent entry and affected Child Integration;
• timestamp with time zone;
• visible Status and Health Status before and after the action;
• exact path in the user interface and executed action;
• complete error message;
• for DNS problems, the domain, Record Name, time of the change, and the result of a query to the authoritative DNS server, but no unnecessary sensitive values;
• for a Posture Check Title, Provider Type, Published, Last Modified and displayed Status;
• Change or Incident ID and the expected result.

Until clarification, Delete Integration is not repeated as a troubleshooting measure and no undocumented sensor, provider or retention steps are executed.