Mutual TLS: An advanced security control for the Brale platform

Brale now supports mutual TLS as an additional, advanced security control for API access. It's live today for clients who want it, powered at the edge of our platform alongside Cloudflare's technology.

I've been a fan of mTLS for years, and I'm very excited to bring this solution to Brale customers. Imagine a secure channel with your own endpoint — full established, pre-authentication with the API. It is one of the most fascinating attack surface reduction plays out there.

Let's talk about what mTLS, what it protects against, and how Brale works with clients to turn it on.

What is mutual TLS?

Every time you connect to the Brale API over HTTPS, TLS is already doing work: Our server presents a certificate, your client verifies it, and the two sides establish an encrypted channel. That's standard TLS, and it answers one question: Is the client talking to the real Brale?

Mutual TLS answers a second question: Is Brale talking to the real client?

With mTLS, authentication runs in both directions. Your client presents its own certificate during the handshake, and our edge verifies it before the connection is established. Both parties prove who they are cryptographically, to each other, before a single API request is authenticated, authorized, and exchanged. The result is a two-party secure channel where each side has agreed on the identity of the other.

Why it matters

The practical value of mTLS is that it moves a strong authentication check in front of everything else. Requests without a valid client certificate never reach the platform as they're rejected at the edge, pre-authentication, before they touch application logic. That meaningfully reduces the attack surface of the API: The parts of the platform that handle your value movement are simply not reachable by unauthenticated traffic.

That pre-authentication boundary blunts several classes of attack. Cloudflare's overview of mTLS is a good, deeper read, but the short version: An on-path attacker sitting between client and server can't authenticate to either side. Spoofing a client or a server requires a valid certificate and private key, not just a convincing setup. Credential stuffing, brute force, and phishing all share a failure mode here as even a stolen API key is useless without the certificate that must accompany it. And malicious API requests from unauthenticated sources never get the chance to probe for weaknesses, because the connection is refused before the request exists.

None of this replaces API authentication. Your API credentials still work the way they always have. mTLS is a layer in front of them providing defense in depth, applied at the point where traffic first touches us.

Strong cryptography, continuously evolving

Our mTLS implementation is backed by elliptic curve cryptography today, which gives us strong security properties with efficient handshakes. Because the control lives at the edge alongside Cloudflare, we inherit their operational scale and their cryptographic roadmap.

As the industry evolves, so do we, without clients needing to re-architect anything. This is deliberate. Cryptography isn't a place to stand still, and we'd rather ride a curve (pun intended) that's actively maintained than bolt something on ourselves and let it age.

The edge deployment also matters for availability. Certificate validation happens across Cloudflare's global network, not at a single choke point, so adding this control doesn't add a new single point of failure. It's both highly available and more secure — you don't have to pick one.

How we roll it out

mTLS is most effective when the setup is done carefully, so we don't just flip a switch. We work with each client directly to define new, secure endpoints for their mTLS traffic, handle certificate and key exchange over a secure channel, and support the steps to validate everything before going live. The process is short, and you'll have people and docs on the other end of it.

Live today

Customer mTLS is available now. If your security team has been asking for certificate-based authentication to your stablecoin infrastructure, or if this post just gave you the idea, please reach out. We'll walk you through what the setup looks like for your integration.

As always, questions and feedback are welcome.