Internet Explorer retired; its clinical applications did not

The week

For a whole generation of office workers, the blue “e” on the desktop was the internet. Internet Explorer had shipped with Windows since the 1990s, and its last major version, Internet Explorer 11, had arrived in 2013. On June 15, 2022, Microsoft retired the Internet Explorer 11 desktop application on most supported versions of Windows 10, ending support for the browser.

“Ending support” has a specific meaning in software. It does not mean the program vanishes overnight. It means the maker stops fixing it, including security flaws.

The retirement was not a surprise. Microsoft had announced it on May 19, 2021, more than a year earlier. Its own services had already been moving away. The Microsoft Teams web app had stopped supporting Internet Explorer 11 in November 2020, and the remaining Microsoft 365 apps and services followed in August 2021. Windows 11, released in October 2021, shipped without the Internet Explorer desktop application at all.

The retirement also happened in phases. First, users who tried to open Internet Explorer were redirected to Microsoft Edge, the company’s modern browser. Then an Edge update in February 2023 permanently disabled the old desktop application on affected systems.

The scope was narrower than many headlines suggested. The June 2022 date applied to the Semi-Annual Channel and IoT editions of Windows 10, the versions most offices ran. Microsoft said the retirement did not affect the Internet Explorer 11 desktop application on in-market long-term servicing editions of Windows 10, which are designed to stay unchanged for years, or on Windows Server. Those copies stayed in support for the life of the operating system they came with. Windows 8.1 and Windows 7 under extended security updates were also outside the June date.

Most importantly for what followed, the retirement did not touch the engine underneath. MSHTML, also known as Trident, is the code inside Windows that actually reads and displays pages the Internet Explorer way. It remained part of Windows and continued to receive security updates.

The hard part was that a great many business applications had been built specifically for Internet Explorer. They used old features that modern browsers do not support. Simply switching browsers would break them.

For those sites, Microsoft pointed organizations to Internet Explorer mode in Microsoft Edge, usually called IE mode. Staff browse in Edge as normal, but sites that an administrator has listed open with the legacy engine, the underlying machinery that reads and displays web pages, inside the modern browser. Microsoft said IE mode supported legacy functions such as ActiveX controls.

Microsoft gave administrators controls over the transition. Group Policy settings could disable Internet Explorer 11 as a standalone browser and send users to Edge on a schedule the organization chose, rather than waiting for Microsoft’s redirection. Organizations that had not yet found all their legacy sites could use Microsoft’s Enterprise Site Discovery tooling to record which sites users still opened in Internet Explorer.

The list itself used a familiar format. The Enterprise Mode Site List was an XML file inherited from Internet Explorer 11’s own compatibility features, and organizations that had built one for Internet Explorer could reuse it in Edge. Microsoft also offered a tool to create one from scratch.

Microsoft committed to support IE mode through at least 2029 on supported operating systems. It also promised at least one year’s notice before ending it. That gave organizations a long but finite runway, and a date to plan against.

For hospitals and health plans, that week mattered more than for most. Over two decades, they had built or bought a large number of web applications that only worked properly in Internet Explorer. IE mode bought them time. It also handed them, almost by accident, a list of every one of those applications. What they did with that list would decide whether the retirement left them safer or simply moved old risk into a new browser.

Walk into the back office of almost any hospital in 2022 and you would find screens running software that looked a decade or two old. A scheduling tool. An imaging viewer. A pharmacy interface. A console that manages infusion pumps. A payer website where staff check whether a patient’s insurance covers a procedure. Many of these ran in a web browser, and many of them only worked in one: Internet Explorer.

Few sectors had more riding on this retirement than health care. Over two decades, hospitals and health plans accumulated web applications built for Internet Explorer: departmental clinical systems, scheduling tools, imaging viewers, lab and pharmacy interfaces, device management consoles, payer portals and state registry sites. Many relied on ActiveX controls, old document modes or Java applets that no modern browser supports.

