Mutual TLS Authentication (mTLS)

Complexity	Very High
Pros	Message Confidentiality Non-Repudiation (ensures webhook calls can be sent only by the webhook provider) Both webhook providers and consumers can revocate trust independently
Caveats	High complexity (compared against HMAC) Operational complexity on key issuance, rotation, and revocation
Examples	Adobe Sign DocuSign PagerDuty

The use of Mutual TLS (mTLS) authentication ensures that traffic is secure and trusted in both directions between webhook services and listeners. With mTLS, both webhook service and listener pass through a TLS handshake — in which both systems present trusted certificates — before the webhook notification is sent.

This method delivers a stronger authentication between the webhook service and listener and ensures communication confidentiality — a webhook message is sent only after both sides are authenticated. When combined with webhook signatures, it also delivers message integrity.

Mutual TLS with request signature validation

Security at the transport layer

Mutual TLS (mTLS) applies two-way encryption at the the transport layer. Like two-way SSL, mTLS works the same way with in most TCP communications, regardless of application-level protocol:

Webhooks leverage mTLS for two-way encryption similarly to protocols like HTTPS, SQL, and SSH.
mTLS can be combined with other webhooks security controls, such as HMAC. However, in most cases, mTLS provides enough security to mitigate the use of additional webhook controls.

Drawbacks

However, mTLS is often difficult to configure (when compared against HMAC). It also requires updates whenever TLS certificates are issued, renewed, or revoked both on the webhook service and the listener side. This additional burden is considered overkill for most webhook use-cases.