Passwordless on Shared Workstations

At 03:40 the ward is quiet enough that you can hear the infusion pumps. A nurse comes out of a side room, pulls off one glove, and stands at the computer on wheels parked in the corridor. She needs to chart a dose she gave four minutes ago, check a lab result that should have come back by now, and answer a page. The machine has locked itself, as it does after two minutes, because the previous person walked away from it and the timeout is the only thing standing between a signed-in clinical record and a corridor that anyone can walk down.

She taps her badge on the reader taped to the side of the monitor. Two seconds later she is looking at her own desktop, with her own half-finished note still open, exactly as she left it at the nurses' station forty metres away. She charts the dose. To sign it — because it is a controlled substance — she types a four-digit PIN, and the system records that this specific human, at this specific time, administered this specific drug to this specific patient. Then she taps the badge again on her way past, the session parks, and by the time she is through the door the screen is showing a lock screen with nobody's name on it.

Nothing in that sequence is a passkey. Nothing in it is even, in the strict sense, a login. She authenticated once at the start of her shift, at a terminal in the staff room, with a card and a PIN. Everything since has been re-association: reattaching a living session to a physical location, over and over, sixty or seventy times before she goes home.

Now go and look at how the passwordless literature describes this environment. It mostly doesn't. And when it does, the recommendation is a phone she is not allowed to carry onto the floor, executing a cross-device flow that takes fifteen seconds, at a station where fifteen seconds is a fifth of the time she has.

Every mainstream passwordless design assumes a stable 1:1 binding between one human and one device, and encodes that assumption so deeply that it disappears from the discourse. On a shared terminal that binding does not exist, and its absence does not degrade the model gracefully — it inverts the problem. The scarce, hard, safety-critical operation stops being authentication and becomes de-authentication, and the unit of identity stops being the session and becomes the individual action. Designs that get this right stop trying to log a person into a machine and start authenticating the machine while attributing the work.

This piece is about why that inversion happens, mechanically, and what survives it. I'll work through what specifically breaks in the WebAuthn model when the device is shared; the constraint set these environments actually impose, which is more specific and more brutal than "people share computers"; the five architectures that genuinely work, compared honestly including their failure modes; why de-authentication is the hard half and what it costs to get wrong; the difference between authenticating a person and attributing an action, which is where the regulatory requirements actually live; the operational arithmetic of hardware credentials at scale; and a decision framework matched to environment type rather than to vendor category.

The general case — why passwordless is not primarily a convenience programme, and why the password field survives — is covered in Why Passwordless Isn't About Convenience and Why Passkeys Won't Eliminate Passwords Any Time Soon. The latter has a short section sketching the shared workstation as one of several reasons the password persists. This is the deep read on that one section, and it argues something the sketch doesn't: that these environments are not a residual case waiting for the technology to catch up. They are a structurally different problem that will still be structurally different in 2035, and the correct designs for them look nothing like the correct designs for a laptop.

I'm assuming the mechanics of WebAuthn as background rather than re-deriving them; The Magic Behind Passkeys and Under the Hood of WebAuthn have the ceremonies and the bytes.

The binding is in three places, and sharing breaks all of them

"Passkeys assume a personal device" is true but useless as an engineering statement, because it doesn't tell you which mechanism to fix. There are three distinct bindings in a platform authenticator deployment, they live at different layers, and a shared workstation severs each one differently.

flowchart TB
    H["A human"]
    UV["User verification<br/>(gesture or PIN)"]
    A["Authenticator<br/>(TPM / secure element)"]
    P["OS user profile"]
    M["The physical machine"]

    H -->|"binding 1: who the gesture belongs to"| UV
    UV -->|"binding 2: which key it unlocks"| A
    A -->|"binding 3: which profile the key is scoped to"| P
    P --> M

    B1["shared: the PIN is<br/>known to the shift"] -.-> UV
    B2["shared: one authenticator,<br/>many people's credentials"] -.-> A
    B3["shared: N profiles per machine,<br/>M machines per person, N×M keys"] -.-> P

Binding one: user verification stops being about a person. WebAuthn gives you a UV bit, and as Authentication Is Becoming Invisible argues at length, that bit tells you verification occurred and nothing about modality or quality. On a personal laptop that is fine, because the set of people who can produce a passing verification on that device is approximately one. On a shared machine the modality question becomes load-bearing, and the answer is usually the worst available one.

