API Gateway Backend mTLS with ACM: A UK Zero-Trust Playbook for REST Integrations
On 8 Sep 2026 AWS let API Gateway REST APIs present an ACM (or Private CA) client certificate to backends for mutual TLS — replacing the old self-signed outbound cert. UK zero-trust playbook for FS/healthcare PKI, stage config and CAB evidence.
On 8 Sep 2026 AWS let API Gateway REST APIs present an ACM (or Private CA) client certificate to backends for mutual TLS — replacing the old self-signed outbound cert. UK zero-trust playbook for FS/healthcare PKI, stage config and CAB evidence.
- On 8 Sep 2026, API Gateway REST APIs can present an ACM certificate for backend mTLS.
- Replaces the previous API Gateway–generated self-signed outbound client certificate.
- Import from existing PKI or issue via ACM Private CA.
- ACM reimport/renew propagates to API Gateway with no redeploy and no downtime.
- Available in all commercial Regions and GovCloud (US) where REST APIs exist.
- Combine with existing inbound mTLS for full client↔API↔backend mutual auth.
- UK gate: CA trust alignment, stage IaC, positive/negative tests, renewal drill.
Backend mTLS is a PKI programme — not a stage checkbox
On 8 September 2026, AWS announced that Amazon API Gateway REST APIs can present an AWS Certificate Manager (ACM) certificate to your backend during the TLS handshake, enabling mutual TLS (mTLS) on the API-to-backend path. Previously, API Gateway could only present a self-signed certificate it generated — which corporate and partner CAs routinely reject.
You can import a certificate into ACM from your existing PKI, or have ACM Private CA issue and manage one. When the certificate is reimported or renewed in ACM, API Gateway propagates the update automatically — no redeployment and no downtime. Combined with existing inbound mTLS for clients, you can enforce mutual authentication on both sides of the API — a common requirement in financial services, healthcare and zero-trust estates.
Network and API security
What AWS made available (facts for CAB)
| Topic | Fact |
|---|---|
| Date | 8 September 2026 |
| Scope | API Gateway REST APIs — backend (outbound) mTLS |
| Certificate source | ACM-imported PKI cert or ACM Private CA–issued |
| Previous behaviour | API Gateway–generated self-signed outbound cert only |
| Renewal | ACM reimport/renew → API Gateway updates without redeploy / downtime |
| Config surfaces | Console, AWS CLI, CloudFormation |
| Regions | All commercial Regions + AWS GovCloud (US) where REST APIs exist |
| Pair with | Existing inbound mTLS for client→API |
This is not Lambda Managed Instances, AgentCore or MCP. Keep it in the API / integration / PKI change stream.
UK zero-trust gate — do this before production
1. Decide the trust model
- Corporate PKI import: export/import the client cert your backend already trusts into ACM (Region of the API).
- ACM Private CA: issue a client cert from a Private CA the backend trust store already (or will) trust.
- Confirm backend trust store pins the issuing CA — not the old API Gateway self-signed cert.
- Prefer eu-west-2 (London) or eu-west-1 for UK data-path estates unless a regulator-approved Region is mandated elsewhere.
2. Stage-level configuration pattern
Typical flow (align with your IaC standards):
- Import or issue the certificate in ACM in the API Region.
- Attach the ACM certificate ARN to the REST API stage as the backend client certificate (console / CLI / CloudFormation — see current API Gateway docs for the exact property name on your API type).
- Deploy the stage once for the initial attach; afterwards rely on ACM renewal propagation for cert lifecycle.
- Validate the backend rejects connections that do not present the expected client cert (negative test).
3. Dual-sided mTLS matrix
| Leg | Control | UK note |
|---|---|---|
| Client → API | Existing inbound mTLS | Keep separate trust stores / domains |
| API → backend | New ACM client cert mTLS | This announcement |
| Both | End-to-end mutual auth | Common FS / healthcare mandate |
Do not claim "full mTLS" in CAB if you only flipped the backend leg.
4. Evidence pack for regulated estates
| Evidence | Why |
|---|---|
| ACM cert ARN + issuing CA | Traceability |
| Backend trust-store change ticket | Proves self-signed rejection path is gone |
| Positive handshake test | API presents trusted client cert |
| Negative test | Random/self-signed client cert fails |
| Renewal drill | Reimport or Private CA renew without outage |
| CloudTrail / config snapshot | Audit |
GDPR, ops and UK language
Backend mTLS does not by itself move personal data — but it changes authentication processing on integration paths that often carry regulated payloads.
| Control | What to document |
|---|---|
| Purpose | Prove API Gateway is the authenticated caller to internal/partner backends |
| DPIA delta | Authentication strengthening; same integration data flows |
| Key custody | ACM / Private CA ownership; who can reimport |
| Region | ACM + API + backend in approved Regions |
| Rollback | Stage can revert to previous cert behaviour only with a controlled change — rehearse |
CAB checklist (print this)
- REST API (not HTTP API assumption) confirmed in scope.
- Issuing CA agreed with backend owners (import vs Private CA).
- ACM certificate in the correct Region; ARN recorded.
- Stage configured; initial deploy complete.
- Positive + negative mTLS tests captured.
- Inbound mTLS status documented separately (on/off/planned).
- Renewal / reimport drill scheduled (no downtime expectation verified).
- CloudFormation / IaC updated so console-only drift cannot undo the control.
Risks if you skip the gate
| Risk | Symptom | Mitigation |
|---|---|---|
| Backend still trusts only old self-signed | Handshake failures after cutover | Align trust store first |
| Cert in wrong Region | Attach fails or wrong API | ACM in API Region |
| Console-only change | Drift on next pipeline deploy | Codify in CloudFormation/Terraform |
| Claiming dual mTLS with only backend leg | Audit finding | Document both legs |
| No negative test | Open backend still accepts others | Reject non-matching client certs |
| Ignoring GovCloud / commercial split | Wrong control narrative | Match account partition |
Closing
API Gateway backend mTLS with ACM closes a long-standing UK enterprise gap: partners and internal PKI teams no longer have to special-case a self-signed API Gateway client cert. Production value appears when CA trust, stage config, dual-leg documentation and renewal drills are evidenced — not when the What's New page is bookmarked.
If you want a structured API Gateway mTLS / zero-trust readiness pass for your UK estate — PKI choice, stage IaC and CAB evidence — AIATS offers a Free Evaluation: practical, UK-enterprise, no theatre.
Questions for the platform / security CAB agenda
- Do backends already reject the old API Gateway self-signed client cert?
- Import corporate PKI or issue from ACM Private CA?
- Is inbound mTLS already on, planned, or out of scope?
- Which Region hosts ACM + the REST API stage?
- Who owns renewal/reimport, and have we drilled zero-downtime update?
- Is the stage setting in IaC or only in the console?
Backend mTLS with ACM finally lets UK FS/healthcare backends trust a real CA-signed API Gateway client cert. Prove positive and negative handshakes, and keep inbound mTLS as a separate control statement.
