Notifications
Clear all
Topic starter
22/06/2026 5:01 pm
TL;DR: Replacing OAuth client secrets with asymmetric key-based assertions and short-lived tokens materially reduces secret exposure and replay risk for machine-to-machine authentication, according to Scramble ID. The remaining failure points are operational ones: clock drift, replay-cache design, and key lifecycle discipline, not the authentication pattern itself.
NHIMG editorial — based on content published by Scramble ID: M2M Authentication Without Secrets
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step JWT client assertion claim handling for OAuth token endpoints, including audience, TTL, and replay checks.
- Implementation guidance for replay caches, clock leeway, and NTP validation across workloads and containers.
- Key storage and signing patterns using KMS, HSM, TPM, and sidecar-based signing agents.
- Rotation, emergency revoke, and mass-compromise runbook details for production machine identities.
👉 Read Scramble ID's guide to machine-to-machine authentication without secrets →
M2M authentication without secrets: are your token flows replay-safe?
Explore further
22/06/2026 5:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: M2M authentication without secrets reduces client secret blast radius