Consider why. Fingerprint readers are out wherever hands are gloved, wet, or sterile — which is most of a clinical shift, all of a wash-down shift on a food production line, and any lane where the operator is handling chilled goods. Face recognition degrades or fails behind a respirator, a face shield, safety glasses, or a hood, and in a corridor with the wrong lighting at 3am. What is left is the device PIN, and CTAP2's PIN is a property of the authenticator, not of a credential. One PIN, one authenticator, one machine, twelve people who all need to use it. Within a week the PIN is on a sticky note, because that is the rational response to a shared secret that must be typed by a shift.

Notice what has happened. You deployed a phishing-resistant credential and reintroduced a shared password to guard it — a password with about thirteen bits of entropy, typed on a keyboard in a public corridor, in front of a ceiling camera, several dozen times a day. The hardware anti-hammering argument that makes a six-digit device PIN perfectly respectable on a personal phone assumes the attacker doesn't already know the PIN because they work the same shift.

Binding two: the authenticator holds a roster. Discoverable credentials are what make usernameless login work, and on a shared authenticator they are an enumeration of the people who use that machine. Anyone who can trigger a conditional-mediation flow at that terminal — which is anyone standing at it — gets a picker listing display names for every enrolled staff member. In a retail store that's a staff roster. In a domestic violence refuge, a psychiatric unit, or a facility with a protected-employee population, it is a materially worse disclosure than it sounds, and it is not a bug you can configure away, because the whole point of a discoverable credential is that it answers "who do you have for this site?" without a hint.

The mitigation — non-discoverable credentials with an identifier-first flow — reintroduces typing a username at every login, which is the latency you were trying to remove, and leaks account existence in allowCredentials instead. Pick your disclosure.

Binding three: the credential is scoped to the OS profile, and the profile count explodes. This is the one that surprises people, and it is worth being precise. A platform authenticator credential on Windows is created in the context of a Windows user profile, protected by the machine's TPM, and it is not portable to another machine. It is not "the user's passkey"; it is this user's key on this box. So the enrollment matrix is not one credential per person. It is one credential per person per workstation they might ever stand at.

Run the numbers on a mid-sized hospital: 4,000 clinical staff, 1,200 shared endpoints, and a nurse who might use any of the sixty devices on her floor plus anything in radiology, theatres, and the ED. Even under a generous locality assumption you are provisioning tens of thousands of credentials, each requiring an enrollment ceremony performed by a human being who is at that moment being paid to do something else. And each first login on a new box also creates a Windows profile, which is where the thirty-to-ninety-second first-logon penalty lives — the reason profile-virtualisation products exist in these estates at all.

Then somebody leaves. Deprovisioning a synced passkey is one revocation; deprovisioning a person from a thousand-endpoint estate of TPM-bound platform credentials is a fleet-wide sweep that will not complete and will not be verifiable. The credential is dead the moment you remove the account server-side, so this is hygiene rather than exposure — but it is the kind of hygiene finding that shows up in every audit forever.

The constraint set, written down properly

Teams design for these environments badly because they design for a caricature of them. The real constraints are specific, and several of them are hard physical limits rather than preferences.

Login frequency is one to two orders of magnitude higher than you assume. An emergency department nurse touching sixty to eighty distinct terminal sessions in a twelve-hour shift is unremarkable. This is the number that decides the architecture, and it is worth doing the arithmetic in public rather than hand-waving at "friction." Take 70 re-authentications per shift. A badge tap resolves in two seconds; a cross-device passkey flow — scan the QR, unlock the phone, approve, wait for the BLE proximity check — resolves in fifteen to twenty on a good day. Call it a sixteen-second delta. That is nineteen minutes per nurse per shift, which across two hundred nursing staff is sixty-odd hours of clinical time per day, which is a headcount number that any finance director can compute and no security argument survives contact with.

