No. Being inside a private network proves little about who is calling. NIST SP 800-207 describes zero trust as assuming no implicit trust based solely on physical or network location. Each service call should carry a verified identity, and each receiving service should check it and the permissions behind it.
The perimeter habit
Many internal APIs were built on one assumption: if a request arrives from inside the network, it is friendly. So they skip authentication, or accept a header such as a user ID that "the gateway sets". This works until one workload is compromised, a misconfigured route exposes a service, or a developer machine joins the network.
NIST's zero trust architecture abstract describes the shift: defences move from static, network based perimeters to users, assets and resources. Zero trust assumes no implicit trust is granted to assets or accounts based only on location, and focuses on protecting resources rather than network segments.
What to require on every internal call
| Control | Question it answers |
|---|---|
| Caller identity | Which service is this? |
| Authentication | Can it prove that, with a credential only it holds? |
| Audience | Was this credential meant for me? |
| Authorization | Is this caller allowed to do this action on this resource? |
| Transport protection | Can anyone read or alter the call in transit? |
| Logging | Can we reconstruct who called what? |
Ways to give services an identity
You have several options, and many teams combine them:
- OAuth client credentials. Each service authenticates to an authorization server and receives a short lived access token. See client credentials for service to service auth.
- Mutual TLS. Both sides present certificates. See mTLS or service tokens.
- Workload identity. The platform issues short lived identities to workloads, such as SPIFFE style identities. See SPIFFE IDs and SVIDs.
- Platform tokens. Orchestrator issued service account tokens that the receiver validates.
Whichever you choose, avoid long lived shared secrets copied between services.
Audience matters internally too
RFC 9700 says access tokens should be audience restricted to a specific resource server, or a small set, and that every resource server must verify, on every request, whether the token was meant for it. If not, it must refuse the request. This stops a token stolen from one low value service being replayed against a high value one.
The same RFC says token privileges should be limited to the minimum needed, which also reduces the impact of leakage.
Do not trust forwarded headers
A header like X-User-Id is only as trustworthy as the weakest hop that can set it. If you must pass user context between services, pass a signed token and verify it, or use token exchange so the downstream service sees a token issued for it. Strip identity headers at the edge, and never accept them from outside.
A migration path
- List internal APIs that accept unauthenticated calls. Start with those handling sensitive data.
- Add authentication in report only mode, logging calls without valid credentials.
- Fix the callers that fail.
- Turn enforcement on, service by service.
- Add audience and scope checks.
- Remove the network allow rules that existed only as a substitute for authentication.
Network segmentation still helps. It reduces exposure and noise. It is a layer, not the identity system.
Quick check
Does zero trust mean no firewalls?
No. NIST describes shifting focus from network perimeters to resources. Network controls remain a useful layer.
Is a service mesh required?
No. A mesh is one way to deliver mutual TLS and identity. You can also get there with tokens or platform workload identity.
Safeguard's policies, gates and guardrails can enforce checks in pull requests, and its agent identity capability applies the same idea to AI agents and tools. A free scan shows your dependency picture.
Sources
Last reviewed: 19 October 2026.
