Set up MDR and XDR integrations in Sophos Fusion

Integrations allow Sophos Fusion (formerly Sophos Central) to bring together telemetry from Sophos and third-party products in the Sophos Data Lake, or to provide targeted Response Actions. Choosing the correct integration type is crucial: Data Ingest provides data for queries, Detections and investigations, while Response Action performs an action in the connected product. Not every product supports both directions.

The entry point depends on the tenant’s product version. For the enhanced XDR/MDR solution, use Security Operations > Integrations > Marketplace; existing Classic configurations are under Threat Analysis Center > Integrations. The TAC instructions retained below describe this Classic path, not an identical click sequence for the new interface. The tenant-specific upgrade check helps identify which applies. Visible Fusion names alone do not prove a completed product upgrade.

Within the Endpoint onboarding path, this article completes the cross-product integration phase between protection configuration and operational acceptance.

A practical workflow is to check the licence and source system, choose the appropriate product tile and configuration in the Marketplace, establish the connection with the minimum permissions required, check it under Configured, and verify it with an expected test event. Only then should you consider the integration ready for production.

Check connectivity and actual data flow separately

In the current interface, open Security Operations > Integrations > Configured Integrations. Under Data Ingest, the status shows the configuration and connectivity of the API, syslog, or Sophos integration. Green confirms communication, not yet correctly normalized events. A warning may appear after 20 minutes without communication or when some resources have not reported; an error after 60 minutes or failed authentication. Hover text gives the specific reason.

For an API integration, open its name and API Query Logs. The default is the last day; up to seven days can be selected. Under Details, compare the parameters with the correct source tenant. Hierarchical integrations may contain a parent with several child endpoints; a healthy subpath does not prove all children work.

Then check Security Operations > Integrations > Configured Data Sources. This separate view answers whether logs actually arrive and which schemas they map to. Healthy means activity within one hour, Warning between one and 24 hours, and Unhealthy more than 24 hours without activity. These criteria differ from the connectivity thresholds above. Assess a rarely transmitting source against its expected activity, rather than declaring it healthy through an invented test event.

Clicking the source shows message history by schema for the last 24 hours. For acceptance, generate an approved event in the source system and compare time, source, required fields, and normalized schema. Advanced Search in source details opens a prepared search for the sensor ID over the last 24 hours. The search guide explains further filtering. If data is missing, first check source → integration/collector → schema; an ordinary audit event need not produce a detection.

Export All as CSV or Export Selected as CSV saves the source inventory through Data Exports. The trash icon, by contrast, removes only the data-source record, not telemetry already received. Deletion cannot be undone; a source that continues sending reappears, and removal may take up to five minutes. Deleting is therefore neither confirmation of telemetry deletion nor a repair test.

Visibility, permissions, and the current API allowlist

Depending on the product, Marketplace shows separate ingest and actions cards. EDR without XDR shows no non-endpoint ingest cards; response actions may remain visible. Admin and Super Admin can manage integrations. Help Desk and Read-only can see only configuration and status. For custom roles, grant Integration: read and only the required create, update, delete, and download permissions. Check a missing feature against licensing and role before expanding permissions.

Distinguish the current XDR allowlist from the Classic IP snapshot retained below and the collector uplink. Determine the actual geographical XDR region under Profile icon > Support settings; do not guess from a product name. The vendor list dated September 25, 2026 specifies these ranges for administrative/API calls to third-party products:

Allow only the range belonging to the actual integration, following change approval. This list does not establish availability of every product in every region or replace checking the API destinations currently required. The collector’s outbound mTLS path uses other destinations.

Address health notifications precisely

The rules explained below for 24 hours of continuous failure, countdown reset, and 30-day recurrence also apply to the current Fusion help dated October 20, 2026. The email is not an immediate alert after the 20 or 60 minutes noted above.

Open a custom recipient rule under General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. After selecting role, administrators/distribution lists, and device scope, choose Medium alert, product Sophos Central, and category Central Integrations Alert under Alert Types. Then set a name/description and save. Plan delivery of other alerts before saving: the first custom rule disables default delivery of all email alerts to all administrators. Preserve other required recipients through additional appropriate rules; do not create a test outage on a production connector merely to force an email.

Source-specific next steps