The general framing is in The Identity Latency Budget, but the shared-terminal version is sharper: on a shared workstation the authentication latency budget is not a user-experience concern, it is a staffing cost with a linear coefficient, and if you exceed it the staff will defeat the control rather than absorb it. They will leave sessions open. They will share a generic login. They will prop the ward computer against the wall with a mouse jiggler under it. Every one of those outcomes is worse than the design you were replacing, which is the same dynamic Session Timeout Policy Across a Product Suite describes when a strict number meets a work rhythm that won't accommodate it.

Hands are not available. Gloved, wet, contaminated, sterile, or holding something. A sterile field is the extreme case: a scrubbed clinician physically cannot touch a keyboard, a screen, or a security key, which is why theatre workflows route through a circulating nurse and why voice and pedal controls exist in that room at all.

The device you'd like to use is prohibited or absent. Personal phones are banned from many clinical floors, from PCI-scoped call centre floors under clean-desk rules, and from intrinsically-safe zones on chemical and food-production sites where non-certified electronics are a genuine ignition risk. Where they're permitted, coverage frequently isn't: basements, MRI suites, shielded rooms, steel-framed warehouses, and refrigerated areas are RF-hostile by construction. A cross-device flow that depends on a handset with a data connection is not a fallback in these places; it is a dependency on a thing that isn't there.

The terminal is sealed. This one gets missed constantly by people who have never specified industrial hardware. A wash-down HMI panel on a production line is behind an IP65 or IP69K enclosure with a membrane keypad and no exposed ports, because the panel gets hosed down with caustic at shift end. There is no USB socket for a security key. There is often no USB socket at all. Contactless readers work through the panel; anything requiring insertion does not. Similarly, a POS lane's peripheral set is fixed by the payment-hardware certification and adding a port is a re-certification event.

The network is not guaranteed. A POS lane must complete a sale when the store's uplink is down; a ward must dispense medication when the WAN link to the datacentre is out; a production line must keep running when the plant network partitions. This is the constraint with the deepest architectural consequence, and I'll come back to it, because FIDO2 has no answer to it at all.

Shifts hand over. There is a moment — end of shift, break, patient handover, lane close — where one human stops being responsible and another starts. The system needs to represent that transition, and "the session simply continues" is exactly the wrong answer. This is a business event that most session models have no vocabulary for.

Attribution is legally mandatory and individually granular. Not "an authorised user accessed the record" — which human. US electronic-signature rules for regulated records require a signature attributable to a specific individual, executed as a distinct act; controlled-substance prescribing rules require two factors at the moment of signing each order, not at the start of the session. Similar requirements exist in aviation maintenance sign-off, food safety records, and pharmaceutical batch release. These are per-action requirements, and they are the reason the architectures that work look the way they do.

The five things that actually work

Here is the honest comparison. None of these is a clean win; each trades something specific.

1. Roaming authenticators — the one FIDO shape that fits. A hardware security key carried by the person, on a lanyard or clipped to a badge holder, works with any terminal that has the right interface. The credential travels with the human instead of living on the machine, which restores the binding the platform authenticator lost. It is genuinely phishing-resistant, genuinely per-individual, and it is the only mainstream FIDO deployment shape that survives a shared endpoint.

The costs are real and mostly operational. NFC keys need readers on every endpoint; USB keys need exposed ports you may not have. Discoverable-credential slots are finite — commonly a few dozen — so a person with credentials for a dozen internal relying parties will eventually hit a wall you have to design around. The CTAP2 PIN retry counter is a live operational hazard: exhaust the attempts and the key requires a factory reset that destroys every credential on it, which in a high-frequency environment with cold, gloved, tired users happens often enough to need a documented recovery path rather than an apology. And a key still requires a PIN or a biometric for user verification, which puts you back in the modality problem — a fingerprint-sensing key is elegant right up until the finger is inside a glove.

2. Smart cards — PIV, CAC, and the badge you already have to wear. Healthcare and government converged on card-based PKI for reasons that are worth stating explicitly, because they are not accidents of procurement.

The card is a credential the person is already legally required to carry and display. It is a roaming authenticator whose form factor was already mandated by physical security, which means the logistics — issuance desk, photo capture, replacement process, lost-badge procedure, return-on-termination — already exist and are already funded. That is not a small point. Most of what makes a hardware credential expensive is the lifecycle, and here the lifecycle is somebody else's existing budget line.

