Overview
A computer device such as a laptop or desktop must be fully supported for it to be used on the Department of Medicine secure network. There is a stage in the lifecycle of each device where it can no longer be efficiently and reasonably supported and this stage is called end of support, otherwise generally known as end-of-life (EOL) in the IT industry.
There are three primary factors involved in determining when a device reaches its end of support status.
Each supported device must be running an operating system (OS) that is provided with regular and timely security updates by its vendor for it to be supported and allowed on the Department of Medicine secure network. The device must also be capable of running required security and management tools. The physical hardware makeup of a device is the largest factor in determining whether it can run a supported OS, therefore the hardware must be capable of being supported by IT.
This document describes the Department of Medicine end of support policy, including what factors are considered when determining whether a device can be supported and allowed on the Dept of Medicine secure network.
Currently Supported OS Versions
Microsoft Windows
Windows 11 – 23H2, 22H2, 21H2
Windows 10 – 22H2 (Ends Oct 2025) - 21H2, 20H2 ended but will auto-update to 22H2
Microsoft will stop releasing free updates for all versions of Windows 10 on Oct 14, 2025. Paid support will be available for 3 years.
Apple MacOS
Sequoia (v15)
Sonoma (v14)
Ventura (v13)
Monterey (v12) support ended late 2024
Big Sur (v11) support ended late 2023
Redhat (including Centos & AlmaLinux)
v9 (ends May 31, 2032)
v8 (ends May 31, 2029)
v7 (ended June 30, 2024)
Why is the supported OS policy important?
Some of the most important reasons to remain up to date are:
- Improved security
- Requirement for compliance
- Fixes for known problems, bugs and security gaps
- Access to the latest features
- Better compatibility
- Better device performance
- Vendor support
- Increased productivity and efficiency
How do vendors define the lifecycle of an OS
Each operating system vendor has a unique method to determine whether a particular OS is within its supported lifecycle.
Microsoft
- Modern Microsoft operating systems have a major and minor release version. Major versions have names such as Windows 10 or Windows 11. Minor release versions within a major version are currently released annually and have less obvious names such as 20H2, 21H2 & 22H2 where the first two numbers are the year it was released and the H2 meaning that it is released in the second half of the year. Microsoft used to do semiannual minor releases, so historically there was an H1 and H2 version released every year, but now that they only do an annual release, it will just be H2 going forward as long as they keep the same release timeline.
- Microsoft has been shifting to a 5-year lifecycle timeline for a major version, and a 30-month lifecycle timeline for each minor release version.
Apple
- Apple is famously secretive and does not publish any end-of-life schedules. Apple will only provide full updates for its latest released OS. Apple will provide security only updates for the prior two operating system releases, so there is effectively a 3-version sliding window of security update support for which there is no explicit timeline provided.
Redhat, Centos, AlmaLinux
- Redhat explicitly releases the support timeline at the time the OS is released.
How do I keep the OS on my device up to date?
In most cases, the Department of Medicine IT group will make sure each device is kept up to date with the latest OS the device is capable of running. Numerous management tools have been deployed to devices to automate this process. There may be cases where this can not be automated, such as vendor requirements on devices hooked up to specific pieces of lab equipment that preclude the use of automation and when this occurs, compensating controls will be discussed on a case-by-case basis with input from all interested parties in order to come up with a manual mitigation plan.
Required Management Tools
Supported devices must be running the management tools determined mandatory by UW System, UW Madison, SMPH and the Department of Medicine. These tools are required to be installed for compliance with Federal and State privacy and security laws. (relevant policies can be found at the end of this document) These tools are also used to automate the process of keeping a machine up to date with security and feature updates. Over time, the health of a machine may degrade to the point where certain management tools no longer function even though the machine may appear to be working satisfactorily. This can sometimes prevent the device from automatically updating itself. When this occurs, it may be necessary for the helpdesk to have physical access to the device to manually restore it back to a healthy supported state.
The required management tools currently in use are always evolving to be more powerful and robust which require more computing resources being utilized per device over time. As machines age, they end up having fewer resources available to do meaningful work because the management tools start using too high of a percentage of the set amount of resources available. Sometimes this can be mitigated by upgrading the ram or increasing the speed of a cpu or hard drive, but the industry trend is to manufacture machines that are not upgradable any more than what’s provided at the time of purchase. This explains why a given device tends to slow down over time even if the actual meaningful workload doesn’t increase. Once the combined utilization of management tools and useful work become too great for a particular device, software tends to crash or at the very least run extremely slow and this has a large effect on the efficiency of any particular workflow. When hardware cannot meet the demands of running all of the required management tools and do meaningful work at the same time it is a good sign that it should be replaced with something newer.
Hardware Considerations
Modern operating systems have hardware requirements that must be met to run them. Apple is the sole provider of both the OS and the hardware for their devices so Apple can publish a list of supported devices per OS version. Microsoft and RedHat do not provide the hardware for their systems so they can only provide a list of minimum requirements that hardware vendors such as Dell must adhere to. Therefore, we must rely on each hardware vendor to provide a list of what models they provide that can support any given OS version when dealing with Windows or Linux hardware.
- macOS Sequoia - https://support.apple.com/en-us/120282
- macOS Sonoma - https://support.apple.com/en-us/105113
- macOS Ventura - https://support.apple.com/en-us/HT213264
- macOS Monterey - https://support.apple.com/en-us/HT212551 - EOL
- macOS Big Sur - https://support.apple.com/kb/sp833?locale=en_US - EOL
- Windows 11 - https://www.dell.com/support/kbdoc/en-us/000187485/dell-computers-tested-for-upgrade-to-windows-11
- Windows 10 - https://www.dell.com/support/kbdoc/en-us/000180684/dell-computers-tested-for-windows-10-october-2020-update-and-previous-versions-of-windows-10
- Redhat - Use of linux is typically done on a case by case basis and hardware lifecycle is determined at the time of implementation due to there not being an explicit list of supported device models provided by the hardware vendors. Linux is also typically used in a virtual environment of some sort. Virtual environments are typically not constrained by specific model numbers from hardware manufacturers.
Hardware lifecycles and warranty support
Hardware failures are typically grouped into one of two separate types of failures. Breakage is typically more of an acute type of failure that happens as the result of some sort of accident such as dropping a device, a power surge, or water leaking on the device. The other group of hardware failures occur mainly due to wear and age. Examples of wear and age failures are hard drives and batteries failing after a set amount of usage cycles, individual cells within ram modules starting to fail, or screens having burn-in and pixel loss over time. These types of failures are far more difficult to detect and or resolve. Devices within their warranty period can always have parts replaced regardless of the type of failure although each vendor warranty will dictate whether the cost of repairing accidental damage is covered. This is why it is generally suggested to replace a device once it is out of warranty.
Once a device falls out of warranty, it becomes unpredictable whether a device can have hardware repaired within a reasonable time period and/or for a reasonable cost.
Once repair parts are no longer generally available for a device, a hardware failure can cause a major disruption in the important work the device is performing so it is imperative to replace a device before repair parts are no longer available for a given device model.
Some manufacturers such as Apple have moved away from a system of using modular component parts that are combined into a complete system where each module can be replaced individually if need be. Apple has transitioned to a system where all major components are integrated together into a single unit with no ability to replace individual components. These devices require replacing the entire integrated system component as a single unit even if just one small part of it is failing. The cost of replacing these integrated system parts is typically more expensive than just replacing the device with a new device model. Each specific device will get a status of end of support if repair parts cannot be reasonably obtained. As already noted, wear and age-related failures can sometimes take significant time and effort to determine the cause and find a resolution because they may not show up in the system as not functioning during the course of everyday use.
Due to the intricacies of troubleshooting systems, the best course of action while troubleshooting can sometimes be to try to replace components likely to be the cause of a particular problem to see if the problem resolves. This is not possible if there are no replacement parts available or if they are cost prohibitive and is why there must be a distinct line between whether the hardware is supportable or in need of replacement.
Older equipment is always going to be less productive and have fewer capabilities than newer due to how much faster newer equipment will always be. Slower devices also take considerably more time to diagnose and repair than a newer system. Once the amount of effort to keep an older machine working takes more resources than it does to replace it with a new machine it makes sense to change the status of the machine to end of support and have it replaced.
Implications of a device reaching a status of End of Support
A device will fall to a status of end of support if any of the following become true. If it A) cannot run a supported OS, B) cannot run all of the required management and security tools, or C) if the hardware is no longer reasonably maintainable.
End of support devices are not allowed on the Department of Medicine secure network (which includes VPN) so the best course of action is to replace a device before it reaches this status in order to do meaningful work in most cases. Due to the different nuances between vendor requirements, it is not always straightforward to determine that a machine needs to be replaced with enough time in a given budget period. Dept of Medicine IT will make every effort to keep the supported list as up to date as possible along with future predictions to give enough warning so that budgetary constraints can be considered. Ideally devices are replaced before they reach an end of support status.
Once an actively used device changes from a status of supported to end of support, it may continue to be used if it can meet the following restrictions. If the following restrictions cannot be met the device must be turned in for decommissioning.
- There must be an approved business case presented as to why the specific unsupported device must continue to be used. Some examples of acceptable business cases: The device is connected to a unique data collection instrument and the vendor of that device has specific requirements of what computing devices can be connected to it, or there are some cases where newer hardware no longer has the type of interface that is required to connect to a data collection instrument.
- The device will be removed from the Dept of Medicine secure network and placed on the Dept of Medicine restricted network if possible. This restricted network does not have access to the internet but can still connect to file shares for the purposes of moving data off for further analysis. If the restricted network is not available in the facility the device needs to run, other compensating controls will be implemented to protect the device and prevent it from getting on the internet and or causing potential problems for the rest of the secure network.
- If an end of support device is having a hardware failure it will presumably be out of warranty. Dept of Medicine IT will make reasonable efforts to repair or replace relevant failed components if possible, and funding will be provided by the Division. Success with repairing devices of this age should not be considered the norm, and the expectation should be that it will be less expensive to replace than repair. The chances of data loss are much higher once a device has reached a state of end of support. If this occurs and the data it is deemed necessary to recover the data, there are third party data recovery services available, but it should be known that these services are extremely expensive and time consuming and there is a good chance that they will not be successful in recovering any data at all.
- A plan must be presented along with the business case that shows what the intended timeline will look like to either replace or decommission the device for good. Budgetary concerns may also be addressed with this plan if they are relevant.
Policy guidance references
- U.S. Department of Health & Human Services Security Rule Guidance - https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html
- UW System Administrative Policy 1036 - https://www.wisconsin.edu/uw-policies/uw-system-administrative-policies/information-security-endpoint-protection/
- UW Madison Endpoint Management and Security - https://policy.wisc.edu/library/UW-526
- UW Madison Supported OS Policy - https://kb.wisc.edu/doit-departmental-support-supported-os-policy
- UW Madison HIPAA Security Program - https://it.wisc.edu/about/division-of-information-technology/enterprise-information-security-services/office-of-cybersecurity/hipaa-security-program/
- SMPH Device Standards - https://kb.wisc.edu/smph/internal/smph-endpoint-device-standards
- SMPH Endpoint Security - https://policy.wisc.edu/library/SMPH-6010