M2M authentication without secrets reduces client secret blast radius

At a glance

What this is: This is a standards-based approach to machine-to-machine authentication that replaces shared client secrets with asymmetric keys, JWT assertions, and replay-resistant short-lived tokens.

Why it matters: It matters because IAM and security teams can shrink the blast radius of leaked machine credentials while aligning workload authentication with stronger lifecycle, token, and replay controls.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Scramble ID's guide to machine-to-machine authentication without secrets

Context

Machine-to-machine authentication is the problem of proving a workload or service identity without relying on long-lived shared secrets. The current model fails because client secrets are easy to copy, hard to contain, and often survive far beyond the moment they are first exposed, which turns a single leak into persistent impersonation risk for NHI programmes.

Scramble ID's position is straightforward: the safer pattern is cryptographic client authentication with short-lived assertions, replay checks, and sender constraints where token theft is plausible. That shifts identity governance from secret storage to key lifecycle, token validation, and operational resilience, which is where modern NHI controls already need to move.

This is a typical machine identity problem, but the same pattern increasingly affects API security, CI/CD workloads, and any autonomous system that depends on non-interactive access paths.

Key questions

Q: How should security teams replace client secrets in machine-to-machine authentication?

A: Use asymmetric key pairs and JWT client assertions so the client proves possession of a private key at token time instead of reusing a shared secret. Pair that with short-lived access tokens, replay detection, and careful key lifecycle management. That reduces blast radius and removes the most common secret leakage failure mode for non-human identities.

Q: Why do shared secrets remain a high-risk pattern for workload identity?

A: Shared secrets are easy to copy into code, build logs, and environment variables, and they remain valid until someone rotates them. That means one leak can create long-lived impersonation across multiple systems. For machine identities, the risk is not just exposure, but the persistence of the credential after exposure.

Q: What breaks when replay prevention is not designed carefully for signed assertions?

A: Valid traffic can be misclassified as replay if the TTL is too short, the clock drifts, or the jti cache is incomplete. The result is either false positives that interrupt service or weak validation that lets attackers reuse assertions. Reliable replay defence needs both accurate time and strict nonce tracking.

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

A: 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.

Technical breakdown

JWT client assertions replace shared client secrets

RFC 7523 lets a workload authenticate by signing a JWT with a private key instead of presenting a reusable secret. The authorization server validates the signature, audience, expiry, and replay token before minting a short-lived access token. That changes the trust model from possession of a static bearer secret to proof of control over a private key at request time. The practical advantage is containment: compromise of one assertion does not expose a reusable credential. This is a workload identity pattern, not a human login substitute.

Practical implication: move machine clients off shared secrets and onto key-based assertions wherever the downstream service supports OAuth token exchange.

Replay resistance depends on TTL and jti enforcement

A signed assertion is still replayable if it lives too long or if reuse is not tracked. The article's recommended pattern is a very short expiry, unique jti values, and a replay cache that rejects duplicate assertion identifiers within the valid window. That only works when time sync is reliable, because the verifier must distinguish legitimate clock drift from malicious reuse. In practice, this is where many deployments fail: not cryptography, but validation discipline.

Practical implication: enforce sub-minute assertion lifetimes, cache jti reuse, and verify workload time synchronisation before tightening validation.

Sender-constrained tokens narrow bearer-token abuse

If an access token can be copied from logs, proxies, or memory, a bearer model still allows replay even after the original assertion is spent. mTLS binds the token to a client certificate, while DPoP binds it to a proof key at the application layer. Both make stolen tokens materially less useful because the attacker cannot simply paste the token into another session. The choice is architectural: mTLS fits controlled internal paths, while DPoP is more flexible for diverse clients.

Practical implication: add mTLS or DPoP when token theft would create unacceptable lateral movement or downstream impersonation risk.

Threat narrative

Attacker objective: The attacker wants durable, reusable machine access that survives the original leak and can be used to impersonate services at scale.

1. Entry occurs when a client secret is copied from a repository, build log, or environment variable and becomes usable outside the workload that created it.
2. Escalation happens because that shared secret can mint tokens repeatedly with no native proof that the requester is still the legitimate client.
3. Impact follows when the leaked secret enables silent, long-lived impersonation of machine identities across services and environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client-secret authentication was designed for a world where machine access could be trusted to remain static between issuance and use. That assumption fails when workloads copy secrets into repos, logs, and pipelines, because the secret is no longer bound to the original runtime context. The implication is not just better storage, but a different identity model for non-human clients.

