> ## 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.

# Vitals Configuration

> Define which security controls are required for which devices, and what 'configured correctly' means

<Info>
  **Tier:** Vitals are included in the **Discover** and **Protect** tiers. Customers on Connect see device inventory but cannot configure Vitals.
</Info>

[Security Monitoring](/security-monitoring) covers *what* Vitals are conceptually. This page covers *how* you configure them in practice.

## The three configuration surfaces

| Surface                      | Where                                                                             | Purpose                                                                      |
| ---------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Per-integration settings** | [Settings → Integrations](/settings/integrations) → click integration → Configure | What field values count as "Configured" for this integration                 |
| **Tag requirements**         | [Settings → Tags](/settings/tags) → tag → Logic Engine                            | Which devices the integration's checks apply to                              |
| **Inventory column gear**    | [Devices](/device-management) → column header gear → Configure Mode               | A faster path to the same per-integration settings, scoped to a Vital column |

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.

<Steps>
  <Step title="Make sure End-User exists as a tag">
    Visit [Settings → Tags](/settings/tags). Confirm `End-User` has a Logic Engine rule that captures your actual end-user devices. See [Tags & Logic Engine](/tags-and-logic-engine) if you need to create or refine it.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Click the gear on the CrowdStrike column header">
    Each Vital column header has a small gear icon. Click it → **Enter Configure Mode**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Choose the configuration checks">
    Each integration exposes a different set of checks. For CrowdStrike, typical checks include:

    | Check                          | What it validates                |
    | ------------------------------ | -------------------------------- |
    | Agent reporting in last 7 days | Functioning (not stale)          |
    | Prevention policy applied      | Not just detection-only          |
    | Sensor status = Online         | Live link to console             |
    | Agent version > N-2            | Recent enough to receive updates |

    Tick the checks you want enforced. Unchecked = ignored.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Review and iterate">
    Sort the column to find the unhealthy / misconfigured devices. Investigate a sample via [X-Ray](/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.
  </Step>
</Steps>

## 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](/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.

| Device general activity (across tools) | Tool-specific activity (e.g. CrowdStrike) | Result                                                                             |
| -------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------- |
| \< 24h (device is online)              | Tool saw it \< 24h                        | **Healthy / Functioning**                                                          |
| \< 24h (device is online)              | Tool hasn't seen it > 7 days              | **Not Functioning** — agent broken, regardless of what the tool's own console says |
| > 14 days (device is offline)          | Any                                       | No alert — device is genuinely offline / decommissioned                            |

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:

<AccordionGroup>
  <Accordion title="CrowdStrike Falcon">
    * 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
  </Accordion>

  <Accordion title="Microsoft Defender ATP">
    * 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
  </Accordion>

  <Accordion title="Microsoft Intune">
    * Device enrolled
    * Compliance status = Compliant
    * Last check-in within N hours
    * Required app deployments succeeded
    * Configuration profiles applied
  </Accordion>

  <Accordion title="JAMF Pro">
    * Device managed
    * Last check-in recent
    * Configuration profiles applied
    * Security settings enforced (FileVault enabled, Firewall on)
    * Patches up to date
  </Accordion>

  <Accordion title="ZScaler Client">
    * Client deployed
    * Connected to cloud
    * Policy enforcement active
    * SSL inspection active (if required)
  </Accordion>

  <Accordion title="Active Directory / Entra ID">
    * Account enabled (vs disabled)
    * Last logon within N days
    * Password not expired
    * MFA enrolled (Entra ID only)
  </Accordion>
</AccordionGroup>

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](/platform-overview#dashboard) Integration Control panel
3. **Watch the [Action Center](/automation)** for sudden spikes in Unresolved Devices — that suggests the rule is too strict
4. **Schedule a [Scheduled Report](/scheduled-reports)** of unhealthy devices weekly to catch regression

## Cross-references

<CardGroup cols={3}>
  <Card title="Security Monitoring" icon="shield-halved" href="/security-monitoring">
    The conceptual model
  </Card>

  <Card title="Tags & Logic Engine" icon="tag" href="/tags-and-logic-engine">
    Tag the devices first
  </Card>

  <Card title="Reference → Vitals states" icon="book" href="/reference/vitals-states">
    Canonical state table
  </Card>
</CardGroup>