The argument here is that IE mode’s site list was the most useful artifact the retirement produced, and that it was worked down fastest by sorting each entry by who could fix it. The article first explains the old technology and how IE mode contains it. It then takes the three owner groups in turn: applications the hospital owns, products its vendors supply, and portals outside parties run. It closes with what is at stake and what a program that shrinks the list looks like.

What the old technology was, and why it lingered

A web browser is the program that fetches web pages and displays them. Underneath, it has an engine that interprets the code a website sends. Different engines interpret code slightly differently, and older engines support features that newer ones have dropped.

Internet Explorer supported several such features. ActiveX controls were small programs a website could install and run inside the browser, giving it powerful access to the computer. That power made them useful for things like controlling a scanner or displaying medical images, and also made them a favorite route for attackers. Java applets were a similar idea using a different technology. Document modes were settings that made Internet Explorer behave like even older versions of itself, so pages written for 2005 would still display correctly.

Modern browsers deliberately left these features behind, mostly for security reasons. Java applets had already lost their footing elsewhere: Oracle deprecated the browser plug-in in 2017 and removed it from later Java releases. But software built around these features did not rewrite itself. In hospitals especially, applications tend to live a long time. They are woven into clinical workflows, staff are trained on them, and changing them can require revalidating processes that affect patient care. If a system works, there is little appetite to touch it.

That is how a hospital ends up, in 2022, depending on a browser from another era. Nobody chose it as a strategy. It accumulated, one reasonable decision at a time.

A less visible reason these applications survive is that nobody owns the whole picture. The pharmacy team knows its interface. Radiology knows its viewer. Revenue cycle knows the payer portals. Clinical engineering knows the device consoles. No single person sees all of them together, and so no single budget line ever covers their replacement. Each one looks small. Together, they amount to a sizable dependency on technology the maker has stopped maintaining, which is exactly the kind of risk that boards and auditors expect leadership to know about.

Why health care held on longer than most

Several features of the sector made the dependency stickier. Clinical software often goes through validation before go-live: testing that a workflow produces the right result, every time, for the patient. A change of browser engine can force that testing again, and clinical informatics teams have limited capacity for it.

Purchasing is fragmented. A large health system may buy hundreds of applications, many through departmental budgets, and some through physician groups or affiliates that later joined the system. Mergers make this worse. Each acquired hospital brings its own long tail of tools, and integration projects tend to focus on the electronic health record, not on the departmental remainder.

Devices add a hardware clock. Imaging equipment, laboratory analyzers and pump fleets are capital assets with long service lives. The software that manages them was often frozen at the time of purchase, and the manufacturer may support only the configuration it originally validated.

How the pattern differs across health care

The same retirement played out differently by type of organization. A large academic health system usually had the longest list, the most custom-built tools, and the in-house developers to fix some of them. A community hospital had fewer custom tools but less staff to work the list, and relied more heavily on vendors.

An ambulatory network or large physician group typically ran its electronic health record as a hosted service, which reduced the internal tail. Its exposure sat mostly in payer portals and state registries, which its front-desk and billing staff use all day. A health plan’s exposure was different again: internal claims, care management and provider-data tools, plus the provider-facing portals it ran for others.

Life sciences companies faced a distinct constraint. Systems used in regulated manufacturing and clinical trials are often subject to computer system validation expectations under FDA rules on electronic records. Changing the browser underneath a validated system can trigger documented revalidation. That made IE mode especially attractive to them, and the exit especially slow.

How IE mode works in practice

IE mode solved the immediate problem well. Staff browse in a modern browser, and only sites an administrator places on an enterprise site list open with the legacy engine. The enterprise site list is a central file, controlled by IT, that names each web address needing the old treatment. When a nurse opens the lab interface, Edge checks the list, sees the address, and switches engines for that tab. When the same nurse opens a news site, it loads normally.

