What operational problems appear when borrowers switch devices during onboarding?

Where device switching creates friction in onboarding

The main operational issue is not the handoff itself, but whether the onboarding flow can preserve progress when the customer moves from one device to another. If session state, document state, or signing state is tied too tightly to a single browser or device, the workflow behaves like a restart rather than a continuation. That creates duplicated effort, broken continuity, and more drop-off at the exact point where intent is fragile.

Borrowers usually experience this as wasted time: they may complete identity checks on one device, then find that the next step cannot resume cleanly on another. The more steps that depend on a stable session, the more likely the process is to stall when a phone, laptop, or tablet change happens mid-flow.

What actually breaks in the workflow

Three parts tend to fail first: verification continuity, document upload continuity, and signature continuity. If the workflow does not reattach the user to the same application context, the platform may force repeated authentication, lose uploaded files, or require a fresh consent or signing sequence. Those are process failures, but they feel to the borrower like the platform is unreliable.

This is also where product design and state management matter more than raw security posture. A good onboarding flow should let the customer change devices without losing the business state of the application. If it cannot, the operational cost appears as support calls, abandoned applications, and longer completion times rather than a classic security incident.

For teams designing that journey, IAM and IGA Basics is useful because the same continuity problem often sits beside access governance decisions about how a session or entitlement is resumed, revalidated, or re-issued.

Why this matters for conversion and support

Device switching is a stress test for onboarding resilience. When the process cannot preserve state across sessions, borrowers repeat work, lose confidence, or stop mid-application. The practical outcome is lower completion rates, more manual intervention, and more exception handling for operations teams.

The issue becomes sharper when the borrower has already invested time in uploading documents or completing verification. A failed handoff at that stage has a stronger abandonment effect than an early friction point, because the customer has more to lose by restarting. In lending and similar onboarding flows, that makes continuity a conversion problem as much as a workflow problem.

Where the process also involves device trust or secure device onboarding, the distinction between a usable transfer and a forced restart matters. The Device and IoT Identity Guide is relevant here because it covers secure onboarding and device trust patterns that shape whether a user can move between devices without breaking the journey.

Risk and Threat Considerations

Device switching is usually an availability and usability issue, but weak continuity controls can also create trust and session problems. If an application cannot distinguish a legitimate handoff from a stale or replayed session, teams may either over-block genuine borrowers or over-accept resumed activity that should have been revalidated.

Failure mechanism: Session, upload, or signing state is bound too tightly to a single device or browser, so a legitimate handoff invalidates the workflow or forces the user to start over. Poor state transfer design can also leave ambiguous recovery paths that are easy to misuse.

Impact: Borrowers abandon onboarding, duplicate work, or contact support, and operations teams absorb more manual exceptions. In higher-friction flows, repeated retries can also blur the line between legitimate continuation and suspicious session reuse, which increases review burden.

Practitioner Guidance

What to verify: Check whether the onboarding flow can safely resume after device change without re-entering already completed steps. The test should cover verification state, document state, and signing state separately, because each may fail in a different way.

Decision rule: If a borrower can switch devices during an active application, design the process so the new session is clearly reattached to the same application record instead of forcing a restart. If that cannot be done reliably, make the failure explicit and recoverable rather than silent.

What good looks like: The user can continue on a second device with minimal repetition, while the system still preserves clear auditability of what was completed, when it was completed, and under which session context.

Practitioner takeaway: The goal is continuity, not blind persistence, preserve the business state of onboarding across devices while keeping re-entry rules strict enough to avoid confusion, duplication, and support-heavy recovery paths.

Related resources from NHI Mgmt Group

• What operational problems does remote eSIM management help solve in difficult-to-reach IoT devices?
• What operational problems can appear if security teams confuse patch-related Windows defects with exploitation activity?
• Why do healthcare identity failures create operational risk beyond login problems?
• Why do shared clinical devices create problems for standard IAM controls?