Limits of Custom Sign‑in Page Accessibility in Okta OIE

Background

Okta’s Custom Sign‑in Page feature allows administrators to inject HTML, CSS, and JavaScript into the authentication UI to improve accessibility and branding. While the feature supports ARIA labels and color‑contrast adjustments for the initial login screen, its reach into the Multi‑Factor Authentication (MFA) challenge screens is less clear.

Goal

To determine whether an Okta Identity Engine (OIE) tenant can fully customize the accessibility of MFA challenge screens using the Custom Sign‑in Page editor.

Constraints

• The Custom Sign‑in Page editor is limited to the authentication flow; administrative consoles and system‑generated emails remain under Okta’s control.
• Adding excessive JavaScript may compromise the authentication handshake or expose security vulnerabilities.
• Custom CSS that hides critical error messages or visual cues can break WCAG compliance.

Uncertainty

The documented behavior indicates that while the initial login screen is fully customizable, the MFA challenge screens retain a more rigid structure. It is unclear whether OIE provides hooks for ARIA attributes or structural modifications on these screens.

1. Does Okta OIE expose ARIA label support for MFA challenge screens through the Custom Sign‑in Page editor?
2. Can custom CSS be safely applied to MFA screens without disrupting the authentication handshake or violating Okta’s security model?
3. What documented limits exist on modifying the internal layout of MFA challenge screens in OIE tenants?