Posted in

Untitled

by ailona•

Frontline device deployments have a dirty secret: identity is where the pilot stalls. You’ve got the hardware deployed, the policies configured, and the Conditional Access rules written. Then someone asks, “Wait — which person is actually signed in right now?” and the whole rollout hits a wall.

Microsoft’s latest Intune Customer Success guidance cuts through this with a clear framework for thinking about identity on frontline mobile devices. The core distinction is simple — assigned versus shared — but getting it wrong has real consequences for security, auditability, and day-to-day operations.

The two device models — and the three sign-in patterns underneath

Assigned devices go to one person. The doctor with a clinical tablet. The field engineer carrying their own device across job sites. These align with standard Entra ID identity, Conditional Access, and user-based audit controls. If something goes wrong, you know exactly who was on the device. This is the straightforward case.

Shared devices split into two distinct patterns, and conflating them is where MSPs run into trouble:

  • Shared — kiosk mode (no sign-in). The device does one thing: scan a price, log a temperature, confirm a bin location. No user identity required, no personal data involved. This works fine when the task is genuinely device-centric and nothing follows the worker from shift to shift.

  • Shared — individual sign-in. Workers rotate across shifts, collaborate via Teams, receive digital task assignments, and capture information at the point of work. This is where individual identity becomes non-negotiable. If a nurse accesses patient data, a retail associate pulls up shift schedules, or a warehouse worker interacts with AI-assisted workflows — every action must trace back to a named user.

As Microsoft puts it: “Frontline setups may fail because the sign-in flow doesn’t match reality. If authentication takes 60 seconds and the worker has to do it 30 times a shift, they’ll find a workaround.”

Why shared credentials are the worst option

Shared logins — one username and password passed around a shift — are the path of least resistance and the source of maximum headache. They kill Conditional Access (policies can’t distinguish one worker from another), destroy audit trails (was that action Nurse Adams or Nurse Baker?), and make incident response a guessing game.

The MSP angle here is direct: if you’re deploying shared devices and the customer is using shared credentials, you’re inheriting a compliance and security problem. This is a conversation worth having early — before the pilot, not after the first incident.

QR code authentication: the practical unlock

The real friction in individual sign-in on shared devices is the login flow. Typing a complex username and password on a shared tablet 20 times a shift is a non-starter.

Microsoft Entra QR code authentication solves this: workers scan a QR code with their personal device, enter a simple PIN, and they’re authenticated on the shared device under their own identity. No typed credentials, individual accountability, fast shift transitions.

It integrates directly with Intune and Conditional Access. A custom authentication strength policy targets the QR code method, scoped to the appropriate frontline worker group — so the right people can use it and the policy doesn’t leak to other user types.

Identity decision checklist

Before deploying any frontline device, run this checklist:

  • Use individual sign-in when users access personal or role-specific data, when auditability or compliance is required, when MFA must be enforced, or when applications depend on user identity.

  • Use kiosk/device-only identity when the device performs a single task, no sensitive organizational data is involved, and workflows are entirely device-centric.

  • Avoid entirely: shared usernames or passwords, reused local accounts across shifts, MFA exclusions that weaken security without compensating controls.

Conditional Access must match the actual model

CA policies are only as good as the signals they receive. If a policy expects user-based identity but the device is running shared credentials, the policy either silently fails or blocks legitimate work. Align the policy model to the device model from day one.

Real-world testing is the validator here: can workers sign in and out reliably across shifts? Is personal data cleared between sessions? Does the chosen authentication experience match the pace of frontline work? Paper testing gets you 80% there — the last 20% only comes from hands-on validation.

What’s next

The next article in this series covers enrollment models: how different Intune enrollment approaches support or constrain the identity and sign-in patterns discussed here, and what each approach means for session identity, data separation, and user switching on shared devices.

Sources