Tunnel Mobile

The native endpoint where operators actually work.

Tunnel Mobile supports the approved capabilities and policies of the customer's Tunnel deployment on native Android and iOS. Content is encrypted and decrypted on the device. Credentials belong to the device. Nothing about the operator's communication requires trusting the infrastructure that carries it.

  • Native Android
  • Native iOS
  • Device-bound credentials
  • Offline capable

What operators get

A communication surface, not a security exercise.

The security architecture is the point, but it is not the experience. An operator opens the application and communicates; the platform enforces what the organization decided.

01

Secure messaging

End-to-end encrypted conversation, with content sealed on the device before it reaches any infrastructure.
02

Secure files and voice notes

Files and voice notes travel inside the same Secure Mission Bundle as text, under the same authorization and the same expiration policy.
03

Mission-scoped identity

An operator holds a separate mission-scoped pseudonymous identity in each operational context, rather than one permanent identity everywhere.
04

Disconnected operation

Bundles are composed while offline, held on the device, and delivered when a permitted transport becomes available.
05

Controlled provisioning

Enrollment is governed by the organization. QR-controlled provisioning binds a device to an operator under the organization's authority.
06

Multi-device, separately trusted

Each device an operator enrols holds its own credentials and its own authorizations, and can be withdrawn on its own.

On the device

Cryptography happens where the operator is.

Tunnel Mobile derives content keys on the endpoint. The platform's administrative components have no part in that derivation, and the relay carries the result without the means to open it.

Device-binding key
A P-256 key that proves this specific device. It is generated inside the platform's secure element where one is present, is not exportable, and authenticates the device to the deployment.
Protocol signing key
An Ed25519 key used for sender authentication on a Secure Mission Bundle. It signs; it never participates in key agreement.
Protocol agreement key
An X25519 key forming the classical half of hybrid key establishment.
Post-quantum KEM key
An ML-KEM-768 key forming the post-quantum half. No secure element on any current platform supports ML-KEM, so this key is hardware-wrapped rather than hardware-resident, and Tunnel states it that way.
Payload key
Derived on the endpoints from the agreement and encapsulation results. It exists only at the endpoints. No administrative component contributes an input to it.

Device lifecycle

A device that is lost is a device that can be withdrawn.

Because each device holds its own credentials and its own authorizations, withdrawing one device does not disturb the operator's other devices and does not require re-establishing the organization.

Device loss and revocationEach enrolled device holds its own credentials and its own authorizations. When a device is revoked in Tunnel Command, new signed state withdraws that device's authority. Connected devices apply it on receipt. A disconnected device applies it when it next receives newer signed state, or when its existing authority reaches the end of its validity window, whichever comes first. The operator's other devices are unaffected.Tunnel Commandrevocation issuedOperator device 2unaffected, retains authorityRevoked deviceauthority withdrawnDisconnected deviceapplies on next contactcredentials are per deviceno reuse on another devicebounded by validity windowA credential bound to one device does not function if it is copied to another.
Revocation is bounded rather than instantaneous: a device that is out of contact cannot apply state it has not yet received. The signed validity window bounds that exposure.

Revocation is bounded rather than instantaneous. A device that is out of contact applies withdrawal when it next receives newer signed state, or when its existing authority reaches the end of its validity window, whichever comes first.

Deployment profiles

One product family, separately governed builds.

Different deployment profiles require separately signed, configured and governed builds, because a managed deployment and a sovereign deployment are different trust domains. Externally this remains one product family: Tunnel Mobile.

  • Deployment identity is fixed at build time, not chosen at runtime.
  • A sovereign build accepts no commercial credential or endpoint.
  • Signing identity and application identity stay separate per deployment.
  • Policy distribution is signed and governed by the customer's authority.

Next step

See Tunnel Mobile in a deployment like yours.

A private briefing walks through the operator experience, the enrollment and revocation model, and how the client behaves when the network does not.

Request a Private BriefingTunnel Command