European accessibility law is reshaping digital authentication

At a glance

What this is: The article argues that European accessibility rules now reach consumer authentication, making accessible identity and security experiences part of compliance.

Why it matters: This matters because IAM teams must design authentication, recovery, and transaction verification that work for all users without weakening assurance across human identity programmes.

By the numbers:

• The European Accessibility Act became effective in April 2019, and compliance is required by 28 June 2025.
• The Digipass 750 Comfort Voice includes 10 accessibility-focused features, including voice output and adjustable speech speed.

👉 Read OneSpan's accessibility guidance for Digipass and consumer authentication

Context

The European Accessibility Act extends accessibility obligations into consumer-facing authentication and security journeys. For IAM teams, that means identity controls cannot be judged only on assurance strength. They also need to be usable by people with visual, motor, sensory, or cognitive constraints.

In banking and similar regulated services, the practical problem is not whether authentication exists, but whether users can complete it reliably with assistive technologies and different interaction modes. The accessibility test now applies to the identity layer itself, not only to the surrounding application experience.

Key questions

Q: How should security teams make authentication accessible without weakening assurance?

A: Design the control so users can complete it through multiple sensory and input paths while keeping the trust standard unchanged. Use clear prompts, configurable interaction options, and validated fallback paths. Then test the journey with real assistive technologies and measure whether users finish authentication without help or informal bypasses.

Q: What breaks when consumer authentication is not accessible?

A: Users cannot complete secure access reliably, so support teams create exceptions, workarounds multiply, and the organisation inherits hidden risk. The control still exists on paper, but in practice it becomes partially unenforceable. In regulated environments, that is both a usability failure and an identity governance failure.

Q: How do banks know if accessible authentication is actually working?

A: Look for completion rates across user groups, support-assisted sign-in volume, exception requests, and the number of flows that fail under assistive technology testing. If one browser, device, or access mode consistently produces failures, the control is not robust enough for production use.

Q: Who is accountable when accessibility rules apply to authentication controls?

A: Accountability sits with the organisation operating the customer identity journey, not only with the product team that built the interface. Compliance, IAM, security, and digital experience owners all share responsibility for proving the control works for users who rely on accessibility support.

Technical breakdown

WCAG principles in consumer authentication flows

The article maps authentication design to the WCAG POUR model. Perceivable means users can access information through more than one channel, such as screen output and audio. Operable means the interface supports different input methods and avoids timing or navigation traps. Understandable means prompts, labels, and recovery steps are clear and consistent. Robust means the flow works reliably across devices and assistive technologies. In identity terms, this is about making assurance flows machine-readable and human-completable without changing the trust standard.

Practical implication: test sign-in, transaction confirmation, and recovery journeys against accessibility criteria, not just security acceptance criteria.

Accessible hardware authenticators and connected mode

Accessible hardware authenticators solve a different problem from app redesign alone. Features like larger buttons, voice guidance, repeat playback, and configurable messaging reduce friction for users who cannot depend on visual-only or precision-touch interactions. A connected mode can also remove the need for users to type challenge data manually, which lowers interaction burden in high-assurance journeys. The design challenge is to keep the assurance process intact while reducing dependence on a single sensory or motor pathway.

Practical implication: evaluate whether your highest-risk authentication paths still require manual entry that excludes users with assistive needs.

Robustness across platforms and assistive technologies

Robustness in accessibility means the identity control behaves predictably across browsers, operating systems, and assistive tools. That matters because authentication is only secure if it can actually be completed. If a control fails in one environment, users will route around it, support teams will create exceptions, or the business will quietly weaken the process. From an IAM perspective, robust design is part of control reliability, not a separate user experience concern.

Practical implication: validate authentication controls across the actual device and assistive-technology mix used by customers.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Accessible authentication is now an identity control requirement, not a design preference. The EAA pushes consumer authentication into the same compliance conversation as the services it protects. That matters because inaccessible identity flows create informal exceptions, support workarounds, and unusable recovery paths. The practitioner conclusion is straightforward: assurance that users cannot complete is not operationally real.

