Security you can verify.

You decide where the workspace runs

Sovereign Workspace supports two deployment models. The software architecture remains the same; the main difference is who operates it.

Self-hosted

Run Sovereign Workspace on infrastructure you choose — your own hardware or a cloud provider that meets your requirements.

For a self-hosted deployment, Sovereign Workspace does not operate the infrastructure and does not receive product telemetry.

Managed

Sovereign Workspace operates the deployment for you. Today managed hosting is available for swCollab only.

Your organisation retains ownership of its data while Sovereign Workspace operates the infrastructure required to provide the service.

Administrative access does not have to mean content access

Traditional infrastructure administration and access to business content are separate concerns. Sovereign Workspace therefore distinguishes between ordinary permission-controlled spaces and spaces protected by additional cryptographic controls.

Standard Spaces

Access is controlled through identity, membership and permissions.

These spaces are suitable for normal business information.

An administrator with sufficient database or infrastructure access may technically be able to access Standard Space content.

Restricted Spaces

Files in Restricted Spaces are encrypted with their own key, and Restricted content is left out of the search index. Search finds Restricted pages by their title only. The server holds the key and decrypts content for authorised users, so an administrator with sufficient database or infrastructure access may technically be able to access Restricted Space content.

Sealed Spaces

For highly sensitive information, Sealed Spaces are designed so that the encryption key never leaves the user’s browser.

Because the server operator does not possess the content key, infrastructure-level administrative access alone is not sufficient to decrypt Sealed Space content.

1. Identity
2. Workspace membership
3. Resource permission
4. Encryption key (protected spaces)
5. Content access

One identity. Central control.

Users authenticate through a central identity layer. Organisations can use Sovereign Workspace identity management or integrate an existing identity provider.

Create a user once and grant the required access. Disable that identity when the person leaves and their workspace access is removed centrally.

• OIDC
• SAML
• Active Directory integration where supported
• WebAuthn / FIDO2
• Passkeys
• Hardware security keys
• Argon2id password hashing
• Short-lived access tokens

Identity platform: Keycloak

Encryption and key boundaries

Data in transit

• Connections use HTTPS. Plain HTTP is redirected to HTTPS.
• TLS is terminated by the web server on the host.
• Minimum TLS version: TLS 1.2. TLS 1.2 and TLS 1.3 are enabled.
• Certificates: Let’s Encrypt, a local certificate authority, or your own certificates.
• Traffic between services on the same host runs over the internal container network without TLS. The services listen only on the local interface.

No product telemetry

Sovereign Workspace does not collect product usage analytics, crash reports or behavioural telemetry from a running deployment.

No runtime licence dependency

The application does not require a continuous connection to a Sovereign Workspace licence server in order for an existing deployment to operate.

No mandatory hyperscaler dependency

The core Sovereign Workspace platform can operate without relying on a specific hyperscale cloud provider.

This gives organisations freedom to select infrastructure based on their own requirements for jurisdiction, cost, availability and operational control.

The core platform does not require a US cloud service to operate.

Code review

Enterprise customers with high security requirements can arrange to review the source code for the software they run.

The purpose of source review is security assessment and audit. It does not grant redistribution rights.

Architectural independence

Several important properties do not depend on source-code access.

• Self-hosting is available. The core platform can run on infrastructure you choose.
• No product telemetry is sent to Sovereign Workspace.
• The core platform does not require a US cloud service to operate.
• No licence-server dependency. An existing deployment does not require a continuous connection to Sovereign Workspace merely to remain operational.

Audit logs and history

Sovereign Workspace records security-relevant administrative activity so organisations can investigate changes and integrate relevant events with their existing monitoring processes.

Current verified events include:

• authentication events
• administrative actions
• policy changes

Each event records:

• timestamp
• actor
• action
• target

Content history includes:

• page versions
• file versions
• immutable baselines where supported

Export:

• CSV
• JSON

Your backups do not depend on a proprietary format

Self-hosted deployments store application data in PostgreSQL and object storage, allowing organisations to use familiar backup tools and processes rather than a proprietary export format.

Self-hosted

The customer is responsible for its own backup and recovery strategy.

Compatible tooling can include PostgreSQL-native and filesystem/object-storage backup tooling.

Security updates and vulnerability reporting

Self-hosted deployments receive updates through the installer’s update mode.

Security issues can be reported to hello@sovereignworkspace.org.

Software supply chain

• Dependency pinning with lockfiles
• Automated dependency scanning
• Container-image scanning

Leaving Sovereign Workspace

Sovereignty includes the ability to leave.

For self-hosted deployments, your application data is already stored in your environment using standard PostgreSQL and object-storage technologies.

There is no proprietary export fee required simply to access your own data.

What happens if our relationship ends?

For self-hosted deployments, the customer’s data already resides in infrastructure it controls.

Where the licence permits continued operation without an active licence-server connection, the existing deployment does not depend on Sovereign Workspace being continuously reachable.

Data remains in standard storage technologies that can be backed up and migrated using established tooling.

FAQ

Where can our data be hosted?

Self-hosted: on infrastructure you choose, your own hardware or a cloud provider that meets your requirements. Managed (swCollab only today): Sovereign Workspace operates the deployment for you.

Can Sovereign Workspace staff read our content?

In a self-hosted deployment, Sovereign Workspace does not operate the infrastructure. In a managed deployment, Sovereign Workspace operates the infrastructure, so staff with sufficient infrastructure access may technically be able to access Standard and Restricted Space content. Sealed Spaces are designed so that the encryption key never leaves the user’s browser. Sealed Spaces are available only when you self-host.

Can our administrators read everything?

An administrator with sufficient database or infrastructure access may technically be able to access Standard and Restricted Space content. Infrastructure-level administrative access alone is not sufficient to decrypt Sealed Space content.

Do you collect telemetry?

No. Sovereign Workspace does not collect product usage analytics, crash reports or behavioural telemetry from a running deployment.

Does the system require internet access?

Not to stay operational. Some features make outbound connections depending on configuration: email delivery, an external AI provider if one is configured, webhooks and automations, link previews if enabled, websites that users open, and certificate issuance.

Does it require AWS, Azure or Google Cloud?

No. The core platform has no mandatory hyperscaler dependency.

Can we use our existing identity provider?

Yes, through OIDC or SAML. The identity platform is Keycloak.

Can we review the source code?

Enterprise customers with high security requirements can arrange to review the source code for the software they run. The purpose of source review is security assessment and audit. It does not grant redistribution rights.

What security logs are available?

Authentication events, administrative actions and policy changes are recorded with timestamp, actor, action and target. Logs can be exported as CSV and JSON.

How are backups handled?

Self-hosted: the customer is responsible for its own backup and recovery strategy. Application data is stored in PostgreSQL and object storage, so familiar backup tools and processes work. Managed: ask us about the backup arrangement.

What happens if we leave?

For self-hosted deployments, your application data is already stored in your environment using standard PostgreSQL and object-storage technologies. There is no proprietary export fee required simply to access your own data.

Which security certifications do you have?

We currently hold no security certifications. The current product supports self-hosted deployment, managed hosting for swCollab, source-code review for eligible enterprise customers, security-relevant audit logging, and customer-controlled deployment choices.

How do we report a vulnerability?

Email hello@sovereignworkspace.org.