An access token is a temporary digital credential that tells an online service what an authenticated user or application is allowed to access. After you sign in, a website or cloud service may use tokens so that you do not need to enter your password again for every page, file or API request.

That convenience creates an important security lesson: protecting the password is not enough if an attacker can obtain a valid token after authentication. A stolen token can sometimes be presented to a service as proof of an already authenticated session. Depending on the token, its scope and the system’s controls, the attacker may be able to act as the user until the token expires, is revoked or is otherwise rejected.

On 15 September 2026, the US National Institute of Standards and Technology (NIST) finalised NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. Developed in coordination with the US Cybersecurity and Infrastructure Security Agency (CISA), the report provides implementation guidance for protecting identity tokens, access tokens and related assertions across cloud services, single sign-on, federation, APIs and workload access.

This article explains the problem at a defensive, educational level. It does not provide instructions for stealing, forging or replaying tokens.

What is an access token?

When you log in to an online service, the system first needs to establish who you are. That process is called authentication. The service may check a password, passkey, security key, authenticator app or another factor.

After authentication, the system often creates or obtains a token. The token can contain or represent information such as:

  • which user or application has been authenticated;
  • which service issued the token;
  • which resources the token can access;
  • what actions are allowed;
  • when the token expires;
  • other security information required by the receiving system.

The service receiving the token then performs authorisation: deciding whether that token is valid for the requested action.

A useful analogy is an event wristband. You show identification when entering the venue, then receive a wristband that proves you have already been checked. Staff inside the venue inspect the wristband rather than asking for your passport at every doorway. If somebody else could take and successfully use that wristband, they might gain privileges intended for you.

Why do modern systems use tokens?

Tokens make modern digital systems practical. A single sign-in can give a user controlled access to several applications without repeatedly entering credentials. Applications can call APIs on a user’s behalf. Cloud services can exchange identity information across organisational boundaries. Automated workloads can prove their identity to other services.

These patterns are common in:

  • single sign-on (SSO);
  • cloud applications;
  • mobile and web apps;
  • application programming interfaces (APIs);
  • federated identity systems;
  • machine-to-machine and workload access.

NIST IR 8587 focuses on these environments because a token can become a valuable security target when it represents access to sensitive resources.

How is token theft different from password theft?

A password is usually used at the beginning of the authentication process. A token is often used after authentication has already succeeded.

This difference explains why token theft can be dangerous.

If an attacker steals only a password, a service may still stop them with multifactor authentication (MFA), device checks or another login control. If an attacker obtains a valid session or access token, however, the service may interpret it as evidence that authentication has already taken place.

This does not mean MFA is useless. MFA remains an important protection against many account-takeover attempts, and phishing-resistant MFA is especially valuable. It means organisations should protect the entire identity lifecycle, not just the login screen.

What does “session hijacking” mean?

A session is the period during which a service remembers that a user has authenticated. Tokens, cookies or related credentials can help maintain that state.

Session hijacking means an unauthorised party gains the ability to act within another user’s authenticated session. In a token-based system, one route is misuse of a valid token that was exposed or stolen.

The exact impact depends on the token’s permissions. A token with narrow access to one low-risk resource is very different from a token that can access email, cloud files, administrative tools or connected services.

This is why the principle of least privilege matters: tokens should grant only the access that is actually required.

How can tokens become exposed?

At a high level, tokens can be put at risk when they are stored, transmitted, logged or handled insecurely. They can also be exposed when an attacker compromises a browser, device, application, identity system or cloud environment.

Common risk categories include:

  • malware or device compromise;
  • phishing and malicious sign-in flows;
  • unsafe browser extensions or applications;
  • tokens accidentally written to logs or debugging output;
  • weak application or cloud configuration;
  • compromised signing or encryption keys;
  • inadequate token verification;
  • tokens that remain valid for too long;
  • excessive permissions attached to a token.

The important defensive lesson is that token security is both an endpoint problem and an architecture problem. Users need secure devices and good security habits, while organisations must design systems that limit how much damage one exposed token can cause.

