"Remember This Device": Designing Trusted-Device Auth Without Lying to Users

Every product that adds a second factor eventually adds a checkbox next to it: Remember this device for 30 days. Users love it, because being challenged for a code every single morning is the fastest way to make them turn MFA off entirely. Security teams are nervous about it, correctly, because it is a deliberate hole in a control they just finished building.

The checkbox is fine. It is the implementation that determines whether it is a reasonable risk decision or a quiet nullification of your second factor. This article is about building it so that it is the former.

What is actually being remembered

Start here, because the mental model determines everything downstream.

"Remember this device" does not remember a device. Browsers do not expose a stable device identity, and every attempt to construct one from observable properties is either unreliable or a privacy problem. What you are actually doing is issuing a long-lived bearer credential, scoped to one user, that asserts: the second factor was satisfied on this browser profile at time T.

That reframing immediately answers several design questions. A bearer credential must be high-entropy and unguessable. It must be revocable. It must expire. It must be stored somewhere script cannot read it. It must be bound to the user it was issued for. Those are not novel requirements — they are the same requirements as any other credential, and they follow from calling the thing what it is.

It also tells you what the trust token is not: it is not a session. A session says "you are logged in." A device token says "on this browser, you already proved the second factor, so don't ask again." They have different lifetimes, they survive different events, and conflating them causes the bug where signing out destroys the device trust and users get challenged every single time despite having ticked the box.

Why device fingerprinting is the wrong tool

The tempting shortcut is to identify the device by its properties — user agent, screen resolution, timezone, installed fonts, canvas rendering, WebGL parameters — hash them into an identifier, and skip MFA when it matches. This is wrong on three independent axes.

It is not stable. A browser update changes the user agent. Plugging in an external monitor changes the screen dimensions. Travelling changes the timezone. Each of these silently invalidates the fingerprint and re-challenges a user who did nothing wrong. Meanwhile, the fingerprint is stable in exactly the wrong direction: browsers are actively reducing entropy — user agent reduction, canvas noise, font enumeration limits — so the signal degrades over time regardless of what you do.

It is not secret. Every input to a fingerprint is something the browser hands out. An attacker who can observe or guess the victim's environment — from a support ticket screenshot, a user agent in a log, a common device model — can reproduce it. A credential an attacker can construct is not a credential.

It is a tracking mechanism. Fingerprinting is the technique privacy engineering exists to defeat, and using it puts you in a category of behavior that browsers, regulators, and users are all moving against. Building a security control on top of it means building on something actively being removed.

Fingerprint-like signals do have a legitimate role — as risk inputs, not as identity. A trust token presented from a wildly different environment than it was issued in is a reason to re-challenge. That is anomaly detection, and it is additive. It is not the primitive.

The design

A trusted-device credential that holds up looks like this.

A random token in an HttpOnly cookie. 32 bytes from a CSPRNG. HttpOnly so XSS cannot exfiltrate it, Secure so it never crosses plaintext, SameSite=Lax so it is not sent on cross-site subresource requests. Store only a hash server-side, exactly as you would a refresh token.

Scoped to a single user. The row records which user it was issued for, and the token is only honoured for that user. Otherwise a shared machine turns into a machine where anyone's MFA is skipped. On a genuinely shared computer, two users should each get their own token, and neither should benefit from the other's.

Bound to a cookie path and domain you control. Not readable by subdomains that host user content. A trust cookie scoped to .example.com on a platform where customers get customer.example.com is a credential handed to every tenant.

An absolute expiry, and no sliding renewal. Thirty days is the common default. The important word is absolute: if every use extends the window, a device stays trusted forever, and "30 days" is a lie you told the user. Sliding renewal is defensible for low-risk products, but say so honestly in the UI, and cap it.

Recorded with context for the user, not for authorization. Store the IP, the parsed user agent, the approximate location, and the time it was created — so the user can look at a list and recognize "Chrome on Windows, Amsterdam, three weeks ago." Do not authorize against these fields. Binding to IP breaks every mobile user; binding to user agent breaks on every browser update.

trusted_devices
  id
  user_id
  token_hash          -- SHA-256 of the cookie value
  label               -- "Chrome on macOS" (display only)
  created_ip, created_ua, created_at
  last_used_at
  expires_at          -- absolute
  revoked_at

When the token must not be honoured

This is the part that separates a considered implementation from a checkbox. Skipping MFA is only acceptable when the risk profile has not changed. Enumerate the events that change it, and invalidate on all of them.

