Skip to main content
Tier: Vitals are included in the Discover and Protect tiers. Customers on Connect see device inventory but cannot configure Vitals.
Security Monitoring covers what Vitals are conceptually. This page covers how you configure them in practice.

​
The three configuration surfaces

Most users start in Configure Mode from the inventory because the workflow is “I’m staring at devices showing red — fix it.”

​
Workflow: configuring a control end-to-end

We’ll configure CrowdStrike Vitals for end-user devices.
1

Make sure End-User exists as a tag

Visit Settings → Tags. Confirm End-User has a Logic Engine rule that captures your actual end-user devices. See Tags & Logic Engine if you need to create or refine it.
2

Switch the Devices grid to Vitals view

Open /devices. In the footer, the Deployment / Vitals toggle is on the left. Click Vitals. Each integration column changes from a check / no-check to a Healthy / Functioning / Misconfigured / Not Healthy state.
3

Click the gear on the CrowdStrike column header

Each Vital column header has a small gear icon. Click it → Enter Configure Mode.
4

Set the required tags

Tick the boxes for tags this integration is required on. For CrowdStrike, you’d typically check End-User, Server, and VM, leaving BYOD and Stock unchecked. Devices in the unchecked tags will never fail this Vital.
5

Choose the configuration checks

Each integration exposes a different set of checks. For CrowdStrike, typical checks include:Tick the checks you want enforced. Unchecked = ignored.
6

Save by exiting Configure Mode

Click Exit Configure Mode. The column repaints with the new configuration applied across the estate. Devices that previously showed Healthy may now show Misconfigured if your new checks are stricter.
7

Review and iterate

Sort the column to find the unhealthy / misconfigured devices. Investigate a sample via X-Ray. If your rule is producing false positives (e.g. agents update weekly so N-2 is too strict), come back to Configure Mode and relax the check.

​
The composite states

Once configured, every device shows one of the composite Vital states (Healthy / Functioning / Misconfigured / Not Healthy / Not Required), each derived from a four-boolean model. For the canonical state table, the underlying booleans, and how composites map to query syntax, see Reference → Vitals states.

​
What “Functioning” actually measures

This is where Protect’s cross-tool model earns its keep. The functioning boolean isn’t just “the agent is installed” — it’s “the agent is doing something.” The platform computes it by comparing two timelines:
  1. The device’s general activity — most recent activity across any integration
  2. The specific tool’s activity for this device — most recent activity from just this integration
If general activity is recent (device is clearly online) but tool-specific activity is stale, the tool is Not Functioning even though it might claim Healthy in its own console. This is silent failure detection — and Protect’s core differentiator.

​
Configuration checks per integration

Each integration’s available checks come from what its API exposes. Examples:
  • Agent reporting (last seen within N days)
  • Sensor status = Online
  • Prevention policy applied (vs detection-only)
  • Agent version within N versions of current
  • No detection alerts pending
  • Real-time protection enabled
  • Tamper protection enabled
  • Cloud-delivered protection enabled
  • Signatures within N hours of current
  • Last quick scan within N days
  • No active vulnerabilities of severity ≥ N
  • Device enrolled
  • Compliance status = Compliant
  • Last check-in within N hours
  • Required app deployments succeeded
  • Configuration profiles applied
  • Device managed
  • Last check-in recent
  • Configuration profiles applied
  • Security settings enforced (FileVault enabled, Firewall on)
  • Patches up to date
  • Client deployed
  • Connected to cloud
  • Policy enforcement active
  • SSL inspection active (if required)
  • Account enabled (vs disabled)
  • Last logon within N days
  • Password not expired
  • MFA enrolled (Entra ID only)
If an integration doesn’t expose a check you need, that’s a vendor-side limitation. Open a request — the Protect engineering team adds new checks regularly as vendor APIs evolve.

​
Validation loop

After any rule change, validate:
  1. Spot-check 10 devices via X-Ray — does the new state make sense?
  2. Compare counts before / after the change in the Dashboard Integration Control panel
  3. Watch the Action Center for sudden spikes in Unresolved Devices — that suggests the rule is too strict
  4. Schedule a Scheduled Report of unhealthy devices weekly to catch regression

​
Cross-references

Security Monitoring

The conceptual model

Tags & Logic Engine

Tag the devices first

Reference → Vitals states

Canonical state table