Deploying Seedkeeper PRO in Your Organization
From Pilot to Everyone, Without the Usual Pain
Roll out in three phases: a pilot of five to ten people, then privileged accounts, then everyone. Two decisions made early determine whether the project succeeds - how many devices each person gets, and what happens when one is lost. Get those wrong and the rollout stalls at the first incident.
The Two Decisions to Make First
Everything else is logistics. These two are structural, and changing them mid-rollout means revisiting every account already registered.
One Device Per Person, or Two?
A hardware-bound passkey cannot be copied. A user with one device has a single point of failure, and the day they lose it, someone in your organisation spends hours on account recovery.
Issue two devices per person for anyone with privileged access. A card in the wallet and a ring, or a card in use and a card in a drawer. Both get registered on every account at the same time - see Passkey Backup Strategy.
The cost difference is small. The alternative is discovering the problem during an incident.
Who Holds the Backup?
Two workable models, and you should pick deliberately.
The user holds both. Simplest, and the user is responsible for keeping the spare somewhere sensible. Works well when people are reasonably careful.
The organisation holds the spare. A registered second device kept in a safe, retrieved when needed. Better control, and it means a departing employee cannot walk off with both. Requires a process for retrieval that does not depend on one person being available.
There is no third option where nobody holds a spare. That is the same as one device.
Phase 1: Pilot
Five to ten people, chosen for tolerance rather than seniority. You want the ones who will tell you what went wrong, not the ones who will quietly work around it.
Include at least one person who works remotely, one who uses a Mac, and one who is not technical. Those three will surface most of what you need to fix.
What to do in the pilot:
- Provision the devices - see Fleet Management and Bulk Provisioning
- Register each person on their email and one other service
- Have them work normally for two weeks
- Deliberately test a lost device, using the process you intend to use in production
What you are measuring: how many support questions per person, where they got stuck, and whether the reader situation works on every machine people actually use.
That last one catches more rollouts than anything else. The device needs NFC or a contact smartcard reader, and there is no USB path - see Device Capabilities. Confirm your fleet can read it before you order for everyone.
Phase 2: Privileged Accounts
Administrators, remote access, finance. This is where most of the risk reduction sits, and it is worth completing before extending further.
Enforce it centrally rather than asking. If you run Microsoft Entra ID, you can require phishing-resistant methods and restrict which hardware qualifies by AAGUID - see Deploying FIDO2 Passkeys via Microsoft Entra ID.
Keep a break-glass account. An emergency account with its own credentials, stored offline and outside the systems it can access. It exists precisely for the day your normal path is unavailable, which rules out keeping its credentials inside that path.
Remove the weaker methods once the stronger one works. An account is protected by its weakest enabled method. Leaving SMS enabled as a fallback keeps that route open for an attacker - see SMS vs TOTP.
Phase 3: Everyone Else
By this point the process is known and the surprises are behind you. Extend by team rather than all at once, and keep the pilot group available as informal support - people ask a colleague before they open a ticket.
What to Tell People
Keep it to three points. Anything longer will not be read.
- What it replaces. No more password for the accounts covered, no more codes to type before they expire.
- What to do if they lose it. Who to tell, and what happens next. Make it clear that reporting a lost device promptly is expected, not embarrassing.
- That the PIN cannot be recovered. Eight wrong attempts locks the FIDO applet, and recovery means erasing every passkey on the device - see Setting Up Your Passkey PIN.
Skip the cryptography. Nobody needs it, and explaining it makes the change sound more complicated than it is.
What Usually Goes Wrong
No readers on desktops. The single most common blocker. Sort it before ordering devices.
One device per person. The rollout runs fine until the first loss, then stalls while everyone reconsiders.
Old methods left enabled. The deployment is complete on paper and the weak route is still live.
No leaver process. Devices accumulate in drawers and access stays registered. See Employee Onboarding and Offboarding.
Announcing it as a security project. It lands better as a convenience improvement that happens to be more secure, because for the user that is exactly what it is.
FAQ
How long does a rollout take for a company of fifty people?
Typically a two-week pilot, then two to four weeks for privileged accounts, then the rest by team. The constraint is usually reader availability and scheduling rather than the technical work.
Should every employee get two devices?
Anyone with privileged access, yes - a hardware passkey cannot be copied, so a single device is a single point of failure. For other staff it depends on how costly an account lockout is for that role.
Can we enforce hardware keys centrally?
Yes, where your identity provider supports it. Microsoft Entra ID can require phishing-resistant methods and restrict registration to approved hardware by AAGUID.
What if some computers have no card reader?
The device needs NFC or a contact smartcard reader, and there is no USB path. Confirm coverage across your fleet during the pilot, before ordering at scale.
Should we keep SMS as a backup method?
No, once a stronger method works. An account is protected by its weakest enabled method, so leaving SMS active preserves the route an attacker would use.