Most zero trust initiatives stall because they still protect the network, not the workload. Firewalls and VPNs continue to make trust decisions based on network location, while secrets vaults rely on possession of long-lived credentials. These controls help, but they all stop short of verifying what a workload truly is.

This location-based security worked when networks had clear perimeters. Now, with services scattered across clouds and credentials leaked in every breach, the perimeter is gone. True zero trust requires verified identity at every request and eliminating static credentials entirely.

The Accidental Origins of Network-Based Security

The foundation of traditional network security emerged from a technical workaround. Network address translation (NAT) was created to address IPv4 exhaustion, not security. As a side effect, NAT blocked unsolicited inbound connections, accidentally creating a security boundary. Organizations noticed this and built entire security models around it, cementing the “inside equals trusted, outside equals untrusted” mindset that persists today.

Firewalls made this implicit boundary explicit. VLANs and network segmentation reinforced the same assumption. The result? Ambient trust where any entity inside the perimeter was automatically trusted to communicate with other internal resources.

When John Kindervag coined the term “zero trust” at Forrester in 2010, he challenged this fundamental assumption. Fifteen years later, the concept has gained widespread recognition. 

Yet despite zero trust appearing in virtually every security strategy and vendor pitch, breaches continue to accelerate. That’s because most implementations remain incomplete and many organizations are trying to achieve zero trust while maintaining network-based trust models.

This model collapses when workloads span multiple clouds, containers spin up and down dynamically, and services need to communicate across organizational boundaries. The perimeter doesn’t exist anymore, yet many organizations still try to recreate it at smaller scales.

Current Zero Trust Approaches Still Trust the Wrong Thing

Most zero trust implementations fall into three categories, each with fundamental limitations that prevent identity-first security:

1. Traffic Inspection Platforms Create New Trust Zones

Secure access service edge (SASE) vendors and similar platforms route all traffic through their infrastructure for inspection. They market this as zero trust, but they’ve simply moved the trust boundary to their own systems. Your organization now implicitly trusts the vendor with access to all traffic, violating the principle of least privilege.

These solutions also face significant challenges with encrypted traffic. Even when endpoint agents cooperate, full deep packet inspection (DPI) of TLS/SSL-wrapped flows can introduce latency, increase complexity, or require key management. Without endpoint-level decryption support, you’re often limited to metadata and header analysis, leaving gaps that sophisticated threats can exploit while also creating performance bottlenecks.

2. Mesh Networks Shrink the Perimeter Without Eliminating It

Service meshes and VPN technologies move from network-level perimeters to machine-level or service-level encrypted tunnels. Identity gets attached to cryptographic keys for tunnel establishment, which seems like progress.

The challenge? Identity typically dies where you terminate the tunnel. If the tunnel ends at the network interface, you’ve created a smaller perimeter that still relies on network location. You need additional mechanisms like request signing or tokens for end-to-end identity, adding complexity and potential failure points.

These solutions also introduce encryption overhead at scale. For high-throughput environments, the performance cost becomes significant.

3. Token-Based Authorization Needs Transport Security

Extending JWT tokens, OAuth, and SAML to service-to-service communication moves identity closer to the request. Policy engines can make fine-grained authorization decisions based on token claims rather than network location.

But tokens don’t solve transport security. You still need a secure connectivity layer beneath the authorization system. JWT flexibility also creates operational chaos without strong standards and governance. When tokens act as distributed policy caches with long expiration times, you’re back to static credentials with different packaging.

None of these approaches fully solve the problem because they enforce identity at boundaries rather than maintaining cryptographic identity binding across the entire request lifecycle. Workload identity and access management requires a fundamentally different approach.

What Request-Scoped Identity Actually Requires

True zero trust means cryptographically binding identity to every request across its entire lifecycle, not just at entry points. This represents a shift from managing secrets to eliminating them through secretless architecture:

• Cryptographic identity verification: This starts when a workload launches, and the environment attests its identity using platform-specific mechanisms like AWS instance metadata, Kubernetes service account tokens, or GitHub Actions OIDC tokens. This identity must survive through proxies, load balancers, and service boundaries without degradation.
• Continuous authorization: Policy evaluation happens at every access point, shifting the question from “can you reach this system” to “should this specific identity perform this specific action right now.” The evaluation considers identity, security posture, environment context, and time. A workload might have valid credentials but be denied access because the container image is outdated or the access happens during an unusual time window.
• Elimination of static credentials: This removes the persistent attack surface that credential compromise creates by eliminating hardcoded API keys, passwords, and long-lived tokens entirely. Instead, ephemeral credentials are issued just-in-time based on verified identity and current context, then automatically expire. Workloads never handle credentials directly in a secretless architecture, dramatically reducing the risk of leakage and the operational burden of rotation.

The request flow follows these steps:

1. The environment attests its identity using platform-specific mechanisms.
2. A trust provider like AWS, Kubernetes, or GitHub Actions verifies the identity cryptographically.
3. The system evaluates access policies based on identity plus contextual signals like security posture and environment.
4. Only after policy approval is a short-lived credential issued or direct access granted.
5. Every action gets logged with full context for security analysis and compliance.

Making Identity Work Across Real Architectures

Theory is one thing. Implementation across production infrastructure with reverse proxies, multi-hop service chains, and legacy applications requires practical patterns. The gap between zero trust principles and operational reality explains why adoption remains challenging despite fifteen years of industry discussion.

Reverse Proxy Plus Backend Services

In a typical setup, NGINX or Envoy terminates TLS before passing requests to application servers that connect to databases. The challenge? Identity dies at proxy termination.

The solution requires injecting identity into headers at the proxy layer, using request signing to maintain cryptographic binding, re-authenticating at each service boundary, or deploying an identity broker that maintains context throughout the chain. Modern proxies can be configured to preserve identity information and pass it downstream, but this requires careful implementation to prevent spoofing.

Multi-Hop Service Chains

API gateways frequently route requests through multiple services before reaching the final destination. Each hop introduces an opportunity for identity loss or privilege escalation if not handled correctly.

Standardizing identity propagation through trace context or signed headers maintains the chain of trust. Each service validates and re-signs requests before forwarding them. Policy enforcement happens at each hop rather than just edges, preventing lateral movement even if one service gets compromised. A centralized audit trail reconstructs the full request path for security analysis.

Legacy Applications Without Code Changes

The most challenging scenario involves applications that can’t be modified to handle modern authentication. Legacy codebases, vendor applications, and systems in maintenance mode need security improvements without rewrites.

The sidecar pattern solves this by deploying a proxy that intercepts traffic transparently. Credential injection happens at runtime through environment variables or local files. No-code authentication works through traffic interception, with policy enforcement external to the application. This approach modernizes security posture while respecting the constraints of existing systems.

From Network Trust to Identity Trust

The shift from location-based security to identity-based security represents more than swapping out tools. Network perimeters create ambient trust that attackers exploit through lateral movement. Identity-first zero trust verifies every request based on cryptographic proof of who the workload is, what its security posture looks like, and whether the context justifies access.

This vision is now echoed across industry standards.

• NIST SP 800-207 defines Zero Trust Architecture as continuous identity, posture, and policy verification at every access request.
• CISA’s Zero Trust Maturity Model expands that guidance to enterprise operations, identifying identity as the first of its five pillars.
• For workloads specifically, the CNCF’s SPIFFE/SPIRE frameworks standardize how to issue, verify, and federate cryptographic identities across environments, bringing Zero Trust principles to machine-to-machine communication.
• Even cloud providers now embed these ideas through workload identity federation in AWS, Azure, and GCP, proving that identity, not network placement, is becoming the true trust anchor.

Together, these frameworks outline what “identity over network” really means: every workload must present verifiable proof of identity, posture, and intent before gaining access, regardless of location or infrastructure.

Aembit helps organizations operationalize these principles in production, leveraging trust providers like Kubernetes, cloud instance metadata, or GitHub OIDC to establish attested workload identity and issue short-lived, scoped credentials automatically. Policies, auditing, and conditional access remain centralized while credentials stay ephemeral and invisible to code.