Most frontline systems still run on shared accounts. One PIN per terminal. Six associates, twelve clinicians, one login. Compliance asks for individual attribution. Operations can't afford to migrate. ScrambleID for the frontline surface sits on top of your shared-account model and gives you per-user identity, per-user audit logs, and a passwordless experience without rebuilding the systems underneath. No personal phone required.
Five associates work the same register over the course of a shift. The legacy POS keeps logging the shared account it always has, register02, line by line, the same way it did yesterday. ScrambleID logs five distinct cryptographic events at the same instant, one per associate, one per tap. Two records exist for every shift. Compliance can name the person. Operations doesn't have to migrate anything.
Native Biometric
Workstation . Desktop client
Cleanroom-safe
Windows Hello, Touch ID, fingerprint reader. Platform authenticator unlocks the device-bound key.
PIN at workstation
Workstation . Desktop client
Cleanroom-safe
Numeric PIN at the device. For environments without biometric hardware.
Proximity badge tap
Wearable badge . reader-equipped workstation
Cleanroom-safe
Wearable-bound credential. Signed event per tap, not session resume.
QR cross-device
Workstation . Mobile app
For environments where personal phones are allowed. Workstation displays the QR; phone scans.
Code entry
Workstation . Desktop client
Cleanroom-safe
Fallback when no biometric and no badge. Code typed at the workstation.
FIVE MODALITIES . FOUR CLEANROOM-SAFE . ONE SIGNATURE PER TAP
Frontline systems weren't built for individual user accounts. They were built to be fast, available, and operationally simple for shift work. Compliance now asks for individual attribution. The audit log can't name a person. The time clock can't tell who actually clocked in. The unattended workstation can be walked up to. Three places frontline auth breaks today.
THREAT . 01
Six associates, one PIN. Twelve clinicians, one badge. Compliance asks for individual attribution; the audit log can only name the terminal. PCI DSS 8.4.2 expanded MFA into the cardholder data environment. HIPAA Security Rule 164.312(d) requires authenticated user access to ePHI. Rotating the PIN faster doesn't fix attribution. Per-user identity at the cryptographic layer does.
THREAT . 02
Shared credentials make time-clock fraud trivial. A co-worker taps in for an absent colleague. The system records arrival; the absent worker gets paid. Labor laws and audit programs require records of work hours that can be tied to individuals. Buddy-punching is unattributable when the credential is shared. Per-user authentication at the time-clock event makes it attributable.
THREAT . 03
A clinician steps away from the workstation on wheels for a moment. The session is still active. Someone walks up. The audit log records the wrong identity for whatever happens next. Sub-second tap-out on movement away and a fresh signed authentication on the next tap-in change that. Session continuity stops being attribution risk.
An associate on a shared register, a clinician at a workstation on wheels, a contact-center agent on a cleanroom desk. Three operational realities, three different modalities, the same cryptographic primitive underneath. None of them require a personal phone.
SCENARIO . 01
Multiple associates per shift on the same Front Register. Fast handoffs. Shared PIN today, with the post-it note on the side. With ScrambleID for the frontline surface, each associate taps a wearable badge or uses the workstation's biometric. The legacy POS still sees its shared register account. The audit log knows it's Sarah Chen. Sub-second context switch between users.
SCENARIO . 02
Hospital floor. Dozens of clinicians per shift. WoWs and fixed nursing-station terminals. The clinical workflow demands sub-second context switches: walk up, tap in, chart, walk away. ScrambleID for the frontline surface produces a fresh signed authentication per tap (not session resume), so the audit log carries per-clinician attribution that holds up in a HIPAA review or an EPCS prescription event.
SCENARIO . 03
A contact center where personal devices are banned by policy: no phones, no USB, no smartwatches. The auth has to happen at the workstation itself. Native biometric or PIN. No QR, no app, no second device. ScrambleID for the frontline surface runs as a desktop client that authenticates the agent cryptographically before the agent's session opens, with per-agent attribution in the audit log.
On paper, every associate has their own account. In practice, they all use the same PIN. The policy says individual attribution. The legacy system can only name the terminal. The badge reader vendor has a kiosk credential baked in. ScrambleID for the frontline surface doesn't ask you to fix any of that. It sits on top of your existing shared-account model, authenticates the actual person at the device, and produces a per-user audit record while the legacy system keeps using its shared credential exactly as before.
Same shift. Same register. Two records. The legacy system keeps working. Your auditor gets the proof.
SHARED PIN
Everyone in the store knows it. No attribution at the audit layer.
SESSION-RESUME TAP-AND-GO
Fast handoffs, but no fresh ceremony per tap. Session is just resumed.
SMART CARDS (PIV / CAC)
Phishing-resistant, but PKI-heavy. Slow rollout, no cross-surface reach.
Cryptographic per tap. Cleanroom-safe. Sits on top of your legacy. No other primitive does all three.
Five primitives . one row holds the line
Swipe sideways to compare. ScrambleID is the highlighted column.
| Method | Per-user cryptographic ceremony per tap | No personal device required | Compatible with shared-account legacy systems | Cross-surface | Recovery without help-desk reset |
|---|---|---|---|---|---|
| Shared PINOne PIN on the terminal, everyone knows it | NoNo cryptography, no per-user proof | YesPIN at the terminal | NativeIt IS the legacy system | NoFrontline only | NoReset is a sticky-note rotation |
| HID proximity badge aloneTap-on-reader, no challenge-response | NoReplay-vulnerable, no signed event | YesWearable, not a personal phone | PartialReplaces the PIN, not the legacy account | NoFrontline only | NoLost badge requires help-desk reissue |
| Session-resume tap-and-goTap-and-go that resumes a kiosk session | NoSession resume, not a fresh signed ceremony per tap | YesWearable badge, no personal phone | PartialOften a stored kiosk credential, not true overlay | NoHealthcare-flavored, not cross-surface | NoHelp-desk-driven re-enrollment |
| Smart cards (PIV / CAC)Federal-grade phishing-resistant credentials | YesPer-user, cryptographic | YesCard, no phone | NoPKI-heavy, requires legacy-system change | NoWorkstation only, no voice/agent reach | NoCard replacement workflow |
| ScrambleIDCryptographic per-tap, overlays shared accounts | YesFresh signed event at every tap | YesCleanroom-safe by design | YesSits on top, no legacy migration | YesSame primitive on web, voice, agent | YesIdentity-proofing-based reissue |
Every frontline environment is its own operational reality. Retail POS at line speed. Hospital floors with sub-second clinician switches. Field crews on truck-mounted devices. Contact centers and secure facilities where personal devices are banned. Each context fits a different modality. The cryptographic primitive underneath is the same one ScrambleID runs on web, voice, and agent.
INDUSTRY . 01
Shared POS terminals at the front of every store. Multiple associates per shift on the same register. Fast handoffs, line speed pressure, shared PIN reality. ScrambleID for the frontline surface gives per-associate identity at the existing register without forcing a POS migration. Modality fit: badge tap or workstation biometric, with PIN as fallback.
INDUSTRY . 02
Workstations on wheels, fixed nursing-station terminals, clinical desktops. Dozens of clinicians per shift. Sub-second context switches: walk up, chart, walk away. ScrambleID for the frontline surface produces a signed event per tap (not session resume), satisfies HIPAA's authentication requirement, and meets the EPCS hard-token-or-biometric bar for controlled-substance prescriptions.
INDUSTRY . 03
Service technicians, delivery drivers, logistics crews, traveling clinicians. Devices are mobile, sometimes shared across vehicles or routes, sometimes carried by the same worker for a shift. Identity has to travel with the worker. Modality fit: native biometric on the device, PIN as fallback, proximity badge where deployed.
INDUSTRY . 04
Environments where personal devices are banned: contact-center floors with PCI scope, defense SCIFs, financial-services trading desks, semiconductor fabs, pharmaceutical compounding rooms. The auth has to happen at the workstation itself. No phones, no USB, no QR. Native biometric or PIN at the device, signed at the cryptographic layer.
Edge cases
// what about lost or broken badges?
Identity-proofing-based reissue, not help-desk-issued reset. The replacement badge is bound to the user via the same proofing event the original was. No "vish the help desk to re-enroll" attack surface.
// what about end-of-shift handoffs?
Tap-out is cryptographic, not session-resume. The outgoing user's session ends when they tap out. The incoming user produces a fresh signed authentication on tap-in. The legacy account on the workstation can stay open across the handoff if it needs to.
// what if the workstation has no biometric reader?
PIN is the cleanroom-safe fallback. Code entry covers environments without biometric and without badge readers. Modality fit is policy-driven; the desktop client picks the strongest available mode at the device.
// can this run on Citrix / VDI / RDS thin clients?
Yes. The desktop client runs on the endpoint where the user actually taps in. The published session inherits the per-user authenticated context via standard Windows session APIs and signed token forwarding.
// what about offline or air-gapped workstations?
Pre-cached credentials and offline biometric/PIN unlock work for the duration of the offline window your policy permits. The signed events queue locally and flush to the audit ledger when connectivity returns.
// what about terminated employees?
Revocation propagates through the IdP federation in real time. The next tap on any registered surface is rejected. Old signed events stay in the audit ledger for forensic purposes; new events stop the moment the principal is revoked.
Two records get written for every tap. The legacy system writes its usual shared-account line: register02 logged in, drawer assigned, sale committed. ScrambleID writes a per-user signed authentication record at the same instant: Sarah Chen, badge tap, signature, verifier accepted. Both records exist. Both are auditable. The legacy system never has to know about the second one. That's the whole architecture.
No. That's the entire point of the overlay. Your legacy POS, EHR, or workstation keeps its shared local credential exactly as it does today. ScrambleID adds the per-user identity layer above it. No schema migration, no application change, no individual-account rollout on systems that were never built for it.
Three: native biometric on the workstation (Windows Hello, Touch ID, fingerprint reader), PIN at the workstation, and proximity badge tap. All three are wearable or workstation-bound and require no personal phone. QR cross-device requires a phone and is reserved for environments where personal devices are allowed.
Session-resume tap-and-go unlocks a stored kiosk credential on tap and resumes the session. No fresh cryptographic ceremony per tap, which means the audit attribution is structurally weaker than it appears. ScrambleID for the frontline surface produces a fresh signed event on every tap, bound to the device and the user, with a cryptographic verifier accepting or rejecting in real time. Your audit log carries proof, not just claims.
Yes. The desktop client runs on the endpoint where the tap actually happens. The published session inherits the per-user authenticated context. Common deployment patterns (Citrix Workspace, AVD, Horizon, RDS) are supported via standard Windows session APIs.
Sub-second on commodity hardware. Healthcare workflows demand sub-second context switches at workstations on wheels; that's an explicit design target. Badge tap is typically the fastest modality. Per-environment numbers depend on the modality and hardware profile; we can share specifics once your team's runtime profile is known.
Identity-proofing-based reissue, not help-desk reset. When a badge is lost, the replacement is bound to the user via the same proofing event the original was. The help desk doesn't issue a temporary credential the attacker can vish their way into. This closes the same recovery-flow ATO surface that ScrambleID for the web surface's recovery answers, with frontline-appropriate proofing.
Yes. The shared-account overlay applies wherever workforce identity needs to be auditable on shared workstations or shared accounts. Retail runs it on POS terminals, drive-thru tablets, and back-of-house kiosks where multiple associates log into one local credential per shift. Healthcare runs it on EHR workstations, workstations on wheels, pharmacy systems, and shared clinical terminals where sub-second context switches and HIPAA 164.312(d) attribution are non-negotiable. Pharma runs it on EPCS-controlled workflows where DEA 21 CFR Part 1311 requires hard-token or biometric authentication on every controlled-substance prescription. Manufacturing and hospitality run it on production-floor stations, line workstations, hotel front desks, and field-tablet check-ins where the same overlay produces per-user signed events without migrating the legacy system. One primitive, every industry, every shared workstation.
Yes for HIPAA Security Rule 164.312(d) (authenticated user access to ePHI) and PCI DSS 8.4.2 (MFA into the cardholder data environment). For DEA EPCS 21 CFR Part 1311, native biometric and proximity badge configurations meet the hard-token-or-biometric bar; PIN-only does not. Specific implementation guidance and audit artifacts are available on request.
Pre-cached credentials and offline biometric/PIN unlock work for the offline window your policy permits. Signed events queue locally and flush to the audit ledger when connectivity returns. The cryptographic primitive doesn't depend on a live verifier round-trip; the verifier just accepts or rejects the queued signatures on reconnect.
Same cryptographic primitive, same identity binding, same key material. A worker enrolled in ScrambleID for the frontline surface can authenticate to a web app (web surface), to a contact-center caller verification flow (voice surface), or to an autonomous agent action (agent surface) without re-enrolling. The control plane is unified; the audit model is unified; the user experience is consistent across every surface they touch.
At a shared device, a named human is attested even when agents drive the workflow.
Per-user proof keeps a real person in the loop on the taps that matter. As an overlay it proves and records who acted; on the auth path it gates.
How the rail gates an actionWEB SURFACE
Phishing-resistant web auth, every device
Five modalities, one signature, every browser. The same primitive that runs Frontline runs the web side too.
NON-HUMANS
Per-agent identity. Per-call signature. Zero static secrets.
Cryptographic authentication for AI agents, RPA bots, M2M services, and service accounts. The non-human half of the trust chain.
VOICE SURFACE
When the call sounds right but isn't
Deepfake-resistant voice authentication for contact centers. Closes the recovery-flow vishing surface.
Shared logins can't carry what you're automating next. Per-user proof can.
Per-user identity at every shared device. No personal phone required. Overlays your shared-account systems.
Pilot ScrambleID →