ASD ISM 2147Cryptographically Bind Tokens and Session Cookies to Issuing Device
Stolen logins should be useless elsewhere: tokens, session cookies and refresh tokens only work on the device that originally received them.
Plain language
When a person signs in to a system, the system hands their device a set of credentials that keep them signed in: an authentication token, a session cookie, and often a refresh token that quietly renews the session in the background. These items are valuable because whoever holds them is treated as the signed-in user, without needing the password or a multi-factor prompt. This control requires that each of those items is cryptographically bound to the device it was issued to. In practice, the token or cookie is tied to a key that lives on that device and cannot be exported, so that the server can prove the presenting device is the same one that received the credential. If a copy of the token turns up on any other device, the proof fails and the server refuses it. Why it matters: token and cookie theft is one of the most common ways attackers bypass multi-factor authentication. Info-stealer malware, malicious browser extensions, adversary-in-the-middle phishing kits and compromised proxies all harvest session cookies and refresh tokens, then replay them from the attacker's own machine. Without device binding, a stolen token is as good as the user's identity for as long as it remains valid. With device binding, the theft yields nothing usable.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessSection
Credential managementTopic
Protecting authentication artefacts
Official control statement
Authentication tokens, session cookies and refresh tokens are cryptographically bound to the device on which they were issued.
Why it matters
If tokens, session cookies and refresh tokens are not bound to the issuing device, any copy that is stolen can be replayed from an attacker's machine to hijack the user's session. This sidesteps passwords and multi-factor authentication entirely, and refresh tokens in particular can keep an attacker signed in for days or weeks, giving persistent unauthorised access to email, data and administrative functions until the theft is noticed and every affected session is revoked.
Operational notes
Day to day, device binding is largely invisible to users when it is working: they sign in once and their session continues normally on that device. The operational effort sits with identity, platform and application teams.
Keep a current inventory of every place your organisation issues authentication tokens, session cookies or refresh tokens (identity providers, single sign-on, web applications, APIs, mobile apps) and record for each whether binding is enforced, in monitoring mode, or not yet supported. Watch the identity provider's sign-in and token logs for binding failures; a spike can indicate replay attempts or a client platform that has stopped presenting device proof after an update.
Expect some friction with older browsers, unmanaged devices and legacy applications that cannot present a device-bound proof. Decide in advance how these are handled (blocked, restricted, or given shorter sessions) and record the exceptions with an owner and a review date. When device-binding features in your identity platform, browsers or operating systems move from preview to general availability, or when new client platforms are onboarded, revisit enforcement settings so coverage does not silently shrink.
Implementation tips
- Identity team: enumerate every system that issues authentication tokens, session cookies or refresh tokens (identity provider, SSO, web apps, APIs, mobile apps) and record for each whether device binding is available, so you know the full scope before changing anything.
- Identity administrators: enable the device-bound token or token-protection feature in your identity provider so that sign-in sessions and refresh tokens are tied to a non-exportable key held on the device (for example in a TPM or secure enclave), and enforce it through conditional access or session policy.
- Application developers: for in-house web applications, implement bound session cookies using the browser's device-bound session mechanism or an equivalent proof-of-possession scheme, so the server verifies a device-held key signature before accepting the cookie.
- API and backend engineers: issue access and refresh tokens using a proof-of-possession profile (such as DPoP or mutual-TLS certificate binding) and configure the resource server to reject any token presented without a valid proof from the same key that received it.
- Platform team: roll binding out in report-only mode first, review the sign-in logs for clients that fail the device proof, remediate or formally exempt them, then switch each system to enforced mode and document the change.
Audit / evidence tips
- AskAsk for the list of systems that issue authentication tokens, session cookies or refresh tokens, and the status of device binding for each.Look atCheck that identity providers, SSO, web applications, APIs and mobile apps are all included, and that each has a clear status of enforced, monitoring or exempt.GoodEvery token-issuing system is listed, most are marked enforced, and any that are not have a documented exception with an owner and a review date.
- AskAsk for the identity provider's session and token protection policy configuration.Look atLook at whether the policy requires a device-bound (non-exportable key) proof for sign-in sessions and refresh tokens, and whether it is in enforce rather than report-only mode.GoodThe policy is enforced for all users and applications in scope, with a small, justified set of exclusions rather than broad carve-outs.
- AskAsk for design documentation or code for in-house web applications and APIs describing how cookies and tokens are bound to the device.Look atLook for a proof-of-possession mechanism (device-bound session cookies, DPoP or certificate-bound tokens) and server-side verification of the device signature on each request or refresh.GoodThe server rejects a cookie or token that arrives without a valid proof from the original device key, and this is tested as part of the release process.
- AskAsk for a demonstration or test record showing what happens when a valid token or cookie is copied to a different device and replayed.Look atCheck that the replay was attempted against production-equivalent configuration and that the response was recorded.GoodThe replayed token is rejected and the failure is visible in the sign-in or token logs, confirming binding works end to end.
- AskAsk for recent identity provider logs showing device-binding failures and how they were followed up.Look atLook for entries where a token was rejected due to a failed device proof and evidence that someone reviewed them.GoodFailures are logged with the user, application and device, are reviewed regularly, and unexplained clusters are investigated as possible token theft.
Cross-framework mappings
How ISM-2147 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.5 | ISM-2147 requires authentication tokens, session cookies and refresh tokens to be cryptographically bound to the device they were issued ... | |
handshakeSupports(1)expand_less | ||
| Annex A 5.15 | ISM-2147 requires cryptographic device binding for tokens and session cookies to prevent reuse of stolen session material on other devices | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.