Downstream mutual TLS secures the client to gateway connection. The gateway presents a certificate to the client and may also require the client to present one. Upstream mutual TLS secures the gateway to backend connection, where the gateway presents its own certificate to the service and the backend verifies that the call came from the gateway.
How downstream and upstream mutual TLS split trust in an API gateway
Downstream mutual TLS protects the edge between the calling client and the gateway. It is the trust boundary that decides whether the gateway should accept traffic from that caller at all, and it is where client certificate validation most directly lives. Upstream mutual TLS protects the hop from the gateway to the backend, so the backend can trust the gateway as the authenticated intermediary.
Why the two directions solve different security problems
The practical difference is that downstream mTLS answers, “Who is calling the gateway?” while upstream mTLS answers, “Can the backend trust the gateway that forwarded this request?” The same transport mechanism is used in both cases, but the trust relationship changes. That matters because authentication at the edge does not automatically authenticate the gateway to the service behind it.
In most api gateway deployments, downstream mTLS is the control that protects client access, partner integrations, and machine-to-machine callers. Upstream mTLS is the control that preserves internal service trust after routing, policy enforcement, and request transformation. If either side is missing, the system may still function, but one side of the trust chain is no longer cryptographically verified.
What changes operationally when both are enabled
When both directions are used, the gateway plays two roles: server to the client and client to the backend. That means certificate management, trust store configuration, renewal timing, and failure handling need to be correct on both legs. A misconfigured downstream trust store blocks legitimate callers; a misconfigured upstream trust relationship can let a backend accept traffic from an untrusted intermediary or reject valid traffic from the gateway.
This is why API teams often separate the concerns in design reviews. Downstream mTLS is usually about ingress control, caller identity, and edge policy. Upstream mTLS is usually about service-to-service trust, backend authorization assumptions, and preventing direct backend access from bypassing the gateway path. The distinction is architectural, not just terminological.
The most useful implementation test is whether the backend could independently verify the gateway as the approved hop even if the client side were completely different. If the answer is no, then the upstream side is not really established as a separate trust boundary.
Risk and Threat Considerations
Without downstream mTLS, the gateway may still expose the API surface to unauthenticated or weakly authenticated callers, which increases the chance of unauthorized access and abuse at the edge. Without upstream mTLS, a backend may trust forwarded requests too broadly, especially if network location or header-based assertions are treated as sufficient proof of origin.
Failure mechanism: The two directions are often conflated during implementation, so teams secure the client-to-gateway path but leave the gateway-to-backend path dependent on network placement, shared secrets, or implicit trust. That creates a gap where the backend cannot cryptographically confirm the gateway identity, and attackers who reach the internal path may be able to exploit the trust assumption.
Impact: The likely result is weaker caller assurance, greater exposure to spoofing or request injection, and reduced confidence that backend requests came through the intended control point. In larger environments, this can also complicate auditability because the trust chain is no longer explicit end to end.
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 SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | mTLS setup errors in either direction are API gateway misconfigurations. |
| Recommendation — Harden gateway TLS trust stores and verify both client and backend certificate validation paths. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Downstream mTLS authenticates external callers to the gateway. |
| IA-5 — Authenticator Management | Both directions depend on certificate issuance, renewal, and revocation lifecycle. | |
| AC-4 — Information Flow Enforcement | The gateway enforces which traffic may cross from client to backend. | |
| Recommendation — Require certificate-based authentication for external API callers at the gateway edge. Manage certificate rotation and revocation for gateway and backend trust material. Enforce flow controls so only approved requests traverse the gateway to backends. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | mTLS on both legs supports explicit verification at each trust boundary. |
| Recommendation — Treat the gateway and backend as separate trust decisions and verify each hop explicitly. | ||
Practitioner Guidance
What to verify: Confirm which side is authenticating which party. If the gateway is only validating clients downstream, do not assume the backend is protected upstream unless the backend validates the gateway certificate and trust chain separately.
Decision rule: If the backend must trust the gateway as a security boundary, treat upstream mTLS as mandatory, not optional. If the backend is already directly reachable or makes authorization decisions on forwarded headers alone, the design needs rework.
Practitioner takeaway: The core distinction is trust direction, downstream mTLS proves the caller to the gateway, while upstream mTLS proves the gateway to the backend, and both are needed when the gateway is meant to be a real security boundary.
Related resources from NHI Mgmt Group
- What is the difference between mutual TLS and signed JWTs for upstream request verification?
- What is the difference between downstream mTLS and upstream TLS in zero trust access paths?
- What is the difference between request-time enrichment in an API gateway and doing the same transformation in the upstream application?
- What is the difference between privilege reduction and secret rotation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
