A Guide to Breaking Free from IE Mode Dependence

1. This Article in One Sentence

“Use IE mode safely as an officially managed operation, reduce the dependence a little at a time, and eventually bring IE mode to zero” — that is the realistic strategy. Before you throw it away, manage it properly first.

Terms used in this article

Here are the terms that come up repeatedly below.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (23 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Background: How Long Can IE Mode Actually Be Used?

The point to keep in mind here is that having it available until 2029 does not mean you can relax and leave it alone. This window is strictly a grace period for a planned exit, and the only way to avoid a scramble right up against 2029 is to start preparing now.

3. Why Is It So Hard to Get Off IE Mode Dependence?

IE mode is a mechanism inside Chromium-based Edge that renders only legacy sites with the Trident (MSHTML) engine. Here is what that Trident engine is carrying:

• Legacy document modes
• ActiveX controls and BHOs (Browser Helper Objects)
• Legacy security zone settings
• Enterprise Mode compatibility settings

As long as you depend on these, updating the browser alone will not solve the problem. Identifying exactly what the dependence consists of is the first step.

Problems that come up regularly in the field

1. Misconfigured document modes -> broken layouts, script errors
2. Missing neutral site configuration -> re-authentication loops or redirect loops with SSO (single sign-on)
3. Wrong Enterprise Mode Site List format -> schema v.1 is not supported for IE mode integration, so migration to schema v.2 is required
4. Edge processes only one site list -> the Edge-side policy takes precedence over the IE-side policy

Classifying the dependence: first work out what you actually depend on

4. Step 1: Life Extension — Run It Safely First

1. Manage the site list properly (the most important item)

Leaving reload-in-IE-mode up to the user is dangerous. Manage it officially through policy.

What to do: Migrate to Cloud Site List Management and manage centrally who uses which sites in IE mode, and until when.

A minimal site list XML

The site list is written as Enterprise Mode Site List schema v.2, that is, XML whose root element is <site-list>. A minimal configuration is just this:

<site-list version="1">
  <!-- Sites to open in IE mode -->
  <site url="legacy.contoso.local">
    <compat-mode>IE8Enterprise</compat-mode>
    <open-in>IE11</open-in>
  </site>

  <!-- Authentication server: open in the engine the navigation came from (neutral site) -->
  <site url="login.contoso.local">
    <open-in>None</open-in>
  </site>
</site-list>

Points to watch when writing it:

• Do not put a protocol in url. Writing contoso.local applies to both http and https.
• Sites with <open-in>IE11</open-in> open in IE mode.
• <compat-mode> specifies the document mode used on the IE mode side (IE8Enterprise, IE7Enterprise, Default, and so on).
• <open-in>None</open-in> is what makes a site a neutral site. Authentication servers go here.
• version is the version number of the site list. Increment it whenever you update the list.

Group Policy settings used for distribution

To distribute the site list, configure two Group Policy settings. Both can be set from either User Configuration or Computer Configuration.

For the site list location you can specify an HTTPS URL (recommended), a network share path, or a local file path. The IE side has an equivalent setting, “Use the Enterprise Mode IE website list” (Administrative Templates > Windows Components > Internet Explorer), but the Edge-side policy takes precedence once it is configured. That lets you distribute the production list company-wide through the IE-side policy while sending a test list to a pilot department only through the Edge-side policy.

2. Nail down the authentication configuration

Once SSO is involved, authentication frequently breaks on transitions between IE mode and Edge mode.

A neutral site is a setting that tells both IE mode and Edge mode to open the site in whichever engine the navigation came from. If you do not register your authentication and SSO relay sites here, the moment a page open in IE mode jumps to the authentication server it gets redirected to Edge and authentication fails. Microsoft’s documentation also states that authentication and SSO servers must be explicitly configured as neutral sites for IE mode to work correctly.

• Configure neutral sites correctly, explicitly specifying the SSO servers with <open-in>None</open-in>
• Configure cookie sharing where needed (by default, the Edge and Internet Explorer processes do not share session cookies)
• While you still do not know which servers are the authentication servers, capture network logs with edge://net-export and identify where the navigation goes
• If you genuinely cannot pin down the authentication server, temporarily use the policy that keeps in-page navigation in IE mode (but turn it off once you have the answer)

3. Get fluent with the diagnostic tools

Decide based on observed data, not on how things feel.

4. Isolate the parts you truly cannot fix

5. Step 2: Exiting — How to Reduce the Dependence

Pattern comparison table

★ marks the first choice in practice.

How to read the rough effort column

The person-months in the table are a range for one internal system, and they are not numbers you can drop straight into an estimate. Even within one pattern, the figure swings by several times depending on the number of screens, the number of IE mode target URLs, the variety of ActiveX and BHO components, the number of SSO paths, the number of external integrations, and how much acceptance testing you need. Treat the table as a way to compare the relative weight of the patterns against each other.

When you estimate for real, count the following first, then multiply by your own historical figures (effort per screen, authentication validation effort per path) and build the estimate up from there.

• Number of screens and reports
• Number of IE mode target URLs (from the Enterprise Site Discovery inventory)
• Types of ActiveX and BHO components, and whether each has a replacement
• Number of authentication and SSO paths
• How long old and new will run side by side
• Number of regression test cases, and what share of them need manual verification

Where each pattern fits

Incremental refactoring is the most realistic option.

• You do not have to rebuild everything at once
• Modernizing one screen or one feature at a time is enough
• While old and new coexist, path design (which screen runs on which engine) matters

WebView2 wrappers are for redrawing the boundaries.

• Not for preserving ActiveX and COM dependence as-is
• Push OS-side responsibilities such as file operations, device integration, and Windows authentication to the native side, and modernize the web UI side
• Note, though, that you take on responsibility for distributing the WebView2 Runtime

Micro-frontends are effective only when team boundaries and deployment boundaries coincide. They should not be adopted because they are fashionable.

A full rewrite is the last resort. Reserve it for cases where dependence on ActiveX or BHOs runs so deep that the system simply cannot be decomposed.

6. Step 3: How to Actually Proceed (Roadmap)

Assess -> Prioritize -> PoC -> Test -> Roll out -> Operate

1. Assess — take stock of the dependence

• List the target URLs with Enterprise Site Discovery
• Make the network transitions visible with edge://net-export
• Classify the dependence into document mode, ActiveX/BHO, authentication, client certificates, file and print, and device and COM

2. Prioritize — decide where to start

Sort by the following criteria.

• Importance (in order of how much damage an outage does)
• Number of users
• Security exposure
• How far the impact spreads to other systems
• How easy it is to carve out (whether the boundaries are clear)

Separating the features that move forward once you cut the boundary from the features that require moving the whole boundary makes the rest of the plan much easier to build.

3. PoC (proof of concept) — try it small

Start with one workflow that has high business value and moderate dependence.

There are four success criteria.

1. IE mode is no longer needed
2. SSO keeps working
3. Response times are in a comparable range
4. You can roll back

4. Test — handle the mix of old and new

• Modern path -> automated Edge tests with Playwright
• IE mode path -> the diagnostics page plus manual verification
• While old and new coexist, state explicitly which path runs on which engine (without that, reproducing a defect is very hard)

5. Roll out — widen it gradually

• Canary rollout (ship to a subset of users first)
• Use Extended Stable (eight-week cycle) to secure a validation window
• Build the site list update interval and the browser restart requirement into the operational flow
• If you use the cloud site list, do not forget that Edge sign-in becomes a prerequisite

6. Operate — keep shrinking it

• Use the feedback feature in Cloud Site List Management to collect the sites users added and the misconfigurations they hit
• Run an operational cycle that shrinks the IE mode list every month
• Always pair a life-extension measure with an operation that reduces it

The overall flow (flowchart)

flowchart TD
    A[Take stock of the target assets] --> B[Classify the dependence]
    B --> C{What kind of dependence?}
    C -->|Mostly document mode and SSO| D[Official IE mode operation]
    C -->|Mostly OS integration and COM| E[Wrap it]
    C -->|Separable screen by screen| F[Incremental refactoring]
    C -->|Multiple teams in parallel| G[Micro-frontends]
    C -->|Dependence runs too deep| H[Full rewrite]

    D --> I[Tune neutral sites and cookies]
    E --> J[WebView2 and native boundary]
    F --> K[Old and new coexist, replaced in stages]
    G --> K
    H --> L[Redesign on a new architecture]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[Automated and operational testing]
    N --> O[Phased rollout]
    O --> P[Collect usage data and feedback]
    P --> Q[Shrink the IE mode list]
    Q --> R[Retirement decision]

7. Step 4: Governance — the Administrative Framework

Codify IE mode as an exception regime

• Every newly added IE mode target URL must have the following items set.
  • Business owner (who is accountable)
  • Technical owner (who manages it technically)
  • Expiration date (by when it has to be gone)
  • Replacement plan (how it will be replaced)
• If your existing XML site list is schema v.1, migrate to schema v.2, the version usable with IE mode integration
• Track change history with Cloud Site List Management or a configuration management tool

Security considerations

• Pinning an old Edge build in production is dangerous -> stay on the current Stable/Beta line
• If you need a validation period, use Extended Stable (eight-week cycle)
• Use the Security Compliance Toolkit and Policy Analyzer to check the quality of your GPOs
• Sloppy browser operations around IE mode cause breakage far more often than vulnerabilities in IE mode itself

Work backward from the timeline

• End of IE mode support: 2029
• End of Edge/WebView2 updates on Win10 22H2: October 2028

These are the outer frame of the withdrawal deadline. The first thing to build is a backward-planned schedule that brings the dependence to zero before support ends.

8. Recommended Strategy by Scale

The person-months in this table carry the same caveats as the rough effort column in Step 2. If the typical conditions column (number of screens, complexity of SSO, number of departments) is far from your own situation, do not apply the numbers directly; rebuild the estimate from your screen and path counts.

9. Common Mistakes and What to Do Instead

10. Conclusion

Standard strategy = official IE mode operation (prevents breakage)
                    + visibility into the dependence (taking stock)
                    + incremental reduction (exit one piece at a time)

• If you are small, go with incremental refactoring
• If you are large, site list governance plus portfolio management
• If budget is tight, contain it with virtualization while stopping new dependence
• A full rewrite is the final trump card
• Containers are normally off the table, VDI is a shelter, and IE mode is a runway, something you use to take off

Reference Links

• Lifecycle FAQ for IE and Edge — the 2029 policy for IE mode
• Overview of IE mode — the basic reference on support scope
• Configure IE mode policies — the three tiers of integration settings
• Enterprise site configuration strategy — neutral sites, cookie sharing, schema v.2
• Enterprise Mode schema v.2 guidance — the elements of the site list XML, with examples
• Overview of the Microsoft Edge update channels — the Stable and Extended Stable cycles
• IE mode troubleshooting and FAQ — the diagnostics page and how to use net-export
• Cloud Site List Management — centralized management from the admin center
• Enterprise Site Discovery — the starting point for taking stock
• WebView2 documentation — for evaluating the wrapper approach
• Azure Virtual Desktop / RemoteApp — as an isolation measure
• Windows Containers migration guide — a poor destination for keeping a GUI alive
• App Assure — the scope of IE mode configuration support
• Playwright — automated Edge testing
• single-spa — micro-frontend fundamentals
• webpack Module Federation — integrating independent builds

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

How long will IE mode in Edge remain usable?

IE mode in Edge is supported at least through 2029, and Microsoft's stated policy is to give one year's notice before retiring it. Edge and WebView2 Runtime updates on Windows 10 22H2 also run at least through October 2028. That window is strictly a grace period for a planned exit, though: treat 2029 as the deadline for completing the exit rather than for starting to prepare, and plan backward from it. The IE11 desktop application itself is already retired.

Why is it so hard to get off IE mode dependence?

IE mode is a mechanism inside Chromium-based Edge that renders only legacy sites with the Trident (MSHTML) engine, and that Trident engine is what carries legacy document modes, ActiveX controls and BHOs, legacy security zone settings, and Enterprise Mode compatibility settings. As long as you depend on any of those, updating the browser alone solves nothing. The first step is to classify the dependence into document modes, ActiveX/BHO, authentication and SSO, client-side integration, and legacy operational assumptions, so you know exactly what you are dealing with.

What options are there for exiting IE mode?

There are six main options: continued IE mode operation, a WebView2 wrapper, incremental refactoring, micro-frontends, a full rewrite, and VDI/RemoteApp isolation. Incremental refactoring is the first choice in practice, because you can modernize one screen or one feature at a time. A WebView2 wrapper is not for preserving ActiveX; you use it to redraw the boundaries, pushing OS-side responsibilities such as file operations and device integration to the native side. A full rewrite is the last resort, for dependence so deep that the system cannot be decomposed.

What should we do if we are going to keep using IE mode for now?

Start by managing the site list officially through policy instead of leaving reload-in-IE-mode up to users. Moving to Cloud Site List Management gives you multiple list distribution, change history, and per-group assignment. Where SSO is involved, configure neutral sites correctly and set up cookie sharing if you need it. Alongside that, every newly added IE mode URL should carry a business owner, a technical owner, an expiration date, and a replacement plan, paired with an operational cycle that shrinks the list every month.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.