Sentinel Enterprise XDR
A shared timeline of security events across endpoints, servers and phones.
The XDR timeline, cases and rule views run in production. AWS read-only checks need a configured provider; Docker and web-log views are partial. Kubernetes, WAF and AI-agent sensing are absent.
- For
- Security teams and MSPs
- Devices
- Organisation
- Platforms
- Web console · Linux server agent · Android events · Mac and Windows server agents (limited) · Desktop pre-release (opt-in events)
- Works today
- 19 of 23 listed features
Is Sentinel Enterprise XDR the right edition?
Security teams
One timeline of reported events from server agents, enrolled Android phones and opted-in pre-release desktop apps, correlated into incidents mapped to MITRE ATT&CK.
Managed service providers
A tenant switcher across customer organisations, with membership re-checked on every switch.
Analysts who read the rules
Every rule has an id, version, level, ATT&CK techniques and thresholds you can read and dry-run.
You need a console, not a SOC
→ Sentinel for Small BusinessYou only run servers
→ Safeavio ServerGuard
An attack is one story told across many logs.
Password guessing on one server, a successful login from a new address, then logins to three more machines: each is an unremarkable line in a different log. Enterprise XDR collects those events into one tenant-scoped store, runs versioned correlation rules over them and raises an incident with the evidence linked.
- SSH password guessing that eventually succeeds
- One account logging in from several addresses within an hour
- A peer probing many ports on a server
- Phones reporting root, tampering or remote-access apps
From install to response
- 01
Collect
Supported server agents send host events, enrolled Android phones send posture and threat events, and the unsigned desktop pre-release can send opted-in reports. No source is assumed present until it reports.
- 02
Validate at ingest
Rate limits, size and batch caps, de-duplication, a clock-skew window and a dead-letter table. Device identity and tenant are set by the server, never read from the event.
- 03
Correlate
Six versioned rules run over the event store. Three are fed by real sensors today; three wait for a sensor that produces their input.
- 04
Raise an incident
Each incident carries the rule id, version and level, links to its contributing events, and ATT&CK techniques added server-side.
- 05
Investigate and resolve
Hunt by text, IP, user, technique or IOC; save and schedule hunts. Cases can have an owner, priority, SLA, notes and a graph made from linked events. The incident lifecycle is an append-only record.
- 06
Respond on servers
Typed, audited server actions. Supported Linux isolation has its own limits; wider endpoint isolation and identity-provider credential revocation are unavailable.
Every feature, with its state today
Grouped by where it runs. A feature is available only when it works in production or in the current download.
- Available
- 05
- Limited
- 14
- Not released
- 00
- Coming
- 04
Detection
- Rule registry with dry-runAvailable
Ids, versions, levels, ATT&CK techniques and compliance tags, served by the API; test events against rules before relying on them.
- SSH brute-force ruleAvailable
5 failed logins from one address in 300 s. The one attack family our register marks as detected. Old log lines can re-raise an incident.
- Lateral-movement and port-scan rulesLimited
3+ addresses per user in an hour; 10+ ports from one peer in 60 s. Fed by the hub agent's collector only.
- Privilege-escalation, exfiltration and config-tampering rulesComing
Deployed, but no sensor produces their input, so they cannot fire today.
- Custom rulesComing
Rules are in code and read-only.
Investigation
- Incident queue and detail with evidenceAvailable
Correlated incidents with the events behind them.
- XDR timelineLimited
Server and mobile sources; cloud and application sources are missing.
- ATT&CK mappingLimited
Techniques are labels on event categories; a label is not a detection.
- Threat hunting and IOC listsLimited
Text, IP, user and technique pivots; server-side saved and scheduled hunts, run history and IOC matching. Process and file search need additional agent telemetry.
- Cases and linked-event graphLimited
Owner, workflow, priority, SLA, append-only notes, timeline and a graph built from linked events. An automatic root-cause verdict is not claimed.
Response
- Server response actionsLimited
Process, service, firewall, container and reboot, through the audited command lifecycle.
> Servers only
- Approval queue and playbooksLimited
Supported actions can use a separate approver. Playbooks can open and assign a case, add a note and e-mail a team; they do not run server commands.
- Endpoint and identity containmentComing
Supported Linux server isolation is separate. Desktop/Android isolation and external identity-provider session revocation are unavailable.
Tenants and MSP
- Tenant switcherAvailable
Shown with more than one organisation; membership is re-checked on every switch.
- Customer overview and portal brandingLimited
Side-by-side servers, important vulnerabilities, incidents, seats and plan; per-organisation portal branding. Per-customer billing, invoices and app/report branding are not built.
Coverage modules
- Docker containersLimited
Host Docker containers and images with audited actions. Kubernetes clusters, workloads, RBAC and secrets are not built.
- Threat intelligenceLimited
ATT&CK coverage plus URL, domain, IP and hash lookups from named public feeds, with sources and matching event counts. Campaign, actor and commercial intelligence are deferred.
- AWS cloud checksLimited
A read-only per-organisation AWS connector has a wizard and scheduled CIS-style checks. It needs the hub’s AWS identity and customer IAM role before it can run; findings do not raise incidents. Azure and GCP are absent.
- Web application signalsLimited
Common attack patterns from a web server access log, per server. No WAF, RASP, request-body telemetry or full API inventory.
- Identity and credential exposureLimited
Authentication-event and exposure views exist; privileged-account, MFA and session risk need more data.
- Outbound integrationsLimited
Filtered Slack, Teams, Discord, signed webhook and Splunk deliveries use a retrying outbox. Ticketing connectors are absent and retries can duplicate a delivery.
- Ingest healthAvailable
Dead letters, throttling and limits are visible to administrators.
- AI-agent securityComing
No AI-security detection runs today.
Where it runs, as it is today
Web console
SOC views at safeavio.com.
Linux server agent
The XDR collector runs on the hub agent today.
Android
Posture and threat events into the timeline.
Mac and Windows server agents
Monitoring is less tested; Linux-only XDR host signals and network isolation do not apply.
Sentinel desktop
Opt-in reporting in an unsigned pre-release; no XDR remote containment.
AWS cloud connector
Read-only checks need a configured AWS identity and customer role; findings do not enter the XDR event stream.
Who can see what, and what is enforced
Hard boundaries
- Consumer devices are not managed endpoints: XDR receives nothing from them
- Consumer accounts are never accepted as enterprise identities
- Seeing an event never grants the right to act on that device
- Raw telemetry never feeds cross-tenant threat intelligence
At ingest
- Device and server identity come from the authenticated token, not the event body
- Only the event categories a source may produce are accepted
- ATT&CK techniques are added by the server; a client cannot assert its own
- Malformed events are dead-lettered, not partially stored
The enterprise administrative plane with certificate-based identity and mutual TLS is designed and not built. Until it is, agents authenticate with an API key and phones with a device token.
Edition ceiling: Sentinel Enterprise XDR may never
- Use consumer accounts as enterprise identities
- Turn a consumer's telemetry into authority to act on their device
A product boundary, not a setting. No flag, plan upgrade or API call can raise it.
How data moves
Each box is a step the data passes through, labelled with where it runs.
- your serverSourcesserver agents, phones
- our hubIngest guardvalidate, dedup, stamp tenant
- our hubEvent storetenant-scoped
- our hubRulesBIDUA-HUB-0001…0006
- consoleIncidentrule id, level, ATT&CK
The correlation engine stores events and raises incidents; it takes no response action by itself.
Specifications
| Correlation rules | 6 versioned backend rules with levels 0–15; 3 fed by sensors today. |
|---|---|
| Rule API | Read the registry; dry-run events against the rules. |
| Coverage register | Every one of 127 attack families mapped to a sensor or marked unavailable (register of 2 October 2026), plus a 352-technique list of what is built, partial or not built. See the threat center for the counts. |
| Identity | Console accounts with roles. Certificate-based enterprise identity (mTLS) is not built. |
| Storage | PostgreSQL with row-level security enforced in production; encrypted nightly backups copied off the host. |
| Event retention | A tenant-aware retention job exists and is off; security events are kept today. |
| Region | One region, one host. Region selection (India, EU, global) is designed, not built. |
How it differs from the editions next to it
Limits come from the edition ceiling in our product boundary. The full matrix compares all seven.
| Property | Enterprise XDR (this page) | Small business | ServerGuard | Personal |
|---|---|---|---|---|
| State today | Limited | Limited | Available | Not released |
| Devices | Organisation | 5–250 | Servers you administer | 1–3 |
| Runs today on | Web console, Linux server agent, Android | Web console, Linux servers, Android | Linux; macOS and Windows less tested | Android. Windows and macOS an unsigned pre-release is available. |
| Strongest action | Supported server actions; wider endpoint and identity response unavailable | Typed server actions by administrators; phone lock and locate | Firewall, service, process, reboot through audited commands | Quarantine and restore, both reversible |
| Who sets policy | Tenant administrators and analysts | Organisation administrators | Server administrators | You, on your own device |
| Device credential | Agent API key; mTLS identity not built | Agent API key; phone device token | Agent API key | Phone enrolment token; separate desktop credentials |
| Cloud reporting | Console-hosted at safeavio.com, one region | Console-hosted at safeavio.com, one region | Console-hosted at safeavio.com, one region | Off by default; opt-in, revocable |
| May never | Borrow consumer account semantics | Silently encrypt devices | Run an API-supplied command string through a shell | Bypass phone permissions or the screen lock |
Questions about Sentinel Enterprise XDR
Q01Is this a complete XDR?
No. It is a working incident queue, timeline and rule engine over server and Android events. Cloud, Kubernetes, API and AI-agent coverage remain limited or unavailable. Server response does not imply general desktop or Android isolation or identity-provider credential revocation.
Q02Which ATT&CK techniques do you detect?
Techniques are attached to event categories and rules. A label is not a detection: our register counts a family as detected only when a sensor, a rule and a test all exist, and today that is one family. The threat center shows the full count.
Q03Can we write our own rules?
Not yet. Rules are in code and read-only, but you can read every rule's thresholds and dry-run events against them.
Q04Can XDR act on our employees' personal phones?
No. Consumer devices are not managed endpoints and enterprise XDR receives nothing from them. Only devices enrolled in your organisation appear.
Q05Do you offer a managed detection and response service?
No. MDR is a deferred decision; we do not offer it.
Capabilities in this product
Each capability page lists the attack families it covers and how far our coverage register says it goes.
Password exposure checks, account sign-in safety and hacked-account help today; verified-address monitoring interfaces need a configured provider for results.
Wi-Fi and connection awareness on phones; port-scan visibility and firewall control on servers.
Defence against prompt injection, agent hijacking and poisoned models. Not built yet.
Known-malware scans, automatic protection and fake-app checks on the phone; ransomware warnings on servers.
See the rules before you trust the alerts.
Talk to us about your environment. We will tell you which of your sources we can read today and which we cannot.