That shrank a large attack surface, because staff were no longer reading general web content with an engine that would soon receive no fixes. The attack surface is the total set of ways an attacker could get in. Most web-borne attacks arrive through ordinary browsing: a malicious link, a poisoned advertisement, a compromised website. Confining the old engine to a known list of internal and trusted sites removed most of that exposure at a stroke.

It also produced something many health systems had never had: a single, authoritative list of every web application that still depended on old technology. Before, that knowledge lived in the heads of departmental staff, in help desk tickets and in vendor contracts. Now it was one file, with usage data attached.

Shared workstations and virtual desktops

Hospitals add a complication most offices do not have. Many clinical staff work on shared workstations, logging in with a badge tap, and many applications are delivered through virtual desktops or published applications rather than installed locally. The site list and browser policies have to reach every one of those images, including the ones maintained by separate teams. A legacy application that works on an office laptop but fails on the virtual desktop used at nursing stations has not been fixed for the people who use it most.

This is also why testing matters more in hospitals. A change pushed to every workstation at once can break a workflow on night shift, when the people who know the application are not on site. Staged rollouts by department, with a quick rollback and a named contact in each unit, avoid most of that.

What the list controls, and what it does not

The site list decides which pages render with the legacy engine. It can also set which document mode each page uses, and whether a site stays in IE mode when a user follows a link elsewhere. Getting those settings right took testing, site by site. Too broad an entry, such as a whole domain, pulls unrelated pages into the old engine. Too narrow an entry breaks a workflow when the application jumps to a different address mid-task.

The list does not control the legacy engine itself. MSHTML stayed in Windows and kept receiving patches, and attackers kept looking for ways to call it outside the browser. In 2021, Microsoft patched an MSHTML flaw that attackers were exploiting through Office documents. In 2024, it patched another that had been abused with crafted shortcut files to open content in the retired browser. Neither depended on a hospital’s site list. Both showed that the old engine remained an attack surface as long as it was present.

The waiting room problem

The risk was that the list would become permanent. A site in IE mode still runs old code, often with old authentication and unmaintained plug-ins, on a dated engine. The browser around it is new. The application is not. IE mode is a very good waiting room, but it is no treatment.

Some organizations also used IE mode as a reason to relax. Once the help desk calls stopped, the project closed. The applications behind the list kept their shared logins, their unsupported plug-ins and their servers running old operating systems. The browser retirement had been handled. The legacy risk had not.

Working the list down required sorting each entry by who could actually fix it, because the remedy differs completely for applications the hospital owns, products its vendors supply, and portals run by outside parties.

Applications the hospital owns

The first group is internal: departmental tools written by hospital developers or long-departed contractors, intranet forms, reporting pages and small databases with web front ends. These are the hospital’s to fix, and also the easiest to neglect, because no vendor will ever send a reminder.

Each needs a decision: rewrite, replace with a feature of an existing platform, or retire. A surprising number can be retired. Usage logs from the site list often show applications opened by a handful of people, or not at all. Others duplicate functions now available in the electronic health record or a standard workflow tool. The remainder justify a small modernization budget, prioritized by clinical importance and by how outdated the authentication is.

Retiring an application without losing its records

Retirement has a step that is easy to skip. Some old tools hold records the organization must keep: logs of who saw what, departmental registers, quality data. Before switching an application off, someone should confirm whether its data falls under a retention requirement. If it does, the data needs to move to an archive that can still be searched and produced on request. Records management and compliance staff should sign off, alongside IT.

The decommissioning itself should cover the server, the database, the service accounts and any firewall rules that existed only for the application. Old servers left running after the application is retired are a common source of unpatched exposure.

Who pays for the internal tail

Funding is where internal entries stall. Each tool is too small for a capital request and too large to absorb in a department’s operating budget. A workable approach is a single, modest modernization fund held centrally, allocated by the same clinical importance ratings used to sort the list. Departments bid for it with a named owner and a retirement or replacement plan. That keeps decisions consistent and stops the loudest department from setting the order.

Proving a replacement works

