Compare

Ewii vs. raw mTLS

mTLS is a primitive, not a product. It establishes that two TLS endpoints have each presented certificates that the other party trusts. That is a useful property, and Ewii relies on it. But if a vendor tells a customer “we use mTLS, so the connection is secure,” the answer to the next several procurement questions is going to be “we’ll get back to you.”

This page assumes you already know what mTLS gives you. It walks through what it does not give you, and what an operator typically has to build to make raw mTLS production-ready for multi-tenant operator-to-customer connectivity.

Hand-drafted comparative stack diagram. LEFT — EWII: a tall outer copper-amber rectangle labeled CLIENT PRESENTS SVID → HUB VALIDATES at top, containing five filled sub-regions stacked vertically labeled ISSUANCE, ROTATION, REVOCATION, MULTI-TENANCY, AUDIT. Forest-green annotation at upper-left reads PRODUCTIZED STACK / ALREADY BUILT. RIGHT — RAW mTLS: identical-size outer rectangle with a solid top region labeled CLIENT PRESENTS CERTIFICATE / SERVER VALIDATES AGAINST TRUST, then eight dotted-border empty sub-regions in a two-column grid labeled CA, ISSUANCE FLOW, TRUST BUNDLE DIST., REVOCATION, PER-QUERY AUTHZ, AUDIT TRAIL, TOPOLOGY, CLIENT PACKAGING. Clay-red annotation at upper-right reads 6–18 MONTHS TO BUILD. Vault-navy vertical divider. FIG. 1 — COMPARATIVE STACK / EWII VS. RAW mTLS centered below. Bottom captions: left productized: issuance, rotation, audit, topology; right primitive: mutual auth only — rest is yours to build. — FIG. 1 Comparative stack — Ewii vs. raw mTLS

What mTLS does

Dimension	mTLS provides	Ewii adds
Mutual authentication	Both parties prove identity at handshake	(uses mTLS at the relay edge)
Transport encryption	TLS 1.3 ciphersuite of your choice	Application-layer ChaCha20-Poly1305 over the mTLS-established channel
Identity issuance	Out of scope — bring your own CA	SPIFFE / X.509 SVID issuance with rotation and revocation
Per-tenant trust isolation	Out of scope — manage trust bundles yourself	Per-tenant trust bundle, validated at handshake
Identity → query authorization	Out of scope	Per-query enforcement plane in the Hub
Audit trail	Connection-level only (handshake events)	Per-query audit, identity-bound, exportable to your SIEM
Operational topology	Out of scope — point-to-point, you build the routing	Hub + relay + Client topology with documented failure modes
Customer-side onboarding	Out of scope — hand the customer a CSR and instructions	Signed Client container; customer runs `cosign verify` and `docker run`
Revocation latency	Whatever your CRL/OCSP infrastructure supports	Sub-second via Hub-side state update

What you would build around raw mTLS

Suppose you decide to skip Ewii and use raw mTLS for operator-to-customer connectivity. Here is the punch list, in the order it tends to come up in practice:

Certificate authority. You need an issuing CA for the customer-side certificates. You need to decide whether that CA is per-customer (operationally heavy, security-cleaner) or shared (operationally light, harder to defend in a review). You need to publish a CRL or OCSP endpoint and decide who hosts it.
Issuance flow. Each customer needs to enroll, generate a CSR, and get a certificate back. You need to authenticate the enrollment request — which is another credential, recursively. You need to handle the renewal cadence.
Trust bundle distribution. The Hub needs to know which customer trusts which CA root. You need to build the configuration surface for that. You need to handle bundle rotation when a customer rolls a CA.
Revocation. When a customer says “revoke the certificate for site B,” you need a mechanism that takes effect in less than however long your existing OCSP staple cache or CRL refresh interval allows. For most existing PKI deployments, that is minutes. For sub-second revocation you need to build a live state-distribution mechanism — which is a non-trivial subsystem.
Per-query authorization. mTLS authenticates the connection. It does not authorize the query. You need a separate enforcement plane that decides “this identity is allowed to run this query against this dataset,” and you need it to be auditable.
Audit trail. mTLS gives you handshake-level events. The reviewer wants per-query records — what identity issued which query at what time, and what the response payload signature was. You need to build that pipeline and plumb it to the customer’s SIEM.
Operational topology. Point-to-point mTLS does not handle relaying. If you want a single Hub serving many customers without each customer having to open a port to your network, you need a relay subsystem with the right failure semantics — keepalive, reconnection, replay protection, sliding window, the whole stack.
Customer-side packaging. The customer security team has to install a binary, generate keys, configure a service. You need a packaging story that their team can audit (signed image, reproducible build) and a runbook they can follow without specialized PKI knowledge.

You can build all of this. Several teams have. It takes 6–18 months and a specialized engineer. The alternative is to use a productized layer that has already done it.

Where mTLS sits in Ewii

Ewii uses mTLS at the relay edge — that is where the SVID is presented and verified. The cryptographic primitives are the same primitives a careful operator would have chosen anyway. The difference is that the issuance, rotation, revocation, audit, multi-tenancy, and operational topology are already built and already tested in regulated environments.

If you are evaluating Ewii because someone said “we already use mTLS,” the useful comparison is not Ewii vs. mTLS — it is Ewii vs. the 6–18 months you would spend building the rest of the stack. The Architecture Review is the fastest way to find out which side that comes out on for your specific case.