How Should Passkey Recovery Work on Shared Workplace Devices?

For shared workplace devices, I would keep each worker's authenticator under that worker's control, provide an approved replacement path, and make recovery incomplete until old access and shared-device residue have been addressed. Restoring the employee's ability to sign in is one requirement. Preventing the next employee from inheriting that identity is another. The recovery design must satisfy both.

That usually means choosing an individually assigned security key, an appropriately controlled personal authenticator, or genuinely separated device profiles rather than storing everyone's credentials behind a shared device PIN. The appropriate choice depends on the applications, assurance requirements, physical work environment and actual device-management capabilities. A phone-based approach is not an operating solution for a workforce that cannot carry phones where the work happens.

My central question is what the next worker can do after a normal handoff, an abandoned session or a lost authenticator. This is narrower than a general assessment of phishing-resistant MFA recovery. It requires reasoning about people taking turns on the same equipment, including the interval between declaring a recovery successful and making the terminal safe to reuse. The examples below are proposed designs and hypothetical timelines, not accounts of deployments or tests I performed.

Sharing a terminal is different from sharing an authenticator

A terminal is a place where work happens. An authenticator is a means of demonstrating control of a credential. They can occupy the same piece of hardware, but treating them as the same administrative object is where a shared-device design becomes confused. A worker can use an individually controlled security key at a shared terminal without leaving the private key there. The terminal can nevertheless retain the worker's application session after the key has been removed.

WebAuthn defines user verification as a local authenticator process and cautions that several natural persons sharing an authenticator can be treated as the same user in that authenticator's context. Separately isolated compartments are a different case (World Wide Web Consortium [W3C], 2021). A successful PIN or biometric check therefore does not, by itself, establish that the person at a shared workstation is the employee named in the application. The organization must establish who controls that authenticator and how the account was bound to it.

Consider a hypothetical terminal whose operating-system profile is shared by a team. If every team member can unlock the same credential store, asking for local verification may merely confirm membership in that group of people. Giving the application accounts individual display names does not repair the underlying control boundary. Conversely, individual operating-system accounts with enforced separation may support a different architecture, provided their isolation, switching and credential storage are tested rather than inferred from the sign-in screen.

FIDO's enterprise guidance specifically treats passkeys stored in a common account or profile as a poor fit and discusses hardware keys and cross-device authentication as alternatives (FIDO Alliance, 2023). I would turn that into a design question, not a universal product recommendation: what remains under the individual worker's control when the terminal changes hands?

Define what must be false at the next shift

I would define a handoff invariant before selecting an authenticator: after the device is released for another worker, that worker must not be able to act as the previous worker, recover the previous worker's account, or read residual protected information through the paths in scope. This is a proposed acceptance condition. Its strength depends on which applications, local stores and recovery interfaces the organization actually includes.

There are at least five distinct objects to examine. The authenticator holds or accesses a private credential. The relying party or identity provider maintains an account binding. Applications hold sessions and tokens. The endpoint may retain documents, cached views and identifying metadata. Recovery systems hold the authority to establish replacement access. Deleting one object does not establish the state of the others.

Object	Relevant question at handoff	Evidence that would answer it
Authenticator access	Can the next worker invoke the former worker's credential?	Controlled attempt using the next worker's permitted device access
Account binding	Is a lost or retired credential still accepted?	Binding inventory and a fresh denial test with a sanctioned test credential
Application session	Can an existing session still perform a protected action?	Application-specific denial, including background clients in scope
Local information	Can a different worker recover protected remnants?	Cache, download and displayed-data checks under the stated threat model
Recovery authority	Can residual state bootstrap replacement access?	Negative recovery/enrollment tests without exposing actual recovery secrets

This separation also makes disagreements easier to resolve. The identity team may correctly report that a credential is disabled while the application team correctly observes an active session. Neither observation should be stretched into a claim about the entire terminal. The release decision needs the combined state, including any uncertainty that remains.

Choose the architecture around the worker's constraints

