It means external callers are authenticated and authorised at the edge, while internal services are separately identified, encrypted, and observed as they communicate with one another. The gateway and mesh are not substitutes. They are complementary controls that cover different stages of the same request path.
How layered access control works in a microservices architecture
layered access control means a microservices system does not rely on a single decision point. Access is checked more than once, at different boundaries, so the platform can distinguish who is calling from what is being called and under what conditions. That reduces the blast radius of a weak trust assumption and keeps edge protection from becoming the only line of defence.
At the edge, gateways, identity providers, and external authorisation policies decide whether the caller should enter the system at all. Inside the platform, service-to-service controls enforce separate checks for each hop, so a request that is valid for one service is not automatically valid everywhere else. In practice, this is where the difference between perimeter control and zero trust-style internal enforcement becomes visible. See NIST SP 800-207 Zero Trust Architecture and Authorisation Models Guide for the distinction between coarse and fine-grained decisions.
The internal layer is usually about service identity, mutual trust establishment, scoped tokens, encrypted transport, and policy enforcement close to the workload. That matters because microservices often chain many internal calls, and each call can carry different data, privilege, and context. A mesh can authenticate the service, but the application still needs to know whether that service should access a specific function, record, or workflow. For machine-to-machine flows, the supporting pattern is well aligned with RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
Why the gateway and mesh solve different problems
A gateway is strongest where the problem is entry control: authentication, coarse authorisation, routing, throttling, and exposure management for external traffic. A service mesh is strongest where the problem is east-west trust: internal authentication, encrypted service-to-service traffic, policy propagation, and observability across a distributed call graph. If you try to use only one of them, you create blind spots either at the boundary or inside the system.
That division of labour is why layered access control is not duplication. The edge decides whether the request should be allowed to start; the internal layer decides whether each internal step should continue. This is especially important when a single external request fans out into multiple services, because the original caller may be permitted to reach one capability but not others. In policy terms, this is where service-level authorisation, not just network trust, becomes the relevant control. The underlying model is consistent with the intent of RFC 8707: Resource Indicators for OAuth 2.0 and CIS Controls v8, especially where access governance and logging need to stay aligned.
Layering also helps when the trust boundary changes over time. A service that is safe to call from one part of the estate may become unsafe when reused by a new client, exposed through a new route, or connected to a third-party integration. The architecture remains safer when the edge and the internal layer each enforce their own rules instead of assuming the other will catch every misuse.
What good layered access control looks like in practice
Good practice is to make the external and internal controls complementary, not identical. External controls should answer whether a caller may enter the platform and reach a broad surface. Internal controls should answer whether a specific workload may invoke a specific API, consume a specific resource, or act on a specific dataset. The policy should follow the request path, not end at the first successful check.
Operationally, that means the team can explain four things at any hop: which identity was authenticated, what authority it carries, what it is allowed to do, and how the decision is logged. If any of those are missing, the architecture is usually leaning too heavily on implicit trust. That is where IAM and IGA Basics is useful as a foundation for entitlement thinking, while Privileged Access Management Guide helps frame time-bound and least-privilege access for especially sensitive flows.
At scale, the key question is not whether a request can be authorised once, but whether hundreds of services can enforce the same rule consistently without creating policy drift. The strongest designs make internal authorisation observable, testable, and narrow enough that one compromised service cannot inherit broad trust simply because it sits inside the network.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | None — Zero Trust Architecture | Microservices layering depends on separate trust decisions for edge and internal calls. |
| Recommendation — Apply zero trust principles so every service hop is independently authenticated and authorised. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Internal microservice calls need service-to-service identity and authentication controls. |
| AC-6 — Least Privilege | Layered control should limit each service to the narrowest action and resource set. | |
| Recommendation — Require service identities and mutual authentication for east-west traffic. Restrict each service to only the permissions needed for its function. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Microservices need managed, reviewed, and logged access paths across layers. |
| Recommendation — Centralise access rule management and review service permissions regularly. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Layered control prevents internal services from exposing functions callers should not reach. |
| Recommendation — Enforce function-level checks on every service endpoint. | ||
Practitioner Guidance
What to prioritise: Treat the edge and the mesh as separate decision planes. If the gateway authenticates users but internal services still trust any peer on the network, the architecture is only partially controlled.
What to verify: Confirm that internal calls are authenticated with a distinct service identity and that authorisation is evaluated on the target resource or action, not just on successful network reachability. Verify that logs show both the external and internal decision points.
Common mistake: Teams often stop after adding a gateway or service mesh and assume the other layer is optional. In practice, one layer usually handles entry risk while the other handles lateral movement and overbroad internal reach.
Practitioner takeaway: Layered access control is strongest when each layer has a different job, because the architecture stays resilient only if no single trust decision can unlock the whole request path.
Related resources from NHI Mgmt Group
- Why does a microservices architecture increase the need for granular access control?
- Why do non-human identities complicate zero trust architecture?
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between JIT access and Zero Trust for NHIs?