For custom sources, HTTP Ingest, S3, and Azure explain the separate transport paths. Collector operations and cloud deployment complement the existing migration runbook. Cloud Flow Logs, network telemetry, and Windows Event Logs cover the source formats and schema licensing boundaries required. Not all telemetry from a vendor is automatically a SIEM-only source.

After the upgrade: restore operational Response Actions

Checked on 11 October 2026: the enhanced solution uses a different execution and permissions model for Actions. Existing TAC connections and their credentials are not simply transferred for this purpose. Before making a change, document affected Microsoft tenants, connections, enabled actions and owners. Successful ingestion by a separate audit or Graph connector is not a response test.

Reconnect Microsoft 365 or reauthorise credentials

These steps require Admin or Super Admin in Sophos Fusion and a Microsoft 365 administrator on the Microsoft side. In each consent dialog, check the actual permissions requested and the correct Microsoft tenant; do not adopt an old TAC app’s permission set without checking.

If the previous TAC connection has not yet been set up in the new interface, create it as follows:

1. Open Security Operations > Integrations > Marketplace and the Microsoft Graph API Actions tile.
2. Select Add new connection. In Add a Connection, select Add new connection again, enter Name and, if needed, Description and Tags, then continue with Done.
3. Use Proceed to start the guided Microsoft authorisation. A name such as M365-Response-Produktiv is only a label of your choice; the correct source tenant and approved permissions are what matter.
4. In Pick an account, choose the intended administrator account. The first Permissions requested prompt authorises the Sophos master application. After returning to Sophos, a second Microsoft step follows for the actual response connection. Review permissions and complete both dialogs with Accept. Cancelling either prevents connection creation.
5. On return, review the offered actions and save only the approved scope with Save. The new connection must appear in Configured Integrations.
6. In Microsoft Entra, use Refresh under Manage > All applications to verify that the newly created response application appears enabled.

If a connection already exists under Microsoft Graph API > Configured Integrations, open the three-dot menu beside its name and Edit Connection. Select Re-Authorize Credentials and complete Microsoft authorisation. The button appears only when reauthorisation is required and disappears afterwards. Repeat this for each affected connection; repairing one is not enough for all tenants or configurations.

The updated guide dated 7 October 2026 explicitly distinguishes continuing protection from Microsoft response actions that may fail until reauthorisation. It gives 1 October 2027 as the expiry limit for the previous credentials. If you need Actions, do not wait until that limit: demonstrate the required functionality now.

Acceptance includes the correct Entra application, expected connections and enabled actions, plus an approved test using a dedicated account. Use only a reversible change documented for the current action. The Classic Block user sign-in / Allow user sign-in pairing described below does not establish that every new Action has the same name or rollback path. Revoked sessions cannot be restored. In the Action details, View Executions > History provides the execution history; also verify the actual state in Microsoft. Neither consent nor a successful execution entry alone replaces this cross-check.

Add Sophos Firewall (Actions) only if the connection is missing

After the product upgrade, first open a Case and check whether Sophos Firewall actions are available. If they are, no new connection is required. If they are missing:

1. Open Security Operations > Integrations > Marketplace.
2. Find and open Sophos Firewall (Actions).
3. Select Add new connection and save with Save.

This connection requires no credentials. Firewall response actions then become available from Cases, for example blocking malicious IP addresses, domains or URLs. MDR analysts can execute them within the approved response setting; XDR users can launch them from the Case themselves. Check availability without blocking production targets. An effect test is a separate approved change with a product-specific rollback path established beforehand.

Disable new Actions selectively rather than blindly deleting connections

Actions in the enhanced solution have a documented control: under Security Operations > Integrations > Marketplace, Configured > Actions, open the relevant Action and disable it in Enable/disable integration. This is not a universal switch for every Data Ingest connector. Disabling does not reverse changes already performed in the source system.

Delete Integration removes the associated connections and conditions and resets the Action configuration to its initial state. Removing the only connection also deletes its associated conditions. Back up or document connections and conditions first. Reverting test actions still requires the specific Microsoft or firewall rollback procedure, not connector deletion.

XDR automations: distinguish Classic REST from GraphQL

The API information is an addendum dated 9 October 2026, not a retroactive promise about the September launch. New XDR integrations and write-based XDR workflows on Fusion should use the new GraphQL APIs. Distinguish these from a Marketplace API connection, whose REST calls may still go to the third-party provider.