Password change or reset. Every trusted device dies. A reset is the canonical "I think I was compromised" action, and leaving a trust token alive means the attacker's browser skips MFA on the way back in. This is the single most commonly missed invalidation.

MFA enrollment changes. Adding, removing, or replacing a factor invalidates all device trust. Otherwise removing a factor is an operation whose effect is silently deferred.

Explicit "sign out everywhere." Users who click this mean it. Kill sessions and trust tokens together.

An organization policy change. In B2B, an admin who tightens the MFA policy expects it to apply now, not in 29 days.

Email address change. The recovery channel moved; re-verify the human.

And two more that are judgment calls rather than absolutes. A high-risk signal — impossible travel, a new autonomous system, a country the account has never been seen in — should re-challenge even with a valid token, because the token proves browser continuity and nothing about who is at the keyboard. And sensitive actions should always step up regardless of device trust: changing payment details, adding an admin, generating an API key, exporting data. Device trust buys you a quieter daily login. It should never buy you a free pass on the operations that matter.

The revocation surface users need

A trusted-device list is not a nice-to-have; it is the control that makes the whole feature defensible. It belongs next to the active sessions list, and it needs three properties.

It must be legible: "Chrome on macOS · Berlin, Germany · trusted 12 days ago · last used 2 hours ago" is something a person can evaluate. A row of opaque identifiers is not.

It must be actionable: revoke one, revoke all, in one click, with immediate effect. Immediate means the next request from that device is challenged — so the check has to hit the store rather than trusting a cached decision.

It must be honest about the current device: mark which row is the browser the user is looking at, or they will revoke it, get challenged, and file a bug.

Pair this with a notification when a new device is trusted. That message — "MFA was skipped for a new device in Frankfurt" — is often the first thing a user sees when someone else has their password and their code. It is worth the email.

What this does to your threat model

Be clear-eyed about what you have traded away, because "we have MFA" stops being true in the general case once trust tokens exist.

The residual risk is theft of the trust cookie. HttpOnly covers script-based exfiltration. It does not cover malware on the device, a stolen unlocked laptop, or a malicious browser extension with cookie access. In each of those cases the attacker also likely has the session cookie, so the marginal loss is smaller than it first appears — but the trust token outlives the session, which means it extends the attacker's window well past a session timeout. That is the specific thing you are accepting.

The mitigations are the ones above: absolute expiry, invalidation on credential changes, step-up for sensitive actions, and a visible revocation list. Together they bound the damage to "an attacker with device-level access gets a quieter login for at most N days, and cannot perform privileged operations without a fresh challenge."

There is also a strictly better answer available now. A passkey is a device-bound, phishing-resistant credential unlocked by a local biometric — which is, functionally, "remember this device" done properly, with the secret in hardware instead of a cookie. If your users can enroll a passkey, the pressure to weaken MFA with a trust token largely disappears, because the second factor stopped being annoying. The right long-term move for most products is to make trusted-device trust the fallback for password+TOTP users, and to invest in getting people onto passkeys instead.

Getting the UX right

Small things, disproportionate effect.

Default the checkbox off. A security relaxation should be a choice, not something that happens to a user who did not read the line.

Say what it means in plain language. "Skip the code on this browser for 30 days. Don't use this on a shared computer." That second sentence prevents real incidents.

Never show it in a private/incognito window — the storage is discarded anyway, so ticking it does nothing and teaches the user the feature is broken.

Tell them when it expires, in the settings list. "Expires in 6 days" turns a mysterious re-challenge into an expected one.

Key takeaways

• You are issuing a bearer credential, not identifying a device. Design accordingly: random, hashed, HttpOnly, scoped, expiring, revocable.
• Do not build it on fingerprinting. Unstable, not secret, and moving against the grain of the platform. Use those signals for risk, never for identity.
• Absolute expiry, not sliding — or the "30 days" in your UI is untrue.
• Invalidate on password change, MFA change, sign-out-everywhere, policy change, and email change. The password-reset case is the one everyone forgets.
• Always step up for sensitive actions, trusted device or not.
• Ship a visible, revocable device list and notify on new trusted devices.
• Long term, passkeys solve the underlying problem better than remembering devices does.

EmbedAuth treats device trust as a first-class, revocable credential alongside sessions — with absolute expiry, automatic invalidation on credential changes, and a device list your users can see and clear themselves.