Passkeys on Multiple Screens: Maintaining Trust Across Connected Displays

Passkeys are often presented as a cleaner replacement for passwords, but the real challenge starts when authentication leaves a single phone screen and enters a connected-display environment. Foldables, tablets, retail POS terminals, self-service kiosks, and companion displays all introduce a new trust problem: users must know which screen is asking them to authenticate, where the approval is happening, and what device is actually being trusted. That is especially relevant now that foldable devices are becoming more mainstream and product teams are designing experiences that span collapsed and expanded screen states, as hinted by ongoing interest in foldable form factors in the broader market. For teams evaluating identity UX, it is worth pairing passkey design with broader guidance on identity signal leakage, deepfake and spoofing risks, and regulated-device operational controls.

This guide is for architects, developers, security teams, and IT administrators who need a practical playbook for passkeys in multi-screen environments. We will cover device attestation, display continuity cues, anti-spoofing patterns, kiosk and POS considerations, and implementation details that reduce friction without weakening trust. If your organization is modernizing identity alongside retail, device, or endpoint programs, you may also find it useful to compare approaches from automated onboarding and KYC flows and workflow version control for sign-off processes.

Why multi-screen passkey flows are different

The trust boundary moves when the screen moves

Traditional passkey flows assume a single primary screen, but multi-screen environments distribute attention across devices. A user may start on a foldable phone in one hand, continue on an unfolded tablet in a docking station, and complete a biometric prompt on a nearby hardware security key or OS-level authenticator. In a retail setting, the same user might start on a handheld shopping app, confirm on a POS terminal, and view receipts or offers on a customer-facing kiosk. Every handoff creates an opportunity for confusion, and confusion is exactly what attackers exploit when they try to redirect an approval or mimic a trusted interface.

Foldables add a specific complexity: the “same” device can present different interface real estate and different user expectations depending on whether it is folded or unfolded. A concise prompt can look trustworthy when the device is held like a phone, but the expanded display may reveal additional UI that was hidden before, including phishing overlays, altered instructions, or misleading approval context. This is why design teams should think about continuity the same way they think about session persistence: users need to recognize that the authenticating session is the same one they started, not a replay or a redirected flow. For broader product strategy around screen-driven experiences, see how interfaces can remain understandable to machines and humans and how accessibility-oriented UX patterns reinforce clarity.

Retail POS and kiosks amplify social engineering risk

In retail and hospitality, the attacker’s goal is often not to steal the device outright but to nudge the user into approving the wrong action on the right device. A customer can be shown a loyalty prompt on a kiosk that looks like the merchant’s official UI while the actual passkey request is being proxied elsewhere. Similarly, a cashier-facing POS terminal can become a deception layer if the customer is asked to scan, tap, or verify something without a clear visual connection to the merchant context. This is why the most effective anti-spoofing controls are not only technical; they are visible, consistent, and context-rich.

Retail teams increasingly rely on first-party and identity-driven experiences to replace brittle anonymous journeys. That change mirrors the shift described in first-party retail identity strategies, where direct value exchange depends on recognized users and trustworthy interactions. When the authentication step is visible to employees and customers alike, the organization can better distinguish genuine identity verification from UI spoofing attempts.

The biometrics question is really a continuity question

Biometric authentication is often treated as a standalone “proof,” but in multi-screen contexts it is only one element in a chain of trust. Face ID, fingerprint readers, and platform authenticators can confirm presence, but they do not automatically confirm that the prompt came from the intended application, the intended browser instance, or the intended device state. A biometric flow that succeeds on the wrong screen can still mislead the user if the surrounding cues are weak. That is why engineers should combine biometric prompts with strong device binding, visible origin indicators, and unambiguous recovery paths.

Think of it the way you would think about versioning production templates: the approval itself matters, but so does the version, the context, and the audit trail. For parallel thinking, review document maturity and sign-off controls and template versioning for sign-off workflows. The principle is the same: a successful action without reliable context can still be operationally unsafe.

Threat model: spoofing, relay, and wrong-screen approvals

Man-in-the-middle UI spoofing across displays

UI spoofing in multi-screen passkey flows is most dangerous when the attacker controls a display the user trusts, even temporarily. A kiosk or secondary display can present a convincing “continue” screen while the actual authentication request is relayed to another endpoint. In sophisticated cases, the attacker may not need to break cryptography at all; they only need to manipulate attention. If the user cannot tell whether the prompt is local, remote, mirrored, or relayed, then the approval channel becomes a liability.

This is similar to how deceptive content works in other domains: the surface can be familiar while the underlying intent is malicious. For a useful analogy, read about how deepfakes create confidence through visual similarity. Passkey spoofing on connected displays is the same category of problem, just applied to authentication UX rather than media authenticity.

