What is the difference between a BFF and an API gateway?

Why This Matters for Security Teams

The difference matters because both patterns sit on the same traffic path, but they solve different identity and trust problems. An api gateway is designed to normalize access across many clients, while a BFF is designed around one frontend’s session, data, and privilege needs. When teams blur that boundary, secrets, tokens, and downstream permissions often get concentrated in the wrong place. NHI governance guidance from the Ultimate Guide to NHIs — What are Non-Human Identities shows why this is risky: only 5.7% of organisations have full visibility into their service accounts, and blind spots in identity inventory make it difficult to tell whether a gateway or a BFF is the right control point.

For practitioners, the real issue is not naming the component correctly, but placing authentication, token exchange, and secret handling where the blast radius is smallest. NIST’s NIST Cybersecurity Framework 2.0 frames this as identity, access control, and protective safeguards working together rather than as one shared perimeter. In practice, many security teams encounter overbroad gateway trust only after a frontend or service account has already been overexposed, rather than through intentional architecture review.

How It Works in Practice

An API gateway usually sits at the edge and enforces cross-cutting controls for multiple applications or consumers. It can authenticate requests, apply rate limits, terminate TLS, and route traffic to backend services. Because it is shared infrastructure, it is best treated as a policy enforcement layer, not as the place to store application-specific secrets or user-session logic. A BFF, by contrast, is created for a single frontend such as a web app or mobile client. It can tailor payloads, consolidate backend calls, and manage session-aware interactions without exposing the same data shape to every client.

That distinction matters for NHI security because BFFs often become the safer place to isolate privileged API calls and short-lived secrets for one user experience. The Ultimate Guide to NHIs — What are Non-Human Identities is a useful reference point here: if a component needs its own credentials, it should have a narrow identity, explicit ownership, and a limited lifetime. In a well-designed flow, the browser or mobile client talks to the BFF, the BFF exchanges or derives what it needs, and backend services never see frontend-specific secrets.

• Use an API gateway for shared entry controls, coarse-grained auth, and traffic governance across many clients.
• Use a BFF when one frontend needs custom aggregation, session handling, or privileged downstream calls.
• Keep secrets out of the browser and out of shared gateway logic whenever possible.
• Apply NIST Cybersecurity Framework 2.0 principles for access control, logging, and protective technology to both layers.

Current guidance suggests that the BFF is the better pattern when the frontend needs identity-bound data shaping and isolated secret use, while the gateway remains the better pattern for organization-wide traffic policy. These controls tend to break down when one shared gateway is asked to manage per-app session semantics for multiple frontends because the trust model becomes too broad.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance cleaner trust boundaries against extra services, deployment paths, and ownership. That tradeoff is worth it when frontend-specific data exposure or secret handling is part of the design, but it is not always the simplest answer for low-risk internal APIs.

One common variation is a gateway plus BFF combination: the gateway handles perimeter controls and the BFF handles client-specific orchestration. That model works well when different frontends need different data shapes or different downstream permissions. Another edge case is when a gateway is marketed as “doing BFF things” by adding aggregation logic. Best practice is evolving here, but there is no universal standard that says a gateway should become the application-specific session layer. Once a shared gateway starts embedding frontend logic, it becomes harder to reason about privilege, token scope, and change control.

For teams assessing architecture choices, the practical test is simple: if the concern is shared policy for many clients, choose the gateway; if the concern is one frontend’s session, payload, and privileged API calls, choose the BFF. That framing aligns with broader identity guidance in the Ultimate Guide to NHIs — What are Non-Human Identities and with the protective control model in NIST Cybersecurity Framework 2.0. In many real environments, the wrong pattern is discovered only after one frontend’s credentials begin to touch too many backend systems.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?