It has no battery and no field-updatable firmware, so it does not go flat at 03:00 and does not need a fleet update campaign. It carries a photograph, so the same artifact serves as visual identification to a human guard and as a cryptographic credential to a machine — a duality no purely digital credential has.

And the decisive property: card-based logon can work during a network partition, and WebAuthn cannot. A smart card logon to a domain via PKINIT can be serviced by a local domain controller replica, with certificate validation against a cached trust anchor and revocation list. The proof happens between the card, the workstation, and a server that can live in the building. A WebAuthn assertion, by contrast, must be verified by the relying party — the signature over the challenge is meaningless until a server you probably host elsewhere checks it against a stored public key. There is no offline mode in the protocol and there is no sensible way to add one, because the whole design depends on a server-generated challenge. If your terminal has to keep working when the uplink dies, this is not a preference. It is the requirement that eliminates the alternatives.

The costs: PKI is genuinely heavy. You are running a certificate authority, an issuance workflow, a revocation infrastructure, and a middleware layer, and revocation checking is the part that will bite you — a CRL cached long enough to survive a partition is a CRL stale enough to honour a revoked card, and that trade is not resolvable, only chosen. Card readers must exist on every endpoint. And contact cards wear out mechanically at a rate proportional to insertions, which in this population is high.

3. Badge tap plus PIN, with session parking. The pattern from the opening scene, and the dominant real-world deployment in hospitals. A contactless badge — often the same proximity card that opens the doors — plus a short PIN, mediated by a layer that holds the user's actual credentials and replays them.

What makes this work is not the authentication; it's the session model underneath. The tap doesn't create a session, it re-associates the person's existing session with the terminal in front of them.

sequenceDiagram
    participant N as "Nurse"
    participant T1 as "Terminal A"
    participant S as "Session broker"
    participant T2 as "Terminal B"

    N->>T1: "badge tap + PIN (shift start)"
    T1->>S: "authenticate, create session"
    S-->>T1: "session attached"
    N->>T1: "badge tap (walk away)"
    T1->>S: "detach, park session with state"
    Note over T1: "screen clears in under 2s"
    N->>T2: "badge tap (elsewhere)"
    T2->>S: "reattach parked session"
    S-->>T2: "same desktop, same open note"
    Note over S: "absolute lifetime bounded by shift"

The reason virtual desktop infrastructure is so heavily deployed in hospitals is not desktop management. It is that a hosted session can be disconnected in under a second while its application state survives on the server, and reconnected somewhere else just as fast. VDI in a hospital is a de-authentication technology that happens to also manage desktops. Once you see that, a lot of otherwise puzzling architecture decisions in that sector make sense.

The honest weakness: the broker holds credentials and replays them, so somewhere in that stack there is very often a password, vaulted and injected. The clinician's experience is passwordless; the system is not. That is the same pattern as the identity-aware proxy in front of a legacy app, and it deserves the same clear-eyed accounting — you have moved the password to a place where it is better managed, not removed it. Also, the PIN is per-person here rather than per-device, which is the crucial difference from the platform-authenticator case, and it only stays that way if the badge is genuinely something the person holds rather than something that lives in a drawer by the terminal.

4. Authenticate the workstation; attribute the action. The most interesting model, and the one most under-used outside healthcare. The terminal holds a device credential — a machine account, a device certificate, a TPM-bound key — and is continuously authenticated as itself. Nobody logs in. The application runs in a ward-scoped or lane-scoped context with the union of capabilities appropriate to that location, and every consequential action carries an individual attestation attached to it: a badge scan, a PIN, a signature gesture.

Medication administration is the canonical example. Scan the patient's wristband, scan the drug package, scan your own badge. The badge scan is not a login and does not create a session; it is a claim attached to that one transaction, recorded as part of it. The session belongs to the ward. The action belongs to the human.

This inverts the ordinary model in a way that maps unusually well onto the actual regulatory requirement, which — as noted above — is about attributing actions, not about establishing sessions. It also degrades beautifully: a terminal with a device credential and locally-cached authorisation data can keep accepting and queuing attributed actions through a network partition, because the attestation is evidence to be recorded rather than a permission to be granted. And it removes the walk-away problem entirely for the class of work it covers, because there is no personal session to leave behind.

