Organisations should provide an authentication path that does not depend on memory, puzzle solving, or repeated code entry. WCAG 2.2 Accessible Authentication prohibits cognitive function tests in any step of the process. In practice, that means offering an inclusive alternative such as biometric verification, while keeping security requirements, usability, and legal accessibility obligations aligned.
Designing a WCAG 2.2 Authentication Flow Without Password Dependence
The design goal is to make sign-in usable without forcing the user to recall secrets, solve puzzles, or repeatedly transcribe one-time codes. That usually means offering at least one accessible authentication path that is not memory-based and that still meets the organisation’s security standard. In practice, the best-known pattern is a phishing-resistant method such as passkeys, supported by recovery and exception handling that do not reintroduce the same accessibility barrier.
For organisations comparing options, the core decision is not “passwords versus security” but “which authenticators can meet assurance, resilience, and accessibility together.” Guidance from NIST SP 800-63 Digital Identity Guidelines and Passwordless and Passkeys Guide is especially useful here because it frames passwordless sign-in as an authenticator and recovery design problem, not just a user experience preference.
What WCAG 2.2 changes in the sign-in journey
WCAG 2.2 Accessible Authentication targets processes that depend on cognition in a way that excludes users who cannot remember credentials or complete challenge-style steps. The practical implication is that a login flow should not require the user to solve a test, reconstruct a memorised secret, or repeatedly enter codes as the only path through the gate. If a password remains available, it cannot be the sole route to access.
This is why inclusive sign-in designs often move to passkeys, device-bound authenticators, or other non-memory-based methods. A successful design keeps the main authentication step simple, reduces repeated friction, and avoids “authentication by obstacle.” The accessibility gain is real only if the alternate path is truly equivalent in access, not a degraded exception with weaker controls or confusing fallback rules.
Useful implementation detail comes from Workforce Identity Security Guide and Passwordless and Passkeys Guide, which both reflect the same practitioner reality: accessible authentication succeeds when enrollment, sign-in, and recovery are designed together. If recovery still depends on a remembered secret or an error-prone code chase, the flow has not actually solved the accessibility problem.
How to balance accessibility, assurance, and fallback design
The strongest pattern is to treat authentication as a portfolio. One method should deliver day-to-day sign-in with low cognitive burden, while recovery should be tightly controlled but still accessible. That means thinking through device loss, account recovery, step-up authentication, and help-desk processes at the same time as the primary login flow.
Security and accessibility align best when the organisation uses one or more methods that are resistant to phishing and relay attacks, then constrains fallback routes so they do not become the easiest bypass. The relevant standards and controls are clear on this point: passwordless authentication, session protection, and recovery hardening need to be designed as one system, not as separate product decisions. See Workforce Identity Security Guide, RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, and OWASP ASVS for the underlying assurance and implementation expectations.
Risk and Threat Considerations
Passwordless authentication reduces cognitive friction, but the risk moves rather than disappears. Weak recovery, over-permissive fallback, or poorly bound sessions can let attackers bypass the improved primary flow through help desk abuse, token theft, or account recovery abuse.
Failure mechanism: If the accessible path is secure but the exception path still relies on knowledge factors, SMS codes, or loosely verified support interactions, attackers target the weakest route and bypass the stronger one.
Impact: Users face exclusion or repeated friction, and the organisation gains a brittle login model where accessibility, phishing resistance, and account recovery are no longer aligned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authentication flow choice determines how users prove identity. |
| IA-5 — Authenticator Management | Passwordless design still depends on secure enrollment, rotation, and recovery of authenticators. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Customer and external sign-in flows also need accessible authentication choices. | |
| Recommendation — Use IA-2 to require accessible, phishing-resistant sign-in methods for users. Use IA-5 to govern authenticator lifecycle and recovery paths. Use IA-8 when the accessible login flow serves external users. | ||
| OWASP ASVS | V6 — Authentication | ASVS directly addresses accessible authentication, factor handling, and sign-in assurance. |
| V7 — Session Management | Passwordless sign-in still depends on secure session binding after authentication. | |
| V10 — OAuth and OIDC | Federated passwordless flows often rely on OpenID Connect and related sign-in standards. | |
| Recommendation — Apply V6 to verify the authentication flow avoids inaccessible knowledge-based steps. Apply V7 to ensure the authenticated session remains protected after login. Apply V10 to validate federated sign-in and step-up authentication behavior. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Secure authentication controls support passwordless and fallback design decisions. |
| Recommendation — Implement A.8.5 to require secure, accessible authentication methods and recovery. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Control 6 covers secure access paths and least-privilege access decisions. |
| Recommendation — Use CIS-6 to manage authentication paths and remove insecure fallback access. | ||
| GDPR | Article 25 — Data protection by design and by default | Biometric or accessible authentication choices may require privacy-by-design treatment. |
| Article 32 — Security of processing | Authentication design must still provide appropriate security for access to personal data. | |
| Recommendation — Apply Article 25 to bake accessibility and privacy into authentication design. Apply Article 32 to ensure the accessible flow preserves appropriate security. | ||
Practitioner Guidance
What to prioritise: Build one primary authentication path that is both accessible and phishing-resistant, then make recovery the second design problem rather than an afterthought. If your fallback is easier to abuse than your main flow is to use, the overall system is not secure or accessible.
What to verify: Test the flow with users who cannot rely on memory, speech, or rapid code entry, and confirm that enrollment, sign-in, step-up, and recovery all work without forcing them back to password-only paths. Validate that help-desk processes cannot override the control with informal identity proofing.
Practitioner takeaway: The right design is not “remove passwords at any cost”; it is “make the easiest path both usable and trustworthy, then ensure every fallback preserves that same standard.”
Related resources from NHI Mgmt Group
- How should organisations design proof-of-identity flows when employees need to access services without relying on passwords or central repositories?
- How should organisations design digital identity proofing without relying on passwords or weak second factors?
- How should security teams harden Linux password authentication without relying on passwords alone?
- How should organisations reduce human risk without relying on annual training alone?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