The previous Cases REST API and Detections REST API are now called Classic XDR APIs and are deprecated. The Detections REST API is already read-only. The Cases REST API remains available for existing integrations; it too is intended to become read-only later. Both APIs are then intended to provide historical data until removal. This version gives no specific shutdown date. Do not indiscriminately delete existing integrations or rewrite their hosts because of the Fusion name.

For each automation, record its API, read and write operations, data period, tenant, permissions and error handling. For existing clients, check separately whether current or historical data is expected and whether a write workflow still tries to use Classic Detections. A GraphQL migration requires field mapping, pagination, authentication, permissions and error handling based on the specific new schema, compared in an isolated test. This article deliberately supplies no invented endpoints, mutation names or payloads. The inventory is complete when every client has an owner and a traceable continuation or migration decision; that is not yet a successful API migration test.

Which GraphQL API belongs to the client?

The release of 18 September 2026 included five GraphQL APIs with different purposes:

• Detections v2: Search and edit Detections from endpoints, network sensors and other sources.
• Cases v2: Manage Cases, Evidence, comments, files and links.
• Threat Timeline v2: Search process relationships for up to 100 processes in one call.
• Events v1: Retrieve event details using known event IDs.
• Live Endpoint Search v1 (LES): Run osquery-style queries on connected endpoints and retrieve results and Telemetry.

Live Discover REST is not included in the deprecation of the Classic Cases/Detections APIs. Existing Live Discover REST integrations can continue operating; migration to LES is optional. The live path and the historical XDR Query API serve different purposes. The Live Discover API distinction also explains session-based LES target selection. Likewise, the Endpoint API under /endpoint/v1 and its Device Migration are not being migrated to GraphQL because of this XDR deprecation.

Since 12 October 2026, the Search GraphQL API v1 has also been released for historical QL searches. It provides createSearch, getOrCreateSearch, search and searchResults; Query the Sophos Fusion Data Lake with the Search GraphQL API covers the request contract, execution status, results pages and SQL migration checks. Data Lake Search remains the interactive search path; the XDR Query API remains available. The new API neither forces an immediate switch nor constitutes a LES live-endpoint workflow. For Assets and Entity Graph, separate reference and tenant checks remain open: their mention in the Cases guide is not full implementation approval.

Check the specific migration contract

The transition is not a URL replacement with an otherwise unchanged client. Compare the individual workflows for Cases, Detections and optionally LES, rather than applying a shared REST-to-GraphQL recipe:

• GraphQL returns only selected fields. The client checks both the HTTP status and the errors array and operation-specific status fields; HTTP 200 can contain a query error. Deliberately select and process required nested fields and time values with seconds/nanos.
• For Detections, detectionSearch replaces the REST workflow of starting a query, polling its status and retrieving results. Small result sets use offset/limit; large result sets use the returned search_id with detectionPoll. Reconcile all parts and the total count. Check filters individually as QL predicates; a host lookup expects an ID, not simply the device name. There is no guaranteed identical replacement for a REST type or an Intelix reputation.
• REST and GraphQL Detection severity evaluate separate datasets using separate models. REST uses an integer scale up to 10, while GraphQL metadata.severity uses a scale from 0 to 1. Do not convert by division. Reassess thresholds based on the respective data and their operational meaning. Case.severity with 2/4/6/8/10 is yet another scale.
• For Cases, the API client uses the UUID id, not the readable shortId in the format CSE#####. Old REST Case IDs are not translated, and old Cases do not become available through the new API. Preserve required evidence from old Cases before cutover using the confirmed existing retrieval method; this implies neither a universal export button nor transfer of history.
• Resolve Case types, statuses and verdicts as dynamic, licence-dependent tenant reference data and refresh them regularly. assigneeId expects a Subject ID or a supported @mention, not an email address. An unresolvable assigneeSubject may be null; the display needs a deliberately chosen fallback for this.
• caseEvidence returns link IDs, not complete Evidence payloads. Retrieve Detections separately through detectionRetrieveById with the argument spelled exactly as iDs, and Events through their unchanged Resource Names. Asset and Entity Graph dependencies remain unresolved until the relevant reference and tenant checks are complete. Detection, Event, Asset and Entity Graph IDs are not interchangeable; an Entity Graph entry point for a Case uses its UUID as INVESTIGATION, not its shortId.
• Case pagination uses either an offset or a cursor, not both in one request. Prefer a cursor for a changing list and return it unchanged. keyFindings is a typed document returned when retrieving an individual Case, not in the Case list. The previous filters overviewContains and escalated have no direct replacement; explicitly decide how to handle required functions before cutover.
• There is no deleteCase to replace REST DELETE. Closing, with the verdict required by the Case type where applicable, and subsequent optional archiving are separate steps. For provider-managed MDR Cases, the actual permitted write fields are more restricted and must be checked beforehand.

