Notifications
Clear all
Topic starter
02/09/2026 3:57 pm
TL;DR: Stolen tokens remain usable when security treats presentation as proof of authorization, according to SecureAuth’s analysis of token security and Zero Trust principles. The core problem is trust in static token validation: once tokens are replayed, stolen, or context-shifted, access decisions must depend on current risk signals, not signature checks alone.
NHIMG editorial — based on content published by SecureAuth: Zero Trust Token Security
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.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when token signatures are not validated with a strong cryptographic algorithm?
A: If token signatures are not validated properly, attackers may forge tokens, alter claims, or bypass access controls.
Q: Why do stolen tokens remain dangerous even when authentication is strong?
A: Strong authentication only helps at the point of issuance.
Q: How should security teams decide when to step up or deny token use?
A: Use step-up or denial when the token is presented from a different device, a different network, or a behavioural pattern that does not match the original session.
Practitioner guidance
- Bind tokens to current context Require device, network, and behavioural context checks at presentation time so a replay from a different environment triggers step-up or denial.
- Shorten token lifetime where risk is high Use short-lived tokens for sensitive workflows and pair them with continuous refresh so legitimate users keep working while stolen tokens lose value quickly.
- Detect replay as an identity event Instrument SIEM and identity telemetry to flag repeated token use from mismatched context, abnormal session transitions, or multiple geographies within one validity window.
What's in the full article
SecureAuth's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how token theft occurs through XSS, MITM, and compromised devices
- The platform's detailed approach to continuous risk scoring and behavioural verification
- How context binding changes session decisions for different identity scenarios
- Deployment considerations for teams using Continuous Authority in production environments
👉 Read SecureAuth's analysis of zero trust token security and session trust →
Token security under zero trust: are your controls keeping up?
Explore further
02/09/2026 3:58 pm
Token validity is not the same as session legitimacy: The article exposes a control assumption that many identity programmes still carry forward from earlier authentication models. A token can be structurally valid while the surrounding context has changed enough that access should no longer be trusted. The implication is that token governance must be treated as continuous decisioning, not a one-time issuance event.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
- The same research found that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
A question worth separating out:
Q: Should organisations use short-lived tokens or continuous refresh first?
A: Short-lived tokens should come first when the primary problem is replay and token theft. Continuous refresh then preserves usability by revalidating the session in the background so users are not forced back through interactive login too often. Together, they reduce attacker dwell time without turning every session into a hard reset.
👉 Read our full editorial: Token security needs zero trust to stop stolen token abuse
