Sophos Central (Endpoint)

Connects to Sophos Central to pull managed endpoint inventory, health state, tamper-protection posture, and protection policy assignments. Surfaces endpoints in degraded (suspicious / bad) health so SMB IT teams can intervene before a real incident.

What this adapter actually does for you

Once connected, Clariti pulls every endpoint Sophos protects in your tenant and surfaces three signals that an SMB IT operator actually acts on:

1. Endpoints in BAD health state — Sophos's own indicator for "something is wrong right now." Causes include tamper protection disabled by an end user, agent offline for 7+ days, or an untreated detection. Each Sophos-flagged endpoint becomes a high-severity Clariti finding with the device name and the recommended remediation path.
2. Endpoints in SUSPICIOUS health state — one component flagged but not yet a confirmed problem. Usually self-resolves after the next agent sync; persistent SUSPICIOUS state for >2 hours is worth a manual review. Medium-severity finding.
3. EDR coverage — every endpoint Sophos manages contributes to your EDR coverage tile alongside CrowdStrike, SentinelOne, and Microsoft Defender. If you have devices in M365 sign-ins that Sophos doesn't see, Clariti flags those as EDR coverage gap findings (cross-adapter correlation).

What this adapter does NOT pull

Stays narrow on the endpoint footprint:

• No quarantine actions. Clariti never quarantines, isolates, restarts, or pushes a policy. The OAuth scope is read-only.
• No user-level identity or device-owner mapping (that's Entra ID's job).
• No firewall rules or web-protection categories (separate Sophos products).

If you want any of those, look at Microsoft Entra ID or Sophos Firewall adapters in the catalog.

SIEM alerts (optional — requires SIEM scope grant)

In addition to endpoint health, Clariti pulls unresolved Sophos SIEM alerts from the last 24 hours and emits one finding per alert (capped at 50 to keep the Findings UI usable). This catches the detections that don't turn the endpoint health badge red — suspicious processes, blocked malware, policy violations.

The SIEM endpoint uses the same OAuth client credential as endpoint inventory, but Sophos exposes it under a separate API scope that has to be enabled on the Service Principal. If you don't enable it, Clariti degrades silently — the primary endpoint-health findings still ship, the SIEM-derived findings just don't appear. To enable: in Sophos Central, open your Clariti API credential and add the SIEM API to its allowed scopes, then re-poll.

If the SIEM endpoint isn't available in your region, the adapter logs a one-line notice and skips it — no operator action required.

Permissions required

The OAuth client credential Clariti uses is read-only. Always create the credential at the tenant level, not the partner level — partner-level credentials don't expose apiHosts.dataRegion in the /whoami response and Clariti can't route requests without that field.

Recommended role: Service Principal ReadOnly. Sophos provides this specifically for read-only integrations; it cannot make any modifications.

Step-by-step credential creation

Connecting in Clariti

In Clariti, navigate to Integrations → Sophos Endpoint → Connect now and paste the two values:

Clariti does NOT ask for a Tenant ID — it discovers your tenant ID and data region automatically by calling /whoami after authentication. If you see a Tenant ID field in any Sophos integration UI, that's an older auth pattern; Clariti uses the modern OAuth2 flow.

Click Connect. Clariti exchanges the credentials at id.sophos.com/api/v2/oauth2/token, then calls /whoami to find your data region (US-1, US-2, EU-1, etc.) and tenant ID. A green checkmark confirms both steps succeeded.

What you'll see after connect

Within ~2 minutes:

• The Assets screen fills with one row per Sophos-managed endpoint, labelled Sophos Endpoint in the source chip. Click any row for the full health breakdown.
• The EDR coverage tile turns green for any device Sophos protects.
• If your tenant has any endpoints in BAD health state, a high-severity Finding card titled "N Sophos endpoint(s) in BAD health state" appears with the offending device names and a remediation checklist.
• If you have endpoints in SUSPICIOUS health, a separate medium-severity finding lists those for review.
• The Findings → Sources filter now includes a "Sophos Endpoint" facet so you can isolate Sophos-driven findings during incident response.

Troubleshooting

"is missing 'apiHosts.dataRegion'" or "is missing 'id'" The credential was created at the partner level, not the tenant level. Partner-level credentials don't expose a data-region or a tenant ID, so Clariti can't route requests. Fix: delete the partner-level credential in Sophos Central and recreate it from inside the target tenant (switch tenant first via the customer-switcher).

401 Unauthorized at connect time Verify the Client ID and Client Secret are pasted correctly with no whitespace. Sophos's OAuth endpoint is strict about the scope=token parameter; Clariti sends this automatically, but if you've revoked and regenerated the credential since copying it, the old secret won't work.

403 Forbidden during the first poll Most often, the credential was created with the wrong role — anything below Service Principal ReadOnly won't have permission to call /endpoint/v1/endpoints. Open the credential in Sophos Central and verify the assigned role.

Endpoints in red badge but no findings Findings fire from the health.overall field, which Sophos populates after the first sync that includes a degraded component. If devices look red in Sophos Central but Clariti shows no finding within an hour, check that the Sophos-side health badge reads bad (not partial or some custom state) — Clariti uses Sophos's own taxonomy.

429 Rate Limited Sophos Central caps most endpoints at ~1000 requests per minute per tenant. Clariti's per-poll request count is well below this; if you see 429s, it's almost certainly another integration (Sophos SIEM, custom scripts) sharing the same tenant. Clariti retries up to 3 times with Retry-After backoff (capped at 60s); persistent throttling exhausts the retry budget and surfaces as a recognisable 429 in the run log.

API rate limits and polling cadence

Sophos Central enforces tenant-level rate limits on the data plane (api-*.central.sophos.com):

| Endpoint | Approximate ceiling | |--------------------------|---------------------| | /endpoint/v1/endpoints | ~1000 req/min | | /endpoint/v1/policies | ~1000 req/min | | /whoami/v1 | ~600 req/min |

Clariti polls once per hour by default. A typical SMB tenant (under 500 endpoints) makes one or two paginated requests per poll cycle — well under any of these ceilings.

When Clariti hits a 429, the adapter honours Sophos's Retry-After header (capped at 60 seconds) and retries up to 3 times. Persistent throttling beyond the retry budget exits with a recognisable 429 in the run log so you can investigate. The token issued at id.sophos.com is valid for ~1 hour and Clariti refreshes it on each poll — no action needed on rotation.