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 and Pulse in Backoffice first.

What it is

Availability: In development.

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

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.

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:

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, the Data Processing Addendum and Sub-processors.

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.

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

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

Related

• Noxtica Pulse: endpoint telemetry overview for the whole picture.
• Pulse in Backoffice: applications, profiles, bundles and rollouts for publishing configuration.
• Webhooks and Authentication for events and keys.
• Roles and permissions for the capabilities named here.
• Privacy, Cookies and Security for data handling.