Who is accountable for accessibility gaps in self-service identity applications?

Why This Matters for Security Teams

Accountability for accessibility gaps in self-service identity applications is rarely a single-person issue. Product owners define the journey, engineering leads implement it, and accessibility reviewers validate it, but security teams still own the risk when identity workflows block legitimate users or push them into unsafe workarounds. That matters because self-service identity is not a cosmetic layer; it is often the front door to provisioning, recovery, and privileged access. The same design mistakes that frustrate keyboard-only users can also weaken authentication assurance and recovery controls. Guidance from WCAG and control expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls both point to accessibility as a design requirement, not an afterthought. NHIMG research shows the operational cost of weak identity governance is already high: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In practice, many teams discover accessibility failures only after a critical user cannot complete enrollment or recovery and support has to bypass the intended control path.

How It Works in Practice

The cleanest accountability model is shared, but not vague. Product management owns the user journey and acceptance criteria, engineering owns implementation, QA owns test execution, and accessibility specialists or reviewers own conformance validation. Security owns the control objective: identity flows must remain usable without excluding keyboard-only users, screen reader users, or people who rely on high-contrast modes and assistive navigation. That is especially important for registration, MFA enrollment, password reset, recovery, and consent screens, where inaccessible controls can become de facto access denials. A practical process usually includes:

• Designing with accessibility requirements in the definition of done, not in a post-release checklist.
• Testing critical identity tasks with keyboard navigation, screen readers, focus order checks, and error-message review.
• Mapping each failure to an owner, a severity level, and a fix deadline.
• Verifying that recovery paths do not create a weaker alternate flow than the primary flow.

For identity-heavy environments, this also intersects with NHI governance. If an application provisions service accounts, tokens, or API keys, inaccessible flows can lead administrators to create manual exceptions that bypass lifecycle controls. That is why the broader NHI context in the Top 10 NHI Issues matters: usability failures in identity systems often cascade into privilege sprawl, insecure workarounds, and poor offboarding discipline. Current guidance suggests treating accessibility defects as control defects when they affect authentication, enrollment, or recovery. These controls tend to break down when teams launch self-service portals without end-to-end testing in real assistive technology environments, because simulated compliance checks do not expose the actual user journey failures.

Common Variations and Edge Cases

Tighter accessibility governance often increases release overhead, requiring organisations to balance delivery speed against the risk of excluding users from critical identity functions. There is no universal standard for every workflow, so the right answer depends on whether the application is customer-facing, workforce-facing, or tied to privileged access. Some edge cases change the accountability picture:

• For third-party identity platforms, the vendor may implement the interface, but the buying organisation still owns acceptance, procurement requirements, and operational risk.
• For legacy portals, remediation may be staged, but new changes should not add fresh barriers while old issues are being retired.
• For emergency access or break-glass flows, usability must be checked carefully because poor accessibility can force unsafe shadow procedures.

Where organizations handle non-human identities through the same portal, the stakes are higher because the workflow may create or rotate secrets, mint tokens, or approve access tied to production systems. That makes accessibility part of secure operations, not just inclusion policy. The emerging consensus is that teams should assign a named business owner, a named engineering owner, and a named accessibility approver for each critical journey, while security retains final risk acceptance for any known gap. The OWASP Non-Human Identity Top 10 is useful here because it reinforces that identity controls fail when process ownership is unclear.

Related resources from NHI Mgmt Group

• Who is accountable for keeping identity self-service resources current and usable?
• Who is accountable when layered identity security leaves gaps between Microsoft and non-Microsoft environments?
• Who is accountable for protecting self-service account creation and authentication workflows?
• Who is accountable for access governance when engineers request privileged database access through self-service workflows?