For a common browser or operating-system profile, an individually assigned roaming security key is an important candidate. The private credential can travel with its owner rather than becoming part of the shared profile. But custody, compatible ports, physical damage, accessibility and replacement distribution now become operational dependencies. Two issued keys can provide continuity only if they are independently controlled and the spare can be obtained when needed; two keys kept in the same lost bag share a failure mode.

An assigned phone used for cross-device authentication may be practical where the phone is permitted, available and appropriately protected. It may be unsuitable where radios are prohibited, devices cannot be carried safely, or users cannot reliably perform the interaction. I would evaluate the whole sign-in journey with the actual browser, authenticator and application. A successful demonstration on a different combination is insufficient evidence of compatibility.

Separately managed device profiles can be another option, but the profile boundary must survive switching, restart, browser persistence and application behavior. A visual account switch is not necessarily a credential-store or data-isolation boundary. The pilot should establish whether the next worker can reopen an earlier browser profile, invoke a password manager, or reuse a background application's access. No assumption about a particular operating system substitutes for those tests.

Google's own account guidance warns against creating a passkey on a shared device and notes that signing out does not remove the access available to someone who can unlock that device (Google, n.d.). That is a concrete provider warning, not a claim that every enterprise device mode behaves identically. Its lesson for this architecture is to distinguish using your authenticator at a shared terminal from creating a reusable credential inside a shared trust context.

Decide what synchronization is allowed to preserve

A synced passkey changes the meaning of losing one device. A credential may remain available through another approved device or be restored through the provider. That continuity can reduce interruptions, but the sync account and its recovery mechanisms become part of the access design. Device ownership alone does not tell you who can obtain another usable copy.

FIDO's consumer guidance explains that access can still be lost when the user loses access to the passkey provider or changes to an unsupported provider environment (FIDO Alliance, 2024). Its consumer setting matters: an employer cannot assume the same recovery arrangements, administrative visibility or exit rights apply to workforce accounts. I would document the provider relationship, permitted destinations, recovery authority and consequences of employment changes before accepting synchronization for a user group.

Apple describes passkey synchronization through iCloud Keychain with end-to-end encryption (Apple, 2024). Its separate platform-security discussion describes secondary authentication and an escrow mechanism for keychain recovery (Apple, 2022). These are two different assurance questions: how stored credentials are protected, and under what conditions access can be restored. Neither statement alone proves that an employer can revoke every usable copy or independently authorize provider recovery. Those capabilities require verification in the chosen managed or personal-account configuration.

A spare authenticator and a restored copy of the same credential are also different recovery assets. The former can have its own relying-party binding; the latter can preserve the original credential's identity. My design would record which case applies. If several devices can invoke the same credential, removing its relying-party binding has a broader effect than removing one local copy. A successful challenge response does not, by itself, provide a complete inventory of every place the credential can be used.

NIST treats syncable authenticators explicitly and requires a non-exportable authentication key for AAL3 (Temoshok, Fenton, et al., 2025). That distinction prevents the policy from treating all passkeys as interchangeable. The organization's required assurance, and the actual implementation meeting it, must be determined before convenience becomes the deciding criterion.

Separate routine replacement from genuine account recovery

A worker with a valid backup authenticator may be able to bind a replacement through an authenticated process. A worker who has lost every acceptable means of authentication presents a different problem: the organization must re-establish the authority to change the account. NIST distinguishes authenticator binding from account recovery and defines recovery requirements that depend on the applicable assurance circumstances (Temoshok, Fenton, et al., 2025).

I would give the service desk different procedures for at least three situations: an unavailable authenticator with no suspicion of compromise, a lost or stolen authenticator, and suspected account takeover. They may converge on a replacement, but they do not justify the same containment scope. Suspected takeover may require examining unfamiliar bindings, changed recovery channels and existing sessions before allowing ordinary enrollment to resume.

On a shared device, the recovery operator must also know whose session is currently displayed. A worker seeking help may be standing at a terminal still authenticated as the previous employee. Starting enrollment from that context risks binding the replacement to the wrong account. A controlled recovery workspace should make the target identity explicit and require the intended verification step before accepting a new binding. A familiar name in a browser corner is not enough.