A pilot must answer the same operational question in the correct tenant, with traceable IDs, complete pagination and evaluated errors. Additional GraphQL functions such as comments, files, links, rules, templates and split/merge are separate extensions, not prerequisites for every cutover. Missing field equivalents or unresolved history remain open client decisions; do not bypass them by assuming equivalence.

Scope: XDR, MDR and licensing

An integration does not replace an XDR or MDR licence. XDR provides analysis capabilities that allow an internal security team to investigate data in the Threat Analysis Center and Data Lake. MDR adds the managed Sophos service. The integrations available in a tenant depend on the Sophos contract, product, integration type and, where applicable, the third-party product licence.

For longer retention or custom data sources, Sophos Next-Gen SIEM explains how to assess the optional add-on and compile a retention inventory for each source.

The frequently cited claim that some integrations are free does not mean that the entire Marketplace is free. For MSP Flex, separate Integration License Packs apply to categories such as Endpoint, Network, Email and Firewall. The previous MSP Flex rule listed Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security and the Microsoft 365 audit appliance as requiring no additional Integration License Pack with an XDR licence. This rule expressly applies only to MSP Flex customers. Cloud Optix is now only a historical entry in that list: its End of Life on 30 September 2026 rules out planning new production use of the service. Check what is enabled in your tenant and contract rather than assuming a blanket free entitlement.

The other platform may also require licences. Sophos’s Microsoft 365 pages conflict: the overview says Management Activity audit logs are available to all Microsoft 365 customers, while the specific setup page requires Purview Audit (Standard or Premium), one of the listed user licences and enabled auditing. Apply these concrete prerequisites for setup. The Detections delivered by Graph Security V2 additionally depend on the Microsoft licence and available Defender XDR capabilities. For Microsoft 365 Response Actions in the Classic/TAC path, Sophos specifies no Microsoft licence requirement, but a Microsoft 365 administrator and the Graph permissions explicitly listed below as Classic are required. Actions in the enhanced solution instead use the prerequisites described above and the actual permissions requested by the two-step authorisation; the Classic list does not define the new consent.

Cloud Optix after End of Life: separate telemetry from CSPM

Sophos Cloud Optix reached End of Life on 30 September 2026. Afterwards, the service collects no new data, generates no findings and forwards no telemetry to MDR or XDR. As of 11 October 2026, the previous recommendation to export before EOL and switch in parallel is no longer an executable future step.

Check now which AWS, Azure, GCP or OCI environments were previously connected exclusively through Cloud Optix and which already have a direct connection to the enhanced XDR/MDR solution. These direct cloud integrations must be configured for each platform; the product upgrade does not do this automatically. Without a verified new connection, do not claim uninterrupted telemetry coverage after 30 September. If a tenant has not yet been upgraded or a product tile is missing, clarify its state with the Sophos account or partner team.

A direct cloud API integration is not the same as a Syslog Data Collector running in AWS, Azure or GCP. In the Marketplace, choose the integration for the required cloud data stream, check its specific source permissions, then verify data and expected Detections. The evidence must identify the cloud account, data source and time window; a green connection alone is insufficient.

Cloud Security Posture Management (CSPM) is not transferred: assessment of cloud configuration posture, compliance benchmark reports and configuration-drift findings are not capabilities promised by the new telemetry integrations. Document this need separately and clarify replacements and remaining contractual entitlements with the account team. Cloud Optix reports, findings history, compliance evidence and inventory data are not migrated to the new system either. Preserve existing exports and check completeness; retrospective export or recovery is not confirmed here.

Integration types and required credentials

REST API

An API integration retrieves data from the vendor’s cloud service or sends a response action to it. Depending on the product, the setup assistant requests items such as a tenant or organisation ID, API URL, client ID, client secret, token or certificate. API integrations do not require a Sophos appliance.

