Notifications
Clear all
Topic starter
08/06/2026 4:39 pm
TL;DR: The European Accessibility Act now extends into consumer banking authentication, so login and transaction security controls must also be usable by elderly users and people with disabilities, according to OneSpan. For IAM teams, accessibility is no longer separate from authentication design, which changes how banks evaluate devices, interfaces, and back-end compatibility.
NHIMG editorial — based on content published by OneSpan: Meeting the European Accessibility Act with Digipass Compliance
Questions worth separating out
Q: How should banks make authentication accessible without weakening security?
A: Banks should treat accessibility as a design constraint inside the authentication control, not as an add-on after launch.
Q: Why does accessibility matter in consumer identity and access management?
A: Accessibility matters because consumer IAM controls only work if customers can actually use them.
Q: What do security teams get wrong about accessible authentication?
A: Teams often assume that accessibility is mainly a front-end or design-team issue.
Practitioner guidance
- Map authentication journeys to accessibility obligations Inventory all consumer login, step-up, and transaction approval flows and map them to the relevant accessibility requirements.
- Test authentication against WCAG POUR criteria Evaluate whether each authentication path is perceivable, operable, understandable, and robust for users relying on assistive technologies.
- Validate backend compatibility before rollout Check that accessible authentication devices or methods remain reliable across the bank's supported operating systems, browsers, and customer channels.
What's in the full article
OneSpan's full article covers the operational detail this post intentionally leaves for the source:
- Specific Digipass 750 Comfort Voice accessibility features, including voice, display, and button options
- How OneSpan positions the device across banking authentication back ends and deployment contexts
- The case-study quote showing how a financial institution evaluated barrier-free service delivery
- Product-level notes on supported authentication suites and configuration choices
👉 Read OneSpan's article on EAA-compliant banking authentication and Digipass →
EAA compliance for banking auth: what changes for IAM teams?
Explore further
08/06/2026 6:23 pm
Accessibility has become a control requirement inside consumer identity, not an external UX concern. The European Accessibility Act pushes identity teams to treat login and transaction approval as regulated user journeys. That changes the boundary of IAM governance because the control now has to be both secure and accessible to remain valid. Banks that still separate compliance, customer identity, and accessibility ownership will keep creating gaps that surface at the point of authentication.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to Oasis Security & ESG.
A question worth separating out:
Q: Who is accountable when banking authentication fails accessibility tests?
A: Accountability usually sits across IAM, security architecture, compliance, and customer experience teams, because the failure spans control design and regulated service delivery. The key question is whether the organisation can demonstrate that the authentication path was tested, approved, and maintained against accessibility obligations throughout its lifecycle.
👉 Read our full editorial: European Accessibility Act compliance reshapes banking authentication
