Microsoft has fixed a persistent Windows 11 kiosk mode glitch that prevented packaged applications from launching when Microsoft Edge was also on the allowed list. The software giant rolled out the correction in servicing updates for Windows 11 24H2 and later, but there’s a critical operational detail: installing the patch isn’t enough. For the fix to take hold, IT administrators must redeploy their Assigned Access configuration—a mere reboot won’t do it.

The bug, which surfaced in Windows 11 24H2, affected kiosks using a restricted user experience with Edge and one or more MSIX or APPX packaged apps. Instead of launching through their package identity as configured in the Assigned Access XML, the packaged apps would silently fail. Microsoft confirmed the underlying issue and resolved it in Windows 11 build 26100.7705 (24H2), build 26200.7705 (25H2), and subsequent releases. A later preview update, KB5083631, distributed on April 17, 2026 to Release Preview builds 26100.8313 and 26200.8313, explicitly described the improvement as "simplif[ying] the configuration of allowed packaged apps when Microsoft Edge is also allowed." The same behavior was carried into the May 26, 2026 preview update for Windows 11 version 26H1 via KB5089570, which brought OS build 28000.2179.

The Bug That Brought Kiosk Apps to a Halt

In an Assigned Access kiosk that includes both Edge and a packaged application, the AppLocker rules generated at sign-in misinterpreted the packaged app’s identity. Instead of respecting the package-based rule, Edge’s presence triggered a denial of the packaged app unless the underlying executable was explicitly allowed via a DesktopAppPath entry. Administrators had to dig into the app’s AppxManifest.xml file, find the Executable attribute, and add that path to the allowed list manually.

This workaround kept kiosks functional but polluted the policy. A single kiosk configuration XML might contain a mix of intentional Win32 allowances and emergency executable exceptions, making audits and troubleshooting messy. The original intent—to manage access via clean package identities—was undermined.

What the Fix Actually Does

Microsoft’s engineering team adjusted the Assigned Access runtime so that when Edge is allowed, the AppLocker rule generation for packaged apps no longer requires a separate executable workaround. The packaged app’s entry in the allowed list is now sufficient. However, as the company’s own documentation emphasizes, the corrected behavior doesn’t activate simply by updating Windows. The existing kiosk configuration must be redeployed on the device after the build is in place.

This nuance is easy to overlook. A device that gets the cumulative update and reboots without a configuration redeployment will continue to enforce the old, broken rules. Only by pushing the XML again—whether through MDM, provisioning package, or PowerShell—does the new logic take effect.

Why You Can’t Just Patch and Forget

For the thousands of organizations running Windows 11 kiosks in retail, healthcare, education, and manufacturing, this means a planned migration rather than a passive update. The fix arrives in a specific build range, but the operational milestone is proving that the kiosk works without the hack.

The two biggest pitfalls are (1) assuming the patch alone solves the issue, and (2) stripping out the executable workaround too soon. A kiosk that fails to launch a line-of-business app after cleanup can’t simply be ignored; it’s a direct productivity loss. Service desks may find themselves scrambling to restore the old configuration while users stare at a broken screen.

Microsoft’s rollout across servicing branches signals that the revised behavior is here to stay. In addition to 24H2 and 25H2, the 26H1 preview build 28000.2179 includes the change. Organizations planning to adopt newer Windows 11 versions won’t need to carry the workaround indefinitely—provided they validate first.

Building a Test Plan That Works

A controlled transition follows a few key steps:

  1. Confirm the build. On 24H2, you need build 26100.7705 or later. For 25H2, build 26200.7705 or later. For 26H1, build 28000.2179 or later. (Check winver or the OS build via systeminfo.)

  2. Redeploy the existing configuration. Even if the XML hasn’t changed, push it again to the test device. This triggers the corrected rule generation. A device that was only patched and rebooted is not a valid test.

  3. Sign out completely, then sign in with the kiosk account. A cold sign-in ensures the AppLocker rules are built from scratch. Testing during an existing session may give false positives.

  4. Launch Edge and every allowed packaged app. Launch them in the order a real user would, not just individually from an admin prompt.

  5. Create a revised XML that removes only the DesktopAppPath entry corresponding to the packaged app’s executable. Keep all other entries intact. Deploy this simplified configuration and repeat the sign-out/sign-in cycle.

  6. Reboot the device and test again. A successful launch from a warm session isn’t proof. The kiosk must survive a full restart and cold sign-in.

Only when the device passes this gauntlet—Edge open, packaged app launching reliably, no executable exception needed—should the workaround be considered safe to retire.

A simple test matrix can expose image-specific failures quickly:

Test State Edge Allowed Workaround Present Expected Result
Production baseline Yes Yes All apps work
Patched + redeployed baseline Yes Yes Same stable behavior
Patched + simplified XML (no workaround) Yes No Packaged app launches via package rule
After reboot + cold sign-in with simplified XML Yes No All apps still available
Rollback to production XML Yes Yes Kiosk returns to validated state

If even one test fails—especially after a reboot—keep the workaround in place until the root cause is found.

Cleaning Up the Policy Without Breaking It

Not every DesktopAppPath is a workaround. A conventional Win32 app may legitimately need one. Before deleting anything, build a mapping for each allowed packaged app: its package identity, AUMID, the executable declared in AppxManifest.xml, and the relevant XML entry. Entries that can’t be mapped to a specific package should be investigated, not blindly removed.

Also, remember that Assigned Access enforces rules at the package level. If multiple apps share a package—common with vendor suites—denying or allowing that package affects all apps inside it. Deleting an executable entry that’s actually required for one of those sibling apps can break the whole family. This is especially dangerous when a package update changes the executable name, making a static path suddenly obsolete. Moving back to package-based rules where possible reduces that fragility.

No, This Doesn’t Affect Regular Users

If you’re not managing a kiosk device, this bug and its fix are irrelevant. Regular Windows 11 users on desktop or laptop PCs never encounter Assigned Access rules, and Edge’s interaction with packaged apps is unaffected. The flaw lives solely in the locked-down, multi-app kiosk scenario where an administrator explicitly pairs Edge with one or more MSIX/APPX applications.

Looking Ahead

Microsoft’s direction is clear: kiosk configuration should be simpler, not a maze of executable exceptions. The fix in 24H2, 25H2, and 26H1 lays the groundwork for cleaner policies, but it’s up to each organization to execute the migration. Keep the workaround’s XML handy as a rollback plan. Monitor kiosk sign-in failures, unexpected restriction dialogs, and app launch errors after any configuration change. And remember: the patch is the first step; redeployment is what turns the bug fix into reality.

As Windows 11 evolves, the interplay between browser-based kiosks and packaged apps will likely face further refinement. For now, the message is simple: update your kiosk device, redeploy your policy, test thoroughly, and then—and only then—retire the hack.