Rewriting or replacing an internal tool brings its own risk. The old application may encode rules nobody wrote down: a calculation, a validation check, a field that triggers a downstream report. Before switching over, the owner should list what the tool actually does, run old and new side by side for a period, and compare outputs. Help desk tickets in the weeks after go-live are the best early signal of a missed rule.

Authentication and ownership

Authentication deserves its own review. Authentication is how a system checks that you are who you say you are. Legacy internal applications frequently use local accounts, shared logins or integrated Windows authentication without multi-factor protection. Multi-factor authentication asks for a second proof, such as a code on a phone, so a stolen password alone is not enough. Single sign-on lets staff log in once and reach many applications under one well-protected identity. Folding legacy applications into the hospital’s single sign-on, or retiring them, closes gaps that a browser project alone would not touch.

That is often harder than it sounds. Many old applications cannot speak modern single sign-on protocols at all. A common workaround is to put the application behind a gateway or reverse proxy that handles the modern login, and then passes the user through. That adds a component to maintain. It is usually still cheaper than a rewrite, and it brings the application under the same access reviews as everything else.

Ownership is the other gap. Many internal tools have no current business owner, only a server and a URL. Assigning each surviving application to a named department head, who confirms each year that it is still needed, prevents the list from refilling. It also gives the modernization budget a sponsor who can explain the clinical or operational case for the money.

Consider a community hospital whose IE mode site list has 140 entries. Sorting them takes a week. Sixty are internal tools. Usage data shows that twenty-five of those have not been opened in six months; they are switched off after a short notice period, and nobody complains. Fifteen duplicate features in the electronic health record and are folded into it over the next year. The remaining twenty get named owners, single sign-on and a modest rewrite budget, starting with a medication reconciliation form used on every ward. Within eighteen months, the internal portion of the list is down to a handful of entries, each with an owner and a date.

The trade-off in that sequence is clinical attention. Folding fifteen tools into the electronic health record means build work, testing and training for the clinical informatics team, which also has regulatory and safety work queued. A realistic plan spaces those moves across the year and lets clinical leaders choose the order.

Products the vendors supply

The second group is vendor software: clinical and departmental systems, device management consoles, and administrative products whose web interfaces were built for Internet Explorer. The hospital cannot fix the code, but it can use the contract.

For each product, the useful questions are concrete. The first is whether a version exists that runs in a modern browser. If it does, the hospital needs to know what the upgrade requires, such as new licenses, new servers or revalidation of clinical workflows. If it does not, the vendor should give a committed date and say what happens to support if the date slips. The answers belong in the vendor management file and in renewal terms. A renewal is when the hospital has the most bargaining power, and a clause that ties continued payment to a modern-browser release by a set date focuses attention.

Why vendors lagged, and what moved them

Vendors had their own reasons to move slowly. A modern-browser version of a clinical product is a rewrite of its user interface, with testing across every customer configuration. Smaller vendors serving a niche specialty may have had a few developers and dozens of hospital customers on different versions. The cheapest course for them was to tell customers that IE mode worked, and leave it there.

What moved them was usually commercial. Large customers wrote browser commitments into renewals. Group purchasing and peer networks shared which vendors had modern versions and which did not. And many vendors were moving to cloud delivery anyway, which made a modern interface part of a larger product plan rather than a standalone cost.

The hospital’s side of the bargain matters too. A vendor that ships a modern version is owed an upgrade project that actually happens. Hospitals that demanded new versions and then deferred the upgrade for budget reasons ended up with the commitment on paper and the old version on the floor.

What belongs in the contract file

For each vendor entry, a short record keeps the conversation honest across renewals. It should hold the product and version in use, and whether a modern-browser version exists. It should record the vendor’s written answer and date, the upgrade requirements, the renewal date, and the internal owner who will run the upgrade. Procurement, IT and the clinical owner should all be able to see it. When the renewal approaches, the record turns a vague worry into a specific negotiating position.

Medical device consoles