Some integrations accept credentials directly in the assistant. Others request a reusable Integration Credential. You can tell whether a connector supports this from the option to select an existing credential or create one in its setup assistant. The Integration Credential Manager is available only for a limited subset of API integrations; its existence does not mean every secret can be reused centrally.

Log collector

The appliance description below applies to the Classic SVA path. In the enhanced XDR solution, XDR Data Collectors collect Syslog data and have their own resource and network requirements. Do not apply old SVA minimum values to the new VM. Migration provisions configurations but does not start a ready-to-use replacement. SVA Syslog cutover and XDR Data Collector operation explains addressing strategies, excluded settings and safe switchover. NDR is not migrated automatically with it.

With a Log Collector integration, the source system exports events by Syslog to a Sophos appliance. Its Log Collector processes the data and uploads it to the Sophos Data Lake. The appliance runs on ESXi, Hyper-V, AWS or Nutanix, or suitable Dell, NUC or OnLogic hardware. For ESXi or Hyper-V, allocate at least 4 CPUs, 16 GB RAM and 160 GB storage; supported versions start at ESXi 6.7 Update 3 with VM hardware version 11, and Hyper-V on Windows Server 2016. Sophos manages appliance operating-system and security updates; do not install another Sophos or anti-malware agent on it. Scale up for high data volumes or multiple integrations, and validate DNS, proxy, and required port and domain exclusions before approval. Configure the third-party product to send to this appliance, not to an arbitrary Syslog server.

Several integrations can use the same appliance. You must nevertheless configure the protocol, port, format and source for each product according to its integration guide. A green appliance alone does not prove that the correct event type is arriving.

Sophos products

Products such as Sophos Firewall and Sophos NDR have product-specific setup paths. Sophos NDR and Log Collector integrations require an integration appliance, but not necessarily a conventional VM. A REST API-only integration does not require an appliance. Use the affected tenant’s Marketplace as the availability check: each product tile shows the methods offered there and opens the relevant setup assistant.

Safely separate the NDR workload on a shared appliance

The shared appliance topology below applies to Classic SVA/TAC, not the new XDR Data Collector. The latter replaces the Syslog portion; NDR remains a separately operated appliance workload and is not transferred to the new collector.

Only one Sophos NDR integration is permitted per appliance. The same appliance can also host multiple appliance-based third-party integrations as Log Collectors. Before making any change, expand the appliance entry under Configured > Integration Appliances and review every assigned integration. Neither the Integrations value nor a green appliance status replaces this check.

A targeted NDR restart interrupts the NDR sensor while the Log Collectors continue running. By contrast, Restart or Shutdown of the entire VM interrupts NDR and every Log Collector on that appliance. Schedule these actions within a maintenance window, document the state of every workload beforehand, and check each one separately afterward. Operate the Sophos NDR Appliance and Sensor Safely describes the procedure.

Delete in the appliance menu does not remove only one integration. Do not delete the appliance while NDR or a Log Collector is assigned to it. The menu item also does not establish that the deployed VM will be removed or that previously ingested Data Lake data will be deleted. Before decommissioning, clarify the assignments, data retention, removal of platform resources, recovery path, and final verification. Until then, leave the appliance in place.

Before setup

1. Sign in to Sophos Fusion as an Admin or Super Admin. Sophos specifies these roles as a prerequisite for general setup.
2. In the third-party product, check the required licence, administrator role, API capability or Syslog export.
3. Decide whether you need Data Ingest, Response Action or both. A response integration does not automatically provide the telemetry on which an investigation depends.
4. Where possible, create a dedicated app or service account for API access. Grant only the permissions required by the product guide and document the owner, expiry date and secret rotation path.
5. If the third-party product requires a source IP allowlist for administrative API calls, first identify the Central region under My Environment > Installers: hover over a download link under Endpoint Protection or Server Protection and read the region from the displayed URL, for example eu-central-1. Then allow only that region’s addresses from the table below. These addresses are the sources of Sophos API calls, not outbound destinations for the integration appliance.
6. For an integration appliance, check its own outbound network path, DNS and, where applicable, proxy against the appliance requirements.
7. Plan a reproducible, harmless test event. A login or audit event is preferable to a real malware attempt.

