Skip to content

Security model

Tenant isolation is enforced by the database

Section titled “Tenant isolation is enforced by the database”

Every tenant-bound table has row-level security, forced, with the tenant taken from the connection context. A query that forgets a tenant filter returns nothing rather than everything.

This matters because application-level filtering fails silently the first time someone writes a query without the right WHERE clause. Here, the database refuses.

A consequence you will see: requesting an object belonging to another tenant returns 404, not 403. A 403 would confirm the object exists, which is itself a leak. From your token’s perspective the row genuinely does not exist.

What How it is held
API tokens SHA-256 hash only. The value is shown once and is unrecoverable
CA connector credentials Envelope-encrypted at rest, write-only from outside - no API reads them back
Sensor identity mTLS client certificate; the private key is generated on the sensor host and never transmitted
Bootstrap tokens Hashed, single-use, short-lived
  • Private keys of your certificates. Renewal takes a CSR. There is no endpoint that accepts a private key, and the sensor cannot see the keys of the services it scans.
  • Application data from your network. The sensor completes a TLS handshake, reads the chain, and closes. No HTTP bodies, no mail contents.
  • Your CA credentials in plaintext at rest.
Surface Mechanism
Public API Bearer token, scoped, default-deny
Sensor → ingest mTLS, TLS 1.3, client certificate from the internal CA
Sensor → registration Single-use bootstrap token
Console Passkey/WebAuthn, email magic link, or SAML SSO

The Console is passwordless-first. Passkeys are phishing-resistant in a way that passwords with TOTP are not, which matters for an account that can authorise certificate issuance.

Tenant-scoped, hash-chained and append-only: each entry links to its predecessor, and there is no update or delete path. Rewriting history breaks the chain visibly.

Signing operations of the private CA are recorded the same way.

Tenants are pinned to eu or us. Data does not replicate between regions. Pick the region at tenant creation - moving later is a migration, not a setting.

Risk What to do
Leaked API token One token per integration, rotate on staffing changes, revoke immediately on suspicion
Over-broad scopes Give certs:read unless the integration genuinely renews
Token in a log Never put it in a URL query string - headers only
Compromised approver account Enrol a passkey; the approver role authorises spending
Sensor host compromise The sensor’s identity can report certificates for its tenant. Treat the host as production infrastructure

Coordinated disclosure via nextpki.com/security. Please do not open a public issue for a security finding.