Medical device consoles are the hardest case. A console tied to imaging or lab equipment may only be upgradeable along with the hardware, which has a long service life and a capital budget of its own. Those entries should be linked to the device replacement plan and isolated on the network in the meantime, with access limited to the clinical engineering staff who need it. Network isolation means placing those systems in a separate, fenced-off section of the network, so that if something goes wrong there, it cannot easily spread to the rest of the hospital.

Isolation has practical details. The workstation that runs the console should be dedicated to that job, not used for email or general browsing. Its IE mode entries should cover only the console’s addresses. Remote access for the manufacturer’s service engineers should go through the hospital’s controlled route, with multi-factor authentication, rather than a modem or vendor tool left permanently open.

How a renewal conversation can go

Suppose a health plan’s claims-review tool still needs IE mode, and the contract is up for renewal. The vendor management team asks three written questions: is there a modern-browser version, what does moving to it require, and if there is none, by when will there be one? The vendor says a new version is planned but undated. The plan offers a one-year renewal instead of three, with an option to extend once a modern-browser release ships by an agreed date. The vendor commits to a date. Nothing about the conversation was technical. It was ordinary commercial discipline, applied to a browser dependency.

The same approach has limits. A sole-source clinical vendor, or a product embedded across many departments, may not accept a short renewal. In those cases the hospital has less bargaining power. The better use of the renewal may be to secure a dated roadmap and the right to exit if it slips, rather than to force an immediate change.

Portals outside parties run

The third group is external: payer portals for eligibility and prior authorization, state immunization and disease reporting sites, and some partner systems. Staff use them daily, and the hospital controls none of them.

The options here are indirect. Report the dependency to the portal owner through account managers, provider relations or industry associations, since one hospital’s complaint carries less weight than a group’s. Avoid building new workflows around portals that still require the legacy engine. Where an alternative exists, such as an electronic data interchange transaction or an interface that replaces manual portal entry, prefer it. Electronic data interchange, or EDI, is a standard way for computer systems to exchange structured business messages directly, such as an eligibility check, without a person typing into a website. That often improves efficiency as well as removing the browser dependency.

The public sector side of the same problem

State immunization registries and disease reporting systems are run by public health agencies, often on older platforms funded through grants. Their modernization depends on public budgets and procurement cycles that hospitals cannot speed up. Hospitals often have alternatives already: many report immunizations and some laboratory results through electronic interfaces from the health record, rather than by typing into a website. Where those interfaces exist, moving the remaining manual entries onto them removes the browser dependency and the transcription risk together.

When the health plan is the portal owner

Health plans sit on both sides of this problem. They depend on vendor tools internally, and they run portals that thousands of provider offices use for eligibility, claims status and prior authorization. A plan whose provider portal still required IE mode imposed the legacy engine on every practice that used it. For a plan, modernizing those portals reduced its own exposure and removed a burden from its network. It also reduced phone calls to provider services from practices whose staff could not get the portal to work.

Managing what cannot be fixed

External entries also need a contingency plan. If a portal stops working in IE mode, or Microsoft eventually ends IE mode, staff need another route to complete eligibility checks or required reporting. Knowing in advance which portals have a phone, fax or file-based fallback prevents a scramble.

External entries carry a security consideration of their own. A hospital that adds an outside portal to its site list is telling the legacy engine to trust content it does not control. Entries for external sites should be as narrow as possible, reviewed often, and removed as soon as the portal owner modernizes. A periodic check of whether each external portal still needs IE mode is cheap and frequently finds that it no longer does.

Care, revenue and reporting at stake

A browser retirement sounds like the most technical of topics. The consequences are not.

• Patient care. If an imaging viewer or pharmacy interface stops working, clinicians lose time or work around it. Workarounds are where errors creep in.
• Revenue. Eligibility checks and prior authorizations run through payer portals. If those break, claims are delayed or denied.
• Security and liability. Old code with weak logins is an easy target. A breach that starts in a forgotten departmental tool still lands on the hospital’s desk.
• Regulatory reporting. State immunization and disease reporting sites are not optional. A plan for when they misbehave is part of compliance.
• Capital planning. Device consoles tied to hardware turn a browser problem into a multi-year equipment budget conversation.

