This guide collects the technical security details an IT team typically asks about: how credentials are stored, how each integration authenticates, how traffic is encrypted, and where the platform is hosted.

Credentials at rest

Every integration's credentials are stored encrypted in the database with AES-256-GCM (per-record IV and authentication tag). The encryption key lives in a cluster secret and is never written to a database row. Decryption happens only inside the running pods at the moment a credential is needed for an API call.

Per-integration authentication

Each integration authenticates against its vendor with whatever scheme that vendor expects. There is no shared secret across integrations — a leaked credential for one provider has no effect on any other.

1. IWMAC: a JSON-RPC token endpoint exchanges your Client ID + Client Key for a short-lived bearer token.
2. Airthings: OAuth 2.0 client-credentials grant — Client ID + Client Secret exchanged for a scoped access token.
3. Disruptive Technologies: HTTP Basic authentication using a Service Account Key ID + Secret.
4. Niagara N4 (MQTT): MQTT broker authentication with a dedicated username and password tied to the platform.

Encryption in transit

Inbound traffic to the Arcturus dashboard at relog-arcturus.eu terminates TLS at our nginx ingress with certificates issued by Let's Encrypt and HTTPS redirect forced. Outbound calls to vendor APIs go over HTTPS to the vendor endpoints; the negotiated TLS version is whatever the vendor offers. For Niagara MQTT we recommend the broker is configured for TLS — see the Niagara guide.

Hosting and data residency

The Arcturus platform runs in a European data centre (Amsterdam region). All operational telemetry and configuration is stored in databases that run in-cluster alongside the services, so data does not leave that region. We have not yet published a formal retention / DPIA policy — if your IT team needs one for audit purposes, open the assistant and we will start that conversation.