Prerequisites
- Role with fingerprints.view permission for viewing policies and drift events
- Role with fingerprints.manage permission for creating/editing policies and capturing baselines
- Target hosts must be online with active agents reporting heartbeats
- At least one organization configured in your account
Creating a fingerprint policy
Fingerprint policies define which categories of host state to monitor and how frequently to check for changes. Each organization can have one default policy.
- Navigate to Fingerprints > Policies
- Click Create Policy
- Select the target organization
- Choose categories to monitor from the 18 available, grouped by tier (see category reference below)
- Optionally override the default severity for individual categories
- Set the check interval (default: 24 hours)
- Set the drift alert severity (default: warning)
- Optionally attach custom fingerprint scripts for application-tier checks
- Toggle Set as default if this should be the org-wide policy
- Click Save
One default per org
Only one policy can be marked as default per organization. Setting a new default automatically clears the flag on the previous one.
Fingerprint category reference
Categories are grouped into three tiers reflecting their operational impact when drift is detected.
Tier 1 -- Critical
| Category | What it captures |
|---|---|
services | Running services, startup type, service accounts |
ports | Listening TCP/UDP ports and bound processes |
local_accounts | Local user accounts, enabled/disabled, group membership |
local_groups | Local security groups and their members |
installed_software | Installed applications with version numbers |
disk_space | Volume capacity, free space, mount points |
Tier 2 -- Medium
| Category | What it captures |
|---|---|
scheduled_tasks | Scheduled tasks / cron jobs with triggers and actions |
environment_variables | System-level environment variables |
firewall_rules | Firewall rules (iptables, Windows Firewall, pf) |
dns_config | DNS resolver configuration, search domains |
network_interfaces | Network adapters, IP addresses, MAC addresses |
startup_programs | Auto-start programs (registry Run keys, systemd, launchd) |
Tier 3 -- Informational
| Category | What it captures |
|---|---|
registry_keys | Monitored registry hives (Windows only) |
system_info | OS version, kernel, hostname, domain membership |
certificates | Installed certificates with expiry dates |
security_policies | Local security policy settings (password policy, audit policy) |
shares | Network shares and permissions |
printers | Installed printers and print queues |
Editing a fingerprint policy
- Navigate to Fingerprints > Policies
- Click the policy name to open the detail view
- Modify categories, check interval, severity, or custom scripts
- Click Save
Editing does not retroactively update baselines
If you add new categories, you must re-capture baselines on affected hosts to start tracking those categories.
Capturing a fingerprint baseline
Baselines are the known-good reference state. All subsequent captures are compared against the baseline to detect drift.
- Navigate to Fingerprints > Hosts
- Select a host from the list
- Click Capture Baseline
- The system dispatches a fingerprint check job to the agent
- Once the job completes, the baseline JSON is stored and timestamped
When to capture baselines
Capture baselines after approved build milestones, hardening completion, or major change windows. Avoid capturing baselines on hosts in an unknown or degraded state.
Each host stores one baseline at a time (unique per host). Subsequent captures replace the previous baseline and generate drift events for any differences detected.
Drift detection
When a new fingerprint capture runs against a host that already has a baseline, the system performs a per-category diff. Any differences are recorded as drift events with the following attributes:
CategoryWhich fingerprint category changed (e.g., services, ports)
TierTier level of the category (1 = critical, 2 = medium, 3 = info)
SeverityEffective severity (may be overridden per-category in the policy)
Change DetailsDiff showing exactly what was added, removed, or modified
StatusOne of: new, acknowledged, accepted, or resolved
Responding to drift events
Navigate to Fingerprints > Drift Events to review all detected changes.
- Review the drift event details: category, tier, severity, and the detailed diff
- Choose one of three response actions:
| Action | Effect | When to use |
|---|---|---|
| Acknowledge | Marks the event as reviewed. No baseline change. | You are aware of the change and investigating |
| Accept | Accepts the change as the new baseline. Updates the stored baseline data. | The change was intentional and should persist |
| Resolve | Marks drift as resolved without accepting it into the baseline | The change has been reverted or remediated |
Do not ignore drift events
Drift events left in
new status indefinitely create noise and obscure real issues. Establish a review cadence to process drift events within 24-48 hours.
Scheduled fingerprint checks
The fingerprint system runs on a background scheduler. For each policy, the system automatically dispatches fingerprint check jobs at the configured check interval.
Check IntervalHow often to re-check hosts (default: 24 hours). Shorter intervals catch drift faster but increase agent load.
Drift Alert SeveritySeverity level assigned to drift alerts (default: warning). Set to critical for high-value servers.
Scheduled checks follow the same baseline comparison flow: if a baseline exists, diffs are computed and drift events created. If no baseline exists yet, the first scheduled check becomes the baseline.
Policy configuration reference
| Field | Type | Default | Description |
|---|---|---|---|
| Organization | Selection | Required | Organization this policy applies to |
| Categories | Multi-select | All 18 | Which categories to monitor (see reference above) |
| Check Interval (hours) | Number | 24 | Hours between automated checks |
| Drift Alert Severity | Selection | warning | Severity for drift alerts: info, low, medium, warning, high, critical |
| Category Overrides | Per-category | None | Per-category severity overrides (e.g., set "services" to critical) |
| Custom Scripts | Multi-select | None | Scripts for custom application-tier fingerprint checks |
| Set as Default | Yes/No | No | Whether this is the default policy for the org |
| Enabled | Yes/No | Yes | Enable or disable the policy without deleting it |
Permissions reference
| Action | Permission |
|---|---|
| View fingerprint policies and drift events | fingerprints.view |
| Create, edit, or delete policies | fingerprints.manage |
| Capture baselines | fingerprints.manage |
| Acknowledge, accept, or resolve drift | fingerprints.manage |
Drift monitoring lifecycle
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Fingerprint capture stuck in pending | Agent offline or job not completing | Check the Jobs page for the fingerprint check job status. The host must be online. |
| Drift events showing as "new" indefinitely | No one has reviewed them | Acknowledge or accept drift events to clear them from the queue. |
| New categories not being checked | Policy updated but baseline not re-captured | Re-capture baselines on affected hosts after adding categories. |
| Scheduled checks not running | Policy is inactive or no hosts in the org | Verify the policy is enabled and that hosts have agents reporting heartbeats. |