ASP.NET Core Identity Passkeys in .NET 8: Primary Sign-In vs. Optional Factor Decision Changes Accessibility Workflow

Compatibility boundary

ASP.NET Core Identity introduces passkey (WebAuthn) APIs in .NET 8, making the target framework the decisive factor for availability. The accessibility upside—removing password typing and recall—is real but conditional on prompt usability, focus management, and a reliable non-passkey fallback.

Unresolved workflow decision

The core design choice remains whether passkeys replace password entry entirely, serve as a second factor, or stay opt-in. That decision reshapes the sign-in steps, recovery design, and support load. A known constraint is that WebAuthn credentials bind to the relying-party origin, so staging and production enrollments are separate and promotion forces re-registration.

Template and platform gaps

Identity UI scaffolding and passkey endpoints differ across .NET generations; a flow that works in a sample may not match the templates or options in the deployed SDK. Platform authenticator prompts and credential-provider UI are outside application control, so app-side accessibility cannot guarantee the whole sign-in experience.

Verification requirements

Keyboard-only operation, visible focus, error announcements, and a tested recovery path for users who lose authenticator access all need explicit design and manual testing with assistive technology on the exact SDK and patch version deployed.

What criteria should drive the choice between primary, second-factor, or opt-in passkey roles when accessibility is a first-class requirement? How can the origin-bound credential constraint be mitigated without forcing re-registration across environments? What minimal fallback flow satisfies both WebAuthn spec compliance and screen-reader usability when the platform authenticator is unavailable?