Passkeys for Business Applications: Plan Sign-In, Recovery and a Safe Rollout

The user fails to recall the password to the business portal. Another uses the same password in some other place. Yet another depends on a password manager but finds it difficult to recover from the application in case of switching to another device. These are common sign-on issues and impact both security of the user account and the effort that goes into helping real users get back to their accounts.

Passkeys provide a different way of authenticating based on public-key credentials. The application verifies a cryptographic response instead of receiving a reusable password. A private key is managed and interacted with by either the device or the credential provider. But introducing passkeys does need some account enrollment, verification by the server, and recovery considerations.

This guide provides information on how passkey authentication is planned for enterprise software applications. This guide will discuss the account journey, credential management, fallback mechanisms, security boundaries, testing, and roll-out. The examples in this guide are purely for illustrative purposes and not Digitonix customer implementations. Consider your account model, your users, device configurations, and security requirements when deciding how passkeys can be used by your enterprise.

Determine the account journey that needs improvement

Understand how your users currently create accounts, log-in, enroll devices, recover their accounts, and leave your organization. Understand the confusing parts of the account journey along with security issues with the existing account journey. Understand the difference between consumer accounts where customers manage themselves versus business accounts where an administrator has control over the memberships. The same technology for authentication might be present in both but very different in enrollment and recovery due to difference in ownership and authority.

State your objective in concrete terms. Minimizing the effort of a password reset, increasing security against credential phishing, or streamlining frequent login can be applicable. Be wary of claiming too broadly that passkeys resolve all possible risks related to an account. Stealing of session, modification of account, insufficient account recovery, and authorization issues represent different problems. The implementation must cater to your goal without compromising on controls elsewhere in the application cycle.

Know what the server and the authenticator possess

When using the passkey through a WebAuthn protocol, the server possesses information for validating the credential, like its public key. The private key is managed by the authenticator or the credential provider in line with its design. The application will not require the user’s fingerprint or face biometric in order to validate the credential. There is a difference between the local process and its cryptographic output.

Consult official sources prior to making a choice. For example, the W3C WebAuthn specification lays down the protocol rules, whereas Google's passkey overview is an example of its actual application. There could be variations in the behaviour of devices and providers. Be mindful of the difference between the protocol, platform and your own policy so that the proposal does not make the promise of providing an experience that is not feasible for your particular deployment.

Deciding on passkeys in the context of account policy

Determine whether the passkeys should be either optional, encouraged or mandatory for certain users and operations. Think about managed devices, shared computers and accounts in place. Do not assume that all your customers have similar agreements with providers and access to their mobile phones at work. Discuss the policy with account and security managers first.

Discuss how current authentication mechanisms continue to be available during the transition process. A fallback could be useful for legitimate users, but it would affect the security of the account itself. As a weaker mechanism bypassing the security measure, the advantage would become less. The choice of fallback mechanism should be guided by the company’s threat model and needs, with clear reasons why certain mechanisms could be used for enrollment.

Protect enrollment as an account-changing action

Adding a passkey changes who can authenticate to the account through that credential. Determine how the system determines that the enrollment is authorized. Assess the recent authentication and step-up authentication needs that are applicable to the account. Do not allow an unauthorized request to enroll in the account simply by providing the account ID.

Let users know what the credential is that got added and where they can manage it. Account changes should be communicated via appropriate means in the organization's infrastructure. Do not reveal more device and provider details than necessary. Ensure that you test the flow if the enrollment process gets interrupted and starts again. Partial interaction with the browser must not leave the application believing that there is a credential until the server verifies and stores the registration result.

Registration and authentication verification on the server

Use an up-to-date implementation that fits the stack used by the organization and check its settings. Server verification must perform appropriate protocol validations, such as the challenge, relying party context, origin, and the credential itself. Do not consider a successful indication from the frontend to be authentication. The application should only establish or renew its session after successful server verification.

Ensure that challenge handling and expiry remain consistent with the selected library and process flow. Do not reuse the challenge as a generic, indefinite sign-in credential. Validate rejected and expired challenges, origin changes, and invalid credential usage on the wrong account context. Such validation should happen during acceptance review. A proof-of-concept where one credential works to log in will not prove that the server properly rejects the invalid scenarios.

Relying Party & Domain Arrangement Plan

WebAuthn credentials are registered based on a relying party context. This means that the domain and origin selection will impact both registration and subsequent authentication. Examine the existing setup for your application across production and staging and any subdomains you may have. Do not assume that simply by moving your application to another domain, the same credential experience will be preserved.

