---
title: "Pulse detections, response, devices and privacy"
description: "Review Pulse detections with a person in the loop, answer appeals, set the response ladder, manage devices and attestation, read the privacy page, and use the tenant API and webhooks."
canonical_url: "https://noxtica.com/docs/pulse/detections-and-privacy/"
markdown_url: "https://noxtica.com/docs/pulse/detections-and-privacy/index.md"
last_updated: 2026-10-27
published: 2026-10-27
section: "hunter-pulse"
section_title: "Hunter & Pulse"
site: "Noxtica"
language: "en"
source: markdown
---

# Pulse detections, response, devices and privacy

This page covers the Backoffice pages you use once devices report: Detections, Response, Devices, Privacy and Usage, plus the server API and webhook events that connect Pulse to your own account system. A detection is an indicator that a person reviews. It is never a verdict.

Administrators and reviewers use it. Read [Noxtica Pulse: endpoint telemetry overview](https://noxtica.com/docs/pulse/overview/) and [Pulse in Backoffice](https://noxtica.com/docs/pulse/backoffice/) first.

## What it is

Availability: In development.

| Page | What it holds | Role |
| --- | --- | --- |
| Detections | Detections, Appeals, Suppressions and the Review policy | Read: viewer. Per-device evidence: analyst. Review and policy changes: administrator. |
| Response | The response profile (ladder) and the audit of response decisions | Read: viewer. Edit and reverse: administrator. |
| Devices | Enrolled devices, attestation and the attestation policy | Read: viewer. Revoke and policy changes: administrator. |
| Privacy | What the server accepts per application, retention, what Pulse never collects, export and deletion requests | Read-only for everyone; change settings in the profile editor |
| Usage | Meters per UTC day | Viewer |

Writes need step-up MFA and are audited. Opening a detection or a response decision shows per-device evidence, needs the analyst role, and every access is recorded.

### Human review is the default

Under the review policy that applies by default, a detection is an indicator only. No adverse action, such as suspending a session or blocking a device, is permitted until a person confirms the detection in Backoffice. Open, under-review, dismissed, overturned and suppressed detections can never ground an adverse action. The decision stays yours as the controller.

You can switch human review off, but only with a recorded policy reference. Do not do so without your own legal sign-off. Backoffice warns that letting automated actions run on unreviewed detections is solely automated decision-making and needs a legal basis, safeguards and a way to contest.

### Evidence tiers

| Tier | Meaning |
| --- | --- |
| Tier 0 · signal only | Only the fact that the rule fired. No evidence fields. |
| Tier 1 · indicators | A small, fixed set of indicator fields, such as a tool class or a module name |
| Tier 2 · case bundle | Attached on the server after a documented review. Rules cannot request it. |

## Prerequisites

- Pulse provisioned for your organisation, and an application with a published profile that contains detection rules. Until a rule fires on an enrolled device, Detections is empty.
- Administrator role to review, set policy, edit the response profile or revoke a device. Analyst role to open per-device evidence.
- For the server API: a server API key with `read:pulse` or `write:pulse`.
- For response: the Response module enabled for your workspace, and acceptance of the response addendum by an administrator.

## Steps

### 1. Review a detection

Backoffice → Noxtica Pulse → Detections → **Detections**. Filter by severity, status, reason code, device reference, device-owner pseudonym, appeal state and dates. Open a row.

The detail page shows what was detected, why it fired, the evidence fields that were stored (allow-listed fields only), the bundle revision, the audit trail and any appeals. Press **Start review**, then **Confirm detection** or **Dismiss detection**. A **Reviewer note** is required to confirm or dismiss and is recorded in the audit trail.

Statuses: Open, Under review, Confirmed by a reviewer, Dismissed, Overturned on appeal, Suppressed.

### 2. Answer appeals

Device owners file appeals from their own Pulse privacy page. On the **Appeals** tab, filter by state (Appeal open, Appeal under review, accepted, rejected, withdrawn) and press **Resolve**.

- **Accept the appeal — overturn the detection** overturns it and creates a suppression, so later detections of the same rule are recorded as suppressed.
- **Reject the appeal — uphold the detection** keeps the detection.

Enter a **Reason for the decision**. It is recorded in the audit trail and shown to the device owner.

### 3. Manage suppressions

On the **Suppressions** tab, **New suppression** covers a known-good tool. Choose the scope: this rule on one device, this rule for one device owner, or this rule everywhere. A rule-wide suppression silences the rule for every device in the workspace, so prefer the device scope. Choose an expiry (30, 90, 180 by default or 365 days, or never) and enter a reason. While a suppression is active, a matching detection raises no webhook and can never ground an adverse action. **Revoke** ends it.

### 4. Set the review policy

On the **Review policy** tab (**Human review policy**):

- **Require human review before any adverse action** is on by default. To switch it off, enter a **Policy reference** (the document or ticket that approved it, with a minimum length Backoffice states) and confirm.
- **Device owners can appeal detections** turns appeals on or off.
- **Appeal window (days)** is how long a device owner can appeal after a detection. Backoffice shows the allowed range.

### 5. Configure the response ladder

Backoffice → Noxtica Pulse → Response → **Response profile**. A response is what an enrolled device does when a rule fires. Pulse itself never ends a session, stops a process or touches the device.

| Action | Meaning |
| --- | --- |
| Notify the person | Shows a plain-language notice in the desktop app, with a link to contest it |
| Hint: end the session | Tells your application that the session may be ended. What your application does is your decision, and an adverse one needs a person. |
| Observe only | No local action; records that a step matched |
| Report | No local action; the detection is the report |

1. Press **Add a response section**. It starts switched off, in observe mode, with an empty ladder.
2. Add steps. A step selects on exactly one of a rule, a reason code or a severity, and names its actions. Steps are tried top to bottom and the earliest match decides. Set a cooldown in seconds (0 to 604800).
3. Turn on **Requires a person** on every step that can end a session while human review is required. The device then reports the step as held until a person confirms.
4. Choose a **Notice text** from the desktop app's catalogue. Free text is not possible.
5. Set the rate limits and the **Hint lifetime (seconds)**, from 60 to 86400.
6. Choose the **Mode**: Observe (dry run) or Enforce.

Enforce stays unavailable until the **Publish gate** has no blocker: the Response module is enabled, the response addendum is accepted, an observe period has run for its minimum length, at least 30 detections have been reviewed, the measured false-positive rate is at or below your threshold (at most 5%), and the kill switch is off. The platform records the observe period and the measured rate when you publish. A response section needs a minimum client version of 0.2.0 or higher.

Accept the **Response addendum** with **Review and accept**; you can withdraw it at any time, and new hints then stop at once. The **Response kill switch** stops every local response action on devices that take the published bundle, after you save and publish.

On the **Decisions** tab, each decision shows its outcome: Executed, Dry run, or Suppressed (cooldown, kill switch, rate limit) or Held (needs a person). **Reverse this hint…** ends an active hint, requires a reason and delivers the reversal by webhook. Accepting an appeal reverses an active hint automatically.

### 6. Manage devices and attestation

Backoffice → Noxtica Pulse → Devices lists enrolled devices with OS and architecture, client version, key protection (Hardware key, OS key store or Software key), attestation level, "clone suspected", account link and last seen. Accounts, e-mail addresses and global device identifiers are never shown.

The key fingerprint is a one-way identifier of the device key that is specific to your organisation, so the same machine shows a different value in every tenant. Its first 16 of 43 characters are shown; copy the full value with the copy button. A device user can compare it with the value printed by `pulse-ctl device` on the machine.

**Revoke** stops a device being accepted right away; it must enrol again to resume. This cannot be undone. It frees the device's seat.

Attestation levels:

| Level | Meaning |
| --- | --- |
| L0 | Software key. Nothing about the platform is verified. |
| L1 | The device reports an OS key store or hardware key, but the server could not verify platform evidence. |
| L2 | Hardware-backed key. The server verified the platform-reported key attributes. This is not a TPM quote. |
| L3 | A fresh TPM quote of PCR 0 and PCR 7 matched an allowed PCR set of your attestation policy, the device key was certified by the same TPM, and the posture met the policy. The genuineness of the TPM is not verified. |

Attestation is opt-in per application. In **Attestation policy**, press **Enable attestation**, add allowed PCR sets (up to 16, each a sha256 value for PCR 0 and PCR 7 read on a machine you trust), set the posture requirements (Secure Boot, kernel lockdown, IMA, dm-verity) and the maximum age of a statement, then **Save policy**. **Use strict template** requires Secure Boot and kernel lockdown at least integrity. In the current build, TPM statements are collected on Linux only.

### 7. Read the privacy page

Backoffice → Noxtica Pulse → Privacy shows, per application, what the server accepts under its current revision: data classes, which are always collected, which are optional for the player, the required consent version, pseudonymisation and the kill-switch state. A retention table shows your requested days, the applied days and the plan maximum per kind of data. Backoffice marks the default retention periods as provisional.

Change these settings in the profile editor and publish a new revision. The page lists what Pulse never collects, which the client discards before queueing, the server rejects in a configuration and ingest strips. Among them: microphone, camera or any audio or video; browser history, URLs and cookies; the clipboard; credentials or tokens of any kind; file contents; keystrokes and input streams; screen or window contents and window titles; e-mail addresses, contacts and user identity; and environment variable values. No profile setting switches these on.

Players export their data and delete their Pulse account themselves in the Pulse privacy centre; you do not have to run either. Per Backoffice, a deletion cuts the player's devices off at once, erases their detections, appeals and suppressions, deletes their telemetry from the warehouse and records a certificate. For how Noxtica handles data, see [Privacy](https://noxtica.com/privacy/), the [Data Processing Addendum](https://noxtica.com/dpa/) and [Sub-processors](https://noxtica.com/subprocessors/).

### 8. Check usage

Backoffice → Noxtica Pulse → Usage shows, for a month and per UTC day, the counters the ingestion service accepted: enrolled devices, active devices per day, events, metric data points, log volume, crash reports and detections.

### 9. Link players to your accounts with the server API (optional)

Calls go to `https://pulse.noxtica.com` with `Authorization: Bearer sk_prod_your_server_key`. The key needs `read:pulse` or `write:pulse`; create it in Backoffice → Integrations & API → API & SDK. These routes are separate from the `/v1` API. Limits: 300 requests per minute per IP and 120 per key.

| Method and path | Scope | Purpose |
| --- | --- | --- |
| `POST /pulse/v1/tenant/link-codes` | `write:pulse` | Issue a one-time link code for one of your users |
| `GET /pulse/v1/tenant/subjects/{subject}` | `read:pulse` | Status of one player: enrolled or not, attestation level, last seen, open detections |
| `GET /pulse/v1/tenant/links/{subject}` | `read:pulse` | Read one link |
| `DELETE /pulse/v1/tenant/links/{subject}` | `write:pulse` | Unlink |
| `GET /pulse/v1/tenant/decisions` and `/decisions/{id}` | `read:pulse` | Read response decisions |
| `POST /pulse/v1/tenant/decisions/{id}/reverse` | `write:pulse` | Reverse an active hint |

```bash
curl -sS -X POST https://pulse.noxtica.com/pulse/v1/tenant/link-codes \
  -H "Authorization: Bearer sk_prod_your_server_key" \
  -H "Content-Type: application/json" \
  -d '{"externalUserId":"cust_example","appId":"<application-id>"}'
```

The response carries a `url` to hand to that person. The code is valid for 10 minutes, single use, and shown once. At most 5 unused codes exist per application and user, and 30 codes per key per minute. The person opens the address signed in to their Pulse account, sees what your organisation will see and approves or denies. The link is the consent record. A subject can be a pseudonym (`psub_…`), a link subject (`plnk_…`) or your own user id; the answer carries no account e-mail or device identifier. See [Authentication](https://noxtica.com/docs/api/authentication/) and [Errors](https://noxtica.com/docs/api/errors/).

Webhook events you can subscribe to, per endpoint: `pulse.detection.v1`, `pulse.enrolment.linked.v1` and `pulse.response.v1`. Delivery is at least once, so deduplicate by `deliveryId`. See [Webhooks](https://noxtica.com/docs/api/webhooks/).

## Verify it works

- A detection opened by an analyst shows "Evidence (allow-listed fields only)" and an audit trail entry for your access.
- After **Confirm detection**, its status is "Confirmed by a reviewer" and the gate reads "Permitted: a reviewer confirmed this detection."
- After you accept an appeal, the status is "Overturned on appeal" and a suppression appears on the Suppressions tab.
- The Response publish gate shows "Enforce is available" only when no blocker remains.
- A revoked device shows status Revoked and its seat is free.
- A link-code request returns `201` with a `url`.

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| "No detections" | No rule has fired on an enrolled device yet | Publish a profile with rules and wait for devices to report. |
| "Reviewing, confirming and dismissing detections needs the administrator role." | Role | Ask an administrator. |
| "Enter the reason for your decision." | A note is required | Fill the reviewer note. |
| "Enter the approved policy reference" when switching review off | Reference too short | Enter the approved document or ticket reference. |
| "Enforce is blocked" with a list of blockers | Addendum, entitlement, observe period, reviewed sample or false-positive rate | Work through each blocker shown under "Why enforce is blocked". |
| "The response addendum text … has not been approved yet" | The addendum text is not available to accept | Ask your account team. |
| "This step can end a session. While human review is required … switch on Requires a person" | Article 22 safeguard | Turn on **Requires a person** for that step. |
| "This hint is no longer active" | It expired or was reversed | Reload to see its current state. |
| Attestation stays below L3 | No policy, PCR values not in the policy, a stale statement, no TPM, or an unsupported platform | Open attestation details for the reason code and fix the policy or the device. |
| Server API `401 missing_api_key` or `invalid_api_key` | Key missing, unknown, revoked or wrong environment | Send a valid server API key. |
| Server API `403 insufficient_scope` or `tenant_not_armed` | Key lacks the scope, or the workspace is not armed | Create a key with the scope; ask your account team. |
| `404 subject_not_found` | Unknown subject, or an unlinked link | Check the identifier and link state. |
| `409 ambiguous_subject` | One user id is linked in several applications | Add `?appId=`. |
| `409 external_user_already_linked` | That user already has an active link in the application | Unlink it first. |
| `429 too_many_outstanding_codes` or `rate_limited` | Too many unused codes or requests | Wait; use a code that is already issued. |

## Related

- [Noxtica Pulse: endpoint telemetry overview](https://noxtica.com/docs/pulse/overview/) for the whole picture.
- [Pulse in Backoffice: applications, profiles, bundles and rollouts](https://noxtica.com/docs/pulse/backoffice/) for publishing configuration.
- [Webhooks](https://noxtica.com/docs/api/webhooks/) and [Authentication](https://noxtica.com/docs/api/authentication/) for events and keys.
- [Roles and permissions](https://noxtica.com/docs/security/roles-and-permissions/) for the capabilities named here.
- [Privacy](https://noxtica.com/privacy/), [Cookies](https://noxtica.com/cookies/) and [Security](https://noxtica.com/docs/security/) for data handling.