Relay attacks on public or semi-public devices

Public kiosks, shared tablets, and POS terminals are high-risk because users naturally assume the organization has already secured them. But a locked-down shell does not guarantee that the displayed action is legitimate. An attacker with partial network position, malicious browser extension access, or compromised kiosk software can induce the user to approve a prompt that is actually bound to a different session. The user only sees a branded screen, not the request path.

To reduce this risk, organizations should treat shared displays as untrusted presentation layers and never as primary trust anchors. That means using attested devices, short-lived challenges, and explicit user-visible verification of origin. Teams working on identity verification can borrow from onboarding pipelines such as automated KYC workflows, where chain-of-custody and document integrity matter as much as the final approval.

Folded vs. unfolded state confusion

Foldables introduce a surprisingly subtle threat: the user may approve a prompt in one device posture and later see a different interface in another posture, but still believe they are in the same session. For example, a passkey enrollment prompt shown on the cover display might switch to a richer, multi-pane UI when unfolded. If the screen changes without a continuity cue, the user may not realize the same action is still pending or that the state was altered. Attackers can exploit this kind of ambiguity if the interface does not clearly persist the original intent.

This is where product teams should adopt “state continuity” as a first-class requirement. You can think of it as a visual checksum for the user. The job is not to overwhelm the user with warnings; it is to give them enough persistent cues to notice when the environment changes. In regulated flows, even small visual inconsistencies can become audit findings, which is why regulated device DevOps practices emphasize repeatability and controlled change.

Device attestation: proving the right device is participating

What attestation should tell you

Device attestation is one of the strongest controls available for multi-screen trust, but it must be used correctly. Its purpose is to help the relying party determine whether the authenticator and the device posture are what they claim to be. In practical terms, you want assurance that the passkey operation is occurring on a genuine, policy-compliant device, not a tampered emulator or a compromised browser environment. For retail and kiosk deployments, attestation can also help distinguish approved managed endpoints from opportunistic devices on the same network.

Good attestation design does not require you to over-collect device data. Instead, it should validate a small set of high-value properties: platform authenticity, secure enclave or TPM presence, enterprise management status, and policy compliance where appropriate. If your team is comparing operational approaches for digital identity programs, it may help to review how identity signals can leak through metadata and why minimal disclosure is often safer than maximal telemetry.

Use attestation selectively, not indiscriminately

Not every passkey assertion needs the same level of attestation. A low-risk sign-in on a private phone may warrant a lightweight policy, while a high-value transaction on a POS terminal or a public kiosk should require stronger device verification. This risk-based approach improves usability and avoids turning attestation into a blanket surveillance mechanism. The goal is to raise confidence proportionally to the risk, not to create a data-hoarding exercise.

Enterprises with regulated workflows often use similar tiering for signing and approval. In document-heavy environments, controls vary depending on the value and sensitivity of the action, which is why maturity mapping for scanning and eSign can be a useful reference point. The same principle applies to authentication: risk should drive the level of proof required.

Recommended attestation policy matrix

Designing UI continuity cues users can actually trust

Persistent origin markers

Users should always know which application, organization, or kiosk is requesting the passkey action. That means displaying persistent origin markers that survive screen rotations, unfolding events, and layout changes. Do not rely on a logo alone. Combine the logo with the domain, merchant name, or terminal identifier in a stable location, and ensure that it remains visible throughout the entire authentication journey. When screen space is scarce, abbreviate but do not hide; users need continuity, not decorative minimalism.

For a useful parallel, see how machine-readable property details help reduce ambiguity in travel discovery. The same design logic applies here: the system should make identity of origin legible at a glance, even after interface transitions.

State banners and challenge timelines

Every passkey interaction in a multi-screen environment should include a visible state banner: “Authenticating to Acme Retail POS,” “Confirming sign-in on Foldable Tablet,” or “Approving checkout on Kiosk 4.” This banner should not disappear when the screen changes posture or when the browser moves into a full-screen prompt. Users also benefit from a challenge timeline that explains whether the flow is idle, awaiting biometric input, verifying device integrity, or finalizing trust. The more you reduce uncertainty, the less likely users are to click through blindly.

This is especially important in shared environments where people are already multitasking. Think of the UX discipline described in productivity stack design: tools only help when they reduce cognitive overhead instead of creating it. Authentication UI should follow the same rule.

Do not hide critical context in secondary panes

Foldables tempt designers to use the larger unfolded display for “extra” information, but critical trust cues should not be hidden in a secondary panel that a user may miss. If the prompt changes from a compact cover screen to a split-screen form, the security-critical context must remain in the primary viewport. Users should never need to hunt for the device name, app origin, or action summary. If the important context moves, the trust signal degrades.

