What breaks when legacy web apps still depend on Internet Explorer?

Why This Matters for Security Teams

Legacy Internet Explorer dependencies are not just a browser problem. They create an exception path that often bypasses modern controls, including current browser security baselines, stronger authentication flows, and the assumptions behind zero trust. When a business-critical app only functions in IE mode or an actual IE runtime, security teams inherit a compatibility carve-out that can outlive the original technical debt and quietly become policy by exception. NIST’s Security and Privacy Controls are built around managed access, accountability, and control enforcement, but IE-dependent apps often force teams into weaker handling for sessions, scripting, and file transfer. That matters because non-human identities and legacy access path already amplify risk: NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. In practice, many security teams encounter the real break only after a legacy app becomes the easiest route around stronger browser policy, rather than through intentional exception review.

How It Works in Practice

The practical failure mode is usually layered. First, the application itself depends on IE-specific behaviours such as ActiveX, legacy document modes, or old authentication handoffs. Second, the organisation keeps the app alive by allowing IE mode, a compatibility VM, or a segregated workstation profile. Third, those exceptions spread into identity and access policy because the app is now treated as “special,” which usually means broader trust, weaker session controls, and less frequent review. A safer approach is to treat every IE dependency as a migration risk, not a normal operating state. Security teams should document which workflows still need the legacy path, who owns them, what data they touch, and what compensating controls are in place. Typical controls include:

• Restricting IE mode to named applications and named users only.
• Requiring modern authentication at the edge even if the backend app is legacy.
• Segmenting legacy apps from general browsing and from privileged admin tasks.
• Adding review dates, expiry dates, and business owners to every exception.
• Monitoring for credential reuse, local admin access, and outbound data transfer from legacy sessions.

This is also where NHI governance matters. Legacy apps often depend on service accounts, stored passwords, and embedded tokens, which can persist long after the browser issue is “solved.” The Ultimate Guide to NHIs highlights the broader problem of weak visibility and overprivilege, and that pattern is commonly mirrored in legacy application access. For browser-specific implementation guidance, current guidance suggests using enterprise controls aligned to modern browser compatibility management rather than allowing ad hoc exceptions to accumulate. These controls tend to break down when the legacy app is tied to third-party vendor support constraints, because the organisation cannot change the code or the authentication flow quickly enough.

Common Variations and Edge Cases

Tighter compatibility control often increases operational overhead, requiring organisations to balance usability against reduction in attack surface. The biggest edge case is when the “IE dependency” is not a single app but a cluster of workflows spread across finance, HR, or supply-chain systems, each with different owners and different risk tolerance. In that situation, there is no universal standard for this yet: best practice is evolving toward phased retirement, application rationalisation, and exception sunset dates rather than permanent IE support. Another common variation is regulated or vendor-hosted software that still requires a legacy browser for a narrow function. In those cases, the right answer may be a highly constrained access zone, not broad enterprise exceptioning. Teams should also watch for hidden dependencies such as scanners, portal plugins, or line-of-business tools that trigger the IE path without being obvious to end users. The security risk increases if the legacy path is used by privileged users, because one weak browser carve-out can become a launch point for broader access. The core rule is simple: if the app cannot leave IE today, the exception must be owned like any other high-risk control gap, reviewed on a schedule, and tied to a documented retirement plan.

Related resources from NHI Mgmt Group

• What breaks when insurance approval workflows still depend on paper handling?
• What breaks when unmanaged devices can still access business apps?
• What breaks when access controls still depend on passwords for sensitive records?
• What breaks when inherited accounts still use legacy authentication?