Passkeys can let someone sign in using a device or credential manager rather than typing a password. They also offer phishing resistance because the authentication is tied to the legitimate service instead of a reusable secret someone can type into an imitation page.
That’s a meaningful improvement. For a customer, the important result is simpler: can I get into my account without another password-reset expedition?
Troy Hunt’s May 2025 explanation of passkeys is useful because it follows real setup and sign-in experiences, including the differences between services and devices.1 Those differences matter when designing a business portal.
A passkey rollout needs to cover the ordinary sign-in and the awkward day when the expected device isn’t available. Otherwise the lovely new entrance still has an unresolved question about the spare key.
Explain the change in the customer’s language
The website doesn’t need to teach cryptography before offering a passkey. It does need to explain what the person is creating and how they will use it.
The wording should match the actual device and browser experience as closely as the implementation allows.
Keep the security explanation accurate and short
Passkeys use cryptographic key pairs. The service stores the public part, while the private credential is held by the user’s authenticator or credential provider.
A fingerprint, face check or PIN may authorize use of the credential locally. The website does not need to receive the person’s fingerprint or facial data to perform that passkey authentication.
That is different from a business deciding to collect biometric information itself. Clear wording can prevent people from reasonably misunderstanding what the sign-in prompt is asking.
It is also important not to call the whole account invulnerable. Passkeys improve the authentication mechanism; session management, recovery and permissions still need attention.
Somebody has to own the quiet, unglamorous work. See our hosting and support plans.
Make creation and later use feel connected
A customer may create a passkey and return weeks later. Help them recognize that the new sign-in option is the one they set up.
Provide an account view where the supported credentials can be managed appropriately. A person should understand how to remove an old credential or add another permitted way to sign in.
Avoid a rollout that celebrates creation but leaves the returning customer unsure which button to choose. We haven’t reduced login friction if we’ve merely moved the uncertainty to a more stylish screen.
Plan for different devices and different kinds of account
Some passkeys can sync through a credential provider; others are bound to a device or security key. That distinction affects how someone signs in elsewhere and what happens when hardware is lost or replaced.
The business needs to choose and explain the account model it supports, rather than treating every passkey as interchangeable.
Test the customer’s second device
For a fictional customer portal, try a person who uses a phone at home and a computer elsewhere. Test the supported combinations and the available sign-in routes.
Then examine a shared device. A customer using a family computer or a member of staff using a shared workstation needs an appropriate way to sign in without accidentally saving a personal credential to an unsuitable shared profile.
Shared operational access also raises a separate question about individual accountability. Giving several staff members one account is not automatically repaired by changing how that shared account authenticates.
For an ASP.NET Core application, verify the capabilities of the chosen framework version, identity provider and authentication components. A general .NET release announcement isn’t evidence that a specific passkey integration is already available in the application.
Treat recovery as a first-class journey
The best sign-in method still needs a plan for a customer who can no longer use it.
Make the fallback worthy of the account
Decide which alternative credentials or recovery processes are appropriate for the account’s risk. A weak recovery route can undermine a stronger everyday sign-in.
Support staff need a defined process as well. They should be able to help without improvising identity checks from whatever information a caller happens to know.
Explain recovery before someone is locked out, and test it with the same care as enrollment. Record how old credentials and existing sessions are handled when access changes.
I would introduce passkeys in a measured rollout with clear support information and observation of real sign-in attempts. Look at successful access, failed attempts and recovery needs, rather than counting only how many people created a credential.
The aim is a friendlier account experience backed by a stronger mechanism. Customers don’t need to admire the authentication architecture. They need to find their order, update their information and get on with the day.