To avoid this trap, maintain a clear hierarchy: action title, origin, device state, then biometric confirmation. If the user is also dealing with accessibility constraints or older-user ergonomics, borrow from accessible UX principles for older audiences, where clarity and consistency matter more than dense information.

Passkey implementation patterns for foldables, POS, and kiosks

Foldable devices: support posture-aware flows

Foldable-aware passkey UX should detect posture changes without creating duplicate prompts or losing session context. If the device is folded mid-challenge, the flow should continue seamlessly with a preserved state indicator and the same origin marker. If unfolding changes the layout, the prompt should adapt while keeping the same security metadata pinned in place. The user must not be asked to guess whether the action restarted, migrated, or changed scope.

One practical pattern is to lock the challenge UI to a logical session ID and display a visible “continuing from prior state” indicator after posture change. This is analogous to how teams manage version changes in production workflows: the interface can evolve, but the underlying transaction must remain the same. For a related operational mindset, review version control for sign-off templates and document process maturity benchmarks.

POS terminals: keep customer and merchant trust distinct

In POS environments, the merchant’s device and the customer’s device are not interchangeable. If the customer is approving a passkey login, the system should clearly indicate whether the action is for the merchant account, the payment flow, loyalty enrollment, or a receipt handoff. If the POS terminal itself is the authenticating device, it must be strongly managed, attested, and physically controlled. The display should not blur customer identity, cashier identity, and device identity into a single vague prompt.

This is a good place for tight policy boundaries. Only allow the POS terminal to initiate passkey operations that match its role, and only allow the customer-facing display to show read-only state unless a trusted binding is present. Operational teams can borrow from safe update and validation discipline, where role separation and controlled capabilities are mandatory.

Kiosks: treat them as temporary trust surfaces

Self-service kiosks are ideal for convenience, but not for broad trust delegation. Use them for limited-scope actions such as check-in, ticket retrieval, or account lookup, and require step-up authentication for sensitive actions. When a kiosk displays a passkey prompt, it should clearly disclose that the kiosk is a shared device and show a prominent session expiration or reset indicator. After completion, the kiosk should visibly clear state and prove to the user that the session ended.

Organizations that manage kiosk fleets should also evaluate network posture, physical tamper resistance, and software update integrity. Similar to how teams thinking about limited-edition devices or imports need to account for region and supply-chain risks, as discussed in region-locked device risk management, kiosks need boundary controls that account for both software and hardware realities.

Preventing spoofing: technical controls that matter

Origin binding and anti-phishing payloads

Passkeys already improve resistance to credential phishing, but your implementation must preserve that advantage across screens. Always bind requests to the correct origin and never allow a UI layer to rewrite the relying party identity after the challenge starts. When available, use platform features that expose origin and RP ID in a way the user can verify. If the rendering layer is compromised, the backend should still refuse any assertion that does not match the expected origin and challenge context.

Teams should also design for failure: if the origin cannot be shown clearly on a small or auxiliary display, the safest behavior is to block the flow and redirect the user to a trusted screen. That may seem conservative, but in identity engineering the most dangerous failures are the ones that look polished. This principle is closely related to the caution urged in identity signal leakage analysis and visual spoofing detection.

Short-lived challenges and freshness checks

Every passkey operation in a multi-screen environment should use short-lived challenges with strict replay limits. The shorter the window, the less useful a captured prompt becomes to an attacker trying to pivot between displays. Freshness checks should also be reflected in the UI, so the user sees that a stale prompt has expired instead of silently failing or reusing a previous state. Clear expiration is a trust feature, not merely a back-end control.

When teams neglect freshness, the result can resemble a delayed announcement problem: users keep expecting the original state, but the system has moved on. The communication lessons in messaging about delayed features are surprisingly relevant here. If the challenge has expired, say so immediately and explain the next step.

Hardware-backed policy and remote management

For managed endpoints, pair passkeys with device policy enforcement, secure boot, and remote attestation from your endpoint management stack. On kiosks and POS systems, the OS should be locked down to a small set of approved actions, and update channels should be controlled like any other high-value production environment. If a device fails policy, do not quietly degrade to a weaker user flow; instead, move the user to a trusted alternative such as a staffed terminal or a separate, verified device.

When planning the administrative side, think like an IT operator rather than a UI designer. A well-run fleet is closer to IoT-based monitored infrastructure than to a normal consumer app. You want observability, alerts, and policy enforcement, not just a polished front end.

Operational best practices for identity teams

Instrument every handoff

Log when a passkey challenge starts, when a screen posture changes, when the user switches from one display to another, when attestation is validated, and when the flow is completed or abandoned. These event markers help you detect unusual transitions that may indicate spoofing, UI injection, or usability failures. Correlate those events with device inventory, terminal location, and risk score so your security team can spot anomalies before they become incidents.