Authentication accessibility and assurance strength are not opposing goals. The article shows that readable, operable, and robust flows can coexist with secure identity verification. In NIST CSF terms, control effectiveness depends on both execution and usability. If users cannot complete the control, the programme inherits hidden risk through bypass behaviour and service desk intervention.

Accessible transaction verification: The important governance question is whether identity journeys remain trustworthy when users interact through voice, larger interfaces, or connected modes rather than standard visual input. That shift changes how banks should assess control coverage, exception handling, and customer support exposure. The practitioner conclusion is to treat accessibility as part of authentication assurance design.

Consumer IAM programmes must evidence inclusion at the control layer. Accessibility requirements now extend into identification and security methods, which means compliance teams need proof that authentication journeys work for diverse users in real operating conditions. The broader implication is that identity governance must track accessibility outcomes alongside security outcomes. The practitioner conclusion is to align IAM testing with both compliance and usability evidence.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves many identity programmes operating with partial control evidence.
• For a broader view of how visibility, rotation, and offboarding shape identity governance, see 52 NHI Breaches Analysis.

What this signals

Accessible authentication will increasingly be judged as control reliability. As regulatory pressure extends into the identity layer, teams will need to prove that security journeys are usable by more than the default user profile. The governance shift is toward evidence-based assurance, where completion rates and assistive-technology testing become part of the control record.

Accessible credential journeys reduce exception risk across both human and non-human programmes. The same discipline that makes customer authentication inclusive also improves operational clarity for support teams and auditors. For a wider identity baseline, the Ultimate Guide to NHIs remains the reference point for lifecycle, visibility, and offboarding controls.

Robustness will matter more as identity journeys diversify across devices and channels. The programme signal is that a secure control no longer counts if it works only in ideal conditions. Teams should expect accessibility testing to sit alongside assurance testing, especially where regulated customers interact through mobile, voice, and assistive interfaces.

For practitioners

• Map accessibility requirements to identity journeys Review login, step-up authentication, transaction signing, and account recovery against WCAG POUR expectations. Make sure each journey is perceivable, operable, understandable, and robust for users with assistive technologies.
• Test hardware and software authenticators together Validate whether your authenticator options work across screen readers, voice guidance, larger-button devices, and mobile browsers. Include real assistive-technology combinations in acceptance testing, not just standard desktop paths.
• Remove manual-entry traps from high-risk flows Where possible, reduce challenge typing and repeated numeric entry in connected authentication modes. If a flow depends on exact visual input, document the exception risk and measure support-assisted completion rates.
• Build accessibility evidence into IAM governance Add accessibility test results, exception records, and recovery-path validation to control attestations. That gives compliance teams evidence that identity controls are both secure and usable in production.

Key takeaways

• The European Accessibility Act now reaches consumer authentication, so IAM controls must satisfy both assurance and usability requirements.
• Accessible design is a control-quality issue, because unusable authentication drives workarounds, exceptions, and support-assisted access.
• Banks and regulated service providers should validate identity journeys with real assistive technologies before treating them as production-ready.

Key terms

• Accessible Authentication: Authentication designed so people with different sensory, motor, or cognitive needs can complete it reliably. In practice, that means the control works through more than one interaction mode, preserves assurance, and remains usable across devices and assistive technologies.
• WCAG Pour Model: The WCAG principles of perceivable, operable, understandable, and robust. In identity programmes, the model is useful because it shows whether login and verification flows can be experienced, completed, and interpreted by real users, not just technically validated by developers.
• Connected Authentication Mode: An authentication pattern where the device helps reduce manual challenge entry and related friction. For identity governance, the value is not convenience alone but lower interaction burden in high-assurance journeys, provided the underlying trust and auditability remain intact.

Deepen your knowledge

Authentication accessibility and inclusive identity journeys are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control programme that must work for diverse users and regulated channels, it is worth exploring.

This post draws on content published by OneSpan: Répondre à la loi européenne sur l'accessibilité avec le Digipass® Conformité. Read the original.