Why IAM's Core Assumption Fails on the Frontline

For most of the history of enterprise computing, identity and access management solved a fairly narrow problem: confirm that the person sitting at a desk, logging into a corporate network, was who they claimed to be. Single Sign-On, Multi-factor Authentication, and the rest of the modern IAM toolkit grew up around that assumption. One person, one device, one login session that lasted the better part of a workday.

That assumption held up reasonably well for decades, because it matched how most digital work actually happened. It does not match how frontline work happens now.

How Frontline Work Outgrew Legacy IAM Design

The Workforce Behind the Shift

Frontline employees, the people stocking shelves, running production lines, staffing hospital floors, and keeping logistics networks moving, make up roughly 80 percent of the global workforce, an estimated 2.7 billion people, according to Emergence Capital's analysis cited by Flip. Until recently, most of this workforce had limited or no interaction with corporate identity systems at all. They clocked in, did physical work, and rarely touched a login screen. The challenge wasn't that identity systems suddenly became worse. It was that millions of workers who were never part of the original design assumptions suddenly became heavy users of enterprise applications.

App Access Has Multiplied Faster Than Identity Architecture

That has changed quickly. Frontline roles now routinely require access to scheduling tools, EHRs, point of sale systems, inventory platforms, compliance documentation, and communication apps, often several of these in a single shift. Microsoft's own internal data showed frontline usage of Teams grew 400 percent between March 2020 and November 2021, with the steepest growth in healthcare and other frontline-heavy sectors. That single data point captures a much larger shift: digital access stopped being a desk-job privilege and became a frontline requirement, almost overnight, without a parallel redesign of the systems meant to secure that access.

IAM did not redesign itself around this shift. It added layers on top of the same core assumption. MFA got bolted onto logins built for individual desk users. SSO got extended to roles that were never going to sit at a single workstation. The architecture stayed the same while the population using it, and the threat landscape surrounding it, both grew far beyond what it was designed to handle.

Shared Logins are a Symptom of Shift-Based, Shared-Device Work

This is where shared logins, shared passwords, and the sticky note taped near a shop floor terminal usually enter the conversation, and where they usually get framed as a discipline problem. Shared passwords aren't evidence that frontline workers ignore security policy. There's evidence that the policy was written for workflows that don't exist on a shared production floor.

Picture a hospital unit with three shifts a day, rotating staff, and a shared workstation at the nurses' station. Or a manufacturing floor where a kiosk needs to support a dozen different operators across a 24-hour production cycle. The identity system in front of these workers still expects one person to own one set of credentials on one device. When that assumption breaks down against the operational reality of shift work and shared hardware, teams find a way to keep working. That way is usually a shared password.

The numbers behind this workaround layer are not small. Gartner estimates that 20 to 50 percent of all help desk calls are password resets, at a cost of roughly $70 to $100 per incident. Multiply that across a frontline workforce that is constantly rotating through shared devices, and the operational drag compounds fast, before any security consequence even enters the picture.

And the security consequence is real. Credential-based breaches now take an average of 292 days to identify and contain, the longest dwell time of any attack category, largely because a shared or stolen credential looks legitimate right up until it does not. When an account is shared across a shift rotation, that dwell time problem gets worse, not better, because there is no clean way to trace activity back to an individual. Beyond incident response, this breaks one of identity's most important promises: accountability. Whether investigating a medication change, approving a quality record, or reviewing production activity, organizations increasingly need to know exactly who performed an action. Shared identities make that certainty impossible. 

None of this reflects poorly on the IT and security teams managing it. They inherited infrastructure built for a different workforce shape and have been patching around its limits ever since. The patches have been reasonable. They have also reached their ceiling.

Why Bolting MFA and SSO Onto Frontline Workflows Falls Short

Adding MFA or extending SSO to frontline environments solves part of the problem and leaves the structural mismatch in place. These controls still assume an individual sitting at a device they own, authenticating once, and holding that session for a meaningful stretch of time. Frontline work looks different in every dimension. Devices are shared, sessions are short. Identity needs to travel with the person, not the hardware.

Retrofitted controls also tend to add friction precisely where speed matters most. A worker needing fast access to a scanner or terminal between tasks does not have time for a desk-era authentication flow, which is exactly how the workaround culture re-establishes itself even after a new control gets rolled out.

The Real Design Failure: One Person, One Device, One Login

The real issue is structural. Identity infrastructure was built around a one-person, one-device, one-credential model. Frontline work runs on a different logic entirely: shift-based, device-shared, and layered by role and time window rather than by individual ownership of a single machine. Closing that gap requires identity systems designed around how frontline work actually happens, not additional layers stacked on top of a model that was never built for it.

That means authentication that recognizes a shared device without defaulting to a shared identity. It means access that resolves to the individual on shift, not the terminal they happened to use. A growing class of frontline identity platforms, including  OLOID, starts from this premise. They treat the shared-device, shift-based reality of frontline work as the starting design constraint rather than an edge case to work around. It is one example of identity architecture catching up to a workforce that has already moved past the assumptions IAM was originally built on.

Organizations didn't arrive here by making poor security decisions. They inherited identity systems designed for a workforce that looked very different. The next generation of identity won't come from adding more controls; it will come from redesigning identity around how frontline work actually happens.
Mohit Garg, Co-founder & CEO, OLOID

What CISOs and CIOs Should Ask Instead

This is not a call to audit frontline teams more aggressively or roll out another round of password policy training. The workaround behaviors driving today's shared login problem will keep reappearing for as long as the underlying identity model assumes a workforce that no longer matches operational reality.

The more useful question for CISOs, CIOs, and the executives who sit above them isn't how to enforce the existing model more strictly. It's whether that model was ever built for the workforce running their operations. Two decades into optimizing identity for the desk, frontline work was never part of the original design brief, and it's time the architecture caught up. The future of enterprise identity isn't about making frontline workers behave more like office workers. It's about building identity systems that finally recognize how the majority of the workforce actually operates.