Verification evidence should come from the approved process, with a documented path for exceptions. A shift supervisor can confirm assignment or urgency, but urgency is not proof of control of an account. Where the procedure requires independent identity verification, a supervisor's request cannot silently replace it. The organization must also provide a refusal and escalation path that works outside normal office hours, because an unusable recovery desk creates pressure to borrow another worker's identity.

Temporary access is a credential, not an administrative favor

A temporary bootstrap method creates an access path and should be treated accordingly. I would constrain who may issue it, how it reaches the intended worker, what it authorizes, how long it is usable and which event ends that authority. Avoid printing it into a shared ticket queue or leaving it in a message preview on the terminal being recovered. Record issuance and use without reproducing the secret in the evidence trail.

Microsoft's Temporary Access Pass is a time-limited passcode configurable for single use or multiple sign-ins and can support onboarding and replacement of strong authentication methods (Microsoft, 2026a). That is a concrete capability to evaluate, not evidence that the person receiving a pass has been correctly identified. Administrative issuance and secure delivery remain separate decisions, as do the policies controlling enrollment and subsequent application access.

A subtle limit deserves attention: Microsoft's documentation says that TAP expiration does not retroactively invalidate already established sessions and points to session controls for limiting continuing access (Microsoft, 2026a). I would therefore reject a test that ends when the temporary pass expires. It must also examine the sessions created with that pass, whether a durable authenticator was added, and whether the bootstrap path can be reused in an unintended context.

The success condition is specific: the intended worker has established the approved durable authenticator, the temporary authority has reached its intended end state, and any remaining sessions have an authorized basis. Do not assume that every bootstrap product offers a narrowly enrollment-only permission. If it also permits application access, include that scope in the risk decision and the test. The product's label does not define your authorization boundary.

End the sessions that the passkey did not create or destroy

Removing a key from a terminal does not necessarily terminate the application session established after authentication. NIST's federation guidance distinguishes the identity-provider session, the assertion and the relying-party session, with separate lifetimes (Temoshok, Richer, et al., 2025). That distinction is central to shift work: the next employee may never need to perform another passkey ceremony if the previous employee's application remains usable.

Microsoft documents that an application controls its own session token and that Entra ID cannot directly revoke a token issued by that application (Microsoft, 2026b). The practical consequence is an application inventory with an identified termination mechanism. For each important service, establish whether sign-out removes local state, revokes server-side authority, requests provider logout, or performs some combination. Verify the result with an already established test session, rather than relying on the wording of the button.

OpenID Connect RP-Initiated Logout defines a way for an application to request logout at the provider. It also discusses supported notification mechanisms and cases in which notifications may not arrive or the user may not approve provider logout (Jones et al., 2022). A redirect to a logged-out page is consequently not proof that every downstream application has completed its own transition. That is a protocol limitation to accommodate in the design, not a reason to abandon coordinated logout.

I would check foreground browsers, background clients and in-scope offline behavior separately. If an application can continue displaying protected cached information after remote access is revoked, the recovery record should say so. Server denial and local information removal are different outcomes. Where neither can be established promptly, the device can remain unavailable for handoff while the employee resumes work through another approved terminal. Continuity of the person does not require premature release of the device.

Verify the shared-device mode at the application boundary

A managed shared-device feature can coordinate much of this work, but its name is not an acceptance result. Microsoft's shared device mode covers supported applications on configured Android, iOS and iPadOS devices; unsupported applications do not receive its single-sign-on and single-sign-out benefits. Its documentation also assigns applications responsibility for cleaning up cached user data when users change (Microsoft, 2025).

I would therefore build a compatibility matrix from the applications actually required during the shift. Include embedded browser views, document viewers and any auxiliary application opened from the main workflow. An officially supported main application can still hand data to another component with a different lifecycle. The matrix should name the software version, account mode, shared-device integration and residual-data behavior that was exercised.

