Security & Sovereignty

Sovereign by architecture, not by promise.

Your workloads, application data and control plane remain within infrastructure under your control. Here is how sCloud and sAxess PRO keep it that way — layer by layer.

Request a security review See the architecture

The sovereignty boundary

What stays inside infrastructure you control — all of it.

Workloads, application data, the control plane, identities, keys and audit logs all run on your servers, in your data centre.
sCloud needs no connection to Serenity to operate. It runs fully air-gapped.
Serenity has no standing access. Support sessions happen only when you open them, and are recorded in your audit log.
No telemetry is required. Anything you choose to share with support is exported by you.

Identity, SSO & access control

sCloud Identity: one passwordless sign-in for the platform and your applications.

Built-in SSO for the console, API, CLI and your own applications over OpenID Connect and SAML.
Passwordless by default: the sAxess PRO Card is the primary method, with any FIDO2 / WebAuthn authenticator also supported.
Federates with your existing directory so joiners, movers and leavers stay in one place.
Role-based access per organisation and project, with quotas — least privilege is the default, not a setting.

Privileged access & critical actions

sAxess PRO: biometric step-up and cryptographic authorisation for what matters most.

You define which actions are critical: admin access, IAM changes, production deletion, backup and data export, security-policy changes, key and secret operations.
A critical action is held until it is signed on a sAxess PRO Card. The fingerprint is matched on the card; the private key never leaves its secure element.
The signature covers the action's exact details, so an approval cannot be replayed for a different action.
M-of-N policies require several named people — each on their own card — for exceptionally sensitive actions.
The rule applies to every interface: console, API, CLI and Terraform. There is no side door.

Encryption in transit and at rest

Encrypted on the wire and on disk, by default.

TLS protects the console, the API and traffic between control-plane services.
Volumes, object storage and database backups are encrypted at rest.
Encryption is on by default for new resources; it is not a premium option.

Key ownership

Your keys are generated, stored and used inside your boundary.

Encryption keys are created and held in your environment. Serenity never holds a copy.
Root keys can be anchored in your own HSM or KMS.
Reading, rotating or destroying a key can be made a critical action that requires sAxess PRO approval.

Secrets management

A built-in secrets store for platform and application credentials.

Applications and Kubernetes clusters receive secrets at runtime, rather than from code or images.
Secrets are encrypted at rest; every read and change is audited.
Access follows project roles, so a team can only reach its own secrets.

Audit architecture

Who did what, when — and who authorised it.

Every console action and API call is recorded with the identity behind it.
Critical actions carry the sAxess PRO signatures that approved them, so approvals can be verified independently.
The audit log is append-only and streams to your SIEM in real time.

Tenant isolation

No path between projects unless you create one.

Each project gets its own private networks. Traffic between projects is denied by default.
Managed Kubernetes gives each team a dedicated cluster, not a namespace on a shared one.
Quotas stop one tenant from starving the others of compute or storage.

Signed updates & air-gapped delivery

Nothing is installed unless Serenity signed it and you imported it.

Every release bundle is cryptographically signed by Serenity; sCloud verifies the signature before installing.
Air-gapped sites import bundles on offline media — no route to the internet needed, ever.
Upgrades roll server by server inside your change window. Applying them can be made a critical action.

Vulnerability management

Defined patch times, written into your support plan.

Security advisories are published to customers with a severity rating and the affected versions.
Patch times for vulnerabilities are committed by severity in your support plan.
Fixes ship as signed bundles, so air-gapped sites are patched the same way as connected ones.

Backup & disaster recovery

Recover a database, a project or the platform itself.

Managed databases have automated backups and point-in-time recovery.
Volumes and object storage can be snapshotted and replicated to a second site that you own.
The control plane is backed up and can be restored, including into a recovery site.
Restoring or exporting data can require sAxess PRO approval, so backups cannot become an exfiltration route.

High availability

No single server failure takes the platform down.

Control-plane services run replicated across several servers.
VMs on a failed host restart on healthy ones; live migration empties a host for planned maintenance.
Managed databases support replicas for failover.

Need the detail for your assessment?

We share the security whitepaper, the architecture documents and the answers to your questionnaire under NDA, and walk your security team through them on a call.

Talk to our security team