> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threataware.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Silent Failure
> The category of security failure that's invisible to single-tool consoles — and Protect's signature differentiator
## What it is
A **silent failure** is a security control that's deployed, looks healthy in its own console, but has stopped actually protecting the device.
The agent process is running. The vendor console still lists the device. The last check-in timestamp might even look recent (if the console caches state aggressively). But the agent has lost contact with its cloud back-end days or weeks ago, and is no longer sending telemetry, no longer receiving policy updates, and no longer providing the protection you think it is.
The single-tool console can't detect this because it doesn't have a reference frame. From *its* perspective, the device exists and the agent is "installed" — that's all it knows.
## A worked example
```
TOOL DEVICE STATE Anomaly
---------------------------------------------
Intune LAPTOP-001 Active Device active this morning.
Last seen: 2026-05-21
Same device, but...
CrowdStrike LAPTOP-001 Online ...the CrowdStrike agent on
Last seen: 2026-05-07 LAPTOP-001 hasn't reported
since 2026-05-07.
Process is running, can't
reach the cloud, returning
cached status to the console.
```
Intune saw the device this morning. CrowdStrike says it's "Online" but the actual telemetry is twelve days stale. Either tool, on its own, would tell you everything is fine.
This is exactly what cross-tool correlation surfaces.
## How Protect detects it
Protect computes Vitals as a three-stage check. The middle stage — **Function** — is silent-failure detection.
| Stage | Question | Computed from |
| ---------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. Deployment | Is the control present at all? | Comparing the device's presence in identity/management sources against its presence in the security tool |
| 2. **Function** | Is the control actively working? | **Freshness of the security tool's per-device data versus the device's general activity across all other tools.** Stale tool data on an active device = silent failure |
| 3. Configuration | Is the control configured per your policy? | Configuration checks you defined in [Vitals Configuration](/vitals-configuration) |
A device passing 1 but failing 2 lands in the **Not Functioning** state — the silent-failure signal.
See [Vitals States](/reference/vitals-states) for the full state machine, and [Security Monitoring](/security-monitoring) for the conceptual overview.
## Why it matters
A silent EDR failure is functionally identical to no EDR at all — except worse, because nobody knows. The device shows green on every dashboard.
Common silent-failure root causes (vendor side, not Protect):
* Agent process is running but the cloud connection broke (proxy, certificate, DNS, firewall change)
* Agent's tenant ID was rotated and the device wasn't re-enrolled
* A management tool's policy disabled real-time protection
* The agent crashed and silently restarted into a degraded state
* Device was imaged with a stale agent that registered briefly but never updated
* License pool exhausted; agent reports but does nothing
Across a large estate, a few percent of agents are typically in some form of silent failure at any given time. Protect surfaces them as a count and a queryable population, not a vague concern.
## Investigating a specific silent failure
[X-Ray](/x-ray) shows every connected integration's raw view of the device side-by-side. You'll see the freshness gap immediately.
The device should have recent activity in identity / MDM / network sources. If everything is stale, the device might be genuinely offline — not a silent failure.
The security tool's last-seen timestamp should match the device's general activity. A multi-day gap is the diagnostic.
Once confirmed, the fix is vendor-side — reinstall, re-enrol, re-tenant, or whatever the agent needs to recover. Protect's job is detection, not remediation; the [Action Center](/automation) can drive the remediation workflow.
## Querying for silent failures
The canonical query shape, against any integration:
```text theme={null}
system..deployed:true AND system..functioning:false
```
Examples:
| Use case | Query |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| All broken CrowdStrike agents | `system.crowdstrike.deployed:true AND system.crowdstrike.functioning:false` |
| All broken Defender agents | `system.microsoftDefenderAtp.deployed:true AND system.microsoftDefenderAtp.functioning:false` |
| End-user devices with broken EDR (any integration) | Combine with `tags:End-User` and the per-integration silent-failure clauses |
See [Query Syntax](/reference/query-syntax) for the verified grammar, and [Continuous Actions → Broken agent recovery](/actions-continuous) for an end-to-end automation example.
## Best practices
Each major EDR / MDM / identity tool gets its own broken-agent recovery Action. Use a 48-hour minimum-time-in-view to avoid firing on transient outages. See [Continuous Actions](/actions-continuous).
Default resolution = "no longer matches the query" — but a device going *offline entirely* also leaves the query, and that's not "fixed". Specify positive resolution: `deployed:true AND functioning:true AND configuredCorrectly:true`. See [Automation → Resolution Criteria](/automation#advanced-configuration).
A baseline of 1-3% is normal for large estates. A sudden spike usually signals a vendor-side issue (mass agent disconnect, license problem, cert rotation). Use a [Scheduled Report](/scheduled-reports) of the silent-failure population for trend visibility.
## Cross-references
The Vitals model end-to-end
Not Functioning state definition
Configure detection per integration
Broken agent recovery patterns
Investigate a single device
The functioning:false grammar