Ephemeral credential trust debt: short-lived tokens reduce exposure, but they do not remove the governance burden created by static trust at the point of authentication. Once a client secret has existed, every duplicate copy expands the trust surface beyond the original workload boundary. Practitioners should treat repeated secret propagation as accumulated identity debt, not an isolated hygiene issue.

Replay prevention only works when identity validation is operationally precise. Tight TTLs, unique jti enforcement, and time synchronisation are not optional implementation details, because a cryptographic assertion is only as trustworthy as its validation window. That makes replay handling a control-plane discipline, not a developer convenience.

Machine identity governance must move from credential ownership to key lifecycle ownership. The real control question is no longer who knows the secret, but who can enroll, rotate, revoke, and audit the private key that proves the workload's identity. That is the governance boundary NHI programmes need to formalise.

Sender-constrained access is the point where bearer-token convenience stops being acceptable. If downstream tokens can be copied and reused, then the authentication layer has not yet reduced blast radius enough for high-value workloads. Practitioners should use proof-of-possession as the deciding line between acceptable and excessive token portability.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• That trend makes the Guide to the Secret Sprawl Challenge the natural next resource for teams redesigning secret handling and rotation.

What this signals

Ephemeral credential trust debt: the industry is moving away from static shared secrets, but most programmes have not yet absorbed the operational cost of key enrollment, assertion validation, and emergency revocation. As machine identity scales, the control gap shifts from storage to lifecycle, and that is where governance needs to be measured.

The operational signal to watch is whether your programme can rotate, revoke, and attest machine credentials without touching application code. If it cannot, you still have a secrets problem, even if the authentication pattern looks modern on paper. The right benchmark is not just token issuance success, but how quickly a compromised client can be quarantined and re-keyed.

For teams standardising on workload identity, the relevant next step is to align cryptographic authentication with broader identity lifecycle controls. That means treating signing keys, replay caches, and sender-constrained tokens as governed assets, not implementation details, and mapping them to OWASP Non-Human Identity Top 10 and 52 NHI Breaches Analysis for control design and incident learning.

For practitioners

• Replace shared client secrets with key-based client assertions Use asymmetric keys and JWT client assertions for machine-to-machine OAuth flows where the authorization server supports RFC 7523. Keep the private key inside KMS, HSM, or platform-native signing infrastructure instead of distributing a reusable secret.
• Enforce short assertion lifetimes and replay caches Set assertion expiry to tens of seconds, require unique jti values, and store replay identifiers in a cache sized to the full validity window plus clock leeway. Reject duplicate assertions even if the signature is valid.
• Verify workload time synchronisation before tightening validation Check that every signing workload and every verifier is on NTP or an equivalent time service, then confirm drift stays sub-second in production. Tight TTLs break down quickly when clocks are inconsistent across hosts or containers.
• Add sender constraints where token replay would matter Use mTLS or DPoP for high-risk token flows so that stolen access tokens cannot be replayed from another client. Reserve bearer-style portability for low-risk paths where replay would not materially expand blast radius.
• Plan rotation and emergency revocation as a runbook Maintain overlap windows for key rotation, predefine emergency revocation steps, and track which client alias, kid, and downstream token set is affected when a signing key is suspected to be compromised.

Key takeaways

• Shared client secrets create persistent impersonation risk because once they leak, they can keep minting access until manually revoked.
• JWT client assertions, short expiries, replay caches, and sender constraints form the practical control set that shrinks machine identity blast radius.
• Identity teams should treat key lifecycle, time synchronisation, and revocation speed as first-class controls, not implementation details.

Key terms

• Jwt Client Assertion: A JWT client assertion is a signed proof a workload presents to an authorization server instead of a shared secret. It lets the server verify identity using cryptography and a known public key, which is safer than reusing a portable credential across many systems.
• Sender-constrained token: A sender-constrained token is an access token that can only be used by the client that originally proved possession of the binding key or certificate. In practice, that reduces replay value if the token is copied from a log, proxy, or memory dump.
• Replay cache: A replay cache stores recently seen assertion identifiers so the same signed request cannot be accepted twice. For non-human identities, it is a control that converts valid cryptographic proof into one-time use authorisation, provided the cache window matches the assertion lifetime.
• Workload identity: Workload identity is the governed identity assigned to a service, job, or application rather than a person. It is used to authenticate machine access to APIs and downstream systems, and it should be managed with the same lifecycle discipline as any other identity type.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: M2M Authentication Without Secrets. Read the original.