Windows 11 Kiosk (Assigned Access 2022): Is it possible to allow Wi-Fi taskbar flyout without granting access to full Settings app?

Pablo Gil 20 Reputation points
2026-02-09T12:17:59.0333333+00:00

I’m configuring a Windows 11 kiosk using Assigned Access with the 2022 schema and trying to achieve the following:

Goal

  • Allow users to click the Wi-Fi icon in the taskbar to connect to networks

Prevent access to the Settings app in general (outside of Wi-Fi)

Current behavior

The Wi-Fi icon can be shown via systemTray.wifi = true in TaskbarLayout

However, the icon is not clickable unless the Settings backend is allowed

From testing, the Wi-Fi flyout only becomes functional when the following app is added to AllowedApps:

<App AppUserModelId="windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel" />

Once this is allowed, users can technically access other Settings pages (even if search is hidden and Settings is not pinned).

Questions

Is there any supported way (in Assigned Access 2022) to allow the network/Wi-Fi flyout only, without enabling the full Settings app?

Is <AllowNetworkStatusFlyout>true</AllowNetworkStatusFlyout> expected to work independently in the 2022 schema, or does it still rely on the Immersive Control Panel?

If this is not possible by design, can Microsoft confirm this limitation so it can be planned around?

At the moment, the only viable workaround appears to be:

Allowing the Settings app

Hiding discovery paths (search, pins)

Optionally deep-linking users to ms-settings:network-wifi

I’d appreciate confirmation on whether this is the intended and only supported approach.I’m configuring a Windows 11 kiosk using Assigned Access with the 2022 schema and trying to achieve the following:

Goal

Allow users to click the Wi-Fi icon in the taskbar to connect to networks

Prevent access to the Settings app in general (outside of Wi-Fi)

Current behavior

The Wi-Fi icon can be shown via systemTray.wifi = true in TaskbarLayout

However, the icon is not clickable unless the Settings backend is allowed

From testing, the Wi-Fi flyout only becomes functional when the following app is added to AllowedApps:

<App

Once this is allowed, users can technically access other Settings pages (even if search is hidden and Settings is not pinned).

Questions

Is there any supported way (in Assigned Access 2022) to allow the network/Wi-Fi flyout only, without enabling the full Settings app?

Is <AllowNetworkStatusFlyout>true</AllowNetworkStatusFlyout> expected to work independently in the 2022 schema, or does it still rely on the Immersive Control Panel?

If this is not possible by design, can Microsoft confirm this limitation so it can be planned around?

At the moment, the only viable workaround appears to be:

Allowing the Settings app

Hiding discovery paths (search, pins)

Optionally deep-linking users to ms-settings:network-wifi

I’d appreciate confirmation on whether this is the intended and only supported approach.

Windows for business | Windows 365 Business

3 answers

Sort by: Most helpful
  1. Domic Vo 36,745 Reputation points Independent Advisor
    2026-02-10T06:13:57.4866667+00:00

    Good morning

    I hope you are doing well.

    Have you found the answer useful? If everything is okay, don't forget to share your experience with the issue by accepting the answer. Should you need more information, free free to leave a message. Happy to help! :)

    Domic Vo.

    Was this answer helpful?


  2. Domic Vo 36,745 Reputation points Independent Advisor
    2026-02-09T12:53:13.28+00:00

    Hello Pablo Gil,

    Your scenario is directly tied to how Assigned Access (Kiosk mode) with the 2022 schema handles system flyouts and dependencies. The behavior you are seeing is by design. The Wi-Fi flyout in Windows 11 is not a standalone component; it is implemented through the Immersive Control Panel (Settings app backend). That is why the flyout only becomes interactive when you add the windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel entry to AllowedApps.

    The <AllowNetworkStatusFlyout>true</AllowNetworkStatusFlyout> setting in the 2022 schema does indeed expose the network icon in the taskbar, but it does not bypass the dependency on the Settings framework. Microsoft’s documentation confirms that the network flyout relies on the Settings app package, so enabling the flyout without allowing Settings is not supported. In other words, the flyout is not self-contained and cannot function independently.

    The supported approach is exactly what you have already tested: allow the Settings app, then restrict discovery paths. That means hiding search, removing pins, and optionally deep-linking users to ms-settings:network-wifi if you want to guide them directly. This is the intended design, and there is no supported method to expose only the Wi-Fi flyout without also enabling the broader Settings backend.

    To plan around this, you should assume that kiosk deployments requiring Wi-Fi connectivity will need Settings allowed in the AllowedApps list, with UI restrictions layered on top to prevent general access. Microsoft has not provided a schema option to decouple the Wi-Fi flyout from Settings, so your workaround is the correct and only supported path.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?


  3. AI answer

    2026-02-09T12:18:15.26+00:00

    In the context of configuring a Windows 11 kiosk using Assigned Access with the 2022 schema, it appears that there is currently no supported way to allow the network/Wi-Fi flyout in the taskbar without granting access to the full Settings app. The Wi-Fi icon can be displayed using systemTray.wifi = true in TaskbarLayout, but it is not functional unless the Immersive Control Panel (Settings) is allowed in the AllowedApps.

    The <AllowNetworkStatusFlyout>true</AllowNetworkStatusFlyout> setting does not operate independently; it still relies on the Immersive Control Panel being accessible. Therefore, users can inadvertently access other settings pages if the full Settings app is enabled, even if search is hidden and the app is not pinned.

    As of now, the workaround you mentioned—allowing the Settings app, hiding discovery paths, and optionally deep-linking users to ms-settings:network-wifi—seems to be the only viable approach. Unfortunately, this limitation may need to be planned around, as there is no confirmation from Microsoft regarding an alternative method to achieve your goal without enabling full access to the Settings app.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.