Credential theft vs token theft: why SaaS controls miss both

At a glance

What this is: This article explains the difference between credential theft and token theft, and shows why stolen tokens can bypass MFA in SaaS environments.

Why it matters: IAM and NHI teams need separate controls for authentication events and post-authentication session abuse, or they will miss the most damaging SaaS account takeovers.

By the numbers:

• Credential theft remains the dominant attack vector at 88% of breaches.
• PhaaS platforms now capture both credentials and tokens simultaneously in 63% of incidents.
• Threat actors exploit stolen credentials within an average of 14 minutes.
• Security teams blocked 4.2 billion credential stuffing attempts in 2025.

👉 Read Obsidian Security's analysis of credential theft versus token theft in SaaS

Context

Credential theft and token theft are related but operationally different attack paths. Credential theft targets passwords and MFA challenges at the login stage, while token theft targets already-authenticated session artifacts such as bearer tokens and OAuth refresh tokens. For NHI governance, that difference matters because tokens are still identities in motion, and many IAM programmes treat them as a second-order control problem instead of a primary access surface.

In SaaS environments, the security gap is not just initial access. Once a token is stolen, the attacker can often act as the legitimate user without generating the usual authentication signals. That makes discovery, rotation, revocation, and integration inventory central to NHI defence rather than optional hygiene. The article’s starting position is typical for teams that have focused more on login hardening than on post-authentication control.

Credential theft also intersects directly with service accounts, OAuth integrations, and app-to-app trust. If defenders only watch for failed logins, they will miss abuse that starts after authentication has already succeeded. The source article is useful because it frames the problem in practical SaaS terms that most mature IAM programmes are now encountering.

Key questions

Q: How should security teams respond when a SaaS session token is stolen?

A: Revoke the token immediately, force reauthentication, and review all connected apps that could still trust the compromised session. If the token has broad scopes, treat the event like an account takeover and rotate related secrets at the same time. Password resets alone do not close the session if the token remains valid.

Q: Why do stolen tokens bypass MFA?

A: MFA is checked during login, but a stolen token is already proof that login succeeded. Once an attacker has that token, they can often act as the authenticated user without facing another MFA challenge. That is why session protection and token revocation matter as much as the login flow.

Q: What is the difference between credential theft and token theft?

A: Credential theft steals secrets used to authenticate, such as passwords or MFA codes, while token theft steals the session artifact that already proves authentication. Credentials trigger login events; tokens usually do not. In SaaS, that distinction changes both detection and response because token abuse can continue after password resets.

Q: Should organisations prioritise token controls before expanding SaaS access?

A: Yes. Expanding SaaS access without token governance increases the number of identities and integrations that can be abused after login. Organisations should first inventory tokens, reduce token lifetime, and review delegated permissions. Otherwise, every new SaaS connection widens the attack surface without improving control.

Technical breakdown

How credential theft differs from token theft in SaaS

Credential theft captures usernames, passwords, and sometimes MFA codes before or during authentication. That creates login events, failed attempts, and other traces that identity teams can monitor. Token theft, by contrast, captures bearer artifacts such as session cookies or OAuth refresh tokens after authentication has already succeeded. Those tokens are accepted as proof of identity until they expire or are revoked. In SaaS, this is especially dangerous because refresh tokens can mint new access tokens without re-entering credentials, and OAuth scopes can extend the blast radius across connected applications.

Practical implication: Treat token inventory and revocation as first-class IAM controls, not just password-management issues.

Why MFA does not stop token theft

MFA strengthens authentication, but it does not continuously protect an active session. If an attacker steals a session token after the user has completed MFA, the attacker inherits that authenticated state and can often bypass additional prompts. Adversary-in-the-middle phishing makes this worse by capturing credentials and the issued token in one flow. The control failure is structural: MFA is evaluated at login, while token abuse happens after login. That is why a successful sign-in can still be the start of compromise rather than proof of safety.

Practical implication: Add session risk controls such as token binding, conditional access, and forced reauthentication on abnormal behaviour.

How OAuth refresh tokens extend attacker dwell time

OAuth refresh tokens are long-lived credentials that let systems obtain new access tokens without user intervention. In practice, they act like reusable session keys. If an attacker steals one, they may maintain access long after passwords are reset, especially where integrations are overprivileged or poorly inventoried. The governance problem is not only token theft itself, but the trust chain behind the token. Connected apps, API permissions, and service account links can turn one stolen token into SaaS-to-SaaS lateral movement.

Practical implication: Shorten token lifetimes, rotate refresh tokens, and review third-party app scopes as part of routine access governance.

Threat narrative

Attacker objective: The attacker wants persistent SaaS access that survives password resets and provides reach into connected applications without detection.