Token theft is not the same as token forgery

NIST’s guidance distinguishes several related risks.

Token theft involves obtaining a legitimate token that was issued for somebody else. Token forgery involves creating or modifying something that a receiving service incorrectly accepts as legitimate. Token misuse is broader and includes using a valid or forged token in an unauthorised way.

These risks can require different controls. Preventing theft emphasises secure storage, transport and endpoint protection. Preventing forgery places additional importance on cryptographic keys, signatures and rigorous verification. Limiting misuse requires least privilege, monitoring, short lifetimes and effective revocation.

Why token verification matters

A service should not trust a token merely because it looks correctly formatted. It needs to verify that the token is appropriate for the request.

Depending on the architecture, verification can include checking:

  • the token’s cryptographic signature;
  • which trusted issuer created it;
  • which audience or service it was intended for;
  • whether it has expired;
  • whether its permissions cover the requested action;
  • whether it has been revoked or otherwise invalidated.

NIST IR 8587 specifically highlights stronger token verification, key management and lifecycle controls as core protections.

Why short token lifetimes help

A stolen credential is more dangerous when it remains useful for a long time.

Shorter token lifetimes reduce the period during which an exposed token can be misused. CISA guidance likewise recommends limiting session-token durations and requiring reauthentication when sessions expire.

There is a trade-off: making every token extremely short-lived can create usability and reliability problems. Organisations therefore need token lifetimes appropriate to the sensitivity of the resource, the type of user and the ability to renew or revoke access securely.

Why key management is critical

Many tokens are digitally signed. The receiving service checks that signature to confirm the token came from a trusted issuer and was not altered.

If the keys used to sign or protect tokens are compromised, the consequences can be much wider than one stolen user token. This is why NIST’s guidance emphasises strong key-management practices alongside token controls.

Organisations should protect signing keys, restrict access to them, rotate them when appropriate and have a plan for responding if key compromise is suspected.

What is token revocation?

Revocation means making a token unusable before its normal expiry time.

This is important when:

  • a user reports an account compromise;
  • a device is lost or stolen;
  • an employee’s access should end;
  • suspicious session activity is detected;
  • a token or key may have been exposed.

NIST’s final 2026 report expanded references to mechanisms for token revocation and for sharing signals about compromised or suspicious identity activity.

Why monitoring matters

Even strong preventive controls cannot guarantee that a token will never be exposed. Organisations therefore need the ability to detect suspicious use.

Useful monitoring can look for unexpected changes such as:

  • a session suddenly being used from an unusual device or environment;
  • access patterns that do not match the user’s normal role;
  • attempts to reach resources outside the expected token scope;
  • administrative actions that are unusual for the account;
  • simultaneous or otherwise implausible session activity.

Detection should be combined with a response capability so suspicious tokens and sessions can be investigated and revoked.

Why least privilege limits the damage

Least privilege means giving an identity only the permissions needed for its task.

If a token grants broad administrative access to many services, its theft has potentially severe consequences. If the same workflow can use a narrowly scoped token with access to only one resource and one type of action, the possible damage is much smaller.

For organisations, token design and access-control design are therefore closely connected.

What can ordinary users do?

Most people do not directly manage cryptographic tokens, but everyday security habits still reduce the chance that a device or authenticated session is compromised.

Use strong, phishing-resistant authentication where possible

CISA recommends MFA and encourages organisations to move towards phishing-resistant methods where supported. Passkeys and hardware-backed FIDO security keys are examples of authentication approaches designed to resist common credential-phishing techniques.

Keep devices, browsers and applications updated

Security updates close vulnerabilities that malware or malicious websites may otherwise exploit.

Be cautious with browser extensions and third-party applications

Extensions and applications can have substantial access to browser or account data. Install software from trusted sources, review permissions and remove extensions or applications you no longer use.

Treat unexpected sign-in requests carefully

