By shifting enterprise sign-in to passkeys, credophishing is greatly reduced, but problems will surface when you need access. An employee lost his phone. A tech needs to access a shared set of workstations. A remote worker lost his security key and needs to get to work in 30 minutes for a meeting.
As IT leaders, we need to plan these scenarios out as part of our service design and identity deployment plan, providing employees with a means to get to work quickly and easily in case of an outage and also providing the service desk with a means to recover a user’s passkeys for exception scenarios above and beyond normal business operations.
Explain What Changes for the Users
The key concept to understand here is that a passkey is a cryptographic key pair. One half of the key pair is a public key held by a service, and the other half is a private key that is protected on an authenticator such as a phone, computer or hardware security key. In general, approval to sign-in online for services is done with a fingerprint, facial recognition or local PIN that is used to unlock a stored credential on the authenticator. In FIDO authentication, the biometric information used to approve online service login stays on the user’s device and is never transmitted to a website where it could be stolen by a hacker.
Since a passkey is bound to a service, a lookalike site would not be able to use the passkey to authenticate. This type of protection is known as phishing resistance, described by NIST in more detail here. In enterprise configurations, use of a passkey is protected by requiring verification that the user is in possession of the credential as well as knowledge of a PIN or completion of a biometric check.
Clearly explain the local PIN to employees. Employees will wonder why they are required to enter numbers when using a passwordless authentication method. Their local PIN or password is used to unlock the use of the credential on their local computer or device. Never ask employees to supply their credential PIN or password to support them.
Choose Credentials Around how People Work
There are two primary models for how to create a passkey: synced passkeys, which can be made available on multiple devices via a passkey provider, and device-bound passkeys, which are restricted to a single authenticator (e.g. a hardware security key). A single hardware security key can carry a device-bound passkey between workstations, without copying the private key to those computers.
Either of these passkey methods can be made available on multiple devices via a passkey provider, but the provider account, its recovery process, and its synchronization controls all become part of the decision-making process regarding the offering of these methods. The amount of control a organization has regarding where the keys are resides with the Device-bound method. This method would require more planning regarding loss or a change in duties. The NIST guidance on syncable authenticators contains information on the associated assurance considerations. Neither method should be offered solely because it looks easy to set up.
Map these choices to jobs in your organization. A desk worker with a company laptop is a different user case than a shift worker who uses several terminals. A system administrator would likely need dedicated hardware credentials to administer systems. Contractors will likely arrive with their own set of personal devices that the organization has no control over.
For the pilot test, provide an organization-supported option to employees who either cannot use their personal phone or prefer not to for work purposes. Test with people who use assistive technology to Authenticate. A good fingerprint reader, small touch area, and simple QR-code flow that works for one person, may not for another.
Test the Entire Route to Work
A successful sign-in to a browser proves one approach to work, but does not mean to imply that other approaches to access to desktop applications, VPN, remote desktops, etc. are ready for testing. We need to test out the applications that people actually use on the supported OS/Browsers with appropriate access policies turned on.
When testing the signing-in of a browser to a Microsoft-based environment, note that signing-in to a Windows device with a passkey to authenticate to an application is different from using the same passkey to authenticate to the same application from a different Windows device. Check the latest Microsoft compatibility matrix to test each scenario rather than making an incorrect assumption of compatibility between the different credentials.
Consider the physical environment where the sign-in will take place. Does the employee have the ability to connect the recommended security key? Are phones even allowed in that particular work area? Does the approved cross-device flow of sign-in work within the organization’s Bluetooth and network configuration restrictions? Document any workflows that are not supported and assign owner to work through the issues with a review date.
Design Recovery before Requiring Enrollment
When a new credential is enrolled, it must be verified that a new hire has been approved for the organization to begin to use the credential as well as notification sent to the employee who enrolled the other authenticator(s) so they know that other authenticator(s) have been added as well.
For secondary authentication methods supported by your organization’s platform, test to verify that enrollment of the secondary method will allow users to access the organization’s resources using only the secondary method. For example, two accounts on the same lost phone are of little value; however, for users who require continuous access to do their work, a separate, backed-up physical security key may be suitable.
FIDO’s enterprise recovery guidance should be mapped into a service desk process that outlines steps to verify an identity, to get approval from an authorized person, to revoke compromised credentials, and to restore access to resources. Define out-of-hours procedures for recovery as well.
Temporary Access Passes for Microsoft Entra environments can be used for time-limited access to register alternative authentication methods. Such Temporary Access Passes must be treated with the same level of care as other enrollment credentials, i.e. verify the recipient, deliver it through approved channels and limit its lifetime and usage. Temporary Access Passes do not replace identity verification.
Run through the recovery steps for the primary device to be unavailable – if the processes and procedures are stored against the account that cannot be accessed then the basic usability testing of the processes has failed.
Treat Shared Workstations as a Separate Use Case
A shared computer/terminal and shared user account can present different types of risk. Separating employee work into individual sessions is key to holding them accountable for their actions. Saving the passkeys of several employees in a single browser or account profile for an operating system compromises that accountability. It is contrary to the FIDO enterprise deployment guidance for individual passkeys to be stored in a shared account or profile.
Test a single security key (or another approved portable credential) and check what happens at shift change. Does removing the key end the application session? Session management for authentication is covered in NIST’s session guidance for applications and identity providers, including support for separate sessions, sign-out, account switching, inactivity limits, etc. Verify all of this for the next user at the workstation.
Make session cleanup part of your acceptance criteria – as authentication is worth nothing if the subsequent user to use a workstation has access to the applications that the previous user was using.
Prepare the Service Desk and Communicate Plainly
Simulate the actual UIs that employees will encounter on their approved devices. Show them where the generated credential will be stored. Inform them which work account(s) are approved. Describe the alternative work account options that the organization supports and what employees should do when they don’t see the expected prompt.
Be specific about privacy. Local biometric verification does not store, send or share the fingerprint or face images in the work application. Note that the verification is separate from device management. Describe the management requirements and administrative visibility of the organization’s actual device management configuration rather than promissing that IT will never see something on a personal device.
Create a short troubleshooting path for the various aspects of enrollment and authentication on approved devices (screens, credential save locations, account selection, prompts, supported authentication options, etc.). Practice a lost device scenario. Help support technicians understand when to stop troubleshooting an identity issue and escalate to appropriate support.
Measure Dependable Access and Enforce Deliberately
In addition to a registration count of existing credentials, it’s also important to measure employees’ use of them. For a pilot, consider tracking sign-in rates, how frequently users fall back to older workarounds, and the volume of tickets related to registration, as well as the time it takes to restore access when needed. Measure across work environments to ensure that an easy registration process for office workers does not mask challenges for front line workers.
When implementing as described in Microsoft’s deployment guidance, registration needs to be distinguished from usage. Registration of the passkey needs to be completed in phases and, for each group that is ready, the approved authentication methods need to be required for the in-scope resources. Weaker methods that employees have been using for routine access should then be disabled. Exceptions need to have an owner and a date when they expire, with a separately controlled process for emergency-access.
Malware, compromised session tokens and weak recovery passwords still pose a threat after users have enrolled with passkeys. That is why you need to safeguard your endpoints, perform access reviews and verify proper control of sessions.
The question to ask before rolling out to more users is can the average user do their job for a day, lose a device, and then recover access to resources using the process or flows you set up for passkeys.