Make sure that test environments are clearly separated depending on the chosen architecture. Describe the configuration used in each test environment and check that it corresponds with the currently available protocol and library guidelines. The web development services provided by Digitonix can be used in the application integration process, taking into account authentication needs.

Provide a sign-in process based on the familiar user choice

Describe the chosen method in the way appropriate for your customers. Sometimes, a brief description may be more helpful than using the protocol terminology. It is important to give clear instructions for people having a passkey and people needing to use any other supported method. Consider the passkey user journey guide created by Google and test the real interface with your target audience. See Google passkey user journey guidance for related information.

Handle cancellation without giving an indication of account compromise or unrecoverable errors. People might want to try signing into a different device or signing in using a different supported verification mechanism. Separate these cases from failure of verification. Ensure consistency between the interface and browser/OS dialogs such that the application does not give conflicting instructions at sign-in time.

User Presence and Verification Concepts

The terms "user presence" and "user verification" have separate meanings in the protocol. Note what values are requested by the application and what verification results are required by the server. Make sure that, if there is a requirement for a certain level of assurance, the actual verification check is being done for that result. Just because a browser dialog is familiar does not mean that the requirement was met.

Assess the authentication policy based on the full credential and device setup. Do not assume that each passkey implementation is just multi-factor authentication without assessing the specific circumstances. The security guidelines by OWASP for passkeys include various security considerations to consider. Implement these specific choices into actual configurations and testing rather than relying only on generalized marketing statements or architectural diagrams. See OWASP passkey security guidance for related information.

Provide a comprehensible interface for credential management

Enable legitimate users to view and manage their registered credentials in accordance with the policy of the product. Useful labeling and relevant dates can be provided when appropriate without assuming that the display of a certain label implies a specific synchronization location for the credential. Inform users about the implications of deletion and any pre-requisites to retain access. The user should be able to make a knowledgeable decision without divulging sensitive information about other people or accounts.

Protect changes in credentials with proper authorization and confirmation behavior. Addition, deletion, or replacement of a login mechanism is not a matter of modifying a preference setting. Document the security event and give the process for dealing with such unforeseen events. Consider the scenario if a user deletes his only valid mechanism of logging in. The management system is flawed if it could lock out legitimate users without a recovery procedure.

Make recovery as deliberate as enrollment

Document the scenarios in which legitimate users lose access to their account: the loss of a device, an unavailable account with the service provider, or some organizational change. Determine the evidence and authority needed by the organization to regain access to the account. It is erroneous to assume that the helpdesk could always bypass any form of authentication if the user seems genuine.

Outline the recovery process before users require it. Promote proper access recovery arrangements according to product policy. Do not state that all passkeys will be synchronized or recovered through the same vendor. This depends on the credentials and platform setup. Verify access recovery using selected options and outline limitations to ensure customer instructions align with what the application and vendors support.

Consider shared and managed devices

Individual credentials on an individual device and work credentials on a shared workstation present different challenges and requirements. Make sure that the device configuration supports the desired credential and session behavior. Look into sign-out processes and account selections. An employee finishing their shift cannot leave someone else with an unexpected open session just because the login process was easy.

In managed business scenarios, work together with the identity and device policies of the organization. In some cases, the workflow might involve an enterprise identity in addition to or in lieu of a consumer-based enrollment process. Do not impose a requirement for personal provider accounts in situations where that is not allowed. The implementation guide must make clear such restrictions so that platform selection and testing take into consideration the actual users of the application.

Maintain sessions and authorization within scope

A successful authentication process begins an authenticated session depending on the application architecture. Controls around session lifetime, session revocation, sensitive actions, and role-based authorization will still be necessary. Passkeys do not by themselves decide what records the user can see or what changes they are authorized to make in a business scenario. Permissions must be tested post-authentication, particularly in applications with multi-organization users.

Consider the aspects of logout, role change, and membership revocation within the context of the current security model. When a staff member leaves an organization, remove the relevant organizational access according to policy, regardless of the credential used for authentication. Software development and cybersecurity services can be considered together so the broader account and authorization lifecycle remains in scope. See Software development services for related information.

Test a realistic device and browser matrix

Determine the platforms that your users depend on. Determine the current level of support of the platforms using vendor documents. Consider registration, signing in multiple times, cancellation, cross-device journeys where appropriate, and recovery. Consider various states of the accounts and credentials and not just the latest device of the developer. Note which journeys are supported and what users should do if their platform doesn’t allow them to follow the desired journey.

Do not build a universal compatibility story based on a small sample size. Behavior changes, so continue to update the review process for any relevant updates. Test for the ability to navigate the accessible error handling and the accessibility of the flow around application controlled screens. Platform dialog is just one part of the equation; the decisions and instruction screens surrounding it will decide whether or not a customer completes the action without unnecessary help.

