Sentinel Enterprise XDR
A shared timeline of security events across endpoints, servers and phones.
The XDR timeline, incidents and ATT&CK view run in production. Cloud, container, API and AI security modules are not built.
- For
- Security teams and MSPs
- Devices
- Organisation
- Platforms
- Web console · Linux server agent · Android
- Works today
- 12 of 20 listed features
Is Sentinel Enterprise XDR the right edition?
Security teams
One timeline of events from server agents and Android phones, 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
Server agents send authentication, port-scan, account-change and suspicious-process events. Android phones send posture and threat events. Sentinel desktop will send opted-in events once released.
- 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 with a free-text query, read the evidence, and resolve. 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
- 04
- Limited
- 08
- Not released
- 00
- Coming
- 08
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 huntingLimited
One free-text hunt; no query builder or saved hunts.
- Attack graph and automatic root causeComing
Not built. Incident investigation and analyst cases are separate existing workflows.
Response
- Server response actionsLimited
Process, service, firewall, container and reboot, through the audited command lifecycle.
> Servers only
- Approval queueLimited
Named approver distinct from the author. In progress.
- 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.
- MSP customers, usage and billing viewsComing
Not built.
Coverage modules
- ContainersLimited
Host Docker containers only; no Kubernetes.
- Threat intelligenceLimited
ATT&CK references and organisation IOC matching are separate from externally supplied campaign or actor intelligence. External intelligence needs a source.
- Cloud security (AWS, Azure, GCP)Coming
Not built.
- API and application securityComing
No WAF, RASP or request-body telemetry.
- 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.
Sentinel desktop
Opt-in reporting built; app is an unsigned pre-release.
Cloud connectors
None.
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.