Omnichannel retail authentication is shifting beyond single-session login

At a glance

What this is: This is a product-led analysis of omnichannel retail authentication, arguing that login must travel with the customer across devices, channels, and shared endpoints rather than end at a single browser session.

Why it matters: It matters because IAM teams supporting customer identity, kiosks, and mobile journeys need to balance friction, fraud resistance, and session continuity across mixed retail touchpoints.

By the numbers:

• 73% of consumers shop across several channels during their buying journey.

Context

Retail authentication is increasingly a journey problem, not a login-screen problem. In omnichannel retail, the same customer may move from a phone to a kiosk to a loyalty app and back again, while the identity layer is expected to preserve trust and context across each step.

That shift matters for customer identity and access management because the control point is no longer a single authenticated session. The governing question becomes how authentication, step-up checks, and device trust adapt as the customer changes channel, device, and risk posture.

The article frames this as an experience and security trade-off, but the deeper issue is that retail identity is now session-continuous across human, device, and channel boundaries. That is the baseline practitioners have to design for, not an edge case.

Key questions

Q: How should retailers design authentication for customers moving between mobile apps and kiosks?

A: Retailers should design authentication as a continuous identity journey, not a single login event. The practical model is to preserve customer state across channels while re-evaluating trust at each handoff. That means device awareness, step-up checks, and clear session boundaries for shared endpoints so the experience stays smooth without letting a weak device inherit full trust.

Q: Why does shared-device retail authentication create higher fraud risk?

A: 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.

Q: What are the signs that retail authentication is too static for omnichannel journeys?

A: The warning signs are repeated logins across channels, frequent friction on kiosks or smart devices, inconsistent step-up behaviour, and session handoffs that fail when the customer switches from one device to another. If authentication logic is embedded separately in each channel, the programme is probably too static to support modern retail behaviour.

Q: Should identity teams prioritise conversion or stronger verification in retail journeys?

A: They should not treat it as an either-or choice. The better approach is to reserve stronger verification for higher-risk contexts such as unfamiliar devices, payment changes, or reward redemption, while keeping trusted paths friction-light. That balance protects revenue without normalising excessive prompts that push customers out of the journey.

Technical breakdown

Cross-channel session continuity in retail identity

Cross-channel session continuity means an authenticated customer can move between a mobile app, web store, kiosk, or connected device without restarting identity proof at every handoff. The technical challenge is preserving enough state to recognise the user while not over-trusting the device that happens to hold the session. In retail, that usually requires token exchange, device binding, and policy evaluation at each step rather than a one-time login event. Shared devices complicate the model because the session belongs to the customer, not the terminal. The architecture has to separate identity assurance from endpoint ownership.

Practical implication: design retail sessions as transferable state with step-up checks, not as a single browser authentication event.

Device trust and step-up authentication

Device trust is the control that determines whether the current device can inherit a low-friction path or must trigger stronger verification. In the article’s example, a known mobile device may allow passwordless login, while a new or unusual device requires MFA or additional verification. That is risk-based authentication applied to retail journeys, but the critical detail is that the policy is evaluated in real time using device, behaviour, and context signals. This is what lets retailers reduce friction without turning every checkout into a high-assurance event.

Practical implication: build policy rules that elevate assurance only when device trust or session context changes.

Second-device authentication for kiosks and shared endpoints

Second-device authentication uses a public or constrained endpoint, such as a kiosk, to initiate a session that is approved on a trusted personal device. This avoids typing passwords on shared hardware and shifts the sensitive part of the flow to a channel the user already controls. In practice, the kiosk acts as the front-end trigger, while the trusted mobile device performs approval, verification, and token handoff. The result is a cleaner separation between display surface and authentication surface, which is especially important in retail, airline, and smart-device scenarios where keyboard entry is awkward or unsafe.

Practical implication: treat kiosks and other shared endpoints as session initiators, not as the place where credentials are entered.

Threat narrative

Attacker objective: The attacker aims to obtain a valid retail session that can be used for checkout, loyalty abuse, or account takeover without triggering strong friction.