Where the HIPAA obligations come in

The HIPAA Security Rule does not mention browsers. It does require covered entities and business associates to conduct an accurate and thorough risk analysis and to manage the risks it finds. HHS’s Office for Civil Rights has repeatedly cited failures in that analysis in its enforcement actions. A site list of applications running on retired technology is direct evidence for that analysis. An organization that has the list and no plan for it has documented a risk it chose not to manage.

Organizations should check with counsel about how their risk analysis treats legacy applications. The technical point is simpler. The site list, with owners and dates attached, is exactly the kind of inventory an auditor expects to see behind a risk register entry for legacy software.

Metrics that show progress

A few measures make the list useful to leadership. The total number of entries, split by owner group. The share of entries with a named owner. The share of internal entries behind single sign-on with multi-factor authentication. The number of entries with no recorded use in the last ninety days, which should trend to zero as unused tools are retired. The number of vendor entries with a dated modern-browser commitment in the contract. Each can be produced from the list, usage data and the contract file, without new tools.

The case for leaving the list alone

There is a serious argument against urgency. IE mode is supported through at least 2029, with a year’s notice before it ends. The applications on the list work. Clinical informatics and IT teams have more pressing demands, from ransomware defense to regulatory interoperability work. Spending scarce effort on tools that function seems hard to justify.

That argument holds for some entries. A low-use, internal-only tool on an isolated network, with strong authentication in front of it, may reasonably wait. It fails as a general policy, for three reasons. The applications on the list usually carry weak authentication that matters regardless of the browser. The engine underneath kept attracting attackers, as the MSHTML flaws showed. And the work is cheapest when spread over years, through renewals and replacement cycles, rather than compressed into the final twelve months of notice.

Across all three groups, the site list doubles as a management metric. Its length, broken down by owner category and clinical importance, gives leadership a plain measure of legacy exposure. A list that shrinks every quarter shows a program working. One that stays flat shows that the compatibility layer has become the plan by default.

Getting started

For a health system that has a site list but has never worked it, the first few months can follow a simple pattern. First, export the list and attach usage data to every entry: how many people opened it, and how often. Second, tag each entry by owner category, internal, vendor or external, and by clinical importance, using a short scale that clinical leaders agree on. Third, pick the quick wins: unused internal tools to retire and vendor products where a modern version already exists. Fourth, put the harder cases into the plans where they belong, the capital plan for device consoles, the contract calendar for vendor products and the partner relations agenda for external portals.

That sequence does not require new software or outside help. It requires someone with the authority to convene clinical, IT, procurement and finance colleagues, and the persistence to keep the list on the agenda. In most organizations, that person is not in IT. A chief operating officer or chief medical information officer is often better placed, because the decisions involved are about workflows and money as much as code.

A program that shrinks the list

Signs of a healthy program

• Every entry on the site list is tagged as internal, vendor or external, with a clinical importance rating.
• Each internal application has a named owner who reconfirms the need every year.
• Unused applications are retired based on actual usage data, not guesswork, with their records archived where retention rules apply.
• Surviving internal tools sit behind single sign-on with multi-factor authentication.
• Vendor contracts carry dated commitments to modern-browser versions.
• Device consoles are linked to the replacement plan and isolated on the network.
• Each external portal has a documented fallback route and the narrowest possible list entry.
• Leadership sees the list length every quarter.

A gate on new entries

The list grows back unless someone controls the door. A short approval step for any new entry works well: who is asking, which application, why no modern alternative exists, and when the entry will be reviewed. Procurement can help by adding modern-browser support to the standard requirements for new software. A vendor that cannot meet it should need an explicit exception, signed by someone accountable.

How lists stop shrinking

