Workload identity vs. network identity

Authorization decisions in distributed systems are decisions about which identity is allowed to do which thing. The harder problem, almost always, is the identity layer underneath. Get the identity wrong and the authorization is built on sand; you cannot fix authorization by improving the policy engine if the identity it operates over does not actually identify what you think it identifies.

This essay is about a specific identity-layer choice: network identity vs. workload identity. The choice matters because operator-to-customer connectivity has been built on network identity for thirty years, the industry has spent a decade building workload identity as a replacement, and the products that use workload identity behave qualitatively differently from the ones that do not.

What network identity is, and what it actually identifies

Network identity is the cluster of practices that use IP addresses, subnet membership, or VPN tunnel endpoint as the primary input to authorization decisions. “Allow connections from the corporate VPN subnet.” “Allow connections from the partner ASN.” “Allow connections from this specific list of source IPs.”

The thing network identity actually identifies is “this packet arrived at this port from this address.” That is not the same thing as “this packet was sent by this entity.” The two are operationally close enough to be useful for some purposes — packets do not, ordinarily, travel through forged source addresses on the open internet. But the gap between “what sent this packet” and “what address it appears to come from” is exactly the gap an attacker exploits.

The gap is widest in two specific situations. First, when the network trust boundary is large — corporate VPN subnets often contain hundreds of machines, any of which can spoof being any of the others as far as a remote authorization decision is concerned. Second, when the trust boundary is shared — a tunnel endpoint that two entities both have access to gives both of them the same network identity from the remote party’s perspective.

The classic post-incident finding “the attacker pivoted from a compromised laptop to the production database because the laptop was on the corporate VPN” is a network-identity finding. The laptop’s network identity, by construction, was indistinguishable from the network identity of every other endpoint authorized to talk to the database.

What workload identity is

Workload identity is the practice of issuing cryptographic identities to workloads — specific services running specific code in specific environments — and binding authorization decisions to those identities.

The dominant standard is SPIFFE, which produces SVIDs (SPIFFE Verifiable Identity Documents) in two flavors: X.509 certificates and JWT tokens. An SVID identifies a workload by URI: spiffe://example.com/workload/billing-api. The SVID is issued by a SPIFFE workload API in the workload’s own environment, with attestation that the workload is what it claims to be.

The authorization decision is then “does this SVID satisfy this policy.” The decision is made on cryptographic evidence, not on the inferred network position of the requestor.

This is operationally heavier than network identity, in the same way that public-key cryptography is heavier than passwords. The benefit is that the identity actually identifies the thing you wanted to authorize.

The four properties workload identity gives you

When operator-to-customer connectivity uses workload identity, four properties become available that are difficult or impossible with network identity.

1. Authorization survives infrastructure-level events

If the customer reorganizes their network, renumbers a subnet, migrates a workload to a different cluster, or moves to a different cloud, network identity has to be reissued. Workload identity does not. The spiffe://customer.example/billing-svc URI is the same identity whether the workload is in AWS or on a bare-metal server in a colocation facility. The authorization policy on the operator side does not change.

2. Multi-tenant isolation is cryptographic

In a multi-tenant operator deployment, network identity gives you “Tenant A’s traffic comes from these IP ranges.” Workload identity gives you “Tenant A’s workload presented an SVID issued by Tenant A’s trust domain, and the SVID was validated against Tenant A’s trust bundle.” The isolation is one verification step rather than a logical inference.

3. Revocation is meaningful

Network-identity revocation is “remove the IP from the allow-list.” Workload-identity revocation is “the SVID issuer marks the SVID as no longer valid; the next authorization check fails.” The first is operationally heavy and time-delayed. The second takes effect on the next request, given the right state-distribution mechanism.

4. Audit becomes about identities, not connections

Network-identity audit gives you “this many connections from this IP range did this thing.” Workload-identity audit gives you “this specific workload did this thing.” The reviewer can answer “what did Tenant A’s billing service do last Tuesday” without a network-flow forensics exercise.

How this works in operator-to-customer connectivity

The operator runs a Hub. Each customer runs a Client workload. The Client workload is issued an SVID by the customer’s workload API at runtime, attested to be the specific Client image running in the customer’s environment. The SVID identifies the workload as spiffe://{customer-trust-domain}/ewii-client/{workload-id}.

The Client presents the SVID at the connection handshake to the Hub. The Hub validates the SVID against the trust bundle for the customer’s trust domain. This validation is one cryptographic check; it does not depend on network position, source IP, or routing table state.

Authorization decisions on subsequent queries reference the SVID. “This SVID is allowed to issue queries against this dataset” is a property of the policy and the identity, not a property of the network the request came from.

If the customer rotates the SVID, the new identity takes effect on the next handshake. If the customer revokes the SVID, the next request fails authorization — sub-second, given the state-distribution mechanism the Hub uses for trust-bundle updates.

If the customer migrates the Client workload from one network to another, the workload’s SVID does not change. The operator’s authorization policy does not need to be updated. The customer’s network team and the operator’s policy team do not have to coordinate.

These are not subtle properties. They are the operational difference between “we let your AI vendor in via VPN” and “we let your AI vendor’s Client workload talk to our billing service.” The second is the modern practice. The first is the practice we are leaving.

What this requires

Workload identity requires that the workload’s environment can attest the workload — that is, can produce signed evidence that “this is the workload that is asking for an identity.” In practice, this is provided by the workload-runtime layer (Kubernetes, EC2 instance metadata, hypervisor attestation, or a SPIRE node attestor for bare metal). The attestation mechanism is environment-specific, but the SVID consumer (the Hub, in this case) sees a uniform identity regardless of which attestor produced it.

For a customer environment that does not yet run a workload identity plane, the Client image bundles a small SPIRE agent that handles the attestation locally. The customer’s security team reviews the agent along with the Client. Most of them, by 2026, already have workload identity in some form for their own internal services and welcome the opportunity to consolidate.

Closing

If you are evaluating a connectivity product for an AI or SaaS use case into a regulated customer, the identity question is the right place to push. “What identifies the requestor” is the question the rest of the authorization stack is built on. A vendor whose answer is “the source IP” is selling you a 1990s identity model. A vendor whose answer is “an SVID issued in the customer’s trust domain and validated against the customer’s trust bundle” is selling you the model that survives the next ten years of infrastructure change.

The comparison pages walk through how Ewii’s identity layer specifically differs from the identity layers of Cloudflare Tunnel, Tailscale, and raw mTLS. If you want to walk through your specific identity requirements with the team that built Ewii’s, the Architecture Review is a 60-minute working session on exactly that.