This article was modified on September 30th, 2025, to reflect Google’s change in release date from Chrome 141 to 142.

Starting with the release of Chrome version 142 in late October, when signing in with Okta FastPass, Chrome and any Chromium-based browsers will require permission for the Okta sign-in page to communicate with a secure loopback server on the device. 

This is a necessary step for authentication, and users will only need to accept this prompt once per device to maintain a seamless sign-in experience. This process is secure and only communicates with the device where Okta Verify is installed; Okta will not look for or connect to any other device on the local network.

Read the announcement

Google Blog: New permission prompt for Local Network Access.

Why is this happening?

Okta FastPass requires communication between the Okta website and the Okta Verify desktop application to confirm identity. As an updated security measure, Chrome now requests approval for this connection during the initial setup. This prompt appears to obtain the necessary one-time permission for Okta to function as designed.

Key Takeaways

• Privacy-Focused: This Chrome prompt is for authentication purposes only. Okta will not connect to or read information from any other devices on the local network. It only communicates with the device where Okta Verify is installed.
• One-Time Prompt: On non-IT-managed devices, this prompt requires only a one-time approval per device to enable future seamless access.

• FastPass authentication on Chrome browsers on Windows, MacOS, iOS, and Android
• Okta Identity Engine (OIE)
• Multi-Factor Authentication (MFA)

Okta recommends notifying the users that this is a safe and expected prompt.

Android, MacOS, and Windows

To deliver a seamless sign‑in, pre‑grant that permission for the Okta sign‑in origin(s) using the Local Network Access (LNA) enterprise policy for Managed Chrome Profiles (learn more).

iOS

Based on the latest information, Chrome on iOS will not prompt for Local Network Access at this time. No user action is required on iOS devices.

Goal

• Prevent Chrome’s Local Network Access (LNA) permission prompt when Okta FastPass communicates with its local loopback service on localhost/127.0.0.1.

Configuration Overview

• Allow list: LocalNetworkAccessAllowedForUrls.
  Add the requesting page origin(s) (the Okta sign‑in host) so they may call localhost/127.0.0.1 without a prompt.
  
  NOTE: Allowlist the origin making the request (for example, https://[subdomain].okta.com or the custom Okta domain), not the local endpoint.
   

• Global switch: LocalNetworkAccessRestrictionsEnabled.
  Ensures LNA is consistently enforced so that the allow/block lists take effect.

Option 1 - Configure Chrome browser using Google Workspace

Blocking the LNA prompt by configuring the Chrome browser allows both MDM-enrolled and BYOD devices a path to a seamless FastPass experience. 

Prerequisites

• Assign Managed Profiles to the users with Okta and Google Workspace. See instructions.

Step‑by‑step (Google Admin Console)

1. In the Workspace admin console, go to Chrome Browser > Settings.
2. Find the Local Network Access restrictions setting.
    
3. Configure the setting so that Inheritance is Locally applied.
4. Set the Configuration option to Apply restrictions to requests to Local Network Access. Add a URL pattern for each domain to be included in the allowlist.
    
5. Assign the setting to the desired Organizational Unit and hit Save.
6. Open chrome://policy in the test browser, then click Reload to confirm that the values are applied.

Learn more about configuring custom Chrome policies in Workspace - Set Chrome policies using the Custom Configurations page.

Option 2 - Configure Chrome browser using MDM

Use the Mobile Device Management (MDM) solution to deploy a policy that pre-grants LNA permission for the Okta sign-in URLs on managed devices. This prevents users from ever seeing the prompt. The configuration varies slightly by operating system.

Windows (via Intune)

1. In the Intune console, navigate to Devices > Windows > Configuration.
2. Click Create and select New Policy
   • Platform: Windows 10 and later
   • Profile type: Settings catalog
3. In the Configuration settings, click Add settings.
4. Locate Google Chrome Local Network Access settings and select Allow sites to make requests to local network endpoint.
5. Select Enable, then enter the Okta org URL and any custom URLs, if applicable.

6. Assign the profile to the desired groups and proceed to test.

macOS 

For macOS devices managed by an MDM, deploy a configuration profile (.mobileconfig) with a custom Chrome payload. The payload should contain the following keys and values in the Google Chrome preference domain.

Here is an example .plist snippet:

XML

<key>LocalNetworkAccessAllowedForUrls</key>
<array>
    <string>https://atko.okta.com</string>
    <string>https://[*.]okta.com</string>
    <string>https://login.companydomain.com</string>
    <string>https://[*.]companydomain.com</string>
</array>
<key>LocalNetworkAccessRestrictionsEnabled</key>
<true/>

Android (via Managed App Configuration)

For managed Android devices, push the policy using the MDM's managed app configuration capabilities for the Google Chrome app.

1. In the MDM console, navigate to the app configuration settings for Google Chrome.
2. Add a new configuration using the following keys and values. The format will be a JSON block similar to the one used for Google Workspace.

JSON

{
  "LocalNetworkAccessAllowedForUrls": [
    "https://atko.okta.com",
    "https://[*.]okta.com",
    "https://login.companydomain.com",
    "https://[*.]companydomain.com"
  ],
  "LocalNetworkAccessRestrictionsEnabled": true
}

See LocalNetworkAccessAllowedForUrls to learn more about the Local Network Access setting.

Testing

1. Open a browser where the settings have been assigned.
2. Enter chrome://policy in the search bar and verify the policy has been applied to the browser.
   • Look for the LocalNetworkAccessAllowedForUrls policy and verify that the Okta URLs are listed.
3. Enter chrome://flags in the search bar. Find the Local Network Access Checks setting and configure it to Enabled. (It will not be enabled by default until the launch of Chrome M141.)
4. Sign in with FastPass.

Frequently Asked Questions

Is this a security risk? Will Okta access my other devices?

No. This is not a security or privacy risk. Okta uses the local network connection only to communicate with Okta Verify on the device used to sign in. It does not read any other information or connect to any other devices on the network.
 

How many times will this prompt be seen?

The Allow button must be selected only once per device. After this initial authorization, the prompt is suppressed for all future sessions on that device.
 

What if a mobile device is used?

This prompt will also appear on mobile devices. For organizationally managed devices, this setting can be pre-approved for Android devices. If not, users will need to accept the prompt on their first Okta FastPass use.
 

What if a user accidentally clicks "Block"?

If a user accidentally blocks the permission, it can be reset directly in Chrome's site settings for the Okta domain.

1. While on the Okta sign-in page, click the padlock icon (or tune icon) on the left side of the address bar to open the site settings menu.
2. Find the Local network access setting.
3. Use the toggle to change the permission from Block back to Allow.
4. Reload the page. Okta FastPass should now work correctly.

Does access need to be enabled for other Chromium-based browsers?

Yes, browsers based on Chrome 142 or above will need access to the local network for FastPass. The steps in this document can be applied to other browsers; however, the registry location will differ. For example, Edge LocalNetworkAccessAllowedForUrls would be: SOFTWARE\Policies\Microsoft\Edge.

Per Google’s LNA Adoption Guide referenced in the Chrome Enterprise and Education release notes.