osquery + Fleet → SentinelOne
osquery + Fleet ↔ SentinelOne: integration to migration path.
osquery + Fleet deploys alongside SentinelOne first — read-only, low blast-radius, immediately delivering the inventory the S1 Core SKU never shipped. Then Fleet progressively takes over S1's visibility, inventory and forensic-query tier in phases. No flag day, no agent removal, and every phase rolls back in minutes.
The honest exception is the headline: osquery is read-only, so this is a partial migration. S1 keeps prevention, Storyline, ransomware rollback and Vigilance MDR throughout — we say so up front, because the rest only matters if you can trust it.
The idea
Own visibility first. Downgrade the SKU last.
The topology that makes this zero-downtime: osqueryd installs beside the S1 agent on every endpoint, with no kernel hook and nothing to unwind — its binary path and signing cert added to the S1 exclusion policy before mass deploy. S1 stays the threat source of truth; Fleet becomes the posture source of truth. Because osquery is read-only by construction, analysts can query without approval gates while S1 keeps owning prevention, Storyline correlation and rollback. Only after Fleet carries inventory, posture and FIM does the S1 SKU come down at renewal — never the agent.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We document your S1 SKU per group (Core / Complete / Vigilance), whether Deep Visibility is licensed and actually used, retention per tier, the current S1 exclusion list, and which auditor evidence depends on the S1 console. If you are on Core and in PCI scope, we surface the retention gap up front. Read-only.
Stand up Fleet; co-install on a canary
Fleet runs HA — two app nodes behind a load balancer, MySQL replica, Redis for the live-query bus, a sized indexer. About 50 hosts across every OS get osquery alongside S1 with an empty schedule, proving the install is non-disruptive. The osquery binary path and signing cert go on the S1 exclusion policy first.
Scheduled packs in shadow mode
Scheduled query packs (process_events, socket_events, file_events, users, kernel_modules, os_version, installed_applications) run on the canary at conservative intervals and pipe to the indexer. SOC has read access but still treats the S1 console as source of truth — no workflow handoff yet.
Expand to the full fleet; SOC adopts Fleet
osquery reaches 100% of in-scope endpoints in staged waves, each soaked seven days. SOC's inventory, posture and ad-hoc-query workflows move from the S1 console to Fleet; the S1 console is opened only for threat workflows. Auditor evidence queries are produced from Fleet.
Move PCI evidence to Fleet; reduce SKU
PCI Req 10 (1-year retention, 90-day hot) and Req 11.5 FIM are evidenced from Fleet plus the indexer, with WORM object-lock on the cold tier. If you were on S1 Complete only for Deep Visibility queries now in Fleet, you can negotiate down to Core at renewal — this is where the dollars land. Vigilance MDR stays.
Operationalise Fleet's MDM-adjacent surface
Optional. Fleet Desktop ships to end-users for self-service device-health visibility, and Fleet's MDM features fill gaps the current stack misses — most often Linux, where Jamf does not reach and Intune is partial. Communicated as a device-health tool, not surveillance.
Retire S1's visibility tier — not S1
The S1 licence is downgraded where applicable; the S1 console is used only for threat workflows; Fleet is the documented source for inventory, posture, FIM and IR query. S1 agents stay installed — prevention, Storyline, rollback and Vigilance are untouched. This is a procurement action at renewal, not an agent change.
Feature parity
Where each tool genuinely leads.
| Capability | osquery + Fleet | SentinelOne | Parity |
|---|---|---|---|
| Telemetry / event collection | osquery process_events/socket_events/file_events (audit/ETW-backed) | S1 Deep Visibility kernel-mode event stream | Partial |
| Cross-OS SQL inventory | Fleet over os_version/installed_applications/launchd/systemd_units | S1 Application Risk inventory (console-side) | At parity |
| Prevention (NGAV / ML) | None — osquery is read-only | Static AI on-write + Behavioral AI on-execute | SaaS only |
| Behavioural detection content | None (SIEM-side ppid/pid joins are lossy) | Storyline per-process-tree causal correlation | SaaS only |
| Ad-hoc forensic query | Fleet Live Query (push SQL to N hosts) | S1 Deep Visibility query (requires DV SKU) | Partial |
| Response (isolate / kill / remote shell) | None — no osquery_kill table; script table only | S1 RemoteOps + mitigation actions, network isolation | SaaS only |
| Ransomware rollback | None | Rollback-ransomware (VSS-backed restore) | SaaS only |
| Identity threat detection | None | Singularity Identity (AD Kerberos/NTLM anomaly) | SaaS only |
| FIM | osquery file_events (Linux audit / macOS FSEvents / Win EventLog) | No FIM-of-record (QSAs push back on Behavioral AI as Req 11.5) | OSS only |
| Scheduled posture / compliance | fleetctl CIS policies (disk encryption, firewall, sudoers) | Device control + Application Risk; no first-class CIS posture | Partial |
| Data retention | Fleet to indexer (Elastic/OpenSearch/ClickHouse), your storage budget | S1 Core: no EDR retention; Complete/Vigilance tier-dependent | Partial |
| RBAC + multi-tenant | Fleet teams + RBAC on query permission | S1 Sites/Groups RBAC, native multi-tenant | At parity |
| Managed hunting / 24x7 SOC | None | Vigilance MDR | SaaS only |
| Deployment & HA | Self-hosted Fleet (2+ app nodes + MySQL replica + Redis) | S1 cloud-managed | Partial |
| Cost model | Fleet OSS free; Premium per-host | S1 per-endpoint by tier | Partial |
What we're honest about
The caveats most vendors leave out.
osquery is read-only — no prevention
osquery has no kill, no quarantine, no block-on-write; there is no osquery_kill table. S1's Static AI and Behavioral AI ML prevention have no OSS parity here. This pair replaces S1's visibility, inventory and forensic-query tier — not its prevention engine. The S1 agent stays installed. If cost is the driver, you downgrade the SKU, you do not remove the agent.
Storyline auto-correlation has no equal
Every S1 event carries a storyline_id tying it to the causal process tree it descended from, computed on-agent in real time. osquery rows are independent; reconstructing the tree with SIEM-side parent/child joins is lossy under PID reuse, orphaned processes and container namespaces, and it lags real time. This is the single biggest behavioural gap and the reason the migration is partial.
Rollback, Identity and Vigilance MDR stay SaaS
Ransomware rollback (VSS-backed restore), Singularity Identity AD threat detection, and Vigilance 24/7 MDR have no OSS substitute in this pair. Keep S1 for them, or — for MDR — stand up a third-party service (Red Canary, Arctic Wolf, Expel) as a separate procurement. We never claim Fleet's script table is an audited RemoteOps equivalent.
Fleet's value lives in the indexer you size
Fleet without retention is just live query. The PCI Req 10 win exists only because you sized the storage — 90 days hot, a year warm/cold, WORM on the cold tier. Budget it before Phase 2, not as a retro-fit, and run HA Fleet (two app nodes, MySQL replica, Redis) so an outage costs you live query, not your schedule.
Why this beats a flag day
Reversible at every layer.
Every per-phase change rolls back in under 15 minutes — uninstall osquery (no kernel hook to unwind), empty the schedule via fleetctl, or stop scheduled packs per wave so the agent stays installed but silent. And before any S1 SKU is downgraded, Fleet-sourced evidence soaks through at least one full audit cycle and SOC runs at least 30 days with near-zero reliance on the S1 Deep Visibility console. You are never betting threat coverage on one big cutover.
See whether Fleet can carry your visibility tier — and what S1 must keep.
A call with a senior security engineer. We map your S1 SKU mix, find the Deep Visibility queries SOC actually runs, size the indexer that closes your PCI retention gap, and tell you exactly where S1 stays — before you commit to anything.
Map my migration →