Test a normal sign-out, but also an interrupted handoff. The worker may walk away, the network may drop, the application may crash, or the device may restart while a sign-out is in progress. A design that is safe only when a person completes every step without interruption is fragile in precisely the environment where many people share equipment. Decide which failures cause a local lock, which require administrator intervention, and which permit a verified automatic cleanup.

There is an availability tradeoff. Aggressively erasing every local profile may protect the handoff while making the next sign-in slow or breaking required application state. Retaining state may improve continuity while preserving identity or data. I would separate reusable non-user configuration from protected user state and validate that classification with the application owner. The decision should be based on observed behavior of that configuration, not a generic claim that all caching is either safe or unacceptable.

Make the lost-key workflow a sequence of evidenced transitions

I would model a lost-key event with explicit transitions: report received, affected access contained, worker verified, replacement bound, old paths tested, and terminal released. Some work can occur in parallel, but the release decision depends on the required evidence being complete. A completed replacement does not automatically authorize release of the original terminal.

NIST calls for prompt action on compromised authenticators and notifications for recovery and new bindings (Temoshok, Fenton, et al., 2025). My operational extension is to separate the employee's recovery record from the shared device's release record. The first follows the identity and its authenticators; the second follows the terminal, applications and residual state. Link them so the next shift can understand why a seemingly healthy device is still held out of the pool.

Record what was invalidated precisely. Was the action a provider-device removal, a particular relying-party credential binding, an entire account restriction, or a session revocation? If the lost key held credentials for several services, one successful deletion does not establish the state of all the others. The inventory should identify the required scope without storing private keys, recovery codes or unnecessary personal material in the ticket.

A key later found in a drawer is another transition, not an automatic rollback. The approved process must decide whether it is eligible for reactivation, reset, replacement or retirement, given the report and evidence. Reinstating a previously suspended credential without review can undo containment. Conversely, permanently destroying every unavailable credential may create unnecessary disruption when the policy supports controlled suspension. The distinction should be settled in the procedure before the help desk improvises it.

A hypothetical shift-change timeline

Suppose a worker reports a missing assigned security key at minute zero. In this invented example, the identity service records the affected credential binding as invalidated at minute four. At minute six, the shared terminal is withheld from the pool. A critical application does not demonstrate denial of the old test session until minute seventeen. The replacement is bound through the approved process at minute twenty, and local cleanup plus a second-worker handoff test finish at minute twenty-five.

There are several different elapsed times here. Credential-binding invalidation took four minutes. The old application session was not demonstrated unusable until seventeen minutes. Successful replacement took twenty minutes. Terminal release took twenty-five. Reporting only the four-minute result would hide a thirteen-minute difference between binding invalidation and demonstrated session denial. That difference is not proof an attacker acted, nor proof access was continuously usable; it is a limit in the recorded evidence.

For this proposed release decision, assume that session denial, local cleanup and the second-worker negative test are mandatory. Then release time is no earlier than the latest completion of those required checks, subject to any ordering dependencies. The example's twenty-five-minute release follows from those assumptions. A maximum-of-completion-times rule is a decision rule, not a statistical reliability estimate or a guarantee about a real implementation.

Notice that the employee could resume approved work at another verified terminal after successful replacement while the original device remained quarantined. That possibility matters operationally. It avoids turning business urgency into permission to hand an uncertain device to the next person. Conversely, an application session for the recovered worker should not be treated as approved merely because replacement succeeded; its origin and authorization still have to fit the recovery decision.

No number in this example is a recommended service level. Organizations must choose and test their own containment, recovery and device-release objectives. The value of the timeline is that it prevents several different outcomes from collapsing into a single reassuring metric called recovery time.

Test with two workers, more than one application and real failure boundaries

A useful pilot needs at least two sanctioned test identities with different entitlements. Using one account to sign in, sign out and sign back in cannot reveal whether the next worker inherits the wrong identity. Choose at least one application whose session behavior differs from the main workflow so that the exercise does not accidentally test only a single integration path.

I would start with enrollment and normal turnover, then exercise replacement and failure cases. The expected outcomes should be written before execution. If the platform behaves differently, record the discrepancy and revise either the design or the permitted scope. Do not declare the configuration safe because the test operator eventually found a way to reach a login screen.

