Neowin first flagged the approaching deadline, and Microsoft’s Message Center notice MC1459132 confirms that the change applies worldwide in late September 2026. Microsoft’s Edge Stable release notes put general availability for Edge 154 at around September 24. The retirement affects Microsoft Edge and Edge for Business on Windows 10 devices where an administrator explicitly configured WIP or MDAG; neither feature is enabled by default.
For most organizations, this will be a non-event. Microsoft says the affected population is relatively small because WIP and MDAG were Windows 10-era technologies, and both are already unavailable in Windows 11 version 24H2. But “small” can be a dangerous word in enterprise IT: a few surviving policies can sit on regulated desktops, shared workstations, contractors’ devices, or long-lived Windows 10 LTSC estates where nobody has revisited the original security design in years.
Edge 154 removes the last browser dependency
The immediate change is not the removal of a Windows optional feature from every remaining Windows 10 machine. Microsoft is retiring the Edge support paths for WIP and MDAG. Its Message Center notice says those capabilities will no longer function in Edge 154 and later once rollout is complete.
That distinction matters for troubleshooting. An organization could still find the Microsoft Defender Application Guard Windows component present on an eligible Windows 10 PC, or old WIP policy objects still assigned through Intune or Configuration Manager. Their presence should not be mistaken for working protection in the browser after Edge updates to version 154.
MDAG was designed to put untrusted browsing sessions inside a hardware-isolated container, limiting an attack’s access to the host operating system and corporate network. WIP, meanwhile, attempted to separate business data from personal data through enterprise boundaries and application-aware controls. Both depended on policy configuration that many administrators deployed once, then largely left alone.
Microsoft’s own prior MDAG documentation said existing Windows installations could continue to use Application Guard even after the feature was deprecated. The new Edge notice changes the practical answer for organizations using it specifically with Edge: Microsoft is now removing that remaining supported browser integration. Edge 154 is therefore the cutoff administrators should use when assessing exposure, not the older Windows feature-deprecation date.
Windows 10’s long tail is where the risk remains
The deadline lands on systems that are already difficult to govern. Windows 10 reached end of support on October 14, 2025, although organizations can still receive paid Extended Security Updates for eligible deployments. Microsoft’s lifecycle material shows the commercial Windows 10 ESU program continues through October 2028, while individual LTSC releases follow their own dates.
That means a Windows 10 machine can remain patched under ESU while losing an older browser-integrated security control. Security update coverage and feature compatibility are separate matters. An ESU subscription does not preserve MDAG in Edge, nor does it restore WIP support removed from the Windows 11 platform.
Windows 10 Enterprise LTSC 2019, for example, remains supported through January 2029; Windows 10 Enterprise LTSC 2021 is supported through January 2027. Those dates make it entirely plausible that organizations still have supported or security-serviced Windows 10 devices with old policy baselines. The affected estate may be narrow, but it is likely to be concentrated in the environments least able to accept an unplanned loss of isolation or data-handling controls.
Microsoft also says Windows 11 version 24H2 devices are not expected to be affected because WIP and MDAG have already been removed there. That makes the Edge change an especially useful inventory signal: if a team discovers active WIP or MDAG configurations during this audit, it has found a policy design that was already incompatible with its Windows 11 migration path.
Microsoft’s replacements are categories, not a like-for-like migration
Microsoft recommends Microsoft Purview Information Protection, Microsoft Purview Data Loss Prevention, Endpoint DLP, and Intune app protection policies for WIP scenarios. For MDAG, it recommends Edge’s built-in security capabilities and other supported isolation products appropriate to the organization’s environment.
Those are reasonable destinations, but they are not a one-button replacement for either retired feature.
WIP was a Windows-focused enterprise data-protection framework. Purview Information Protection centers on classification, sensitivity labels, encryption, and content protection. Purview DLP and Endpoint DLP concentrate on detecting and controlling risky movement or use of sensitive data. Intune app protection policies govern data handling within supported applications. A company moving from WIP must decide which of those controls actually reproduces the rule it relied on: preventing copy-and-paste to unmanaged apps, labeling files, blocking uploads, restricting removable-media use, or handling data in mobile and bring-your-own-device scenarios.
The MDAG migration question is different. Application Guard provided a specific isolation model: untrusted sites ran in a container separated from the host. SmartScreen, Enhanced Security Mode, typo protection, and DLP can materially improve browser security, but they do not automatically recreate a disposable virtualized browsing environment. Microsoft’s existing MDAG documentation points organizations requiring container-based isolation toward Windows Sandbox or Azure Virtual Desktop, while its current Edge guidance emphasizes browser-native protections.
Administrators should therefore avoid treating Microsoft’s list as a feature checklist. The first task is to document the original threat model. If MDAG was protecting research teams opening hostile links, the replacement may require isolated browsing or virtual desktop workflows. If it was enabled as a broad precaution but never used in policy-driven enterprise mode, Edge security hardening may be sufficient. The technical answer depends on the control the organization needs, not the retired product name.
Microsoft has not published, in the retirement notice, a detailed feature-by-feature migration matrix, licensing impact, or configuration conversion process. That omission is significant for WIP users: adopting Purview and Endpoint DLP can involve different administration portals, policy concepts, endpoint prerequisites, and potentially different licensing than the legacy deployment.
What administrators should check before September 24
The affected group is limited to Windows 10 devices with WIP or MDAG configured for Edge, so a targeted audit is more useful than a fleet-wide panic. Teams should start with their management systems and verify whether any policies remain assigned to active device or user groups.
- Review Intune, Microsoft Configuration Manager, Group Policy, and any third-party endpoint-management profiles for Windows Information Protection and Microsoft Defender Application Guard settings, including policies assigned to old device collections or exception groups.
- Identify Windows 10 devices that still receive Edge updates, particularly Enterprise LTSC, kiosk, lab, frontline, shared-device, and regulated-workload deployments where an old baseline may have survived broader migration work.
- Confirm the business behavior each policy was meant to enforce. For WIP, test handling of corporate files and data movement. For MDAG, identify which sites, network boundaries, or user groups were routed into isolated sessions.
- Pilot Edge 154 against representative devices before broad rollout reaches them, then verify both the expected replacement controls and the failure behavior when legacy WIP or MDAG policies remain in place.
- Remove or unassign obsolete WIP policies once replacement controls are validated. Microsoft’s older WIP retirement guidance identifies unassigning the WIP policy as the preferred way to disable it through Intune.
The audit should include help desk and security operations teams. A user may not recognize a policy name such as MDAG, but they will recognize that an external site formerly opened in a separate protected window, or that copying work content into a personal application has changed. Those reports can reveal edge cases that management-console inventories miss.
The practical deadline is earlier than the rollout date
Microsoft says the Edge 154 change rolls out through normal release channels and is expected to reach general availability around September 24. In a managed environment, that should be treated as the end of the migration window, not the start of a testing period. Edge updates may reach pilot rings, unmanaged Windows 10 endpoints, or less tightly controlled business units before an administrator’s formal enterprise deployment schedule catches up.
Organizations that need more time are told to contact Microsoft Support or their Microsoft account team. Microsoft has not publicly described what extra time would mean in technical terms—whether that could involve an update deferral, a support arrangement, or only migration guidance—so admins should not assume an exception will keep the retired capability operational. The defensible plan is to identify dependencies now and prepare for Edge 154 to remove them.
This retirement closes a long deprecation process that began with Microsoft’s July 2022 announcement that WIP would receive no future development, followed by the removal of both WIP and MDAG from Windows 11 24H2. On September 24, the remaining Edge integration on configured Windows 10 systems becomes the final moving part. Any organization that still finds one of those policies in production has uncovered more than a browser-update task: it has found a Windows 10 security dependency that needs a documented replacement.