Published on: • Last Updated:
Short answer: A small team can move off passwords in about four weeks without a big project: pick one password manager as the passkey home, switch the five accounts that matter most first, then roll the rest of the team over one person at a time — and write the recovery plan before anyone needs it.
Passwords have been failing small teams for years in the same quiet ways: the shared login in a spreadsheet, the reset email nobody can find, the ex-employee who still knows the Wi-Fi password. Passkeys fix the underlying problem instead of patching it. They replace the shared secret with a cryptographic key pair, and the private half never leaves the device that created it. There is nothing to phish, nothing to reuse, and nothing for a breached database to leak.
This guide is a rollout plan, not a product review: what a passkey is, why 2026 is the year the switch became practical, and the four-week plan that moves a real team over — including the recovery and offboarding steps most guides skip.
What a passkey actually is
A passkey is a login credential built on the FIDO2 standard: WebAuthn, the web API browsers implement, and CTAP, the protocol for talking to an authenticator such as a phone, a laptop’s fingerprint reader, or a hardware security key. When you create a passkey, your device generates a key pair. The public key goes to the service; the private key stays locked on your device, protected by your fingerprint, face, or PIN. To sign in, you unlock the device — that is the whole ceremony.
Three properties make passkeys different from passwords in ways that matter to a small team:
They cannot be phished. A passkey only works for the exact website it was created for. A fake login page that looks like your email provider cannot use it, because the credential simply will not match.
They cannot be reused. Every passkey is unique to one service, so a password leaked from one breach cannot be tried against your other accounts.
They cannot be leaked from a server. Services store only the public key, which is useless without the private half. A database breach at a vendor no longer hands attackers your team’s logins.
Passkeys also sync. Apple stores them in iCloud Keychain, Google in Google Password Manager, and Microsoft through Windows Hello and a Microsoft account. You can sign in on a device that does not hold the passkey by scanning a QR code with the phone that does. The major password managers — 1Password and Bitwarden among them — store and autofill passkeys alongside passwords, which is what makes a team rollout practical.
Passkeys for small business: why 2026 is the year to switch
Passkeys have existed for a few years, but until recently they were buried three menus deep. In 2026 they are the default. Google made passkeys the default sign-in option for personal accounts back in 2023. Microsoft made passkeys the default for new consumer accounts in May 2025, and through 2026 it has been moving existing users off text-message codes. Apple builds passkeys into Face ID and Touch ID across iPhone, iPad and Mac.
The numbers now back the shift. The FIDO Alliance’s Passkey Index 2026, published in October 2026, found passkey sign-ins succeeded 93% of the time, against 78% for traditional multi-factor authentication, and that passkeys accounted for 36% of successful sign-ins at participating services, up from 26% in 2025. The passwordless path is now the more reliable one — and that reliability gap is what a small team actually feels day to day, in fewer lockouts and fewer reset tickets.
One more change matters for mixed-device teams. In November 2025, Microsoft shipped native support for third-party passkey managers in Windows 11, so 1Password and Bitwarden now integrate directly with Windows Hello’s biometric prompt — removing the biggest practical complaint from earlier rollouts.
The honest caveat is that you cannot go passkey-only yet. Many banking apps, government services and smaller SaaS tools still do not support passkeys. A community directory at passkeys.directory keeps an up-to-date list of which services do. The plan below is built around that reality: passkeys where they exist, strong unique passwords in the manager everywhere else.
What changes for the team, habit by habit
| Old password habit | Passkey habit |
|---|---|
| One shared login, known by everyone | One shared vault in the password manager; each person signs in with their own account |
| Password reset by emailing the one person who knows it | Passkey on each person’s own device; a lost device is recovered, not a password reset |
| Two-factor codes copied from an app | Biometric unlock on the device — the second factor is built into the sign-in |
| Leaver’s access removed by changing every shared password | Leaver removed from the manager; their passkeys and vault access go with them in one click |
| New starter handed a list of passwords on day one | New starter invited to the manager, vaults shared by job, passkeys created as they go |
| Phishing training as the main defence | Phishing-resistant sign-in as the defence; training becomes the backup |
The table is the whole pitch to a team that does not care about cryptography: fewer resets, fewer shared secrets, and one clean action when someone leaves.
The four-week rollout plan
Four weeks is deliberately slow. A team that tries to switch everything in an afternoon will hit one service that does not support passkeys, one person whose phone is too old, and one shared account nobody owns — and the whole project gets a reputation for being fiddly. Spread it out, and each week has one job.
Week 1: One manager, one vault, one audit
Pick a business password manager first — Bitwarden, 1Password or Keeper are the established choices with business plans — and set it up before touching a single passkey. Choosing the manager is a tool decision like any other: our guide to choosing AI tools for business covers the same shortlist discipline. Create the business account with two admins — the owner and one trusted colleague — and turn on two-step sign-in for both. Then create shared vaults by job, not by person: Finance, Website and social media, Office Wi-Fi and devices, Suppliers.
Then audit. List every service the team signs into, and mark each one: supports passkeys, password-only, or unknown. Check the passkey directory for the ones you are unsure about. This list becomes the rollout order.
Move the shared passwords into the vault this week, starting with the accounts that matter most: email, banking, payroll, accounting, the website, and any admin accounts. Use the manager’s import from browsers or a CSV export; most teams finish this in under an hour. Run the manager’s health report and fix reused or weak passwords on the five most important accounts before doing anything else.
Week 2: The five accounts that matter most
Each person creates passkeys for their own five most-used accounts — usually email, the password manager itself, the accounting and invoicing tool, the cloud drive, and one social or publishing account. Do this in a fifteen-minute sit-down per person: watch them create the first passkey and confirm it is stored in the manager, not only on the device.
Where to create the passkey matters. On Apple devices, iCloud Keychain is the smoothest home; on Android and Chrome, Google Password Manager; on Windows, Windows Hello or the team’s password manager. For a mixed team, the password manager is the right default home, because it works the same way on every device.
Keep the password on each account for now. Passkeys sit alongside the existing password; the service offers the passkey first and the password remains as a fallback. Removing the password comes later, once the team trusts the new sign-in.
Week 3: The rest of the team, one person at a time
Roll the remaining accounts over a few people per day. The practical detail that decides whether this week works is device age: passkeys need a modern device with a biometric sensor or a secure PIN. Check each person’s phone and laptop before their session, and have a plan for the one older device — usually a hardware security key, which costs little and works with any modern browser.
For shared accounts, the rule is simple and non-negotiable: no shared passkey lives on one person’s phone. Shared-account passkeys go in the shared vault of the password manager, where anyone with vault access can use them and where removing a person revokes them.
Expect one failure mode this week: someone creates a passkey, then the service still asks for a password on a different device. That is usually a sync delay or a passkey stored in the wrong home — the device’s keychain instead of the manager. Check where the passkey was saved and re-create it in the manager.
Week 4: Lock it in — and write the offboarding rule
Week four is the week that decides whether the change sticks. First, remove passwords where the service allows it. Google, Microsoft and Apple accounts can now run passkey-only for most people. For each core account, once the team has used the passkey for two weeks without a problem, turn the password off. Keep passwords on the long tail of services that do not support passkeys yet, and review that list every quarter.
Second, write the recovery plan down. A lost phone is the question everyone asks and nobody plans for. The answer: the person’s passkeys sync through their manager or platform account, so signing into the manager on a new phone restores them; the manager itself is protected by its own recovery method, which should be set up in week one and tested once.
Third, write the offboarding rule and follow it. When someone leaves: remove them from the password manager the same day, then change the shared passwords they could see, starting with the most sensitive. With shared vaults instead of shared logins, one removal revokes everything they touched. The same checklist runs in reverse for a new starter — our AI SaaS onboarding tools guide covers the same first-week pattern.
Recovery: the part most guides skip
Passkeys change what goes wrong. Passwords go wrong by being forgotten, reused or stolen. Passkeys go wrong by being lost with a device, stranded in the wrong sync account, or orphaned when someone leaves.
Lost or broken phone. If passkeys sync through the manager or the platform account, a new phone restores them after signing in. If a passkey was created on-device only — no sync — it is gone with the phone, and the account falls back to its password and second factor. That is why work passkeys should live in the synced manager, not on one device.
Someone leaves. Remove them from the manager and from the shared vaults. Their personal passkeys go with them, which is correct. Any shared-account passkey stored in the shared vault stays with the team. Then rotate the shared passwords they knew, most sensitive first.
What passkeys do not fix
They do not fix a bad account. A passkey on an account with weak recovery settings — a reset email nobody monitors, a phone number that belongs to a former employee — is still a weak account. Fix recovery settings during the week-one audit.
They do not fix shared-account chaos by themselves. A passkey in a shared vault is clean; a passkey on one person’s phone for a shared account is a new version of the old problem. The vault rule is the fix, not the technology.
An illustrative example: one month with a ten-person team
The following scenario is an illustrative example only, using invented figures. It is not a real company and not a case study.
Take a fictional ten-person marketing agency. Its shared logins live in a spreadsheet, three people know the hosting password, and the office manager spends part of every Monday resetting something. The team uses a mix of Macs, Windows laptops and Android phones.
Week one, they pick a business password manager, create Finance, Website and Suppliers vaults, and import the spreadsheet. The health report finds one password shared across email, hosting and social accounts; it is replaced the same afternoon. Week two, each person creates passkeys for email and the accounting tool in a fifteen-minute sit-down; one person’s older Android phone cannot create a passkey, so they get a hardware key for the two most important accounts. Week three, the remaining services roll over, and the shared hosting passkey goes in the Website vault rather than on anyone’s phone. Week four, passwords are removed from the email and accounting accounts and the offboarding checklist is written down.
The result is not dramatic, and that is the point. Sign-ins get faster, the Monday reset queue shrinks, and when a contractor leaves the following month, one removal in the manager closes their access instead of a password-changing afternoon.
What worked and what didn’t
What worked: choosing the password manager first; the fifteen-minute sit-down per person; switching the five most important accounts before the long tail.
What didn’t work: trying to switch everything in one afternoon; letting a shared passkey live on one person’s phone; removing passwords before the passkey had two quiet weeks of use.
Frequently asked questions
Can a small team really go passwordless, or is this enterprise-only?
Yes, and the small-team version is simpler than the enterprise one. There is no identity platform to buy and no directory to integrate. A business password manager, a four-week plan, and one person owning the rollout is enough for a team of five to fifty.
What happens if someone loses their phone?
If their passkeys sync through the password manager or their platform account, signing in on a new phone restores them. If a passkey was created on-device only, it is gone with the phone and the account falls back to its password and second factor.
Do passkeys work across Apple, Google and Windows devices?
Mostly yes. Apple syncs through iCloud Keychain, Google through Google Password Manager, and Microsoft through Windows Hello and a Microsoft account. A third-party password manager is the smoothest option for a mixed-device team.
Should we delete our passwords once passkeys are set up?
Not immediately. Keep the password as a fallback for at least two weeks of normal use, then remove it on the services that offer a passkey-only option.
What happens if the password manager itself is unavailable?
The team is not locked out. Passkeys created on Apple devices sync through iCloud Keychain, on Android and Chrome through Google Password Manager, and on Windows through Windows Hello, so the passkey still works from the platform keychain even if the manager is down. And on any account where the password has not yet been removed, the password still works as a fallback. That is also why the manager’s own recovery method is set up in week one and tested once — the manager is the one account the team cannot afford to lose access to.
What do we do about services that still do not support passkeys?
Keep a strong, unique password for each of them in the password manager, exactly as the plan already does for the long tail of services. Check passkeys.directory for the ones you are unsure about — it keeps an up-to-date list of which services support passkeys. Then review the list every quarter: a service that adds passkey support moves onto the rollout list, and a service that still does not support them stays on a strong password in the manager.
Start with the manager, not the passkey
The mistake is to treat passkeys as a feature to switch on. They are a habit to move into, and the move works when the password manager is in place first, the five most important accounts go first, and the recovery plan is written before anyone needs it.
9 thoughts on “Passkeys in 2026: Moving a Small Team Off Passwords”