Its limits are equally clear. It works for transactional work with a natural per-action boundary and does not work for exploratory work — reading a chart, browsing a case history, composing a note. And it is only as good as the authorization layer behind it: a ward-scoped session that can reach any patient in the hospital has made attribution the only control, which is a choice you can defend but must make deliberately. Authentication Is Not Authorization is the general form of that mistake.

5. Assigned-desk hot-desking — the easy case, frequently over-engineered. Call centres are the odd one out. The workstation is shared sequentially: a different agent each shift, but one at a time and for hours at a stretch. You have a normal login budget — one authentication per shift, ten seconds is fine — and the real problem is only that the desk assignment is dynamic and the agent has no personal device at the desk. A roaming authenticator solves it cleanly, because the frequency is low enough that none of the latency arguments apply. What goes wrong is that the environment gets lumped in with "shared workstations" and inherits an architecture designed for the sixty-logins case, at considerably more cost than it needed. Distinguish concurrent sharing from sequential sharing before you pick anything.

The hard problem is de-authentication

Here is the claim I'd most like to land, because it reorganises the whole design space.

On a personal device, logout is a tidiness feature. The threat it addresses — someone else using your machine while you're away — is bounded by the fact that it is your machine, in your home or your bag, and the OS lock screen handles the residual. That is why Why Logout Is Surprisingly Difficult is a distributed-systems article: the hard part is propagating an ending across federated relying parties, not detecting that it should happen.

On a shared terminal the detection is the hard part, and the consequence of missing it is not untidiness. The probability that an unattended shared terminal in a public corridor is approached by someone who is not the previous user approaches one over any interesting time horizon. The security of the entire arrangement is a function of the elapsed time between the human leaving and the session ending — and that quantity is not controlled by your identity system at all. It is controlled by a sensor, or by a timeout, or by nothing.

Which gives you three mechanisms, in descending order of how much you should want them:

Proximity de-authentication. The badge leaves, the session parks. Sub-second, requires no human action, and — critically — is the same gesture as arriving, so it is trained by use rather than by policy. The failure mode is the badge left on the desk, which is common enough that a proximity system without a timeout backstop is not a control. The other failure mode is subtler: a corridor terminal within range of a badge on someone passing by will attach and detach spuriously, and reader tuning in a busy ward is a real deployment activity, not a checkbox.

Idle timeout. The universal fallback and a genuinely bad primary control here, for a reason worth spelling out: the correct idle timeout on a shared clinical terminal is shorter than the time it takes to think. Two minutes is roughly right against the walk-away threat and roughly wrong against a clinician reading a complex history, or a radiologist studying an image, or a nurse on the phone to a pharmacy. Both of those are true simultaneously and no single number resolves them. What resolves them is having a second, faster mechanism, so the timeout is a backstop rather than the control — and then, having relieved it of the primary job, choosing the timeout for the safety case rather than the security case.

There is a clinical-safety argument here that engineers routinely dismiss and shouldn't. A screen that locks while a clinician is mid-task, during an emergency, with gloved hands, is not merely annoying; it is a delay inserted into a time-critical process, and the profession has documented cases of exactly that. The correct posture is not "security versus convenience." It is that a control which can delay care has a cost measured in the same units as the risk it mitigates, and it deserves the same seriousness.

Explicit sign-out. Depend on this and you have designed a system that works when people are unhurried, which is the opposite of when it matters.

And then the requirement that quietly determines whether any of it is adoptable: what happens to unsaved work. If tapping out loses the half-written note, staff will not tap out. They will leave the session open and walk away, and you will have built a de-authentication mechanism whose usage rate is zero. This is why "park the session" and "end the session" must be different operations with different triggers — walk-away parks and preserves; end-of-shift or absolute lifetime terminates. Applications in these environments earn their keep by persisting drafts server-side aggressively, per keystroke rather than per save, precisely so that a two-second detach is never destructive. If you are building an application for this class of user and you have a "you have unsaved changes" dialog, you have a de-authentication bug, and it will present as an unrelated complaint about the timeout being too short.

