Evaluating Enterprise SSO for Shared Devices

Enterprise SSO is single sign-on built for the systems, scale, and compliance requirements of a large organization: one authentication event that opens every application a worker needs. On shared frontline devices, enterprise SSO also has to switch sessions between users at shift change, keep a per-user audit trail on a common device, and complete an SSO login in seconds rather than minutes. Most SSO evaluations never ask the question that decides whether the rollout works, though. The vendors on your shortlist built their products for one user on one device. Your stores run the opposite model: one device, many users, changing hands at every shift.

This guide gives you the four criteria that separate an enterprise SSO platform that survives shared devices from one that fails in the POC, plus the vendor questions that surface the difference early.

In this guide:

• Why does standard SSO break on shared devices?
• What does login friction actually cost?
• Which four criteria decide an enterprise SSO evaluation?
• What should you ask vendors before the POC?
• Frequently asked questions

Why Does Standard SSO Break on Shared Devices?

Standard SSO login assumes a persistent relationship between a person and a device. A knowledge worker signs in to their laptop in the morning, and the session quietly follows them all day. Every major identity provider was designed around that assumption.

Your frontline doesn’t work that way. A morning associate clocks out, an afternoon associate picks up the same Zebra scanner, and that scanner needs to become a different person’s device in seconds. When an IdP configured for single-user laptops meets a shared handheld, you get the failure modes every IT director in retail recognizes: sessions that persist across users, associates working under someone else’s credentials, and full re-authentication into 5 to 10 applications at every handoff.

The problem isn’t your identity provider. It’s that nobody configured it for a device that belongs to three different people before lunch.

Shared-device SSO authentication has to solve problems single-user SSO never faces:

Requirement	Single-user SSO	Shared-device SSO
Session lifecycle	Persists all day for one owner	Instant teardown at logout, clean handoff at every shift change
Audit trail	One user per device, implied	Per-user session records on a common device
Credentials	Every user pre-provisioned in the IdP	Flows for seasonal hires who may not exist in your IdP yet
Login speed	Once a morning, over coffee	Measured against a shift clock, every handoff

That’s a different engineering problem, and it’s why an evaluation that only asks “does it support SAML and OIDC?” misses the criteria that decide success.

What Does Login Friction Actually Cost?

Login friction on shared devices is one of the few IT problems you can price to the minute. On shared fleets without purpose-built SSO, each application login takes 30 to 45 seconds, and associates sign in to 5 to 10 applications per shift. That’s 3 to 7 minutes per associate before any work starts. Multiply by every associate on every shift across a 500-store fleet and the start-of-shift ritual consumes thousands of paid hours a week. Not selling. Not picking. Waiting.

The help desk pays a second time. Forrester Research estimates each manual password reset costs about $70 to resolve, and Specops, citing Gartner, reports that password issues drive roughly 40% of help desk volume. Every locked-out associate on the floor is also a ticket in your queue.

Device loss compounds it. BlueFletch documents 10 to 15% annual device loss as the norm on rugged handheld fleets, and B2M Solutions’ State of Enterprise Mobility research found 20% of frontline workers lose a device at least once a month. Without per-user sessions, there’s no audit trail showing who had the device last, so a $1,500 rugged handheld disappears with no accountability attached.

Travis Epperson at HD Supply describes the operational logic from the delivery side: their TC57 drivers running BlueFletch use NFC tags to log back into devices quickly, because “one of the biggest problems with delivery drivers is how long it takes them to do anything.”

Stack those three costs and the business case usually writes itself. The harder question is which platform actually fixes them, and that’s what the next four criteria are for.

Which Four Criteria Decide an Enterprise SSO Evaluation?

BlueFletch’s buyer research across retail IT organizations shows the same four criteria deciding these evaluations, in roughly the same order: integration with your existing IdP and MDM stack, deployment speed across hundreds of sites, total cost of ownership including the hidden infrastructure, and frontline worker experience. They map to how enterprise SSO projects fail.

1. Integration with your existing IdP and MDM stack

Any platform that requires re-platforming Okta, Microsoft Entra ID, or Ping is a non-starter, and the same goes for your MDM. The right architecture layers on top of what you already run: SOTI, Workspace ONE, or Intune keeps managing the device, your IdP keeps owning identity, and the SSO layer handles the shared-device session logic between them.

This criterion is also your insurance policy. The Broadcom acquisition of VMware pushed Workspace ONE renewal costs up dramatically, with IDC documenting increases from 100% to as high as 800%. An authentication layer that’s MDM-agnostic means a forced MDM migration doesn’t take your login experience down with it. Your workers never experience the MDM. They experience the login.

2. Deployment speed across hundreds of sites

A POC that works in a lab tells you almost nothing about a 2,000-store rollout. Ask for evidence at your scale: how many sites, how many devices, how long from contract to full deployment, and what the store-level touch requirement was. A platform that needs hands-on configuration per device turns a rollout into a year-long project with a help desk spike at every wave.

Named references matter more here than anywhere else. A vendor who can put you on the phone with a Fortune 1000 retailer running a comparable fleet has cleared the bar. A vendor who offers a roadmap slide instead has not.

3. Total cost of ownership, including the hidden parts

Per-device licensing is the visible line. The hidden lines are the infrastructure the platform drags in behind it: proxy servers, dedicated appliances, professional services for every configuration change, and per-integration fees that surface after signature. Build the TCO model on the full picture, then set it against the recoverable costs from the section above. The savings retailers see from SSO on mobile devices come from labor minutes, reset tickets, and recovered devices, so a platform’s price only means something relative to those numbers.

4. Frontline worker experience

The criterion that decides adoption gets evaluated last, if at all. Every additional second and tap at login gets multiplied by your entire workforce, every shift, every day. The bar that purpose-built shared-device platforms have established is a badge tap or NFC login of under 2 seconds into a role-based launcher, with the worker’s applications ready on first screen.

Test it with real associates during the POC, including a seasonal hire who has never seen the device. If the flow requires training, it will generate tickets. The full benefits of single sign-on for shared workforce devices only materialize when workers stop noticing the login at all.

For a deeper technical treatment of these architecture patterns, the guide to enterprise SSO and authentication on Android devices covers protocol, launcher, and IdP integration detail this evaluation framework builds on.

What Should You Ask Vendors Before the POC?

The wrong time to discover a gap is week six of the pilot. These questions surface the gaps in the first meeting:

1. “Show me a session handoff.” Two users, one device, timed. How long from badge tap to working applications, and what happened to the first user’s session and data?
2. “What happens when the network drops?” Stores and warehouses have dead zones. Ask how authentication behaves offline and what the worker sees.
3. “How do contingent workers authenticate?” Seasonal hires and temp labor may not live in your IdP. If the answer is “create accounts for everyone,” price out that provisioning burden.
4. “Which of my legacy apps can you cover?” Green-screen and legacy applications without modern auth support are where SSO projects quietly stall. Get the coverage mechanism in writing.
5. “Who else runs this at my scale, and can I call them?” The reference call is the single most reliable evaluation signal you have. Use it.

A vendor with real shared-device experience answers these in specifics. A vendor who built for single-user laptops and adapted later answers in generalities, and you’ll hear the difference.

Frequently Asked Questions