For teams already building internal visibility systems, the discipline is similar to building retrieval datasets from market reports or automating internal dashboards from APIs: the value comes from structured signals that can be analyzed later, not from raw logs alone.

Test the bad paths, not just the happy path

Security teams should simulate folded-to-unfolded transitions, kiosk refreshes, POS screen swaps, network delay, and delayed biometric confirmation. Validate what happens if the user receives a prompt on one screen but attempts to approve on another. Test whether the session ID persists, whether the origin is still visible, and whether the UI recovers safely after an interrupted flow. The most important findings usually come from the messy edge cases that product demos never show.

That testing mentality resembles the value of structured experimentation in other disciplines. If you are interested in repeatable testing habits, see A/B testing discipline and agentic workflow design, both of which reinforce how systems should behave under variation rather than ideal conditions.

Train staff to recognize trust cues

Frontline staff are part of the defense model in retail and kiosk deployments. They should know what a legitimate passkey prompt looks like, what device-state changes are expected, and when to escalate if a customer reports confusion. A cashier, concierge, or kiosk attendant who can say, “That prompt should show our store ID and the device name,” is a practical security control, not just a customer service asset. Training turns policy into behavior.

Organizations that invest in customer education and support tooling often find that the same clarity improves conversion and reduces abandonment. That is why content and UI teams should coordinate with operations, much as multi-platform content systems or streamlined audience engagement systems rely on consistent messaging across channels.

Implementation checklist and architecture guidance

Reference architecture for multi-screen passkeys

A strong architecture typically includes a relying party backend, a client app or browser, a platform authenticator, a device attestation verification service, and a policy engine that evaluates risk before issuing or accepting a challenge. Add a UI continuity layer that keeps the same session identity across posture changes, screen swaps, and display mirroring events. For shared devices, introduce a kiosk or POS trust module that enforces physical and logical boundaries, including automatic reset and session eviction.

The most important architectural decision is to separate display trust from authentication trust. The display can inform the user, but it should never be the sole source of truth. When possible, cross-check the display state against server-side session state and device attestation to confirm that what the user sees matches what the system expects.

Deployment checklist

Before rollout, verify that the application shows persistent origin markers, challenge freshness, and clear completion states. Confirm that folded and unfolded states are tested separately, not just in emulation. Ensure that shared displays are enrolled, managed, and monitored like any other enterprise endpoint. Set a policy for when to require stronger attestation, when to deny access, and when to reroute the user to a trusted device.

If your rollout includes retail or customer-facing environments, remember that identity is now part of the brand experience. Product teams that already care about first-party engagement and privacy should revisit insights from identity-driven retail strategy and use them to inform trust messaging on the screen itself.

Metrics that indicate you are getting it right

Measure more than login success. Track abandoned auth flows after posture changes, mismatch events between displayed origin and backend origin, attestation failure rates by device class, and support tickets mentioning confusing prompts or “wrong screen” approvals. Over time, you want fewer user-reported ambiguities, fewer fallback recoveries, and lower incidence of repeated authentication attempts on shared devices. Those are leading indicators of a trustworthy multi-screen experience.

Pro Tip: If the user cannot tell in one second what device is asking for authentication, the UI is not ready. In multi-screen passkey design, clarity is a security feature, not just a UX preference.

Conclusion: trust must survive the screen transition

Passkeys solve the right problem only when the entire flow is designed around context, continuity, and device trust. In a world of foldables, tablets, kiosks, and POS terminals, the challenge is no longer simply “prove who you are” but “prove that the prompt you are seeing is the one you should trust.” Device attestation, strong origin binding, and visible continuity cues work together to make that possible. When implemented well, they reduce phishing, prevent UI spoofing, and preserve the low-friction experience that makes passkeys attractive in the first place.

As connected displays become more common in consumer and retail environments, security teams will need to design for posture changes, shared surfaces, and human attention limits. The best solutions will treat trust as a continuous relationship between device, display, and user—not a single approval event. If you want to extend this thinking into adjacent identity workflows, explore how identity signals, regulated device operations, and verified onboarding shape the broader authentication stack.

FAQ

Related Reading

• DevOps for Regulated Devices: CI/CD, Clinical Validation, and Safe Model Updates - How to keep high-risk endpoints trustworthy through change control.
• How Social Platforms Leak Identity Signals Through Notifications and Metadata - A practical look at identity leakage outside the login screen.
• The Deepfake Playbook: How to Tell If That Celebrity Video Is Real - Useful mental models for spotting visual spoofing.
• Small Brokerages: Automating Client Onboarding and KYC with Scanning + eSigning - Lessons for designing trustworthy high-friction verification flows.
• Document Maturity Map: Benchmarking Your Scanning and eSign Capabilities Across Industries - A framework for comparing workflow trust and operational maturity.