1. Entry occurs when a retail session starts on a shared kiosk, public terminal, or new device that does not yet carry strong trust context.
2. Credential access is replaced by identity handoff, where the customer approves the session on a trusted second device and tokens are issued back to the shared endpoint.
3. Impact follows when the session is not bound to device, channel, and risk context, allowing account takeover, fraud, or checkout abuse through a legitimate-looking retail flow.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Retail authentication is becoming a session-orchestration problem, not a login problem: The old assumption was that identity proof happens once at the start of a browser session. That assumption breaks when customers move across mobile, kiosk, loyalty, and connected-device touchpoints inside one shopping journey. The implication is that identity teams have to govern continuity across channels, not just authenticate entry.

Device trust is now part of customer identity policy: Retail control decisions increasingly depend on whether the current device is known, shared, constrained, or riskier than the last one. That makes device context a policy input, not a secondary signal. Practitioners should treat channel switching as an identity event with governance consequences.

Second-device approval is a stronger retail pattern than password entry on shared hardware: Shared kiosks and keyboard-limited devices are poor places to terminate authentication because they create avoidable friction and expose users to unsafe input habits. Moving approval to a trusted mobile device aligns assurance with the device the customer actually controls. That shifts the control boundary away from the public terminal and toward the user-held endpoint.

Cross-channel retail identity creates a new governance boundary around customer data and session state: Once the kiosk, mobile app, loyalty system, and payment provider all participate in one identity journey, the programme has to govern session scope, claim propagation, and handoff integrity together. The named concept here is cross-channel identity continuity: the ability to preserve trust without letting one channel over-authorise another. Practitioners should design for continuity with explicit boundaries, not informal federation.

Omnichannel identity programmes need conversion metrics and security metrics to be managed together: The article correctly frames friction reduction as a business need, but the security team still owns the trust model that makes that friction reduction safe. When authentication becomes adaptive, the failure mode is not just more drop-off; it is over-permissioning trusted journeys until fraud becomes invisible. Teams should govern authentication as both an experience control and a risk control.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Top 10 Agentic AI Identity Issues

What this signals

Cross-channel identity continuity: Retailers now need a policy model that preserves customer trust across devices without assuming one authenticated channel can safely authorise every other channel. The operating shift is from isolated logins to governed session handoffs, which is why device binding and step-up checks matter more than ever.

Authentication flows should become context-aware journey controls, not static screens. When kiosks, smart TVs, and mobile devices all participate in the same customer path, the programme needs explicit rules for when to continue, when to re-verify, and when to force stronger assurance.

According to the 2026 Infrastructure Identity Survey, 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job. That pattern is a warning for retail teams too: convenience often expands trust faster than governance does.

For practitioners

• Map retail journeys by device and channel Inventory where customers start, pause, and resume sessions across web, mobile, kiosks, loyalty flows, and connected devices, then define where identity must persist versus re-verify.
• Use second-device approval for shared endpoints Route kiosk and other shared-device authentication through a trusted mobile approval step so credentials are never typed on public or keyboard-limited hardware.
• Apply step-up rules to high-risk retail actions Require stronger verification for checkout, payment updates, reward redemptions, or unfamiliar device activity, while keeping low-risk browsing paths low friction.
• Bind sessions to device and risk context Evaluate device trust, behavioural signals, and channel context before issuing or continuing a session so a kiosk token cannot silently inherit all prior trust.

Key takeaways

• Retail authentication now has to follow the customer across channels, devices, and shared endpoints rather than stop at a single login.
• The core design problem is preserving session continuity without letting a kiosk, public terminal, or unfamiliar device inherit too much trust.
• Practical controls centre on device-aware policy, second-device approval, and step-up verification for higher-risk retail actions.

Key terms

• Cross-Channel Identity Continuity: The ability to preserve a customer’s authenticated state as they move between channels, devices, and touchpoints without forcing a full re-login each time. In retail, it depends on session binding, risk evaluation, and clear limits on what one channel is allowed to inherit from another.
• Second-Device Authentication: An authentication pattern where a public, shared, or constrained device starts the journey and a trusted personal device completes approval. It reduces credential entry on unsafe endpoints and shifts the most sensitive part of the flow to the device the user actually controls.
• Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.