Two further mechanics, briefly. First, a parked session must have a bounded absolute lifetime, and the natural bound is the shift, not a clock interval — a session that survives a handover is a session that will eventually be used by the wrong person, and a shift-bounded absolute lifetime is one of the very few places where a business-derived number beats a security-derived one. Second, if the terminal is a browser and the parked state is a cookie, everything in Sessions, Tokens, and Cookies about which artifact is actually holding the login together becomes operationally urgent, because "the session ended" needs to be true at every layer simultaneously, and on a shared machine the layer you forgot is standing in a corridor with the next user in front of it.

Attribution is a different question from authentication

Audit requirements in regulated environments are almost never phrased as authentication requirements, even though everyone reads them that way. They ask: which human did this? That is a question about a record, not about a session, and the distinction has three practical consequences.

The strength of an attribution can differ from the strength of a login. A ward-scoped session established with a device credential, where the controlled-substance signature requires a card and a PIN, satisfies a per-action two-factor mandate that a strong shift-start login does not — because the mandate is about the signing act, not the session. Conversely, a passkey login at shift start with no per-action attestation gives you excellent authentication and, twelve hours later, no defensible answer to which of the four people at that station entered the record.

Attribution can be recorded when it cannot be enforced. This is the design freedom people leave on the table. Recording an attestation is cheap, offline-capable, and never blocks anything; enforcing a permission requires a live authorization decision and can block. Splitting them lets a partitioned terminal keep working with full accountability and deferred enforcement.

Break-glass is the acid test, and it inverts the default. Every clinical system has an override: a clinician who is not on the care team needs this patient's record now, because the patient is in front of them and deteriorating. The rule is absolute — the override must never be blocked. Not "rarely blocked." Never, because the failure mode of blocking it is a death, and no access-control policy is worth that.

The engineering consequence is that in this one region of the system, deny-by-default is the wrong posture and allow-and-account is the right one. The control is not the gate; the control is the consequence. The override is granted immediately, logged as an override with a reason, flagged for same-day review, notified to the patient's care team and often to the patient, and — the part that actually does the work — treated by the organisation as a serious disciplinary matter when abused. That control is entirely post-hoc, and it works: break-glass abuse rates in organisations that genuinely review the flags are low, and they are low because people know the flags get read.

Two things follow for the identity layer. The audit record must be trustworthy enough to support a disciplinary or legal process — a different bar from operational logging, and the subject of Immutable Audit Logs Are an Engineering Feature. And the review has to be resourced: an unreviewed break-glass flag is not a control, it is a compliance artifact, and the gap between the two is where the incidents live.

The arithmetic nobody puts in the design doc

Hardware credentials at scale are an operations programme wearing an authentication costume. The numbers decide more architectures than the threat model does.

Loss rates dominate unit cost. A security key is $25–50. In a high-turnover, physically-demanding, wet, gloved environment, annual loss and destruction rates in the tens of percent are ordinary. Retail is the extreme: annual staff turnover above 50% in some segments means the provisioning process, not the authentication protocol, is your system — you will issue credentials to more people each year than you have positions, and every one of those issuances is a manual identity-proofing event.

Set that against what it replaces. A fully-loaded helpdesk password reset is commonly costed in the $20–70 range, and a high-frequency workforce generates a lot of them. The business case for hardware credentials in these environments is frequently sound — but it is sound on reset volume, not on breach avoidance, and the case only survives if the replacement process is cheap. Which brings us to the trap.

The spares drawer is a bootstrap problem in disguise. Every one of these deployments ends up with pre-provisioned spares somewhere, because a nurse who lost her key at 02:00 cannot wait for the enrollment desk to open. A pre-enrolled spare is a bearer credential in a drawer, and a drawer is not an authentication factor. The only sound design is spares that are blank until issued, with an enrollment that a night-shift supervisor can perform in under a minute — which requires a supervisor-attested enrollment path, which is a deliberately-designed weaker credential that exists solely to bootstrap a stronger one. That is the same structure as Passkey Account Recovery Is the Whole Problem: the recovery path sets the real assurance level of the whole system, and in a 24/7 environment it must run at 02:00 with the staff who are actually there.

The honest framing to bring to the architecture review: your steady-state authentication strength is capped by your 3am replacement procedure, so design that procedure first and let it constrain everything else.