1. Entry occurs through phishing, credential stuffing, or adversary-in-the-middle techniques that capture login secrets and the resulting session token.
2. Escalation happens when the attacker uses the token to impersonate the user without triggering new authentication or MFA prompts.
3. Impact follows when the attacker accesses email, files, and connected SaaS applications, then uses those links for lateral movement or exfiltration.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Token theft is no longer a niche follow-on technique, it is a primary identity compromise path. Security teams that still anchor detection on failed logins are looking at the wrong control plane. In SaaS, the decisive event often happens after authentication, when a bearer token or refresh token becomes the real access credential. Practitioners should treat session abuse as an identity problem, not only a threat-detection problem.

Ephemeral session trust debt is the right way to describe this risk. The organisation believes an MFA-protected login has created trust, but that trust continues far beyond the authentication event if sessions are long-lived and poorly governed. That debt accumulates across OAuth apps, third-party integrations, and service-linked access, which means remediation must include revocation, scope reduction, and integration inventory. The practical conclusion is that session governance now belongs in core IAM and NHI controls.

Unified control of credentials and tokens is the only durable response. Separate teams and separate tools for password events on one side and session abuse on the other create blind spots that attackers exploit. Behavioural signals, token lifecycle controls, and integration review need to operate as one programme. Practitioners should align identity telemetry with post-authentication policy enforcement before the next compromise tests the gap.

SaaS lateral movement is the category-defining risk hidden inside token theft. A stolen token rarely stops at a single mailbox or file repository if it carries delegated access into connected apps. That makes overprivileged OAuth scopes and stale integrations a structural exposure, not an edge case. Security teams should re-evaluate every trusted connection as part of NHI governance, because the real blast radius is usually wider than the first compromised account.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, 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 pattern reinforces the need to separate login hardening from token governance, as covered in 52 NHI Breaches Analysis.

What this signals

Ephemeral credential trust debt is becoming the right lens for SaaS identity risk. Once a token exists, it extends trust beyond the original authentication event, which means the organisation is carrying hidden access debt until that token is revoked or expires. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader problem is that machine-readable access artefacts are spreading faster than governance teams can catalogue them.

The programme implication is straightforward: treat tokens, session cookies, OAuth grants, and service-account credentials as one exposure class in your control model. That aligns better with NIST CSF 2.0 access governance and with the practical reality that post-authentication abuse rarely looks like a failed login. Teams that continue to separate IAM, SaaS admin, and threat detection workflows will keep missing the abuse path that matters most.

For practitioners building an operating model, the next step is continuous review of integration permissions and reauthentication triggers, not just password policy. The more SaaS estates rely on delegated access, the more conditional access, token lifetime limits, and revocation automation become baseline controls rather than advanced hardening.

For practitioners

• Inventory every active token path Map session cookies, OAuth refresh tokens, API keys, and service-account credentials across your SaaS stack so you can see which identities can act without a fresh login. Include third-party integrations and delegated apps in the same inventory.
• Shorten token lifetime and rotation windows Set low maximum lifetimes for access tokens, rotate refresh tokens after use, and require reauthentication for higher-risk actions. Pair that with explicit revocation procedures so stolen tokens stop working quickly.
• Detect behaviour after authentication Monitor ASN changes, unusual User-Agent patterns, device drift, impossible travel, and token reuse across locations because these signals often appear when logins look legitimate but sessions are abused.
• Rework incident response for dual theft When you suspect compromise, reset passwords and revoke active sessions together, then review connected app scopes to stop the attacker from pivoting through a valid token chain.

Key takeaways

• Credential theft and token theft are different failure modes, and SaaS defenders need controls for both.
• MFA reduces login risk, but it does not stop stolen session tokens from being used as valid access.
• The operational priority is unified visibility across credentials, tokens, and integrations before attackers chain them together.

Key terms

• Credential Theft: Credential theft is the unauthorized capture of secrets used to authenticate a user or workload, such as passwords, MFA codes, or security questions. In SaaS environments, it usually produces login events that defenders can inspect, but it still becomes dangerous when attackers combine it with token abuse or integration misuse.
• Token Theft: Token theft is the capture of an already-issued session artifact such as a bearer token, session cookie, or OAuth refresh token. Because the token already represents authenticated access, the attacker can often act without triggering a new login or MFA challenge, which makes detection much harder.
• OAuth Refresh Token: An OAuth refresh token is a long-lived credential that lets an application request new access tokens without asking the user to log in again. In practice, it behaves like a reusable access key, so compromise can create persistent access until the token is revoked or expires.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.

Deepen your knowledge

Credential theft vs token theft is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls for SaaS environments, it is a useful place to start.

This post draws on content published by Obsidian Security: Credential Theft vs Token Theft: Understanding the Difference. Read the original.