Connection Security

Every appliance maintains a single secure channel back to your control plane. Deployments and operations ride this channel, and the appliance reports its status back over it. This page explains the mechanics of that channel and the mutual TLS (mTLS) trust model that secures both ends of it.

​

The connection at a glance

• One channel per appliance, between the appliance’s controller and your control plane.
• Outbound-only: the appliance always dials out. It never opens inbound ports.
• Mutually authenticated: both ends present and verify certificates before any data flows.
• Long-lived: established once during appliance setup and re-handshaked as needed.

The channel carries control traffic in both directions: Telemetry (logs, metrics, traces) does not ride this channel - observability data is handled separately. See Observability.

​

Outbound-only by design

The appliance controller initiates the connection to your control plane over outbound HTTPS. It does not open inbound network ports, assign public IPs, or create ingress rules for itself. Your control plane never reaches into the customer’s network unsolicited; it can only send instructions back down a connection the appliance already opened. This matters for two reasons:

• It’s easy for customers to allow. Most networks already permit outbound HTTPS, so customers don’t have to open ingress ports - a request that is often logistically difficult and a security concern in regulated environments.
• It shrinks the attack surface. There is no listening socket on the appliance for an attacker to reach, and no inbound path from your control plane into customer infrastructure.

The connectivity behavior is part of the appliance’s form factor. See connectivity modes for how Connected and Disconnected appliances differ.

​

Mutual TLS: both sides prove who they are

Ordinary (one-way) TLS only proves the server’s identity to the client. mTLS adds the reverse: the client must also present a certificate the server verifies. On the appliance-to-control-plane channel, both ends authenticate each other on every handshake:

• Your control plane verifies that the connecting appliance is one it actually provisioned.
• The appliance verifies that it is talking to your control plane, not an impostor endpoint.

During appliance setup, Tensor9 provisions each end with the certificates it needs to recognize the other. Neither side will complete a handshake with a party it cannot verify.

​

The two identities

​

The handshake

​

Bootstrapping trust with cloud identity

The handshake above assumes each side already holds a certificate. But a brand-new appliance has none - and handing it a pre-shared secret to start with would just move the problem. Tensor9 closes this gap by bootstrapping the appliance’s first certificate off the platform’s own identity system - AWS, GCP, or Kubernetes - so there is no long-lived shared secret to distribute or leak. Enrollment follows the same four steps on every platform; only the proof of identity differs: The proof of identity is each platform’s native primitive: The key property is the same across all three: the appliance proves “I am this workload, running under this identity” using credentials the platform already issued it. Nothing secret is transmitted or stored, and the proof is bound to the customer’s registered identity and to the specific enrollment. The root of trust is the customer’s own cloud or cluster IAM.

​

Per-appliance identity

Each appliance has its own leaf certificate, not a shared secret reused across the fleet. When your control plane issues that certificate, it records the leaf’s fingerprint against that appliance. On every handshake it checks both that the presented certificate chains to its CA and that the fingerprint matches the one on record - so an appliance can only ever authenticate as itself, and that recorded fingerprint is the lever for revoking it. The practical consequences:

• No shared bearer secret. There is no API key or token that, if leaked, authenticates as any appliance. An appliance’s credential only authenticates that appliance.
• Blast radius is contained. Compromising one appliance’s certificate does not let an attacker present as a different appliance.
• No reaching into customer infrastructure. Cutting an appliance off is decided on your side - you don’t need access to the customer’s environment, which is outbound-only and may be unreachable on demand. See Cutting off an appliance.

​

Certificate lifecycle

Every certificate on this channel is issued from a two-tier certificate authority that your control plane operates inside your own AWS account - the same dedicated account your control plane runs in. The CA signing keys are held in KMS in that account: the private keys never leave KMS, and issuance happens through KMS signing operations. There is no exportable CA key to leak, and the CA stays under your control - Tensor9 never holds it on your behalf. The tiers trade off security against operational load. The root key is the most sensitive, so it is long-lived and rarely used: it signs only the intermediate. The intermediate carries the day-to-day signing of leaf certificates on a shorter, two-year clock and can be replaced without touching the root. Leaf certificates are deliberately short-lived and rotated monthly, so a leaked or stale leaf is only useful for a brief window. The appliance renews over the existing authenticated channel - it requests a new leaf before the current one expires, without repeating the cloud-identity attestation - so the long-lived channel stays up across rotations and certificate rollover is invisible to deployments and operations. Operator certificates are issued from the same CA but are longer-lived (about a year); see Relationship to operator authentication.

​

Cutting off an appliance

When your control plane issues an appliance its leaf certificate, it records that leaf’s fingerprint against the appliance. Every handshake checks the presented certificate’s fingerprint against the recorded one, so revoking an appliance is immediate: remove the recorded fingerprint and the cached certificate fails its very next handshake. The appliance cannot reconnect without re-enrolling, which requires a fresh cloud-identity attestation against the role recorded for it. This doesn’t rely on a certificate revocation list - revocation is a single change your control plane makes, enforced on the next handshake.

​

Relationship to operator authentication

Two kinds of mTLS clients terminate at your control plane, and they use the same underlying trust model: In both cases your control plane is the certificate authority that issues these certificates and pins each party’s leaf fingerprint. Revocation is the same underlying operation for both - remove the pinned fingerprint and the cached certificate fails its next handshake - whether the principal is an appliance or an operator. Appliances connect to receive deployments and operations and to report status; operators connect to drive the CLI. Neither relies on a shared bearer secret.

​

What the channel does and doesn’t expose

The mTLS channel secures how the two ends talk; the permissions model and secrets handling govern what the connection is allowed to do. Independent of mTLS:

• Application and business data stay in the appliance. Only control traffic - deployment instructions, operations commands, and status responses - crosses the channel. Your customer’s business data never does.
• Secret values never leave the customer’s environment. The controller detects secrets created in the customer’s own secret manager; their values are not transmitted to your control plane. See Secrets.
• Every operation is authenticated and audited. Commands sent over the channel run through your control plane’s permissions model and are logged.

​

Related topics

• Your Control Plane: What the control plane does
• Customer Appliances: The appliance and its controller
• Permissions Model: What the connection is allowed to do
• IAM Commands: Operator authentication, also built on mTLS