When should organisations choose mTLS over DPoP for access tokens?

Why This Matters for Security Teams

Choosing between mTLS and DPoP is really a choice about where trust is anchored and how much of the path you control. mTLS binds the token to the client certificate at the transport layer, which is strong when you own both endpoints and the network path. DPoP binds the token to a signing key at the application layer, which helps when tokens cross gateways, browsers, or other intermediaries. Current guidance from the OWASP Non-Human Identity Top 10 is that proof-of-possession is only useful if it fits the actual threat path, not an idealised architecture.

That matters because token theft is still common in real environments. In Salesloft OAuth token breach style incidents, the attacker does not need to break the login flow if a bearer token can be replayed elsewhere. And in the Internet Archive breach, exposed credentials became the entry point for broader compromise. mTLS reduces replay risk more cleanly inside tightly controlled service meshes, while DPoP is often the better fit when intermediaries are unavoidable.

In practice, many security teams only discover the difference after a token has already been replayed through a gateway, reverse proxy, or browser-mediated flow.

How It Works in Practice

mTLS works best when the service can verify the client certificate on every connection and the certificate lifecycle is operationally manageable. The token is presented over a mutually authenticated TLS session, so the token holder must also prove possession of the client cert. That makes it a strong fit for service-to-service traffic, internal APIs, and environments with mature certificate automation. DPoP shifts the proof into the HTTP request itself: the client signs a request-specific proof with a private key, and the resource server checks that the access token is bound to the same key. This is useful when TLS terminates before the resource server or when a browser or mobile client cannot safely carry an mTLS cert.

• Use mTLS when service identity, network path, and certificate automation are under one operational boundary.
• Use DPoP when you need proof-of-possession across gateways, CDNs, or application-layer intermediaries.
• Prefer short token lifetimes either way, because proof-of-possession is not a substitute for rapid revocation.
• Treat token binding as one layer in a broader NHI control set, not as a standalone fix.

The operational lesson is reinforced by NHIMG research: Guide to the Secret Sprawl Challenge shows how easily secrets spread across systems, while Ultimate Guide to NHIs frames why identity binding must be designed around the real lifecycle of machine credentials. DPoP also aligns with application-layer policy checks described in OWASP Non-Human Identity Top 10, but it does not remove the need to secure the private key, validate clock skew, or handle key rollover carefully. These controls tend to break down in browser-heavy architectures with mixed legacy proxies because token binding can be lost or inconsistently enforced at the edge.

Common Variations and Edge Cases

Tighter token binding often increases operational overhead, so teams must balance replay resistance against certificate, key, and client-management complexity. There is no universal standard for every architecture yet, especially where sessions span browsers, mobile apps, and backend services at the same time.

For browser-based front ends, DPoP is usually more practical because mTLS client certificates are difficult to deploy and revoke at scale. For service meshes and east-west traffic, mTLS is often the cleaner choice because the trust boundary is narrower and certificate automation is usually already in place. For APIs exposed through third-party gateways, DPoP can preserve application-layer proof even when TLS is re-established downstream, but only if every hop validates the proof correctly. In high-risk environments, some organisations use both: mTLS internally between services, DPoP for external or semi-trusted clients. That hybrid model is not a requirement, but it is a common pattern where different trust boundaries coexist.

Teams should also account for token exposure outside code and runtime. The NHIMG research on secrets leakage shows that State of Secrets Sprawl 2026 found 28% of secrets incidents originate outside repositories, which is a reminder that binding alone does not solve credential distribution. The same governance logic applies in NHI-heavy environments: if the client key or certificate is poorly stored, either mTLS or DPoP can still be undermined. Best practice is evolving, but the practical rule is simple: choose the mechanism that matches the actual trust boundary, not the one that sounds stronger on paper.

Related resources from NHI Mgmt Group

• When should organisations use mTLS-bound tokens for API access?
• Why do passwordless rollouts still fail when organisations use temporary access passes?
• What are the implications of using OAuth tokens in third-party integrations?
• Why do ephemeral credentials still leave risk in machine access models?