Batteries and firmware are procurement criteria. A Bluetooth authenticator has a battery, and a flat battery at 03:00 is a one-person outage in a place where a one-person outage matters. NFC, USB, and contact-card credentials are passive, which in this context is a feature rather than a limitation. Firmware cuts the other way and is worth understanding: many hardware keys are deliberately built without a field update path, on the reasonable grounds that an update mechanism is an attack surface. The consequence is that a vulnerability affecting a key model means physically replacing the fleet — a real, expensive, occasionally-observed event. Ask about it at procurement, decide which side of that trade you want, and size the replacement scenario before you buy three thousand of anything.

Readers are the hidden line item. Every architecture above assumes a reader on every endpoint. Retrofitting NFC or card readers to a thousand terminals — including the sealed ones, the wall-mounted ones, the ones inside dispensing cabinets, and the ones bolted into checkout lanes — is often larger than the credential cost and always larger than the software project. It is also the part with a lead time.

The counterpoint: sometimes the shared credential wins

I want to make this argument properly rather than gesturing at it, because it is the part that gets treated as heresy and shouldn't.

Consider a food production line. Eight operators, a sealed HMI panel per station, all operators on the same shift with the same role and the same authorisations, a process that must not stop, and a regulatory requirement to record which operator signed off each batch check. The purist design gives each operator an individual credential and an individual session on the panel.

Now count what that buys. The authorisations are identical, so it buys no access-control separation. The panel sits in a controlled area behind a physical access system that already records who entered, so it buys no presence evidence. The sign-off is per-batch and already carries an operator identifier, so it buys no attribution that isn't already there. What it costs is a credential lifecycle for a high-turnover population, readers on sealed panels, and a login step inserted into a process where stopping the line has a cost measured per minute.

Against that, an architecture where the panel holds a device credential, runs a station-scoped session continuously, and requires an individual attestation on each recorded sign-off delivers better attribution — because the attestation is bound to the record rather than inferred from a session that might have been left open — at a fraction of the operational cost, with no dependency on the network, and with nothing to lose in a wash-down.

That is not a compliance failure dressed up as pragmatism. It is the correct answer, and the reasoning is the same reasoning you'd apply anywhere else: identify what the control is actually for, and put it where it works. Where a shared credential genuinely fails is exactly where you'd expect — differentiated authorisation, exploratory access to sensitive records, anything where the session itself confers meaningful capability, and anywhere the shared secret leaves the physically-controlled area. The test is not "is it individual?" It is: does anything in this system depend on the session belonging to one person? If the answer is no, an individual session is ceremony.

The failure mode to guard against is the shared credential that starts life properly scoped and then accumulates capability — the station account that gets a supervisor permission added because it was convenient once, and now eight people share the ability to alter a recipe. Shared credentials need capability review on a schedule that individual accounts don't, because they have no natural owner to notice.

A framework, by environment rather than by product

The variables that actually determine the answer are: how many people share the terminal concurrently; how many re-authentications per person per shift; whether the work is transactional or exploratory; whether the terminal must survive a network partition; and whether individual authorisation differs across the sharing population. Everything else is detail.

Three rules cut across all of it.

Choose the de-authentication mechanism first, then the authentication mechanism. The de-auth mechanism determines your exposure window, which determines how much the login is actually worth. Teams do this in the opposite order and end up with a phishing-resistant credential guarding a session that stays open for ninety minutes after the human left.

Separate parking from ending, and bound ending by the shift. Walk-away parks with state preserved; handover and shift end terminate. If your application can lose work on a park, fix that before you touch the identity layer, because it is the reason your control will go unused.

Put the individual attestation on the action, not only on the session — and record it even where you can't enforce on it. It is what the regulation is actually asking for, it survives partitions, it is cheap, and it is the thing that makes an otherwise-shared design defensible.

The larger point, and the reason this doesn't resolve with a better protocol: these environments are not behind. They optimised, correctly, for a constraint set that consumer authentication never faces, and the result is an architecture where the person is authenticated once per shift, the machine is authenticated continuously, and the work is attributed transaction by transaction. That is not a degraded version of the passkey model. It is a different decomposition of the same problem, and on the evidence it is the better one wherever twelve people share a terminal. The mistake worth avoiding is not choosing the wrong mechanism. It is arriving with a model built for one person and one laptop, and treating the mismatch as the customer's problem.