HIPAA and End-of-Life Software: What the Security Rule Requires, and How to Show It
The HIPAA Security Rule does not name a single product, and it has no blanket ban on old software. The words "unsupported", "end of life", "legacy" and "patch" do not appear anywhere in its text (45 CFR Part 164, Subpart C). What it does is make an unsupported system impossible to ignore. Two specifications marked Required, risk analysis and risk management (45 CFR 164.308(a)(1)(ii)(A) and (B)), oblige every covered entity and business associate to find the risks and vulnerabilities to electronic protected health information (ePHI) and to reduce them to a reasonable and appropriate level. A server or workstation that no longer receives security fixes is one of those vulnerabilities, and HHS's Office for Civil Rights (OCR) has said as much: "Legacy systems' lack of vendor support makes them particularly vulnerable to cyberattacks" (OCR Cybersecurity Newsletter, Fall 2021). Protection from malicious software, an addressable specification, and the evaluation standard follow from there. HHS's proposed update to the Security Rule, published on January 6, 2025, would add a written technology asset inventory and fixed patch deadlines, but it is still a proposal, not law.
What the Security Rule says, specification by specification
Each standard in the Security Rule comes with implementation specifications marked either Required or Addressable (45 CFR 164.306(d)). The rows below are the ones that decide how end-of-life software is handled. The wording is paraphrased from the current text on eCFR.
| Section | Required or addressable | What it says (paraphrased) | What it means for end-of-life software |
|---|---|---|---|
| 164.306(a) and (b) General requirements, flexibility of approach |
General rule | Protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI. In choosing security measures, take into account your size, complexity and capabilities; your technical infrastructure, hardware and software security capabilities; the costs; and the probability and criticality of potential risks. | Cost and size are legitimate factors in deciding how to treat an old system. They are not a reason to leave the risk unassessed. |
| 164.308(a)(1)(ii)(A) Risk analysis |
Required | Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI you hold. | An end-of-life system that stores ePHI, processes it or can reach a system that does belongs in the analysis as a named vulnerability. An analysis that does not know which products are past their vendor's end date is hard to call accurate. |
| 164.308(a)(1)(ii)(B) Risk management |
Required | Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. | The decision for each unsupported system: upgrade, buy extended security updates, isolate it, or keep it with compensating controls, with a timeline. |
| 164.308(a)(5)(ii)(B) Protection from malicious software |
Addressable | Procedures for guarding against, detecting and reporting malicious software. It sits under the security awareness and training standard. | An operating system that gets no fixes is an open door for malware. OCR lists supported anti-malware on the old system as one of the controls to consider. |
| 164.308(a)(8) Evaluation |
Standard (no separate specifications) | Perform a periodic technical and nontechnical evaluation, and again in response to environmental or operational changes affecting the security of ePHI. | A product reaching its end of support changes its security from that day. Treat the date as a trigger for re-evaluation rather than waiting for the next annual cycle. |
| 164.306(e) Maintenance |
General rule | Review and modify the security measures as needed to keep protection reasonable and appropriate, and update their documentation. | A plan written while a product was supported has to be revisited once it is not. |
| 164.316(b) Documentation |
Required (time limit, availability, updates) | Keep policies, procedures and any action, activity or assessment the rule requires in written (which may be electronic) form; retain it for 6 years from creation or from when it was last in effect, whichever is later; review it periodically and update it after environmental or operational changes. | The risk analysis entry for each unsupported system, the decision taken and its later reviews are records you keep. |
Required versus addressable
Risk analysis and risk management are Required: there is no alternative to doing them. Protection from malicious software is Addressable, which does not mean optional. Under 45 CFR 164.306(d)(3) you must assess whether an addressable specification is a reasonable and appropriate safeguard in your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure if that is reasonable and appropriate. HHS wrote in its 2025 proposal that OCR's enforcement experience showed "addressable" being misunderstood as optional, which is one reason the proposal would remove the distinction altogether (more on that below).
HHS's risk analysis guidance adds two points that matter for planning. The Security Rule "does not prescribe a specific risk analysis methodology" (HHS, Guidance on Risk Analysis), and it does not say how often to perform one: HHS describes the process as ongoing and notes that some organisations repeat it annually or as needed. So the rule does not set a date by which an end-of-life system must go. Your own risk analysis does, and you are held to it.
What OCR has said about legacy systems
OCR's cybersecurity newsletters are guidance, not regulation; the Fall 2021 issue says it does not legally bind anyone. They are still the clearest statement of what OCR expects to see, and three of them deal with unsupported software directly.
Securing Your Legacy (Fall 2021)
OCR defines a legacy system as one with components supplanted by newer technology and for which the manufacturer no longer offers support, and acknowledges that health care organisations keep them for real reasons: medical devices and electronic health records that cannot be replaced without disrupting care, dependencies, cost. It then sets out what risk management means for such a system: identify the risks and vulnerabilities it poses to ePHI, the security measures that will reduce them, and the proposed timeline, including, if possible, the system's retirement date. The strategies it lists are:
- upgrade to a supported version or system;
- contract with the vendor or a third party for extended support, or migrate to a supported cloud-based solution;
- remove or segregate the system from the internet or from the organisation's network;
- keep the system, but strengthen existing controls or add compensating controls tailored to its risks.
For the last option the newsletter names the controls: more system activity review and audit logging, fewer users, stronger authentication and access controls, removing unnecessary software and services, backups, contingency plans that expect a higher chance of failure, aggressive firewall rules, and supported anti-malware. It closes by asking organisations to plan for the legacy system's eventual removal and replacement.
Defending Against Common Cyber-Attacks (Quarter 1, 2022)
Under the heading of known vulnerabilities, OCR says regulated entities should upgrade or replace obsolete, unsupported applications and devices, and, where that cannot be done yet, add or strengthen safeguards until it can, giving increased access restrictions, removed or restricted network access, and disabled features or services as examples. It ties this to the required risk analysis, which should include processes that identify technical vulnerabilities, for instance from CISA alerts and the HHS Health Sector Cybersecurity Coordination Center.
HIPAA and IT Asset Inventories (Summer 2020)
OCR recommends an IT asset inventory that records, among other things, the version of each asset, and is candid about its status: "Although the Security Rule does not require it" (OCR Cybersecurity Newsletter, Summer 2020), an up-to-date inventory helps make the risk analysis accurate and thorough, and helps track which devices need updates and patches. Without versions you cannot know what has reached end of life.
What OCR looks for: the ACMHS settlement
OCR's resolution agreements show which failures it names. The one most directly about this topic is Anchorage Community Mental Health Services, announced in December 2014 under the headline "HIPAA Settlement Underscores the Vulnerability of Unpatched and Unsupported Software" (OCR bulletin). Malware had compromised ACMHS's systems in a breach reported as affecting 2,743 individuals. OCR's bulletin says the incident resulted from failing to address basic risks, including not applying available patches and running outdated, unsupported software. ACMHS paid $150,000 and agreed to a corrective action plan with two years of reporting.
The resolution agreement lists the covered conduct, and it maps onto the specifications above: no accurate and thorough risk analysis (164.308(a)(1)(ii)(A)); no policies and procedures implementing security measures to reduce risks to a reasonable and appropriate level (164.308(a)(1)(ii)(B)); and, under the transmission security standard (164.312(e)), a failure to ensure firewalls with threat monitoring were in place and that IT resources were supported and regularly updated with available patches. There was no rule against old software to cite. The unsupported systems show up inside the risk analysis, risk management and transmission security findings, as evidence that those safeguards were missing.
That is the practical test. When an investigator finds an end-of-life system, the questions are whether your risk analysis knew about it, what you decided, and whether you did what you decided. Have ready:
- the inventory showing the system, its version and its vendor's end-of-support date;
- the risk analysis entry naming it as a vulnerability, with likelihood, impact and a risk rating;
- the risk management decision, with the measures applied, an owner and a date for upgrade or retirement;
- proof the measures are working: ESU or extended support contracts and update history, firewall rules, access lists, anti-malware and log reviews;
- the evaluation or review performed when the product reached its end date;
- all of it retained for six years.
A worked example: what clinics still run
Here is how common products in clinics and their vendors' back offices look today. The dates and status badges in this table are refreshed from our lifecycle data at every build, so they stay current when a vendor moves a date.
| Component | End-of-life date | Status | What the risk analysis and risk management record should say |
|---|---|---|---|
| Windows 10 22H2 | Oct 14, 2025 | EOL | Commercial Extended Security Updates can run through Oct 10, 2028, bought a year at a time. Enrolled devices: record the subscription and update history as the security measure. Devices without ESU get no security fixes from Microsoft: name the risk, the compensating controls and a replacement date. The consumer program is a separate thing; see how its date moved. |
| Windows Server 2012 R2 | Oct 10, 2023 | EOL | Microsoft's ESU program for it ran to Oct 13, 2026. A practice management or file server still on it needs a high risk rating, isolation from the internet, tight access and a near retirement date in the plan. See the ESU cliff. |
| Windows Server 2016 | Jan 12, 2027 | Approaching | Still supported, with an announced end date. Record the date now and put the upgrade, or paid ESU, in the risk management plan, so the evaluation on that day finds a decision already taken. |
| SQL Server 2016 SP3 | Jul 14, 2026 | EOL | Often the database under an EHR, imaging or billing application, so it holds ePHI directly. Microsoft's paid ESU runs to Jul 17, 2029. Ask the application vendor which SQL Server versions it supports before planning the upgrade. More in SQL Server 2016 end of life. |
| Oracle JDK 8 | Mar 31, 2022 | EOL | Premier Support has ended; Oracle lists Extended Support to Dec 31, 2030. A Java 8 runtime bundled inside a clinical or lab application is updated by that application's vendor, so record which build you run and who is responsible for updating it. See Java 8 end of life. |
| PHP 7.4 | Nov 28, 2022 | EOL | A patient portal, intake form or appointment site on this branch is an internet-facing vulnerability. A one-off fix after end of life, such as the PHP project's source patches for PHP2Shell, is not a support commitment, so the plan needs an upgrade date. |
Three patterns cover most estates. Systems past their end date with no paid update program need a high risk rating, compensating controls and a dated plan to go. Systems past their end date under a paid program (ESU, extended support) still receive fixes, which is a legitimate risk management measure while the subscription is current and the system stays in the plan. And systems whose end date is announced but not yet reached need the decision recorded before the date arrives.
Medical devices: handle with care
Imaging workstations, lab analysers and monitoring systems often run an embedded operating system long past its end of support, and the clinic usually cannot update them itself: changes have to come from the manufacturer. HIPAA treats them like any other system. If a device holds ePHI or can reach systems that do, it belongs in the risk analysis, and OCR's Fall 2021 newsletter names medical devices among the legacy systems organisations keep for good reasons. The controls are usually the segregation and access options above, not replacing the device next week.
The FDA's rules fall on manufacturers, not on the clinic. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by section 3305 of the Consolidated Appropriations Act, 2023, applies to premarket submissions for "cyber devices": in short, devices that include software validated, installed or authorised by the sponsor, can connect to the internet, and could be vulnerable to cybersecurity threats. According to FDA's frequently asked questions, it applies to submissions made on or after March 29, 2023, and requires the manufacturer to submit a plan to monitor, identify and address postmarket vulnerabilities, to maintain processes that provide a reasonable assurance the device is cybersecure and make postmarket updates and patches available, and to provide a software bill of materials covering commercial, open-source and off-the-shelf components.
FDA's premarket cybersecurity guidance, revised and issued in February 2026, goes further in its recommendations, which are nonbinding: for each component in the SBOM, manufacturers should state its level of support and its end-of-support date, and device labeling should include known or anticipated cybersecurity end-of-support and end-of-life information. For a clinic, that gives you something concrete to ask for. Request the SBOM, the end-of-support information and the Manufacturer Disclosure Statement for Medical Device Security (MDS2) for each networked device, and record what you get, or that you could not get it, in the risk analysis. Devices cleared before section 524B applied may come with none of this.
The proposed Security Rule update: still a proposal
HHS published a notice of proposed rulemaking to strengthen the Security Rule in the Federal Register on January 6, 2025 (90 FR 898, RIN 0945-AA22). As of October 30, 2026, the Federal Register lists no final rule and no withdrawal under that RIN; the proposal is the only document there. The current Unified Agenda on Reginfo.gov (the 2026 edition) places it among long-term actions and gives a final action date of July 2027. Nothing in it is in force. If it were adopted as proposed, it would change this topic in three ways:
- A technology asset inventory would become a standard: a written inventory and network map of systems and technology assets that may affect ePHI, recording each asset's identification, version, person accountable and location, reviewed at least every 12 months and after changes (proposed 164.308(a)(1)).
- Patch deadlines: a new patch management standard (proposed 164.308(a)(4)) would require critical risks to be patched within 15 calendar days and high risks within 30, with documented exceptions, including where no patch is available, and compensating controls in their place.
- No more addressable specifications: the proposal would remove the distinction between required and addressable, so every implementation specification would have to be met.
The proposal also included exceptions to its encryption and multi-factor authentication requirements for some FDA-authorised medical devices, tied to the same March 29, 2023 date as section 524B, to whether the device is still supported by its manufacturer, and to the clinic having deployed the manufacturer's updates and patches. All of this is proposal text. Plan with it in mind if you like, but cite the current rule when you document compliance.
How to build the evidence
Every item on the list above starts from an inventory that records versions. Then, for every line, two questions: is it supported today, and does its support end inside the next twelve months? The first feeds the risk analysis; the second feeds the risk management plan and tells you when the evaluation standard will be triggered.
The second question is the one lifecycle data answers. endoflife.ai publishes end-of-life dates for 700+ products, and every answer names the source of its date.
1. The API, with a free key
Look up any product and version and get the status, the end-of-life date, days remaining or days past, and the source URL of the date. Get a free API key (emailed, no credit card); the API documentation covers batch lookups for a whole inventory export.
curl -H "X-API-Key: YOUR_KEY" https://api.endoflife.ai/v1/status/windows-server/2016The response includes status, eol_date, days_past_eol, eol_date_source and eol_date_source_url, which is what you need when someone asks where a date in your risk analysis came from.
2. The scanner and SBOM check
Upload a CycloneDX or SPDX SBOM, or a package manifest, to the scanner for a one-off report of what in it has reached end of life. It suits the SBOM a device manufacturer or an application vendor gives you, and the interpreters, frameworks and libraries an inventory of installed programs misses. How to audit an SBOM for end-of-life software explains the method, and unsupported software detection covers the wider approach.
3. Your RMM, PSA or monitoring tool
MSPs looking after several practices usually have the inventory already. The HaloPSA integration writes end-of-life dates and their sources onto assets and can open a ticket for each asset past end of life, so every client's risk management item has an owner. Zabbix, Splunk, Datadog, Dynatrace, Grafana, a GitHub Action and an MCP server for AI assistants are on the integrations page. For the policy side, the free EOL policy template sets remediation deadlines and an exception process you can adapt into your HIPAA risk management procedures, and the MSP end-of-life audit walks through a client review.
Frequently Asked Questions
Does HIPAA prohibit unsupported or end-of-life software?
No rule in the HIPAA Security Rule names a product or bans software that has reached end of life; the words unsupported, end of life and legacy do not appear in its text. What it requires is a risk analysis and risk management, both marked Required in 45 CFR 164.308(a)(1)(ii). An unsupported system that holds or can reach electronic protected health information is a vulnerability the risk analysis has to identify, and risk management has to reduce that risk to a reasonable and appropriate level, by upgrading, buying extended security updates, isolating the system or adding compensating controls, with the decision documented.
Is Windows 10 still HIPAA compliant after Microsoft ended support?
HIPAA does not certify or ban operating systems, so the question is whether your risk analysis and risk management cover it. Microsoft ended support for Windows 10 22H2 on October 14, 2025. A Windows 10 device enrolled in Microsoft's paid Extended Security Updates program still receives security updates, and the subscription is the security measure you record. A Windows 10 device without ESU receives no security fixes from Microsoft, so the risk analysis has to name it as a vulnerability and the risk management plan has to say what reduces that risk, such as removing internet access, restricting users and functions, and a replacement date.
Is protection from malicious software required or addressable under HIPAA?
Addressable. It is an implementation specification under the security awareness and training standard, 45 CFR 164.308(a)(5)(ii)(B): procedures for guarding against, detecting and reporting malicious software. Addressable does not mean optional. Under 45 CFR 164.306(d)(3) you must assess whether it is reasonable and appropriate, implement it if it is, and if it is not, document why and implement an equivalent alternative measure if reasonable and appropriate.
Has HHS finalized the proposed HIPAA Security Rule update?
No. HHS published the proposal on January 6, 2025 (90 FR 898). As of October 30, 2026, the Federal Register shows no final rule and no withdrawal for it (RIN 0945-AA22), and the current Unified Agenda lists it among long-term actions. Its proposals, including a written technology asset inventory and patching within 15 calendar days for critical risks and 30 for high risks, are not in force. The Security Rule in 45 CFR Part 164 Subpart C, as it stands, is the law.
Does a medical device running an old operating system violate HIPAA?
Not by itself. If the device holds or can reach electronic protected health information, it belongs in your risk analysis, and the risk it carries has to be managed like any other, often by segregating it from the internet and the rest of the network and limiting who can use it. Updates for the device usually have to come from its manufacturer. Since section 524B of the Federal Food, Drug, and Cosmetic Act took effect, manufacturers submitting cyber devices to the FDA must supply a software bill of materials and a plan for postmarket updates and patches, which gives you something to ask for.
How long must HIPAA risk analysis records be kept?
Six years. 45 CFR 164.316(b)(2)(i), marked Required, says documentation the Security Rule requires must be retained for 6 years from the date of its creation or the date when it last was in effect, whichever is later. That covers the risk analysis, the risk management decisions about each unsupported system, and the policies behind them.
Sources
Read for this guide on October 30, 2026:
- eCFR, 45 CFR Part 164, Subpart C, Security Standards for the Protection of Electronic Protected Health Information, in particular 164.306, 164.308 and 164.316.
- HHS, Guidance on Risk Analysis.
- HHS OCR Cybersecurity Newsletters: Securing Your Legacy (Fall 2021), Defending Against Common Cyber-Attacks (Quarter 1, 2022) and HIPAA and IT Asset Inventories (Summer 2020).
- HHS OCR, Anchorage Community Mental Health Services settlement: the bulletin and the resolution agreement.
- Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule, 90 FR 898), and the documents listed for RIN 0945-AA22.
- Reginfo.gov, Unified Agenda entry for RIN 0945-AA22.
- FDA, Cybersecurity in Medical Devices Frequently Asked Questions (section 524B) and Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions.
Related Resources
- PCI DSS and end-of-life software: what Requirement 12.3.4 asks for
- Cyber Essentials and unsupported software
- How to Build a Software EOL Management Program That Survives an Audit
- The MSP end-of-life audit
- Windows Server 2012 and 2012 R2: the ESU cliff
- SQL Server 2016 end of life
- Every Windows version and its end-of-support date
- EOL Watch: lifecycle date changes, tracked as they happen