Shared devices compress the boundary between a customer session and an untrusted terminal. If the authentication flow relies on typed credentials or weakly bound tokens, attackers can exploit the kiosk or public device to capture access, replay sessions, or impersonate the customer. The risk rises because the terminal is visible, reusable, and often outside the customer’s private trust zone.
Why shared devices raise fraud exposure
Shared-device retail authentication is riskier because the terminal is not a stable trust anchor for a single customer. A kiosk, public tablet, or in-store workstation can expose keystrokes, cached sessions, browser state, and recovery paths to the next user, so the attacker does not need to defeat the customer’s own device. The control boundary is weaker from the start.
The practical problem is that the same terminal often serves many different shoppers, staff, or assisted-service workflows. When authentication is designed for convenience rather than strong session isolation, one successful login can leave behind a usable foothold for credential theft, session replay, or account takeover on the next interaction.
That is why retail fraud teams should treat device sharing as an access-control issue, not just a user-experience issue. The more the flow depends on typed passwords, reusable browser sessions, or weakly bound tokens, the more the shared terminal becomes part of the attack surface rather than a neutral channel.
Where fraud attempts concentrate on shared terminals
Fraudsters usually look for the weakest point in the interaction chain, not just the login form. On shared devices, that can mean shoulder surfing, keylogging, browser autofill abuse, token theft, forced logout failure, or session handoff between users who were never meant to share state. Once the attacker has a live session or a recoverable credential path, the retail trust model starts to fail.
CitrixBleed exploitation 2023 is a good reminder that session material can matter more than the initial password. If a device or gateway leaks a reusable session artifact, MFA may not stop follow-on abuse because the attacker is no longer authenticating from scratch.
Retail environments also face a blend of customer fraud and assisted-service abuse. An attacker may use a shared device to test stolen credentials, complete password reset flows, or exploit a session left open by the prior user. For customer identity programs, that makes recovery and step-up verification part of the fraud boundary, not just the sign-in boundary.
Why the control design must assume hostile reuse
Shared devices should be designed as hostile reuse environments: every session must be short-lived, tightly bound to the device context, and cleared before the next user arrives. If the browser, kiosk app, or identity flow allows a reusable bearer token to survive past the transaction, the fraud risk extends well beyond the login moment.
Phishing-resistant methods reduce the value of typed secrets on a public terminal. NIST SP 800-63 Digital Identity Guidelines reinforce the value of stronger authenticators and assurance levels when the authentication context is exposed or shared. In practice, device binding, step-up prompts, and short session windows matter more on retail kiosks than they do on a managed personal device.
Retail teams should also separate authentication strength from session containment. Strong login does not help if the customer can walk away and leave the account open, or if the next shopper can recover cached state from the same browser profile. The safest pattern is one that makes a completed session difficult to reuse, even if the terminal itself is compromised.
Risk and Threat Considerations
Shared-device fraud risk is not just about stolen passwords. The core exposure is that a public terminal can turn one authenticated customer action into a reusable access path for the next user, especially when sessions are long-lived or recovery is weak.
Failure mechanism: An attacker abuses the shared terminal to capture credentials, intercept or replay a session token, or exploit leftover browser state after the legitimate customer leaves. If the retail flow relies on a weakly bound session, the attacker can act as the customer without needing the customer’s device again.
Impact: The likely result is account takeover, unauthorized purchases, loyalty or wallet abuse, fraudulent returns, and escalation into payment or profile changes. At scale, the same flaw can produce repeated fraud losses because the terminal is reused by many customers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Shared-device retail auth depends on assurance, authenticators, and session binding. |
| Recommendation — Prefer phishing-resistant authenticators and step-up controls for exposed retail sessions. | ||
| OWASP ASVS | V7 — Session Management | Shared terminals are dangerous when session state survives user handoff. |
| V6 — Authentication | Retail kiosk logins are vulnerable when weak authenticators and recovery are exposed. | |
| Recommendation — Enforce short-lived, invalidated sessions and clear browser state on logout and timeout. Strengthen authentication and recovery before exposing sign-in on shared devices. | ||
| CIS Controls v8 | CIS-5 — Account Management | Retail fraud often exploits account recovery, reuse, and excessive access persistence. |
| Recommendation — Minimise standing access and remove stale account paths that survive device reuse. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Shared devices need continuous verification because the terminal cannot be inherently trusted. |
| Recommendation — Treat each retail session as untrusted and verify access continuously. | ||
Practitioner Guidance
What to verify: Confirm that every shared-device flow clears session state on logout, idle timeout, and handoff, and that bearer tokens cannot survive beyond the intended transaction window. If you cannot prove session invalidation, assume the terminal is reusable by the next user.
Decision rule: If the customer’s action can change value, payment method, delivery address, or account recovery settings, require stronger step-up authentication and a more tightly bound session than you would for a simple browse-only action.
What good looks like: The device should behave like a disposable access point, not a trusted endpoint. The safest retail pattern is one where the customer’s identity is re-verified for sensitive actions, and nothing meaningful remains on the device after the session ends.
Practitioner takeaway: Shared-device fraud is reduced less by “better passwords” than by eliminating durable session reuse and making each retail transaction self-contained, time-bounded, and hard to hand off to the next user.
Related resources from NHI Mgmt Group
- Why do SMS OTPs create higher fraud and recovery risk than device-bound authentication?
- Why do shared Digital Signature Certificates create higher fraud risk?
- Why do online rental and shared economy models create higher identity and fraud risk than traditional face-to-face transactions?
- Why does device flow create more authentication risk than PKCE?