Source IP addresses for API allowlisting

This table shows the Classic IP set checked on 14 September 2026. It is distinct from the current XDR allowlist above and is not sufficient evidence on its own for a production allowlist change.

Before a change, check the integration generation, tenant region and complete required IP set against the current Sophos information. If they differ, do not use old values or combine regions. Have the region mapping and change checked under your own approval process, allow only the required scope, and then validate the affected integration with a harmless API synchronisation or test event. Record the initial state, approval, results and recovery path in the change.

Sophos currently labels both the São Paulo and Dubai rows as sa-east-1. Distinguish them by the tenant location and the IP set; never combine regions. Record the approved list in the change.

Add an integration from the Marketplace

1. Open Threat Analysis Center > Integrations > Marketplace.
2. Search for the vendor or product. Where similar entries exist, open the product page and check its category, product name, integration type and purpose. Cisco Meraki and Fortinet FortiAnalyzer, for example, are offered as both API and Log Collector variants.
3. Open the required integration.
4. Select the required type, such as Data Ingest, and click Add Configuration.
5. Follow the Integration setup steps. For API integrations, enter the source-system details or grant OAuth consent. For Log Collector integrations, create or select an appliance and then direct the source system’s Syslog export to that appliance.
6. If Sophos asks for internal domains and IP ranges when you add the first integration, enter only your own internal ranges. These details identify owned addresses, group related alerts and avoid third-party lookups; they are not the same as the allowlist of Sophos source addresses.
7. Save the configuration and complete any external consent dialog. Record the integration name, source tenant, owner and next credential rotation date.
8. Open Threat Analysis Center > Integrations > Configured. The new configuration must appear there. You can monitor or edit it later from this page. Connection Method also indicates whether to investigate the API or Log Collector path during troubleshooting.

FortiAnalyzer: API alerts are not all received Syslog events

For Fortinet FortiAnalyzer, the API connector supports Appliance and VM Subscription, not FortiAnalyzer Cloud. It reads only alerts generated by FortiAnalyzer from /eventmgmt/adom/<ADOM>/alerts; <ADOM> denotes the appropriate administrative domain of the source system. A Syslog event merely received by FortiAnalyzer does not automatically become such an alert. If Syslog events need to be ingested, assess the FortiAnalyzer Log Collector integration or the Fortinet Fortigate integration for the specific source instead. Make this decision before configuring the connector, not only when an apparent data gap emerges.

The API connector removes data that does not conform to the format and then discards certain alert types: VPN tunnel messages (vpntunnel), blocked web requests to unrated destinations, IP/port scanning messages, connections exempted from SSL inspection based on an allowlist or address, Link Monitor messages about interfaces going down or up, warnings about a full Memory Log, Disk Quota alerts/warnings and blocked insecure SSL connections. A missing alert of one of these types is therefore not automatically an authentication or transport error. Type mapping uses pattern matching when message is non-empty; otherwise, it uses the fields FTNTFGTattack, ad.subtype and cat; if there is no match, the message field is cleaned. A received alert title does not automatically constitute a complete MITRE mapping.

For acceptance, choose a harmless, approved event that demonstrably generates a FortiAnalyzer alert, for example a configuration change designated for that purpose in your own event handler. First establish evidence of the alert, ADOM and time in FortiAnalyzer, and ensure that the format and alert type are not discarded. Then locate the same alert in the correct tenant using the Sophos search method confirmed for this connector. An arbitrary test login or a sent Syslog line without a FortiAnalyzer alert is not a valid API ingestion test. If the expected alert is missing, first check alert generation, ADOM, format and type filters, then credentials and connectivity; a Sophos Detection or Case is not guaranteed even when ingestion succeeds.

Check operation and test the integration

A saved configuration is not proof that the integration works. Check the connection, data flow and actual content in sequence:

