Should platform teams move more IAM logic into the gateway?

When moving IAM logic into the gateway is the right boundary

Gateway placement makes sense when the logic is request-centric rather than user-centric: token validation, scope checks, route-level allow and deny decisions, header enrichment, and delegation rules that should behave the same across many services. That gives platform teams one enforcement point for traffic-specific policy instead of duplicating the same control in every application.

A gateway is especially useful when the control should travel with the request path, such as enforcing audience restrictions, stripping unsafe headers, translating identity context for downstream services, or applying consistent access rules to an API family. For workload and service traffic, that is often a cleaner boundary than pushing identical checks into each microservice.

It is also a good fit when centralising the logic improves operability. If teams need one place to update policy, observe failures, rotate enforcement rules, and keep services simpler, the gateway can reduce drift and accidental inconsistency. For broader NHI patterns, the lifecycle and ownership side of that decision is covered well in the NHI Lifecycle Management Guide and the Identity Security Programme Guide.

Where gateway IAM logic goes wrong

The main failure mode is overloading the gateway with business authorization or service-specific decisions that only the application can truly understand. Once the gateway starts making fine-grained judgments about object ownership, workflow state, or per-record entitlements, it becomes hard to reason about correctness and easy for teams to create hidden exceptions.

Another risk is false confidence from centralisation. A gateway can validate that a request is authenticated and scoped, but it cannot replace service-level authorization where the decision depends on resource semantics. If teams assume “the gateway already checked it,” they may leave the service blind to a request that is technically valid but operationally unsafe.

Finally, moving logic upstream can concentrate failure. A bad policy change, token translation bug, or misrouted exception can break many services at once. That is why gateway policy should remain narrow, observable, and clearly bounded by the kinds of checks that are uniform across routes. For abuse patterns around overprivilege and credential misuse, the Top 10 NHI Issues and Cloud PAM and CIEM Guide are useful adjacent references.

What good platform teams standardise, and what they leave in the app

The best split is usually simple: keep common request enforcement in the gateway, keep resource-specific authorization in the service. Gateway logic should focus on trust boundary controls such as token inspection, delegated identity propagation, coarse route permissions, and traffic policy. The application should still decide whether a caller may access a specific business object or take a sensitive action.

That division prevents policy sprawl. It also gives platform teams a clearer operating model: the gateway owns shared enforcement, while application owners remain accountable for domain rules. If the organisation uses workload or service identities, the right design usually pairs gateway checks with strong downstream identity handling, not with a blanket attempt to centralise all IAM logic.

Where gateway placement is appropriate, the implementation should be explicit about what is being enforced, what is merely passed through, and which services must still re-check authorization. Teams that want a broader reference point for workload identity and service-to-service access can use the Cloud Workload Identity Guide and the Lifecycle Processes for Managing NHIs section as supporting context.

Risk and Threat Considerations

Centralising IAM logic in the gateway changes the blast radius. If the gateway is misconfigured, bypassed, or overloaded with too much decision-making, an attacker may gain broad access by abusing one weak boundary instead of having to defeat many service-level controls.

Failure mechanism: The most common breakdown is policy drift, where gateway checks and application checks diverge, or where the gateway enforces only coarse rules while services assume deeper protection exists. A compromised gateway policy, token translation error, or weak route exception can turn a single trust boundary into a fleet-wide exposure.

Impact: The result can be inconsistent authorization, unintended access to sensitive routes, larger lateral movement potential after token theft, and harder incident response because the same control point touches many applications. For cloud and external access paths, the CSA Cloud Controls Matrix provides a useful control model for IAM-related cloud governance.

Practitioner Guidance

What to prioritise: Move only the IAM logic that is uniform, request-scoped, and reusable across many services. Keep object-level and workflow-specific authorization in the application unless the rule is truly identical everywhere.

What to verify: Confirm the gateway can prove the caller’s identity context, enforce the intended scope or audience, and preserve enough downstream signal for services to make their own decisions. If a service cannot still answer “should this caller do this action on this resource?”, the split is probably too aggressive.

Common mistake: Treating the gateway as a substitute for application authorization. That shortcut reduces code, but it often removes the only layer that understands the business object being protected.

Practitioner takeaway: Centralise the checks that are consistent by traffic pattern, not the ones that depend on business meaning, because good gateway IAM reduces duplication only when it preserves service-level accountability.

Related resources from NHI Mgmt Group

• What should IAM and platform teams review before exposing Kafka through a gateway?
• How should teams decide whether to keep custom IAM or move to a platform model?
• When should teams prioritise a hybrid or cloud-native API gateway over keeping gateway logic tied to a single platform?
• When should teams move from a self-hosted auth stack to a managed IAM platform?