Teams should decide whether connectivity will be measured as an architecture choice or as a governance control. If the answer is both, the design must preserve least-privilege access, customer-controlled keys, and auditable reach to every in-scope application.
Is the gateway a network shortcut or a governance boundary?
The decision should be made up front because a cloud application gateway is often treated as “just connectivity” while actually shaping who can reach which applications, under what conditions, and with what evidence. If teams treat it only as plumbing, they usually miss the controls that make the gateway defensible: least privilege, key ownership, logging, and scope-limited reach.
The practical test is whether the gateway merely routes traffic or also enforces policy. A routing-only design can be acceptable for simple use cases, but once the gateway sits in front of in-scope applications, it becomes part of the control plane and should be governed accordingly.
That distinction matters because connectivity decisions can silently expand blast radius. A gateway that can reach many back-end systems, or that relies on shared credentials, creates a broader trust boundary than teams often intend. In that case, the architectural choice and the governance control are the same decision, and they should be documented together.
What must be preserved if connectivity is both architecture and control?
If the gateway is allowed to influence access, the design should preserve three properties at minimum: least-privilege access to back-end applications, customer-controlled keys where encryption or token handling is involved, and auditable reach to every in-scope application. Those are not optional hardening extras; they are what keep the gateway from becoming an unreviewed privileged path.
Least privilege means the gateway should not have broader application, network, or secret access than it needs to serve the approved route. Customer-controlled keys matter when organisations need ownership of encryption or decryption trust rather than depending entirely on the provider’s default handling. Auditable reach means teams can show which applications are reachable, by whom, and through which policy or configuration.
A useful rule is to treat any gateway capability that can change reachability, identity trust, or cryptographic control as a governance decision, not merely an implementation detail. If the answer to “what can this gateway reach?” is hard to prove, the design is probably too permissive for production use.
Where this decision usually goes wrong in practice
The common failure is assuming that a managed gateway inherits security from the cloud platform automatically. In reality, the safer design depends on how backend access is scoped, how certificates or keys are controlled, and whether the gateway’s policy changes are reviewable and reversible.
Teams also underestimate how quickly “temporary” broad access becomes permanent. Once the gateway is used as a convenient path for multiple applications, exceptions often accumulate, and the original boundary between network routing and governance control disappears. At that point, remediation is harder because the gateway has become embedded in operational dependencies.
Another recurring issue is treating reachability as equivalent to authorisation. A gateway may successfully connect to an application, but that does not prove the connection is appropriate, minimal, or auditable. The governance decision is about constraining and explaining that reachability, not merely enabling it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Gateway reach should be limited to the minimum back-end access needed. |
| AU-2 — Event Logging | Auditable reach requires logs for gateway policy and access activity. | |
| Recommendation — Restrict gateway permissions to the minimum applications and paths required. Log gateway policy changes and access events for each in-scope application. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The decision is fundamentally about governing and constraining access paths. |
| A.8.24 — Use of cryptography | Customer-controlled keys are relevant when the gateway depends on cryptographic trust. | |
| Recommendation — Define and enforce access rules for gateway-mediated connectivity. Maintain customer-owned control over cryptographic keys where required. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Assume Breach and Verify Explicitly | A gateway should not be trusted as implicit access simply because it is deployed. |
| Recommendation — Verify every gateway access path explicitly before granting trust. | ||
Practitioner Guidance
What to prioritise: Decide whether the gateway is a simple transport layer or an access boundary before implementation begins. If it can expose multiple in-scope applications or sensitive paths, require policy ownership, logging, and review as part of the design review, not after deployment.
What to verify: Confirm that the gateway’s permissions are scoped to the smallest set of back-end resources, that key ownership is explicit, and that every in-scope application can be enumerated from configuration and logs. If any one of those is unclear, the control is not ready to trust.
Common mistake: Teams often approve the gateway based on functionality and availability, then discover that reachability and trust were never documented as governance requirements. That shortcut usually creates later exceptions, more privileged access than intended, and weak audit evidence.
Practitioner takeaway: The right decision is not “gateway or no gateway”; it is whether the gateway’s connectivity is narrow, attributable, and governable enough to deserve production trust.
Related resources from NHI Mgmt Group
- Who should own API Gateway governance when platform and application teams both make changes?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
- How should security teams make NHI best practices usable across the business?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org