1. Connection status: Open the entry under Configured, or the appliance status for an appliance-based connection. For Log Collectors, red means the integration is not working, yellow means it is working with errors, and green means events are being received and processed without visible problems.
2. Defined test event: Generate a harmless event in the source system that the relevant API or Syslog category will definitely capture, such as an administrative change or test login. Record its time, user and source.
3. Data Lake evidence: After the product-specific delay, search in Threat Analysis Center > Live Discover. Use the Live Discover category or query documented by the product-specific guide; if Sophos documents no such query for the connector, this general workflow must not promise a universal query-based test. The Live Discover runbook explains queries, Data Lake boundaries and result validation. Check the timestamp, tenant, user and event type. One matching record proves the connection; multiple recent records over a reasonable period demonstrate ongoing data flow.
4. Detection boundary: Not every ingested event creates a Detection or Case. Data Ingest makes data available for analysis; Detections occur only when relevant detection logic triggers. Test ingestion in the Data Lake first rather than automatically expecting an Alert.
5. Response Action: Use an approved test account and document its initial state. For Microsoft 365, Block user sign-in, followed by Allow user sign-in, is a suitable reversible test; Revoke all current sessions is not reversible. Also note that Entra Connect Sync may later re-enable a blocked hybrid account, the MDR response setting limits actions by Sophos analysts, and the names of individual Inbox Rules are case-sensitive for Response Actions.

Health Alerts are not an immediate test. The 24-hour period begins with the first failure message and produces a medium-severity Alert only if the failure continues without interruption. A green status or acknowledgement of the Alert resets the countdown. If the problem persists, the Alert then reappears once every 30 days.

Microsoft 365: three separate integrations

“Connect Microsoft 365” is not a single switch. The following table describes the separate tasks in the Classic/TAC Marketplace, including its Response Actions boundary. For the enhanced solution, use the Microsoft Graph API Actions workflow described above, with its own connections and new consent; the Classic restriction to one environment is not a limit of that new workflow.

For Response Actions in the Classic/TAC path, Sophos specifies the Microsoft Graph permissions User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite and User.Read. With MDR, the selected MDR response mode still determines whether analysts may act without approval. In a hybrid Entra ID environment, Microsoft Entra Connect Sync may later re-enable a sign-in that was blocked in Central.

Example: connect Management Activity safely

1. Make sure auditing is enabled in Microsoft 365. A Microsoft 365 administrator must authorise the connection.
2. Open Threat Analysis Center > Integrations > Marketplace and select Microsoft - Office 365 Management Activity API.
3. Under Data Ingest (Security Alerts), click Add Configuration.
4. Check the auditing notice, click Save and continue, and then click Proceed under Connect to Microsoft 365.
5. Sign in with the intended Microsoft administrator account, review the requested permissions and confirm with Accept. Finish the confirmation with Close.
6. Check the entry in Sophos Fusion. The Microsoft 365 audit data category must appear under Live Discover > Query. Then generate a traceable audit event and find it with a provided query.

Microsoft does not guarantee a fixed time in which an individual event will appear in the audit log. A delayed record is therefore not automatically an integration error. After auditing is first enabled, data can take up to 12 hours to become visible.

For Graph Security V2, the first synchronisation occurs approximately five minutes after the data becomes available in Microsoft Defender Security Center. If the Alerts and Incidents service must first be provisioned, that Microsoft step alone can take about an hour.

Disable or remove an integration

There is no universal Disable switch for every integration type. The available actions vary by product and Connection Method, so do not rely on a universal control:

1. Open Threat Analysis Center > Integrations > Configured, select the configuration and record its status, name, source tenant, appliance and credential.
2. For an API integration, first stop ingestion in a controlled manner or use a Disable or Delete action if the specific product page provides one. Then revoke OAuth consent or disable the dedicated app or token in the source system. For Response Actions, this prevents further actions from Central.
3. For a Log Collector integration, remove the Syslog destination from the source system. Do not delete a shared Sophos appliance while other integrations use it.
4. Remove the configuration in Central only when retention, audit and change requirements are satisfied. Removing a configuration does not guarantee deletion of Data Lake data that has already been ingested; clarify retention and deletion in advance against the Data Lake and compliance requirements that apply to the tenant.
5. Verify that no new events arrive and that no unexpected Response Actions remain possible. Then remove any secrets, certificates, service accounts and allowlist entries that are no longer needed.

For a short maintenance interruption to a Log Collector integration, stop the Syslog export without deleting a shared appliance. For API and Response integrations, lock a credential as a maintenance pause only if reactivation of the same configuration has been verified beforehand; otherwise use only the connector’s available Disable, Delete or Reconnect path. A locked or expired credential is not a universal rollback and causes synchronisation errors.

Troubleshoot common failures systematically

API integration does not synchronise

