Choose a specific business login for the first pilot
Start with one supported application and a named business owner. List the people, browsers and devices that actually access it, including shared workstations and supplier access where relevant. Decide what the pilot should improve: reducing reusable-password exposure, meeting a supported authentication policy or making sign-in more usable. Avoid declaring every account passwordless before identifying systems that still require a password.
Separate employee authentication from adding passkeys to a website for customers. Those are different projects with different administration and application responsibilities. For this guide, the pilot concerns the business accounts your team uses. If an application lacks the required support or clear recovery controls, keep that gap visible and choose another suitable starting point rather than installing an unreviewed workaround.
Agree the credential model and its ownership boundary
Decide whether the intended method is device-bound or synced through an approved credential provider. Record who owns the authenticator, the sync account and the replacement process. A personal phone may be usable under one policy and unsuitable under another. The decision should address the business's actual control needs, not assume that every synced credential is visible to an administrator.
Microsoft Entra's passkey FAQ describes scoped rollout and notes visibility limitations for synced copies. Apply its guidance only to the current supported Entra environment. For another service, check that provider's equivalent controls. Keep highly privileged users, ordinary staff and external collaborators as separate decisions when their ownership and recovery requirements differ.
Define the policy result and the allowed alternatives
Confirm what the application requests and checks during authentication. OWASP distinguishes user presence from user verification; touching an authenticator is not by itself the same as verifying its user. If the business requires an MFA or higher-assurance outcome, obtain the relevant provider and policy evidence rather than counting prompts or assuming the word passkey is enough.
List other sign-in and recovery routes that remain available. A phishing-resistant method does not strengthen an unrelated weak fallback automatically. At the same time, deleting every alternative before recovery is ready can cause a real lockout. Decide which supported alternatives remain, who may use them and what evidence will be reviewed before changing them.
| Area | Pilot observation | Decision before expansion |
|---|---|---|
| Application | Supported account and current policy. | Which populations and workflows are included? |
| Device and provider | Approved authenticator and ownership model. | Can the business support replacement and departure? |
| Verification | Evidence from the intended sign-in method. | Does it meet the actual authentication requirement? |
| Alternative access | Permitted recovery and fallback behavior. | Which routes stay protected and available? |
| Loss or departure | Supported credential and account actions. | Who verifies identity and authorizes the change? |
| Acceptance | Fresh sign-in and business task result. | What remains untested or blocked? |
Run the pilot with testable boundaries
Use an authorized test account where possible and keep an additional protected administrator available. Register the credential, perform a fresh sign-in and complete the business task the account needs. Record the provider, policy, device and observed result. Do not paste private keys, recovery codes or customer data into the pilot report; describe the control without exposing its secrets.
Include representative conditions rather than only the easiest laptop. For example, check an approved second device or supported cross-device flow if that is part of the business requirement. Keep the exercise controlled: do not remove the sole administrator's current method merely to see whether recovery works. A proposed test remains a proposal until the authorized owner performs and records it.
Separate credential revocation from device and session handling
Prepare a departure and loss procedure that identifies the account, registered credentials, access rights, relevant sessions and device-management owner. A service may let an administrator delete a registered passkey. That is a credential action at the service; it is not proof that a physical device was erased or every application session ended at the same moment.
Keep copied or synced credential questions separate from account authorization. The business can need to remove access to the account itself even if it cannot inventory every stored credential copy. Follow current provider controls and confirm the resulting behavior. If the event suggests compromise, escalate for incident review rather than treating ordinary device replacement as sufficient containment.
Expand only after support and handover work
Review pilot failures with the application owner and retain a list of remaining password-dependent systems. Give staff clear instructions for normal sign-in, unexpected prompts and device loss. Assign ongoing ownership for newly registered credentials, policy changes and departures. A rollout is maintainable when another authorized person can operate the agreed process without relying on the original implementer's memory.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with Israeli technical knowledge of account security and digital infrastructure. We can scope a passkey pilot alongside existing MFA and permission controls. The work is agreed against supported products and acceptance checks, with device ownership, account recovery and staff handover included in the planning.
