Security

What Nyxus holds, where it holds it, who can sign in, and what it is honest about not doing. Written so a security review can be answered from one page, and so the awkward parts are here rather than discovered later.

What is held, and where

Findings do not live in Nyxus. They are written to your log store — a Loki tenant you run — and Nyxus reads them back. Nothing about a finding is kept in the receiver's own database.

The receiver's database holds decisions, credential hashes and the integration secrets it has to present outward: central settings, governance decisions, registry entries you added, the discovery queue and the audit trail. Never a finding.

A finding carries a tool name, a surface, an operating system, a device identifier, a username or an account domain, and the evidence that produced it. It deliberately excludes message content, file content and credentials. The aggregate is still sensitive: it is a map of who uses what, on which machine. Treat the log store accordingly.

How long things are kept

Findings are kept for as long as your log store keeps them. Nyxus does not age them out and cannot: they are not its data. Set a retention window there and the dashboards follow it.

Estate history — a snapshot per finished day, the changes between them, and the first and last day each thing was observed — is kept by the receiver for 400 days by default, and is configurable.

The audit trail is never deleted.

Encryption at rest

Backups are encrypted with AES-256-GCM under a key you generate and keep outside the cluster. Nothing is backed up without one. The consequence runs both ways and is worth stating: without that key no backup can be opened, and anyone holding both the backup and the key can open it.

Portal passwords are stored as scrypt hashes with a per-password salt. Bearer tokens and API tokens are stored as SHA-256 hashes, never in the clear.

The receiver's database is ordinary SQLite on a volume you provide. Nyxus does not encrypt the file itself, so encryption at rest for that volume is whatever your storage class gives you. Most clusters encrypt volumes by default; confirm yours does.

One exception, stated plainly: an API key you save for vendor seat sync is held so the sync can present it, which means it is stored in a form the receiver can read. It is masked in every read but the sync call itself. If that is not acceptable, leave the vendor connections unset and import seats by CSV instead — every figure works the same either way.

Signing in to the portal

Three arrangements, and a deployment picks one.

Local accounts. Username and password, scrypt-hashed. The first owner account is created from a one-time setup code the receiver prints to its log on a fresh install, and stops printing once an account exists.

Single sign-on. OpenID Connect with PKCE, set up step by step against Microsoft Entra. It stays off until a test sign-in works, so a misconfiguration cannot lock you out. Where one deployment serves several companies, each signs in through its own provider.

No portal authentication. For a deployment behind something that already authenticates — a reverse proxy doing OIDC or mTLS. The portal warns on every start in this mode, because it shows which people use which AI tools on which machines and is wrong on anything reachable.

Reading the API uses separate bearer tokens, which are scoped to read and can be revoked individually.

The audit trail

Every action that changes the deployment is recorded: accounts created, access granted and revoked, API tokens made and revoked, break-glass sign-ins, governance decisions, budget changes, backups, exports. More than a hundred distinct kinds of event.

Three things about it are deliberate. Entries carry identifiers and never secrets, enforced where the entry is written rather than by convention. Nothing in the product deletes from it. And it exports as CSV, capped at twenty thousand rows, because a truncated export that looks complete is worse than no export at all.

A team-viewer account is auditor-shaped: it can read the trail and change nothing.

What this is honest about not doing

Collectors authenticate to the receiver with a single shared bearer token, distributed through your MDM. That is a simplicity trade-off with consequences worth accepting before you deploy: any holder of the token can submit findings, including false ones, and the receiver validates shape rather than truth. Enrollment tokens are per-rollout and can be revoked one rollout at a time, which is the lever to use when this matters.

There is no SOC 2 report and no ISO certification. Nyxus is a small product and says so rather than implying otherwise.

Reporting a vulnerability

Email support@nyxus.co.uk with "security" in the subject. It is read before anything else in that mailbox.

Tell us what you did, what happened and what you expected. A proof of concept helps and is never required — a clear description of the fault is worth more than an exploit we cannot reproduce. If a fix needs coordinating with a release, say so and we will agree the timing with you rather than publish around you.

No PGP key is published. If something should not sit in a mailbox in the clear, send a first mail with no detail in it and we will agree a channel.