Sovereign Deployment

You operate the infrastructure. You hold the root of trust.

Sovereign Deployment is for organizations whose requirement is not confidentiality alone but control: control of the infrastructure, the enrollment authority, the audit domain and the process by which software changes. There is no universal Tunnel master key.

  • Customer-operated
  • Customer-held roots
  • Air-gap capable
  • HSM integration

What comes under your control

Sovereignty is a list of specific things, not an adjective.

Each item below moves from the vendor's domain into the customer's. That is what the word is being used to mean here.

01

Customer-controlled infrastructure

The relay and supporting services run inside the customer's infrastructure, under the customer's operations team.
02

Customer-held enrollment authority

The root of trust for enrollment, authority and software signing is generated and held by the customer.
03

Dedicated or isolated deployment

No shared tenancy with another organization's deployment, and no shared trust domain.
04

On-premises deployment

Installation inside the customer's own facilities and network boundary.
05

Private-cloud deployment

Installation into the customer's private cloud environment under the customer's own tenancy and controls.
06

Approved sovereign hosting

Deployment into hosting the customer's own authority has approved for the data in question.
07

Air-gapped installation

Deployment into an environment with no route to the public network, with enrollment and operation designed for it.
08

Offline signed updates

Software and policy updates delivered as signed artifacts and applied through a customer-controlled process, without an online channel.
09

Customer-managed HSM integration

Root and signing material held in the customer's hardware security modules, under the customer's key ceremony and custody procedures.
10

Customer-controlled logging and retention

What is recorded, where it is stored and how long it is kept are the customer's decisions.
11

Role separation

Administrative authority is divided so that no single role can quietly exercise the whole of it.
12

No permanent vendor access

No standing vendor access capable of decrypting customer content, and no universal Tunnel master key across deployments.

The consequence

What sovereignty actually buys.

The practical value of a sovereign deployment is that questions about trust have answers that live inside your organization.

Jurisdiction
The infrastructure carrying your traffic sits where you put it, under the legal framework you selected.
Compulsion
There is no third-party operator holding a position from which they could be compelled to act on your deployment's infrastructure.
Continuity
Operation does not depend on a commercial relationship remaining in place, or on a vendor's infrastructure remaining available.
Accreditation
Because the deployment is customer-operated, the applicable authorization path is your own accreditation process rather than a vendor's cloud authorization.
Attestation
You can state, on your own authority, who is trusted in your deployment, because you hold the authority that makes the statement.

Customer-controlled deployment reduces third-party infrastructure dependency. In a sovereign deployment there is no universal Tunnel master key and no permanent vendor access capable of decrypting customer content.

In context

Where Sovereign sits

Sovereign is a separate trust domain from Managed, established at build and deployment time.

Managed and Sovereign deploymentIn a Managed deployment the relay infrastructure and the deployment and enrollment authority are operated as part of the managed service, while message content stays encrypted end to end and payload keys are derived only by authorized endpoints. In a Sovereign deployment the customer operates the infrastructure and holds the enrollment authority, the audit domain and the update process. Neither model creates an administrator key that can decrypt customer content. Both models run the same product architecture under separately governed deployment artifacts.MANAGED DEPLOYMENTTunnel MobileTunnel CommandTunnel-operated relayand enrollment authoritySOVEREIGN DEPLOYMENTTunnel MobileTunnel CommandCustomer-operated relayand enrollment authorityCUSTOMER CONTROLSOrganization policy · operators · missionsDevice enrollment and revocationRetention within the managed serviceInfrastructure operated by TunnelEnrollment authority operated for youCUSTOMER CONTROLSOrganization policy · operators · missionsDevice enrollment and revocationInfrastructure, hosting and retentionEnrollment authority and HSM integrationSigned update and audit domain
Two separate trust postures, selected at deployment. Neither holds a key that decrypts customer content, and a managed installation cannot become a sovereign one at runtime.
  • A sovereign build accepts no commercial credential, endpoint or account.
  • A sovereign deployment does not fall back to commercial infrastructure.
  • The complete Tactical Profile posture belongs with sovereign deployment, where the customer holds the enrollment authority it depends on.
  • Sovereign deployment is scoped as a program, with the customer's operations and security teams involved from the start.

Next step

Scope a sovereign deployment against your accreditation path.

A private briefing covers infrastructure, key ceremony and HSM custody, the offline update process, role separation and the evidence your own authorizing process will need.

Request a Private BriefingTactical Profile