Yes. If a vendor cannot show which authentication steps were tested for WCAG 2.2 AA conformance, the organisation cannot safely assume the product will work for the full population it serves. Procurement should require evidence, scope, and independent validation, especially for public-facing or regulated identity services.
What counts as authentication procurement evidence?
Accessibility evidence is not a nice-to-have procurement artifact, it is part of proving that the authentication flow can be used by the full population that the organisation intends to serve. For procurement, the key question is whether the vendor can show test scope, the specific authentication steps assessed, and the validation method used, not simply whether the product claims WCAG alignment.
That means the buyer should ask for evidence that covers sign-in, step-up authentication, recovery, enrollment, and error handling where those steps affect access. If the vendor cannot identify which parts of the journey were tested, the buyer is left guessing about whether the control works for keyboard users, screen reader users, low-vision users, or people who cannot complete a visual challenge.
For authentication-heavy products, the evidence needs to reflect the actual workflow the service will use in production. A login screen may look accessible in isolation while the surrounding sequence, such as MFA prompts, recovery codes, or device binding, still blocks users in practice. Procurement is therefore evaluating both conformance and operational usability, because a control that fails a subset of users is a control gap, not just a usability issue.
Why vendor scope and independent validation matter
Accessibility claims are only meaningful when the vendor can tie them to a defined scope and to an independent review of the authentication path. If the evidence is vague, outdated, or limited to marketing statements, the organisation cannot tell whether the tested conditions match the deployed product, integrated identity provider, or authentication method.
That is especially important when the service sits in front of a regulated, public-facing, or high-volume identity workflow. In those settings, a hidden accessibility defect can create exclusion, help desk overload, and inconsistent fallback processes, which in turn produce avoidable security and operational risk. The procurement record should make it possible to trace what was tested, by whom, and against which interaction steps.
In practice, this is similar to buying assurance for other security-relevant capabilities. NIST SP 800-63 Digital Identity Guidelines matters here because authentication assurance is not only about protocol strength, it is also about whether the chosen flow can be reliably completed by intended users. For implementation teams, Passwordless and Passkeys Guide can help frame how phishing-resistant sign-in still needs recovery and rollout decisions that affect real-world access.
What buyers should expect in the procurement pack
The minimum useful evidence set should answer three questions: what was tested, how it was tested, and whether any exclusions or exceptions were taken. A credible pack will usually include the authentication scenarios covered, the conformance target, the date of assessment, the test method, and any unresolved defects that affect access.
- Authentication journey coverage, including login, MFA, recovery, password reset, enrollment, and timeout handling.
- Scope clarity, showing the exact product version, modules, and deployment model assessed.
- Independent validation, preferably from an assessor who can explain the test method rather than a vendor-only self-declaration.
- Exception handling, including any known barriers, workarounds, or compensating processes.
Procurement should also look for evidence that the product supports secure fallback without creating a second inaccessible path. A common failure is to make the primary login accessible while the reset or recovery path is not, which forces users into manual intervention. That is where accessibility and authentication assurance meet operational resilience.
If the product includes modern sign-in methods, the organisation should verify them against the actual user groups it serves. OpenID Connect Core 1.0 is relevant because many authentication implementations depend on layered identity flows, and accessibility problems can appear in the handoff between the application, identity provider, and recovery journey.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Authentication assurance and usable sign-in flows are central to this procurement question. |
| Recommendation — Validate that the authentication journey is usable for the intended population before approving procurement. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Procurement evidence must show access paths are controlled and usable as deployed. |
| Recommendation — Require evidence that access controls are effective across the real authentication workflow. | ||
| OWASP ASVS | V6 — Authentication | The question concerns authentication behavior, including login and recovery usability. |
| Recommendation — Verify authentication requirements and recovery paths against accessibility evidence. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authentication procurement for workforce-facing services needs validated user access paths. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Public-facing identity services must authenticate external users reliably and accessibly. | |
| Recommendation — Confirm the organization can authenticate intended users without inaccessible steps. Assess external-user authentication evidence before accepting the service. | ||
Practitioner Guidance
What to verify: Require evidence for the full authentication path, not just the visible login page. If the vendor only shows a high-level accessibility statement, ask for the exact steps tested, the assistive technologies used, and the product version or build covered.
Decision rule: If the authentication flow cannot be demonstrated for keyboard-only use, screen readers, and recovery scenarios, treat the product as not yet procurement-ready for user populations that depend on those paths. If the service is public-facing or regulated, this should be an acceptance blocker rather than a documentation note.
What practitioners underestimate: Accessibility failures in authentication often surface in edge cases, such as MFA enrolment, challenge retries, or account recovery, not in the happy-path demo. Those edge cases are where users get locked out and where support teams absorb the operational cost.
Practitioner takeaway: Procurement should treat accessibility evidence as proof of usable authentication coverage, because a secure sign-in flow that cannot be completed by the intended population is not fully deployable.
Related resources from NHI Mgmt Group
- When should organisations treat an NHI as a high-priority risk?
- Should organisations treat application authentication code as part of identity governance?
- What breaks when organisations treat analytics tools as low-risk because they are not directly part of authentication or payments?
- How do organisations operationalise NHI ownership at scale?