1Password released enterprise passkey recovery on Sunday, addressing the objection that has slowed passwordless rollouts at every organization above a few hundred people: what happens when an employee drops their phone in a lake. Passkeys are private keys bound to a device or a synced credential store, and losing access to that store historically meant a manual identity verification and re-enrollment across every service. 1Password's scheme splits recovery material across the organization's administrators and the user's own recovery factors using threshold cryptography, so that recovery requires a quorum and no single party, including 1Password, can reconstruct the keys alone.
How the scheme works
At enrollment, the user's vault key is split with Shamir secret sharing into five shares with a threshold of three. One share stays with the user's own recovery credential. Two go to designated organizational recovery administrators, encrypted to their individual keys. One goes to a hardware security module 1Password operates, and one to a separate module in a different jurisdiction operated by a third party. Recovery requires three shares, which means two administrators plus one of the escrow holders, or an administrator plus both escrow holders.
The design deliberately makes 1Password insufficient on its own. Two of the five shares are held by the customer organization, so a compelled disclosure to 1Password produces at most two shares and cannot reconstruct anything. It also means an organization whose recovery administrators both leave without transferring their shares has locked itself out, which the product addresses with mandatory share rotation on administrator changes and a warning system that several early customers described as appropriately aggressive.
The threat model this creates
Any recovery mechanism is an alternate path to a user's credentials, and attackers target the alternate path. Help desk social engineering is how a significant share of large breaches begin, including the 2023 MGM and Caesars intrusions. A recovery process requiring two administrators to approve is substantially harder to socially engineer than one requiring a help desk agent to reset a password, and it is not immune.
1Password's mitigations are procedural rather than cryptographic: mandatory delay periods that the organization configures, notification to the affected user through independent channels, and a full audit record of every recovery event. The default configuration imposes a 24-hour delay with immediate notification, which gives a user whose account is being fraudulently recovered a window to object. Organizations can shorten it and the product warns them when they do.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
Why this matters for passkey adoption
Passkeys have had strong platform support since 2023 and disappointing enterprise adoption. Surveys from the FIDO Alliance put consumer passkey usage above 30 percent for major services and workforce deployment far lower. Recovery is consistently the top cited blocker in those surveys, ahead of application support and ahead of device provisioning.
The reason recovery blocks specifically is organizational rather than technical. An identity team can accept that a passkey is more secure than a password and still be unable to answer the chief information officer's question about what happens on a Sunday when a regional director loses a phone before a board meeting. A documented, auditable, cryptographically sound answer to that question removes the objection, and 1Password is the first vendor to offer one that does not amount to keeping a password around as a fallback.
The competition
Microsoft Entra handles this by keeping alternate authentication methods available, which works and reintroduces the weaker factor as an attack surface. Okta's approach relies on identity verification through a third-party service, checking a government identity document against a live capture, which is effective and expensive and unavailable in several jurisdictions for privacy reasons. Yubico's approach is to enroll two hardware keys and keep one in a safe, which is the most secure option and the one users comply with least.
Apple and Google both sync passkeys through their platform accounts, which solves device loss elegantly for consumers and creates a dependency an enterprise may not want. An organization whose employees' work credentials recover through personal iCloud accounts has an interesting conversation ahead with its auditors. 1Password's pitch is a recovery path the organization controls without a platform account in the middle.
Practical deployment advice
Organizations piloting this should choose recovery administrators carefully and not default to the identity team, since concentrating recovery authority in the same group that manages accounts removes a separation of duties that the threshold scheme was designed to provide. Several security architects recommended pairing one administrator from security with one from a business function.
The other advice, repeated by everyone we asked, is to test recovery before it is needed. A quarterly exercise where a volunteer's device is treated as lost and the full recovery runs end to end catches the process gaps that only appear under real conditions: an administrator on holiday, a notification going to an address nobody reads, a delay period that was configured in a different time zone. Recovery mechanisms that have never been exercised do not work. The organizations that run this drill consistently report the same three findings: the notification path was broken, at least one administrator had never used their share, and the documented steps referenced a console layout that changed two releases ago. None of those are hard to fix once found, and all of them would have turned a bad morning into a bad week.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Zero Trust
- Privacy