Be suspicious of unexpected login pages, links and MFA prompts. Do not approve authentication requests you did not initiate.

Review active sessions

Many major services provide a security page showing signed-in devices or sessions. If an unfamiliar session appears, follow the service’s account-security process to sign it out and secure the account.

Secure the device itself

A strong account can still be at risk if the device using it is compromised. Use device locking, supported software, reputable security tools where appropriate and full-disk encryption when available.

What should organisations do?

NIST IR 8587 is primarily aimed at agencies and cloud service providers, but its design principles are useful more broadly.

A mature token-security programme should consider:

  • secure by design: make token protection part of architecture rather than an afterthought;
  • strong key management: protect the cryptographic keys used to sign and validate tokens;
  • rigorous verification: check issuer, audience, signature, expiry and authorisation;
  • controlled lifetimes: avoid unnecessarily long-lived access tokens and sessions;
  • least privilege: minimise token scopes and permissions;
  • revocation: provide a way to invalidate compromised access quickly;
  • continuous monitoring: identify suspicious token or session use;
  • secure SSO and federation: recognise that identity systems can become high-value shared infrastructure;
  • strong authentication: use phishing-resistant MFA where feasible;
  • incident readiness: know how to contain a token or key compromise before one occurs.

Common misconceptions

  • “If MFA is enabled, token theft cannot matter.” MFA is valuable, but a valid post-authentication token may sometimes be misused without repeating the original login challenge.
  • “Tokens are just another word for passwords.” No. Passwords and tokens play different roles in many systems, even though both require strong protection.
  • “A stolen token gives unlimited access forever.” Not necessarily. Tokens normally have defined permissions and lifetimes, and they may be revoked or rejected.
  • “Token security is only a cloud-provider problem.” Providers, application developers, administrators and end users all influence token risk.
  • “Long sessions are always better because users log in less often.” Longer sessions may improve convenience but can increase the useful lifetime of a compromised session.

If you suspect an account session has been compromised

Use the security controls provided by the affected service. Appropriate defensive steps can include signing out unfamiliar or all active sessions, changing compromised passwords, checking MFA settings, removing unknown applications or extensions, reviewing account activity and contacting the organisation’s security or support team.

For a workplace account, report the incident promptly rather than attempting to investigate it on your own. Security teams may need logs and session information that disappear over time.

Key takeaways

  • Access tokens are temporary digital credentials used after authentication to authorise access to resources.
  • A stolen valid token can sometimes let an attacker impersonate an already authenticated session without knowing the user’s password.
  • Token theft, token forgery and token misuse are related but distinct security problems.
  • NIST IR 8587 recommends stronger key management, token verification, lifecycle controls, secure-by-design architecture and continuous monitoring.
  • Short token lifetimes, least privilege and effective revocation can limit the impact of a compromise.
  • Users can reduce risk through strong authentication, updated devices, cautious software choices, phishing awareness and active-session reviews.

Frequently asked questions

Is an access token the same as a password?

No. A password commonly helps prove identity during login, while an access token is usually issued or obtained after authentication and used to authorise later requests.

Can an attacker use a token without knowing the password?

In some systems, yes. If the attacker has a valid bearer-style token and the receiving service accepts it, the service may not require the password again for each request. The result depends on the system and its security controls.

Does MFA prevent token theft?

MFA reduces many account-takeover risks, but it does not by itself protect every token after authentication. Token storage, verification, expiry, monitoring and revocation remain important.

Why not simply make every token expire immediately?

Very short lifetimes can improve security but can also make systems unusable or unreliable. Organisations need a risk-based balance combined with secure renewal and revocation.

What is NIST IR 8587?

It is the September 2026 NIST report Protecting Tokens and Assertions from Forgery, Theft, and Misuse, developed in coordination with CISA to provide implementation recommendations for agencies and cloud service providers.

Authoritative references

Suggested next learning step: learn the difference between authentication and authorisation, then explore how single sign-on and federated identity allow one trusted identity provider to grant controlled access across multiple services.