When should teams add mTLS or DPoP to machine token flows?

Add sender constraints when a stolen access token would create meaningful lateral movement or downstream impersonation risk. mTLS is appropriate when you control the transport path, while DPoP is better for more diverse clients. Both make copied tokens far less useful than plain bearer tokens.

Why This Matters for Security Teams

Bearer tokens are convenient because they are portable, but that portability is exactly why a stolen token can become a lateral movement primitive. Sender-constrained token flows reduce that risk by binding the token to a specific client key or TLS channel, so copy-and-replay attacks become much less useful. That matters most for machine identities, where tokens often unlock APIs, pipelines, and admin functions with no human challenge step.

Security teams often miss this boundary until a token is reused outside its intended context, as seen in incidents such as the Salesloft OAuth token breach and the JetBrains GitHub plugin token exposure. NIST’s Cybersecurity Framework 2.0 reinforces that identity assurance and access control need to match the risk of the protected asset, not just the convenience of the client. In practice, many security teams encounter token replay only after a downstream service has already been impersonated.

How It Works in Practice

mTLS and DPoP both add sender constraints, but they do it differently. mTLS binds the token to a client certificate and the TLS session, so the token is only useful when presented over the expected mutual-authenticated channel. DPoP binds the token to a cryptographic proof created by the client at request time, which is usually easier for browser-based, mobile, or distributed workloads that cannot reliably hold a stable client certificate.

For machine token flows, the practical decision is usually driven by control over the transport and client environment. If the service-to-service path is private, stable, and under your operational control, mTLS is often the cleanest choice. If the client fleet is diverse, ephemeral, or externally distributed, DPoP is often more workable. Both are stronger than plain bearer tokens because the attacker must steal both the token and the sender proof, not just the token itself.

• Use mTLS when you can manage certificates, trust anchors, and service endpoints centrally.
• Use DPoP when clients are varied and you need proof-of-possession without full TLS client certificate management.
• Combine sender constraints with short TTLs and automated revocation, because binding alone does not solve long-lived exposure.
• Review token audience, scope, and downstream delegation paths so a bound token cannot be over-privileged.

NHIMG research on the State of Secrets Sprawl 2026 shows how quickly exposed credentials can outlive their intended trust boundary, which is why binding and rotation need to be paired. The operational lesson is reinforced by the Guide to the Secret Sprawl Challenge, where secret proliferation turns one compromise into many. These controls tend to break down when legacy services only accept bearer tokens or when intermediaries terminate and reissue requests without preserving the sender proof.

Common Variations and Edge Cases

Tighter token binding often increases operational overhead, requiring organisations to balance replay resistance against certificate, key, and client-management complexity. That tradeoff is real, especially in multi-cloud estates and mixed legacy-modern environments.

Current guidance suggests using sender constraints for any machine token that could unlock privileged APIs, cross-tenant data, CI/CD controls, or agentic workflows that can chain actions automatically. For lower-risk machine calls, the added friction may not justify the cost. There is no universal standard for this yet, but the current best practice is to treat mTLS and DPoP as risk-reduction controls, not universal defaults.

Edge cases matter. mTLS can be awkward when workloads scale rapidly or move across platforms that do not share certificate issuance and trust policy. DPoP can be awkward when clients cannot safely protect private keys or when request forwarding breaks the proof chain. In both cases, teams should validate how token binding behaves through proxies, gateways, and service meshes before declaring the control effective.

For machine identities, the right question is not whether a token is authentic, but whether a stolen token is still usable outside its intended sender context. That framing aligns with NIST’s identity and access principles and with NHIMG’s repeated finding that exposed secrets remain exploitable long after initial compromise.

Related resources from NHI Mgmt Group

• How do teams decide whether to keep weak fallback methods in sensitive flows?
• How should teams add phishing-resistant MFA to Entra ID without rebuilding access policy?
• Which control should teams add when workloads cross trust boundaries?
• How should security teams implement sender-constrained tokens for machine identities?