Okta FastPass is failing with the following error when challenging for phishing resistance inside of an iFrame due to Chromium browser Local Network Access restrictions rolled out in versions > 142.
Unable to sign in
The browser is blocking communication with Okta Verify.
- Go to your browser's site settings
- Find "Local network access" or "Apps on device"
- Change the permission from "Block" to "Allow" and reload this page
For more information, follow the instructions on the Local app access page or contact your administrator for help.
- Okta Verify FastPass with Phishing Resistance in iFrame for Chromium Browsers > 142
- Okta Identity Engine (OIE)
- Local Network Access
- Browser Policies
- Web Applications
A new error returned in the Okta 2026.02.0 Release provides users with instructions on how to remediate this issue. This is not a failure on the Okta side; however, it is an informational error that can help users identify the cause of the failure.
This is a result of permissions not being granted at the Browser level and within the iFrame tags, which prevent the Okta Sign-in Widget from probing the local network loopback address. This access is needed for the Okta Verify Desktop Application to satisfy a phishing resistant challenge with FastPass's signed nonce & device probe. If this fails, the above error is returned.
See the Deep Dive into Okta FastPass whitepaper blog for more information on the loopback server.
NOTE: There was also a permission name change in Chromium 145. See Google's LNA Adoption Guide for differences in permissions between versions < 145 and 145+.
"Updated Sign-In Widget instructions for Chrome 145
The remediation instructions in the Sign-In Widget now reflect Chrome 145 permission changes that differentiate between local and loopback networks. This update describes the permission as Access other apps and services on this device, rather than Look for and connect to any device on the local network. The updated instructions ensure that users see accurate guidance when prompted to allow Okta Verify to communicate with the browser. See Chrome device permissions."
The correct permissions need to be passed both in the browser AND in the iFrame tag. The browser configuration can be found in Chrome device permissions. To allow local network access within an iFrame, see the following example:
<iframe allow="local-network-access *" src="https://subdomain.okta.com" width="100%" height="800" />
Find more information on this permission in the Related References section below.
NOTE: For any of this to work, requests must occur within the secure context described in link 3 of the related resources.
Troubleshooting Methodology
- Determine whether the browser has granted the site the correct permissions.
- Okta's sign-in Widget uses the same API call mentioned in link 4 of the related resources below.
- Determine whether the top-level document hosting the iFrame has a secure context.
- Use a code block to perform this check if there is any uncertainty.
- Confirm the iFrame is passing the correct permission.
- Verify the iFrame tag includes the
allow="local-network-access"permission.
- Verify the iFrame tag includes the
- If the top-level document appears to have both a secure context and local-network-access permissions, perform these checks in the sign-in widget code itself.
- This way, the checks will be performed when the SIW is loaded within the iFrame to determine whether the permissions and secure context are successfully passed through.
