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
How Protect detects it
Protect computes Vitals as a three-stage check. The middle stage — Function — is silent-failure detection.
A device passing 1 but failing 2 lands in the Not Functioning state — the silent-failure signal.
See Vitals States for the full state machine, and 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
Investigating a specific silent failure
1
Open the device in X-Ray
X-Ray shows every connected integration’s raw view of the device side-by-side. You’ll see the freshness gap immediately.
2
Confirm general activity
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.
3
Compare expected vs. actual freshness
The security tool’s last-seen timestamp should match the device’s general activity. A multi-day gap is the diagnostic.
4
Triage the agent
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 can drive the remediation workflow.
Querying for silent failures
The canonical query shape, against any integration:
See Query Syntax for the verified grammar, and Continuous Actions → Broken agent recovery for an end-to-end automation example.
Best practices
Build a Continuous Action for silent failures, integration by integration
Build a Continuous Action for silent failures, integration by integration
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.
Set explicit resolution criteria
Set explicit resolution criteria
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.Track silent-failure rate over time
Track silent-failure rate over time
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 of the silent-failure population for trend visibility.
Cross-references
Security Monitoring
The Vitals model end-to-end
Vitals States
Not Functioning state definition
Vitals Configuration
Configure detection per integration
Continuous Actions
Broken agent recovery patterns
X-Ray
Investigate a single device
Query Syntax
The functioning:false grammar