Shorter device-trust lifetimes improve security but increase verification frequency
Aliases: device trust lifetime · remember this device · trusted session lifetime
What it is
The trusted-device lifetime tradeoff sets how long a device can access without repeating a second factor after strong authentication. A shorter lifetime usually narrows the maximum usefulness of a stolen device or token but challenges legitimate users more often. Lock state, risk change, and sensitive action also need to affect lifetime.
Why it happens
“Remember this device” often uses a long-lived cookie, device key, or session token rather than continuous proof of owner control. Fixed expiry ignores sharing, loss, logout, and sudden risk. Short periods encourage persistent browser sessions or weaker channels; long periods preserve stale trust. Unbounded sliding renewal can make a nominal lifetime indefinite.
Studying it
Compare fixed, idle, and risk-revoked lifetimes on challenge count, login completion, lockout, post-loss window, and takeover. Simulate token copying, sharing, lock, password change, and loss report to test termination. Separate calendar lifetime, idle lifetime, and continuously renewed effective lifetime.
Where it stops holding
Short expiry does not stop an active session hijack, while hardware binding, strong lock, and behavior monitoring can reduce risk during a longer period. Public terminals should not get persistent trust; managed personal devices may. Cookie deletion and privacy tools can cause extra challenges without indicating attack.
Applying it
- Set lifetime from device ownership, protection, and account harm instead of one duration for every context.
- Use both an absolute cap and idle expiry and revoke on lock, loss report, credential reset, and risk escalation.
- Show trusted devices, recent use, and expiry with remote termination; do not rely on an application-supplied name alone.
- Monitor the net effect of lifetime changes on attack window, challenge frequency, and avoidance behavior.