• Treating IE mode as the finish line. It removes the old browser, not the old application.
• Letting anyone add to the list. Without a gate, new legacy dependencies creep in.
• Asking vendors informally. A promise in an email is not a contract term. Renewal is the moment to fix it.
• Ignoring authentication. A browser project that leaves shared logins in place has done half the job.
• Building new processes on old portals. Every new workflow on a legacy-only site deepens the dependency.
• Retiring the application but not the server. A switched-off tool on a running, unpatched server is still exposure.

Measuring the IE mode list and who owns each entry

Five questions give a board or executive committee a clear read on where a health system stands.

1. How many sites are on our IE mode list today, and how many were there a year ago?
2. How many are ours to fix, how many belong to vendors, and how many are outside portals?
3. Which entries support direct patient care, and what is the plan for each?
4. For each vendor product on the list, do we have a dated commitment to a modern-browser version in the contract?
5. What would we need to do if IE mode ended earlier than expected?

The useful answers are numbers and dates, broken down by owner group. A list that can be reported that way is already halfway to being managed.

With hindsight

The phased retirement went as Microsoft described, and the February 2023 Edge update removed the old desktop application from affected systems. The phases gave organizations time to prepare, and the final switch-off came well after the first warnings. Help desks saw a wave of calls when redirection began, and a smaller one when the application was finally disabled, mostly from users whose sites had never been added to the list.

IE mode has remained available, and many health systems still keep a site list in 2026, though most are much shorter than in 2022. That is real progress, and it reflects the slow, unglamorous work of retiring, replacing and renegotiating one entry at a time.

The engine underneath stayed a target. In July 2024, Microsoft patched an MSHTML flaw that attackers had used to open malicious content in the retired browser through crafted shortcut files. The episode confirmed that removing the Internet Explorer icon had not removed Internet Explorer’s code, and that patching Windows promptly remained part of managing legacy web risk.

Clinical and administrative software vendors have, in many cases, shipped browser-neutral versions, often as part of moves to cloud delivery. Cloud delivery means the vendor runs the software in its own data centers and customers reach it over the internet, which tends to push vendors toward modern, standard web technology.

The external portals moved for reasons beyond browsers. In January 2024, the Centers for Medicare & Medicaid Services finalized its Interoperability and Prior Authorization rule. It requires impacted payers, including Medicare Advantage organizations and state Medicaid and CHIP programs, to support prior authorization through standard application programming interfaces, with most of those requirements starting in January 2027. Over time, that should move a large share of prior authorization work off payer websites and into system-to-system exchange.

Device consoles came under a different kind of pressure. Since March 2023, makers of new network-connected medical devices have had to include cybersecurity information in their FDA premarket submissions, including plans for monitoring vulnerabilities and providing updates, and a software bill of materials. That applies to new submissions, not to the installed base. For hospitals, it improved what they could ask for at purchase, while the consoles already on the floor still waited on replacement cycles.

Weak authentication on older access points proved to be the costlier gap. In February 2024, a ransomware attack on Change Healthcare disrupted claims and pharmacy processing across the country. UnitedHealth Group’s chief executive later told Congress that attackers had used stolen credentials on a remote access portal that lacked multi-factor authentication. That portal was not a browser compatibility issue. It was the same kind of control gap that legacy application reviews had been designed to find.

The entries that remain tend to be the ones this framing predicts: device consoles tied to long-lived hardware, small internal tools with no budget, and external portals the hospital cannot change. Each reflects a different constraint. Device consoles wait on capital cycles. Small internal tools wait on someone deciding they matter enough to fund. External portals wait on someone else entirely.

The end of Windows 10 support in October 2025 forced another round of legacy cleanup, and teams that had already worked their IE list found that work easier. Inventory, ownership and contract terms built for one retirement pay off in the next one. Technology platforms will keep reaching end of life on a schedule set by their makers. Organizations that know what they depend on, and who can fix it, meet each deadline with a plan rather than a scramble.

Microsoft’s commitment to support IE mode through at least 2029, with at least a year’s notice before it ends, still sets the outer horizon. For any entry still on the list, that date is the one to plan against.