Ewii vs. "Zero Trust" Marketing Category

“Zero trust” is in the name of the product category and in the name of the product. It is also in the marketing materials of nearly every networking and security vendor shipping anything in the last five years. Most of those products are not zero-trust by any defensible reading of NIST SP 800-207. Most are perimeter-based access control with better UX.

This page is not about specific vendors. It is about the seven properties that distinguish a zero-trust connectivity deployment from a perimeter-based deployment with a zero-trust label, and where Ewii sits on each. If you are evaluating connectivity products and a vendor is making zero-trust claims, this is the checklist.

The seven properties

NIST 800-207 defines zero-trust architecture around principles, not products. For connectivity specifically, the operational implications are concrete. A zero-trust connectivity deployment satisfies all of these. A perimeter-based deployment satisfies some.

1. No implicit trust based on network location

If being on a particular network grants any access, the deployment is not zero-trust. “Internal” and “external” are not authorization claims. A VPN that grants access to subnets based on which IP block the user is on fails this test, regardless of how strong the VPN authentication is.

Ewii: the Hub does not trust traffic based on its source network. Every request carries a SPIFFE SVID. The Hub validates the SVID against the per-tenant trust bundle. Network position is irrelevant to the authorization decision.

2. Per-request authentication and authorization

Zero-trust means every request is authenticated and authorized — not every session, not every connection, every request. A long-lived TLS connection that authenticates once at handshake and then handles a thousand requests fails this test.

Ewii: every query carries an identity claim. The Hub re-evaluates authorization on every query against the current state of the policy engine. Revocation takes effect on the next query, not on the next handshake.

3. Identity tied to the workload, not the user

User identity is necessary but not sufficient. Workload identity binds authorization to a specific service running specific code in a specific environment. Without it, a compromised workload can act on behalf of any user it has a session for.

Ewii: SVIDs are issued to workloads, not to users. The Client container’s identity is the Client container’s identity, regardless of which user is interacting with the upstream operator service. Compromise of a user session does not grant the user’s session the authority to issue arbitrary queries.

4. Cryptographic isolation between tenants

Multi-tenant systems must isolate tenants cryptographically, not just logically. Logical isolation depends on the correctness of every line of code that touches the boundary. Cryptographic isolation depends on the correctness of one specific verification step.

Ewii: each tenant has its own trust bundle. A SVID issued to Tenant A will not validate against Tenant B’s trust bundle. The verification is one function call. There is no cross-tenant code path that a logic bug could walk through.

5. Outbound-only connectivity at the customer edge

Zero-trust at the customer edge means no inbound port. Inbound ports are attack surface even when they are authenticated; the attacker can probe and fingerprint the auth system. Outbound-only removes that surface.

Ewii: the Client opens one outbound connection on port 443. There are no inbound rules. The customer’s firewall does not get a special exception. The attack surface visible from the customer’s external network is zero.

6. End-to-end encryption with no relay-side decryption

Many “zero-trust” deployments terminate TLS at a relay or proxy, decrypt the traffic for inspection, and re-encrypt for the destination. This is operationally convenient and architecturally fatal — the relay sees plaintext and is part of the trust boundary.

Ewii: application-layer payloads are encrypted with ChaCha20-Poly1305 end-to-end between the Hub workload endpoint and the Client. The relay holds ciphertext. The relay cannot decrypt. The trust boundary does not include the relay operator.

7. Audit trail that survives operator compromise

If the audit log lives in the same trust boundary as the system being audited, an attacker who compromises the system can also tamper with the log. A zero-trust audit trail goes somewhere the operator cannot rewrite.

Ewii: audit events are signed at emission with a per-tenant key the operator does not hold. The customer’s SIEM verifies signatures on ingestion. An operator-side compromise cannot retroactively rewrite the customer’s audit history.

How to evaluate a zero-trust claim

When a vendor claims zero-trust, ask:

1. Does the deployment require an inbound firewall change on my side? (If yes, fail #5.)
2. What is the unit of authentication — the connection, the session, or the request? (If anything other than the request, fail #2.)
3. Where is the trust boundary, and who is in it? (If a third-party relay sees plaintext, fail #6.)
4. Where do the audit logs live, and can the vendor’s compromised admin tamper with them? (If yes, fail #7.)
5. Show me the code or the cryptographic primitive that isolates Tenant A from Tenant B. (If the answer is “our application logic” rather than “this verification step,” fail #4.)

A vendor who can answer these without hedging is selling something close to zero-trust. A vendor who hedges is selling the label.

What Ewii claims

Ewii is a productized connectivity layer that satisfies all seven properties above. We are not the only product that does — a few do, with different trade-offs. We are explicit about which trade-offs we made and why. The Architecture Review is where we walk through them.

We do not claim Ewii is the only zero-trust connectivity layer. We claim that a vendor selling you a “zero-trust” product who cannot answer the five evaluation questions above is selling you the label.