Open Configured, check the Connection Method and read the specific error. Resolve Invalid credentials, insufficient permission and expired credentials in the third-party product first: check IDs, secrets, token lifetimes, certificates and API permissions. Network not reachable and invalid domain also require DNS, proxy, firewall and service-status checks. With request throttling, the provider has limited the API; repeatedly saving immediately may worsen the problem. For Microsoft, HTTP 401 means invalid authentication; 429 and 509 indicate throttling.

Log Collector remains red or yellow

Red means not working; yellow means working with errors. Check VM resources, network and DNS, outbound connectivity, and the Syslog path from the source system to the appliance. no events received since last container restart indicates that no Syslog events have arrived since the container started. no received events in last 10 mins may indicate an interrupted export or simply a source that sends infrequently. If uploads fail, the appliance buffers data on disk. If uploading remains blocked and storage fills, older data may be discarded.

Microsoft 365 supplies no data

For Management Activity, Microsoft 365 auditing must be enabled, and Enabled for users to sign-in? = Yes must be set under Office 365 Management APIs. Allow for the startup time of up to 12 hours after enabling auditing. For Graph Security V2, check Defender XDR access, consent, provisioning of the Alerts service and the available Microsoft licence. The old Graph Security API is no longer a fallback.

No Health Alert despite an outage

First check that this is a Data Ingest integration and that the failure has continued for 24 hours without interruption since the first error message. An intervening green status or acknowledgement of the Alert resets the countdown. By default, all Central administrators receive the email; custom Notification Rules can change this distribution.

Security and operational rules

• Use dedicated apps and secrets instead of personal administrator accounts.
• Grant only the API permissions required by the specific integration. Response integrations inherently require write permissions and warrant stricter approval than ingestion-only connections.
• Do not store secrets in tickets, screenshots or KB articles. Record the owner and expiry date in password or secret management.
• Plan credential rotation before expiry. Sophos reports expired credentials as synchronisation errors.
• Allow Sophos IP addresses only where the provider requires a source allowlist, and use the list for the actual Central region.
• Enable health notifications for a responsible team. When creating a Custom Notification Rule, remember that doing so disables the default delivery of all email Alerts to all administrators, so you must recreate any required rules separately.
• Document each integration’s data source, purpose, data classification, retention, permissions, test, owner and removal path.

Acceptance criteria

Setup is complete only when the integration appears under Configured with the expected method, a defined test event can be found in the intended destination, its timestamp and source tenant are correct, and an owner accepts responsibility for credential rotation and Health Alerts. For Response Actions, acceptance also requires an approved, documented test; only reversible actions are returned to the initial state. Irreversible actions such as session revocation must not be used as a rollback test. Record unavoidable delays, such as Microsoft 365 auditing latency, in the operations log.

Frequently asked questions

Does every integration send data to the Sophos Data Lake?

No. Data Ingest sends data to the Data Lake. Response Action enables an action in the third-party product. Some products offer only one type; others have separate configurations for both directions.

Are third-party integrations free with XDR?

Not in every case. For MSP Flex, Sophos lists specific Sophos XDR category integrations that can be used with XDR without an additional Integration License Pack. Other categories require the appropriate packs under Flex. Third-party licences may also be required.

Why can I see data but no Detection?

Ingestion and detection are separate stages. A Data Ingest connector can write events correctly to the Data Lake without every event producing a Sophos Detection or Case. Check the raw data flow first with the intended Live Discover query.

Can I use the same appliance for multiple Syslog integrations?

Yes, in the Classic SVA path, Sophos allows multiple third-party integrations and one Sophos NDR integration on the same appliance. Each source must still be configured with the correct connection and format details. By contrast, the new XDR Data Collector replaces Syslog collection and neither takes over nor hosts this NDR workload. Use the collector migration procedure linked above for the transition; operate NDR separately using the NDR operations runbook.

Why is the Microsoft 365 Response integration not enough?

It provides actions but does not automatically ingest audit data or Defender Alerts. Add Microsoft 365 Management Activity and Microsoft Graph Security API V2 so that Detections and investigation context are available.

Does removing an integration delete historical Data Lake data?

Removal does not guarantee immediate deletion of data already ingested. Treat removal as stopping future data flow, and clarify retention or deletion obligations separately before committing to a deletion deadline.