Trust Boundary Classification

The default — terminate TLS at the edge, plain HTTP internally — rests on an assumption that the internal network is trustworthy. Zero-trust rejects that assumption, and the usual response is to apply mutual TLS everywhere.

Applying it everywhere is expensive and applying it by intuition is inconsistent. The practice is to classify boundaries explicitly and require mTLS at each one.

Why it matters

Encryption and identity are separable, and identity is usually the point. A system with mTLS and no authorisation policy has encrypted channels between services that will still do whatever they are asked. The value arrives when the cryptographic identity drives authorisation — this service may call that endpoint — which is precisely the part teams defer.

Classification also makes the decision reviewable. "Where do we require mTLS" is answerable from a document rather than from whoever configured the mesh.

Implementation patterns

• Enumerate the boundaries: between clusters, between environments, across a data-classification line, to and from third parties, between tenants, and anywhere a compliance regime draws one.
• Require mTLS at each boundary and allow plain traffic within one tightly controlled segment, with the segment's controls documented.
• Automate certificate lifecycle completely. Thousands of short-lived certificates rotated automatically, with alerting well ahead of expiry. Expired certificates are among the most common self-inflicted outages, and the answer is automation rather than longer lifetimes.
• Use the identity for authorisation, not merely for encryption, or the investment buys confidentiality against a threat model that already assumed network access.
• Accept the debugging cost and compensate. Packet inspection stops working, which forces investment in application-level tracing — worth planning for rather than discovering.
• Consider a service mesh specifically for this. Providing mTLS without changing application code is its strongest justification, stronger than traffic management or observability, which are available more cheaply elsewhere.

Industry example

Platforms such as Hasura and Supabase that sit between customer applications and customer databases have to reason about this carefully, because a boundary exists between the platform's control plane, its data plane, and the customer's own infrastructure — three segments with different trust properties that a single "internal network" model would collapse.

The classification also determines what can be offered contractually: a customer asking whether their data is encrypted in transit inside your platform needs an answer derived from a policy, not from a recollection.

Failure scenarios

• mTLS everywhere with no authorisation policy, buying encryption against a threat model that assumed network access.
• Boundaries defined by intuition, producing inconsistent coverage that fails an audit.
• Manual certificate management, producing expiry outages.
• Long-lived certificates as a workaround for rotation difficulty, which reintroduces the risk the short lifetimes existed to reduce.
• A service mesh adopted for traffic management, taking on its full operational cost for capabilities available more cheaply.

Trade-offs

mTLS everywhere costs CPU, adds a certificate authority as a critical dependency, complicates debugging, and introduces a class of outage that did not previously exist. Against that it removes network location as a basis for trust, which is the single largest weakness of a perimeter model.

The honest position is that the identity is worth the cost and the encryption alone frequently is not — so if the programme cannot reach the point of identity-based authorisation, the value is much smaller than the effort suggests.

Interview question

"Your compliance team asks for encryption in transit everywhere internally. What do you actually implement, what do you push back on, and what capability would you insist on adding to make the investment worthwhile?"