Measure helpful metrics without gathering unnecessary information

Collect metrics about enrollment completion, authentication success, cancellations, useful failure states for verification, and recovery attempts in a manner consistent with privacy and security considerations. Interpret the metrics properly. Cancellation could have been the result of a different choice made by the user. Do not keep all responses from the credentials and other identifying information just because you might find it useful for investigation.

Analyze support issues and example sessions based on metrics. Increased enrollment does not mean that users understand the recovery process or that the account policy is the right one. Designate account owners for monitoring and troubleshooting purposes. Give the team sufficient context to determine whether a failure is a result of configuration, unsupported environment, or just a regular user decision, without assuming that all failures are the same and releasing personal information about the account in a dashboard.

Roll out incrementally with a clear way to fall back

Begin with a targeted or opt-in approach that matches the account policy. Test enrollment, authentication, management, and recovery before making the requirement universal. Clarify how things will be different for current users and how they can get assistance. Identify factors that will stop the roll out, such as multiple verification failures and confusion around the recovery process. Incremental rollout leaves the team time to fix practical issues before rolling it out across all users.

Keep the fallback consistent with the security choice from the beginning. Don’t silently offer a simpler workaround if the desired flow has a flaw. Go through the correct account recovery procedure. Document any configuration or implementation changes in case regression is to be investigated. DevOps cloud services can help implement and observe whatever you choose as application architecture. See Cloud and DevOps services for related information.

Select implementation technology for maintenance

The flow should work with your current app and its libraries. Node.js or Python can implement the server part, while React or Next.js can be used for the frontend. Consider the issues of library maintenance, configuration, account integration, and testing. The frontend framework doesn’t do verification on the server or implement recovery policy.

Log the selected library version and process of updating. Any security libraries require an owner who can perform change control reviews and test related journeys after the update. Configuration assumptions and assumptions about the protocols should be kept explicit in the handoff. The business needs to know who owns the flow and how escalation is handled, without relying on the one-off developer who initially added the passkey button to the app.

How Digitonix can support passkey authentication planning

Provide the current account structure, user role definitions, sign in and recovery screens, device restrictions, and security goals. Digitonix can be contacted for discussion around discovery, UI design, implementation, and deployment planning. Ask for a proposal which addresses authorization, server-side verification, credential management, fallback, testing, and operational ownership. These considerations make it much easier to evaluate the full account flow, not just a working sign-in demo.

Learn about Digitonix's services and technology capabilities, and get in touch to discuss an account scenario you have in mind. Make sure to mention a lost-device situation and a staff-membership change in your query. The good solution is one that enhances the desired sign-in process, while being intuitive for the support team who would manage the app after its release. See contact the team for related information.

Frequently asked questions

Is the website getting my fingerprint/face scan data?

In a WebAuthn passkey setup, the site checks a cryptographic response provided by the user. The interaction with the local device happens separately, and thus, the website doesn’t require the biometric data of the user for authentication purposes. It is important to consider the authenticator/provider specifics in this case as well. Learn more about the authoritative documentation for the implementation you choose, rather than relying on the looks of a device prompt.

Will passkeys protect all the accounts from attacks?

No. They can deal with issues around passwords and phishing, but recovery, enrollment, sessions, device configuration, and authorization are still important topics. A poorly designed fallback procedure or unauthorized change of credentials will compromise the protective intentions for the account. Study the entire lifecycle and threat model. Validate the server and account authentication procedures, in addition to the regular login process, prior to presenting it as a security solution.

What if a user loses a device?

This depends on the credential provider, synchronization protocol, additional supported credentials, and account recovery process. Assume not all credentials are readily available on another device. Plan and test an account recovery procedure suitable for your business and user group. Educate users beforehand and make sure your support team has a process for helping users without compromising account security.

Can we continue using passwords during the migration period?

This might be suitable for the selected policy and implementation strategy; however, the fall-back will affect the security of the account. Determine which approaches will allow users to log in, enroll, and restore access. Consider the balance of concerns with the respective owners rather than introducing a fall-back mechanism on your own. Discuss the available possibilities with users and check the mechanisms as part of the same journey through the account.

What should be included in the first passkey release?

The passkey release should include proper enrollment, server verification, sign-in, credential management, recovery, supporting environment, and operational monitoring. You should have ownership and the right staging rollout strategy based on the selected account policy. Check the cases when the process fails along with successful implementations. Having a working passkey button is good for prototyping purposes; however, the release must include an implemented journey through the account.