Closing the loop on client identity for SaaS providers
Cloudflare for SaaS lets providers run their infrastructure in front of customer-owned domains, handling TLS termination, performance, and security at the edge. A new addition to that stack extends mutual TLS (mTLS) authentication to custom hostnames through Cloudflare Access, giving SaaS providers a way to enforce client certificate validation without owning the domain.
Previously, mTLS policies in Access were limited to domains the customer owned directly. That left a gap for SaaS providers who manage origins for domains they don't control. With this update, providers can now issue and enforce mTLS policies on those custom hostnames, bringing the same Zero Trust controls to their tenants.
How mTLS works in a handshake
In a standard TLS handshake, the client validates the server’s certificate to confirm it’s talking to the intended destination. The server, however, doesn’t verify the client’s identity. mTLS reverses that assumption: both sides present certificates, and each party validates the other’s.
Think of it as a bouncer checking IDs against a guest list. The server holds a Certificate Authority (CA) root, and only clients presenting certificates issued from that root get through. A request without a valid client certificate — or one that chains to an unknown CA — is rejected during the handshake.
That model is useful for machine-to-machine communication where you need stronger guarantees about which service is making a request. For example, if service A is the only component allowed to write to a database, mTLS ensures service B can't accidentally or maliciously make that call.
In a typical setup:
With mTLS enabled, the flow adds a second validation step for the client:
Why SaaS providers need this
SaaS providers often expose dedicated API endpoints per customer, such as pay.<business_name>.com for a payment processor. Not every client or device on the internet should be able to hit those endpoints. mTLS gives the provider a way to enforce that only authorized devices can connect.
The provider can configure a separate Root CA for each customer’s endpoint, issue client certificates to authorized devices, and then require valid certificates at the edge. Each customer gets its own trust domain, so a client authorized for one customer’s endpoint can’t use its certificate against another customer’s endpoint.
Setting it up
To take advantage of this, a SaaS provider first configures Cloudflare for SaaS and adds customer domains as Custom Hostnames. From there, mTLS authentication can be enabled in the Cloudflare for Teams dashboard with a few clicks.
The feature is currently in Beta and available to Enterprise customers. Feedback can be routed through the account team.
