Tier: Vitals (Agent Functioning Detection + Configuration Monitoring) is included in the Discover and Protect tiers. Customers on Connect see device inventory but not Vitals — talk to your account team about upgrading.
What “Vitals” means in Protect
Vitals is the term Protect uses for continuous, per-device validation of security controls. Each Vital is a single integration’s view of a single device, classified into composite states such as Healthy, Functioning, Misconfigured, Not Healthy, and Not Required. The canonical definitions and underlying four-boolean model live at Reference → Vitals states. Vitals fire continuously — every integration sync recomputes the state. There’s no manual refresh.
Why Vitals matters
Traditional posture monitoring stops at “is the agent installed?” That’s the bare minimum and it misses the most common failure mode in security: Endpoint Detection and Response (EDR) agents that look healthy in their own console but stopped protecting weeks ago.
The single-tool console can’t tell you the agent is broken because it doesn’t have a reference frame. Protect does — by comparing the agent’s own activity timeline against the device’s activity timeline across all other tools. If Intune saw the device this morning but CrowdStrike hasn’t seen it in 12 days, that’s the diagnosis.
This is called silent failure detection and it’s the single most-cited reason customers describe Protect as different.
The three stages
1. Deployment
Is the control present on this device at all? Computed by comparing the device’s presence in identity/management sources against its presence in the security tool.
2. Function
Is the control actively working? Computed from the freshness of the security tool’s per-device data versus the device’s general activity. Stale tool data on an active device = broken.
3. Configuration
Is the control configured per your policy? Driven by the configuration checks you defined in Vitals Configuration.
Tag-scoped requirements
Not every device needs every control. A server doesn’t need Mobile Device Management (MDM). A stock laptop doesn’t need anything yet because it isn’t deployed. Vitals respect this via Tags:
A device’s tags decide what’s required of it. A device only fails Vitals against the controls its tags require. Get the tags right and Vitals are quiet by default — alerts are exclusively meaningful gaps.
The two grid modes
In Devices, the footer toggle switches between two integration-column views:
Start in Deployment to confirm coverage, switch to Vitals to find what’s actually broken.
Dashboard integration health
The Dashboard’s Integration Control panel renders Vitals at portfolio level. Each card shows:- Integration name + icon
- Health percentage (e.g.
80% Healthy) - Device counts (e.g.
707 / 877) - Trend arrow vs last period (e.g.
↗ 5.7%) - Donut chart visualising the split
What controls Protect monitors
Protect can compute Vitals on any integration that exposes:- A per-device data feed (so we can compute Deployment + Function)
- Configuration / policy fields (so we can compute Configuration)
Vitals are per-device — they validate device-side security controls. Identity providers (Microsoft Entra ID, Okta, Duo, on-premises Active Directory) are used to enrich device records and provide last-user attribution; they aren’t Vital integrations themselves.
If your integration is in the Integrations directory but isn’t listed above, check whether Vitals can apply — open a ticket if you need confirmation. New categories are added regularly.
Configuration approach: declarative
Vitals are configured declaratively:End-User tag continuously. There’s no scheduled scan, no waiting for a job. As soon as a device’s underlying data changes (next sync), its Vital state recomputes.
This is the opposite of imperative monitoring (write a Python script, schedule it nightly, hope it runs). It also means changes propagate fast — relax a rule and the green count jumps; tighten one and you’ll see the new gaps within the hour.
The Vitals lifecycle
Common misconfigurations to avoid
No grace period for new devices
No grace period for new devices
Newly-discovered devices instantly fail Vitals before deployment finishes. Use a
Stock tag (or similar) for not-yet-deployed devices where no Vitals are required, and move them out only when baseline is complete.Too-tight Function thresholds
Too-tight Function thresholds
Some agents update weekly. Requiring “seen in last 24 hours” produces false positives on healthy devices. 7 days is a reasonable default; tune per integration.
Configuration checks the API can't validate
Configuration checks the API can't validate
If an integration’s API doesn’t expose a field, Protect can’t check it. Don’t add a configuration check expecting silent success — it’ll either be absent from the picker or always fail.
Cross-references
Vitals Configuration
Step-by-step setup
Tags & Logic Engine
Define scope per control
Reference → Vitals states
Canonical state table
Issues
The operational queue Vitals feeds
Action Center
Auto-remediate unhealthy states
X-Ray
Root-cause any unhealthy device