Scenario	Required observation in the proposed test
Worker A leaves; worker B takes over	B cannot invoke A's credential, session or protected local material through in-scope paths
Security key is removed during an active session	Actual application behavior recorded; no assumption that key removal logs out
Recovery begins in the wrong existing profile	Target-account mismatch is detected before a new binding is authorized
Old test credential is invalidated	Fresh authentication is denied at each affected relying service in scope
Temporary bootstrap expires or is deleted	Its reuse is tested separately from the sessions and durable bindings it created
Application or network fails during sign-out	Device remains unavailable unless the required handoff boundary can be established
Previously missing key is recovered	Controlled disposition preserves the approved containment decision
Worker cannot use the usual device or gesture	Accessible alternative preserves individual accountability and required assurance

Use designated accounts and non-sensitive fixture data. Record the actual versions and configuration, what was attempted, what was observed and what remained untested. A proposed test matrix is not evidence that those tests passed. I would also repeat the relevant cases after material changes to the operating system, browser, authenticator provider, shared-device integration or recovery policy.

The test should include the human process without becoming a covert exercise against unsuspecting staff. In an authorized rehearsal, a request with convincing organizational details but insufficient required verification should reach the correct refusal or escalation outcome. Assess whether the service desk can do that during a shift transition with the staff and channels actually available.

Preserve accountability without building another sensitive database

The recovery record needs to explain the decision: the requested identity, the device and applications in scope, the verification route used, the authorized approver where required, the affected credential identifiers, notifications, observations and release decision. It does not need the employee's biometric template, private credential, full recovery secret or a copied personal identity dossier. Keep sensitive verification material within the approved system that manages it.

For the next operator, a short status should be actionable: the worker may resume through approved authentication, the original terminal remains withheld, or the terminal has passed the specified release checks. Avoid an ambiguous green label that fails to identify which of those conclusions was reached. Where a test is unavailable, record the alternate control and residual limitation, including the person authorized to accept it.

Notifications are useful detection opportunities, but their delivery route can have the same dependency as the account being recovered. I would check whether the worker can receive and recognize a notice without reopening the suspect session. The exact channel and verification requirements belong to the approved recovery architecture; this article does not prescribe an insecure shortcut to make notification convenient.

Employment separation is a related but broader problem. The SaaS offboarding analysis examines removal of access across an application estate. This shared-device design should feed that process with accurate authenticator, session and device information rather than assuming the return of a physical key completes offboarding.

Where a simpler design is enough, and where it is not

A reasonable objection is that a small workplace cannot operate a complicated recovery apparatus. The appropriate response is to reduce the number of supported patterns and applications, then test those boundaries well. Individually assigned authenticators, one managed terminal configuration and a clear replacement route can be easier to defend than a nominally flexible deployment with undocumented exceptions. Complexity should buy a necessary capability, not merely accommodate every preference.

Another objection is that personal phones and synced credentials provide the easiest recovery. Sometimes they do. They may also introduce accessibility, workforce-equity, privacy and administrative-control problems. Those concerns do not prove synchronization is unsafe; they show why a consumer convenience claim cannot decide an employment architecture. An organization that cannot demonstrate the required provider and device controls should choose a narrower supported pattern.

Passkeys do not establish the trustworthiness of a compromised endpoint, guarantee erasure of every local artifact, or prove which natural person performed every subsequent action. Product documentation also does not establish compatibility in your deployed versions. The limits in this paper are deliberate: standards support particular protocol and lifecycle claims, provider documents describe their own capabilities, and the handoff method is my synthesis for a defined workforce problem.

Request a briefing on shared-device passkey recovery if your pilot works for assigned laptops but has not established safe turnover between workers. I would begin with the device/profile patterns, required applications, authenticator choices and current lost-key procedure. The useful outcome is a scoped architecture and acceptance exercise that shows how a worker regains access, how old authority ends, and when a shared terminal can responsibly return to the next shift.