If anyone on your team set LocalNetworkAccessRestrictionsTemporaryOptOut to keep a kiosk, a printer bridge or a payment terminal working in Chrome, you have a deadline. What you do not have is agreement on when it falls. Google publishes two different removal milestones for that policy on two different pages, and the gap between them is roughly four and a half months. We checked all three sources on 16 September 2026, including the release branch that ships to stable in three weeks, and the contradiction is still sitting there.
TL;DR
- Chrome’s feature tracker says
LocalNetworkAccessRestrictionsTemporaryOptOutis removed in Chrome 156, which reaches early stable on 7 October 2026 and full stable on 20 October. - The Chrome Enterprise policy list and the Chromium source tree both say the policy “will be removed after M163”, which puts it at March 2027 instead.
- The policy’s metadata backs the later date:
supported_onis still open-ended and there is no deprecation flag. - The migration target Google names,
LocalNetworkAccessAllowedForUrls, is the lowest-precedence policy of the six that now govern local network access. - Two of the replacement policies do not support dynamic refresh and are not per-profile, so migrating a managed fleet needs a restart window rather than a policy push.
What the opt-out actually does
Chrome 142 shipped in late October 2025 and put every request from a public site to a local or loopback address behind a permission prompt. Plenty of enterprise kit was not ready. Google’s answer was a temporary escape hatch, policy ID 1401, supported from Chrome 142 onwards on desktop, ChromeOS and Android.
Read what it does carefully, because the wording matters more than most admins noticed. When the policy is enabled, requests that fail a Local Network Access check “will only display warnings in Chrome DevTools”. The request still goes through. The failure still happens. It is simply reported to a console that nobody is reading, because the affected machine is a digital signage panel in a lobby or an unattended till.
That is the first thing worth saying plainly: the opt-out never fixed anything. It converted a hard failure into a diagnostic that your fleet has no way to surface. If you set it eleven months ago, you currently have no inventory of which of your origins depend on it, because the mechanism that would have told you was the breakage you switched off.
Two answers, four and a half months apart
Chrome’s feature entry for Local Network Access restrictions (chromestatus.com, feature 5152728072060928) ends with a flat statement: “In Chrome 156, the LocalNetworkAccessRestrictionsTemporaryOptOut policy will be removed.” Per chromiumdash, Chrome 156 reaches early stable on 7 October 2026 and stable on 20 October.
The Chrome Enterprise policy list, which is the page an IT admin actually reads, carries a different sentence in the policy’s own description: “This enterprise policy is temporary, and will be removed after M163.” M163 reaches stable on 16 February 2027. “After M163” implies M164, which is stable on 2 March 2027.
The Chromium source tree agrees with the enterprise page, and this is the check that settles it. We pulled the policy definition from refs/branch-heads/8059, the Chrome 155 release branch that goes stable on 6 October 2026. It says M163. We pulled the same file from main, which is currently milestone 156, because Canary is on 156.0.8060.2. It also says M163. The policy that chromestatus says is removed in 156 is still present in the 156 tree with no end date attached.
The metadata is the tiebreaker. In the live enterprise policy data, ID 1401 has supported_on of chrome.*:142-, open-ended, with no deprecated flag. Compare that with LocalNetworkAccessRestrictionsEnabled, policy ID 1364, an earlier opt-in that was genuinely retired: it carries deprecated: true and supported_on: chrome.*:138-144. That is what a real removal looks like in the metadata, and the temporary opt-out has neither marker.
Why you should not plan against either date
The tempting read is that the later date wins, so there is no urgency until next spring. That is the wrong conclusion for a reason that has nothing to do with which page is correct.
A policy whose published lifetime varies by four and a half months across the vendor’s own documentation is not a schedule you can put in a change calendar. It is an unmanaged risk with a countdown of unknown length. The correct response to an ambiguous deadline is not to pick the generous reading; it is to remove the dependency on the deadline entirely. In practical terms that means migrating to the permanent allowlist policies now, during a quarter you control, rather than during whichever release turns out to be the one.
The policy Google names is the weakest one in the stack
The deprecation notice tells you what to use instead: “Long term, the policy LocalNetworkAccessAllowedForUrls can be used to allowlist URL patterns.” That advice is now incomplete, and following it literally will produce an allowlist that loses arguments it should win.
Chrome 145 split the single local-network-access permission into local-network and loopback-network. Chrome 146, stable on 10 March 2026, shipped four new policies to match, plus two more for address-space overrides and subframe delegation. There are now six policies that can match a given origin, and the policy descriptions publish an explicit precedence order:
LocalNetworkBlockedForUrlsLocalNetworkAllowedForUrlsLoopbackNetworkBlockedForUrlsLoopbackNetworkAllowedForUrlsLocalNetworkAccessBlockedForUrlsLocalNetworkAccessAllowedForUrls
The recommended migration target is last. Any of the five above it overrides it. If a security team applies a broad LocalNetworkBlockedForUrls at the top of the organisational unit, the allowlist you carefully built at the bottom silently loses, and the only symptom is a permission prompt on a device with no keyboard.
The legacy policy covers both local and loopback in one entry, which is convenient. The granular policies require you to know which of the two each origin actually needs, which is more work and a far better description of your estate. For anything on a managed fleet, use the granular pair and accept the extra inventory work.
Two of the replacements need a restart, not a refresh
This is the detail that turns a config change into a maintenance window. The allowlist policies are dynamic_refresh: true and per_profile: true, so they behave the way admins expect. LocalNetworkAccessIpAddressSpaceOverrides and LocalNetworkAccessPermissionsPolicyDefaultEnabled are both dynamic_refresh: false and per_profile: false. They apply at browser level and they do not take effect until Chrome restarts.
If your estate includes appliances that run one Chrome session for months, that is a reboot plan with an owner and a date, and it is the single most commonly missed item in this migration.
By default, cross-origin subframes must be explicitly delegated the local network permissions before they can even trigger the prompt. If your kiosk shell embeds a vendor configuration panel in an iframe, which is extremely common in signage and access control products, the prompt will never fire and the failure will look like a broken vendor rather than a browser policy.
What to do before 7 October
- Find out whether the opt-out is set at all. Check
chrome://policyon a representative managed device rather than trusting the GPO or MDM inventory, because policy can arrive from more than one channel. - Build the origin list you never built. Every internal site, vendor console and packaged web app that talks to a private IP literal, a
.localname or alocalhostport belongs on it, with a named owner per entry. - Classify each origin as local or loopback. A desktop companion agent on
127.0.0.1is not the same case as a printer at192.168.x.x, and after Chrome 145 the browser no longer treats them as one. - Migrate to the granular policies and check the precedence stack. Confirm nothing above your allowlist in that six-policy order is silently overriding it, particularly inherited blocks at the org level.
- Book the restart window. Anything relying on the two non-refreshing policies needs it, and unattended devices need it scheduled rather than assumed.
- Turn the opt-out off in a pilot group first. That is the only way to discover what it has been hiding, and it is far cheaper to discover it in October on ten devices than in March on all of them.
The wider point is one we keep running into on client estates. Vendor deprecation notices are not a schedule, they are a claim, and the claim is frequently inconsistent with the vendor’s own source of truth. Checking the policy metadata and the release branch took twenty minutes and produced a materially different answer from the documentation page. That check belongs in your process, not in a blog post.
REPTILEHAUS handles browser policy migrations, managed device estates and the DevOps work around them for clients across Ireland and the EU. If you are running kiosks, signage or on-premise appliances that talk to a local network from a browser, and nobody has yet answered which of these six policies applies to them, get in touch.
