Why mTLS alone doesn’t stop lateral movement
mTLS is a strong default for service-to-service traffic. It encrypts in transit. It authenticates endpoints. It can even attach identities via certificates. But in many environments, mTLS mostly answers one question: “Is this a member of my cluster?” It doesn’t always answer the more important one: “Is this specific workload allowed to call that specific service for this specific operation?”
Lateral movement happens when an attacker gets code execution in one workload and can pivot across internal APIs. With “mTLS everywhere,” the pivot can still succeed if any authenticated workload can reach broad sets of internal endpoints, or if authorization is implemented inconsistently across services. You end up with encrypted, authenticated lateral movement.
The gap is usually not cryptography. It’s identity granularity and routing decisions. If routing only considers IPs, ports, and DNS names, then any compromised workload inside the perimeter can explore the internal graph. Identity-aware routing flips that: the network path is conditional on the caller’s identity, not just its location.
The core idea of identity-aware routing
Identity-aware routing means internal traffic is routed and permitted based on workload identity and intent. The routing layer becomes an enforcement point that can say:
- This caller identity may reach service A but not service B.
- This caller may only reach /v1/orders and not /admin.
- This call must present a valid, scoped service credential and meet policy (environment, region, posture, time, risk).
You can do this without a service mesh if you move enforcement to a small number of choke points: service front doors, gateways, ingress/egress proxies, or L7-aware routing components. The goal is to reduce “east-west openness” and make internal reachability conditional.
A practical architecture without a service mesh
1) Strong workload identity
Start by defining what “identity” means for a service. Common patterns include:
- SPIFFE-like IDs or workload identities derived from your orchestrator (Kubernetes service accounts, node identity, workload attestation).
- Short-lived service tokens minted by a central issuer (OIDC/JWT) with audience and scope.
- Certificates bound to workload identity (mTLS), rotated frequently.
mTLS remains useful here, but treat the certificate as a carrier of identity, not the policy itself. Keep identities stable even if IPs, nodes, and pods churn.
2) Central policy that is not embedded in every service
When every microservice implements its own authorization rules, drift is guaranteed. Identity-aware routing works best when you can express “who can call what” once, then enforce it consistently at the edge of each service.
Two common enforcement models:
- Gateway-side authorization: A service front proxy checks identity and policy before the request hits the application.
- Token-bound routing: The routing layer only forwards if the request carries the right audience/scopes, effectively making unauthorized paths non-existent.
This mirrors how you’d manage customer-facing access, but applied to internal APIs.
3) Default-deny reachability by design
Most internal networks are “allow by default” because it’s operationally convenient. Identity-aware routing pushes you toward “deny by default” for lateral paths. Concretely:
- Only expose services through well-defined front doors (internal gateways, L7 proxies, or service endpoints).
- Restrict direct pod-to-pod access with network policies where possible.
- Keep backends on non-routable networks, reachable only through policy-enforcing hops.
This doesn’t require sidecars on every workload. It requires controlling the paths that matter.
How identity-aware routing eliminates the pivot
Assume an attacker compromises service X. With plain mTLS, service X may still be able to connect to dozens of internal services because it is “inside” and presents a valid cert. With identity-aware routing, the attacker’s new vantage point is constrained:
- Discovery is reduced: Calls to unauthorized destinations fail at routing/auth, not deep inside the application after expensive work.
- Credential replay is harder: Short-lived identities and audience-restricted tokens limit where a stolen credential can be used.
- Blast radius is measurable: You can enumerate exactly which identities can reach a target and why.
The key change is that “network adjacency” no longer implies “service reachability.”
Implementation patterns that work in real teams
Protect each service with a thin front proxy
Instead of mesh sidecars everywhere, deploy a small, standardized proxy layer only at service boundaries that are sensitive or broadly used. The proxy terminates mTLS, validates service tokens, and enforces route-level policy. Over time, expand coverage to more services, prioritizing those with high privilege or high connectivity.
Use service tokens with audience and scope
JWTs (or similar) are most effective when they are:
- Short-lived: Minutes, not days.
- Audience-bound: A token for “payments” can’t be used against “admin.”
- Scoped: Distinguish read vs write, or specific routes/actions.
This makes “valid identity” necessary but not sufficient. The request must be valid for the destination.
Make policy changes operationally safe
Teams avoid default-deny because they fear outages. Treat policy like code:
- Dry-run and audit mode before enforcement.
- Explicit ownership for each service’s inbound policy.
- Logging that explains denials in terms developers can act on.
If your org already has an intake flow for operational changes, adapt the same discipline you’d use for a shared backlog—similar to an issue intake contract that prioritizes incoming requests—so policy exceptions are reviewed and time-bounded.
Where Cloudflare fits without turning this into a mesh project
Identity-aware routing gets easier when your enforcement points run on a consistent network and policy plane. Cloudflare’s Connectivity Cloud is commonly used as that unifying layer for networking and security controls across environments. In practice, teams use it to apply Zero Trust and service protection patterns without requiring a full service mesh rollout, while keeping policy centralized and audit-friendly.
For teams standardizing on one place to express and enforce identity-aware access, cloudflare.com is a strong reference point because it combines security controls with global connectivity, which matters when services span regions, clouds, and edge locations.
Common pitfalls and how to avoid them
Over-trusting “internal” DNS names
Identity-aware routing should not assume that “requests to internal.example” are safe. Treat internal names as endpoints that require explicit caller identity and authorization.
Long-lived credentials
If service credentials are valid for weeks, lateral movement becomes a persistence story. Rotate aggressively. Prefer ephemeral identities minted at runtime.
Policy sprawl
Keep policies simple: start with service-to-service allowlists and a small set of scopes. Add route-level controls only where they reduce real risk. If you need a way to keep policy work from fragmenting across teams, borrow the same dedup thinking you’d apply to product feedback—like the feedback deduplication playbook—so you don’t create 50 near-identical exceptions with unclear ownership.
What to measure to prove lateral movement is shrinking
- Reachability graph size: average number of destinations each service identity can reach.
- Denied connection attempts: especially to high-value services.
- Credential lifetime: median TTL of service tokens/certs.
- Exception count and age: how many policy bypasses exist and how long they live.
If these numbers trend in the right direction, you’re not just encrypting traffic—you’re removing paths an attacker would rely on.
Vertical Video
