Enrolment

Enrolment is the moment a fresh appliance becomes a trusted member of the fleet. It involves three parties: the appliance, the central plane, and the operator (you or us, depending on how the unit was ordered).

Token flow

1. We mint an enrolment token — single-use, bound to your tenant, valid for 48 hours by default (we can extend the validity when we mint it).
2. The token is delivered out-of-band — typically emailed to the named contact.
3. During the first-boot wizard the token is entered on the appliance console. The appliance's fleet agent exchanges it for a short-lived, fleet-signed client certificate and its appliance identity.

appliance                                central plane
    |                                         |
    | POST /v1/appliances/enrol               |
    | { enrolment_token, display_name,        |
    |   hardware, audit_pubkey }              |
    |---------------------------------------->|
    |                                         | verify token (single-use,
    |                                         |   tenant-bound, unexpired)
    |                                         | issue client certificate
    |                                         |
    | 200 OK                                  |
    | { appliance_id, client_cert_pem,        |
    |   client_cert_key_pem, cert_expires_at, |
    |   opa_bundle_url, region, tenant_id }   |
    |<----------------------------------------|
    |                                         |

The token is consumed atomically — a second attempt with the same token is refused, and an expired or unknown token is rejected before anything is provisioned.

What we pin at enrolment

• mTLS identity. The appliance's client certificate is issued by the fleet CA at enrolment and delivered to the appliance over the enrolment TLS channel, then stored on the appliance's encrypted disk. Every subsequent call to the central plane (heartbeats, config pulls, cert renewal) authenticates with it. On-appliance key generation with a CSR — so the private key never crosses the wire even once — is on our roadmap; today the key is generated centrally at issuance and never persisted by the central plane.
• Audit signing key. Generated on the appliance at provisioning time; only the public half is sent at enrolment. The private key never leaves the appliance — it signs the tamper-evident audit chain, and the central plane can only verify, never forge, your audit trail.
• Tenant ID. Immutable — an appliance can belong to exactly one tenant for life.
• Region. EU, KSA, or UAE — determines which central-plane region the appliance talks to.
• Hardware profile. CPU, RAM, disk, GPU, and TPM presence are recorded at enrolment and cross-checked against subsequent host-profile reports so an unexpected change is detected and surfaced.

Rotating

Client certificates are short-lived by design. Inside the renewal window the appliance calls the fleet's renew endpoint over its current mTLS identity and receives a fresh certificate — routine rotation needs no human involvement. If a certificate expires entirely, or after a suspected compromise, we require a fresh enrolment ceremony with a newly minted token and administrative access to the appliance. That is deliberate.