Fastly mTLS
To set up fastly mtls, you upload root certificates to the edge network. Then you require both the client and server to check keys before talking. Most engineering teams use this method to lock down API traffic and origin servers. They hand out client certificates to trusted apps, devices, or partner systems. Still, many teams share one broad client certificate across dozens of internal scripts. If that single certificate leaks, anyone holding it gets full reach into the backend. Overly broad ro
East-West mTLS: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up fastly mtls, you upload root certificates to the edge network. Then you require both the client and server to check keys before talking. Most engineering teams use this method to lock down API traffic and origin servers. They hand out client certificates to trusted apps, devices, or partner systems. Still, many teams share one broad client certificate across dozens of internal scripts. If that single certificate leaks, anyone holding it gets full reach into the backend. Overly broad roles also let admins change edge rules without a second check.
How the fastly mtls handshake works at the edge
Standard TLS only asks the server to prove its identity to the user. Mutual TLS adds a second step so both sides prove who they are. Fastly sits between the outside client and your private backend origin servers. This means the edge network handles two separate mutual TLS handshakes at once.
First, the edge checks the client certificate against your uploaded root authority list. It also checks if the key is expired or on a revoked list. If the client key passes, the edge reads the certificate metadata fields. Edge logic can then route or block the call based on those fields.
Second, the edge starts a fresh connection to your private origin server. Here, the edge acts as the client and shows its own key. Your origin server checks this key to make sure traffic came through the edge. This stops attackers from skipping the edge and hitting your backend IP directly.
Managing certificate lifecycles and revocations
Running mutual TLS at scale takes steady work from your security team. Every client device and backend service needs a valid key with a short life. When a key expires, the app breaks right away if renewals fail.
Teams must also push fresh revocation lists to the edge when keys leak. If you forget to update the revoked list, stolen keys keep working. Many teams use automated tools to issue and rotate keys every few weeks. Even with automation, tracking which developer or script owns which key gets messy fast.
East-West mTLS: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native certificate checks solve and what they miss
Edge certificate checks do a great job of blocking unknown network traffic. They stop bots, scanners, and outside attackers before a request reaches your cloud. They also prove that a request came from a known device or service.
Still, mutual TLS only checks identity at the start of a connection. Once the handshake finishes, the network pipe stays wide open for any request. The certificate check does not look at what the user or script does next. It cannot tell a safe read call from a destructive delete command.
Also, device certificates rarely map cleanly to a single human engineer. When an engineer runs a tool using a shared service certificate, logs blur together. You can see that the certificate connected, but not who ran the command. Also, encrypted traffic passes straight through to the origin without field-level data changes. If an API sends back emails, phone numbers, or card numbers, raw text flows out. Teams still need a way to inspect live commands and mask sensitive fields.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between client-to-edge and edge-to-origin mTLS?
Client-to-edge mTLS checks the identity of users or apps calling your public domain. Edge-to-origin mTLS proves to your private backend that traffic came from the edge network.
How do you block a stolen client certificate at the edge?
You add the stolen key serial number to a certificate revocation list. Then you upload that updated list to your edge TLS settings to drop matches.
Does mTLS control which API commands a verified user can run?
No, mutual TLS only checks that the client holds a valid cryptographic key. It does not inspect individual requests or block dangerous commands inside an active session.