Article

Still Stuck on a Legacy Browser App?

·By Mathew Chewing

Internet Explorer is gone, but the business applications that needed it are not. Here is how to keep a legacy web app running safely while you plan its replacement.

Internet Explorer Has Lost All Support (What You Need to Know)

Internet Explorer has been retired and removed. That part is settled. What is not settled, in a surprising number of Australian businesses, is the line-of-business application that was written for it — the ordering portal, the plant maintenance system, the government lodgement tool that has not been touched since 2014.

These applications are the real story. The browser is gone; the dependency it created is still sitting in the middle of somebody daily workflow, and pretending otherwise does not make it safer.

Why the old application still works, and what that means

If an old internal site still loads, it is almost certainly running in Microsoft Edge IE mode — a compatibility layer inside Edge that renders specified sites using the legacy engine for exactly this situation.

IE mode is a legitimate, supported bridge, and it is the right answer while you plan a replacement. But be clear about what it is: a temporary accommodation with an end date, not a permanent architecture. Microsoft has committed to supporting IE mode in Edge through to at least 2029, which is a runway rather than a destination.

The important detail is that IE mode should be enabled for a specific list of sites, applied through policy — not switched on broadly. A site list means the legacy engine handles only the one internal application that needs it, while everything else, including the entire public internet, uses the modern engine with modern protections.

The actual risk of a legacy web application

The danger is rarely the rendering engine on its own. It is what tends to accompany an application nobody has updated in a decade:

  • Old authentication. Frequently a local username and password with no MFA, often shared between several staff.
  • Weak or absent transport security. Plain HTTP, or TLS versions long deprecated.
  • An unsupported server underneath. The application needs an old operating system or database, so that has not been patched either.
  • Browser plug-ins. ActiveX controls and Java applets — technologies removed from modern browsers precisely because they were a reliable route to code execution.
  • No vendor. The supplier is gone, acquired, or no longer writes patches, so a newly discovered flaw will never be fixed.

That combination — unpatched server, weak authentication, legacy transport — is a well-understood way into a network, and it is usually the oldest thing in the building.

Containing it while it still exists

If the application cannot be replaced this quarter, reduce what it can reach.

  1. Put it on its own network segment. If the host is compromised, the attacker should find a segment containing one old server, not your file storage and finance system.
  2. Restrict access to the people who need it, by account and ideally by device. Most legacy applications are reachable by every machine in the office for no reason other than history.
  3. Remove internet exposure. If it does not need to be reachable from outside, it should not be. Remote staff reach it through a VPN or a published application, not a public address.
  4. Put MFA in front of it even if the application itself cannot do MFA, by requiring authentication at the access layer.
  5. Log and monitor it specifically. Legacy systems are the ones attackers go for, so they deserve more attention than a modern one, not less.
  6. Document the dependency. Which application, which sites are in the IE mode list, who owns it, what the replacement plan is, and when it gets reviewed.

Network segmentation and access control are ordinary cyber security work, and the monitoring is what managed detection and response exists to do.

Planning the exit

Containment buys time. It does not remove the problem, and the cost of the old system compounds quietly — in workarounds, in the risk premium, in the staff member who is the only person who knows how to use it.

The replacement conversation usually has four options:

  • The vendor has a modern version. Often true and often unknown, because nobody has asked in five years.
  • A modern replacement exists in the market. The category has usually moved on considerably since the original was chosen.
  • The function can move into something you already own. A surprising number of ageing internal tools are a list, a form and a report — which Microsoft 365 can handle directly.
  • It genuinely must be rebuilt. The most expensive option, and worth confirming the first three have been properly explored first.

Whichever it is, put a date on it. A legacy dependency with no target date does not get replaced; it gets inherited.

The broader lesson

The IE retirement was announced years in advance and still caught businesses unprepared, because the deadline was a browser and the dependency was an application. The same shape recurs constantly — operating systems, server versions, hardware, TLS versions.

The businesses that handle it well are the ones keeping a written inventory of what runs on what, with support end dates against each line. That is the difference between a planned project and an emergency, and it is the core of what our virtual CIO service maintains. An IT audit is the fastest way to find out what is actually still running.

Local IT and cyber security support across NSW

Chewing IT runs managed IT and cyber security for small and mid-sized businesses from our Wyong and Hornsby offices, covering the Central Coast, Newcastle, Lake Macquarie and Hornsby.

Got an old application nobody wants to touch? Ask us to assess it — containment now, a replacement plan with a date on it.

Want this handled for you?

Chewing IT looks after IT, cloud and cyber security for businesses across the Central Coast, Newcastle and Sydney. Free, no-pressure consultation — no contracts, no jargon.