U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES Office for Civil Rights

________________________________________________________________

January 2026 OCR Cybersecurity Newsletter

System Hardening and Protecting ePHI

System hardening is the process of customizing electronic information systems (e.g., computer systems and other electronic devices) to reduce their attack surface,¹ thus reducing the number of weaknesses² and vulnerabilities³ that an attacker can exploit. This customization can take various forms, but typically includes a combination of patching known vulnerabilities, removing or disabling unneeded software and services, and enabling and configuring security measures.

For HIPAA covered entities and business associates (collectively, “regulated entities”), the HIPAA Security Rule requires ensuring the confidentiality, integrity, and availability of all electronic protected health information (ePHI) that the regulated entity creates, receives, maintains, or transmits.⁴ System hardening and creating security baselines (i.e., a set of standardized security controls and settings) for various types of electronic information systems (e.g., servers, virtual machines, smart phones, laptops, desktops) is one step regulated entities can take to help secure their ePHI. For medical devices, regulated entities should consult the labeling provided by their medical device manufacturers to understand the relevant device security information that may enable their own ongoing security posture, thereby helping ensure a device remains safe and effective throughout its lifecycle. Section VI.A (Labeling Recommendations for Devices with Cybersecurity Risks) of the FDA Guidance titled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” provides recommendations and examples of security information that may be included in labeling to communicate to users. These labeling recommendations as well as FDA recommendations regarding security risk management, security architecture and security testing are intended to help manufacturers meet their obligations under Section 524B (Ensuring Cybersecurity of Devices) of the Federal Food, Drug, and Cosmetic Act (FD&C Act). Additional information on cybersecurity requirements for medical devices is available https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity.

Patching Known Vulnerabilities

Whether a device⁵ is brand new or has been in use for a while, one of the first things to do to harden or secure it is ensuring that patches that address known vulnerabilities have been applied. Software that may need to be patched includes an information system’s operating system, as well as other software such as electronic health records, databases, web servers, mobile applications, and office and email software. Firmware, the low-level instructions that control device hardware, may also have known vulnerabilities that can be patched and thus should also be included in mitigation activities. Examples of firmware that may need to be patched could include firmware of network devices such as routers and firewalls. An up-to-date information technology (IT) asset inventory can help entities understand their environment and identify information systems to be hardened. OCR previously published a cybersecurity newsletter on the benefits of creating and maintaining an IT asset inventory.

The HIPAA Security Rule risk analysis provision requires regulated entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI⁶ – this includes risks and vulnerabilities to ePHI from unpatched software. There are various resources and methods available to help identify vulnerabilities, including:

• Signing up for vulnerability alerts from manufacturers and vendors;⁷
• Participating in an information sharing and analysis center (ISAC) or information sharing and analysis organization (ISAO);⁸
• Conducting vulnerability scans to detect vulnerabilities as well as missing patches and obsolete software;⁹ and
• Monitoring authoritative sources for vulnerabilities such as NIST’s National Vulnerability Database¹⁰ and CISA’s Known Exploited Vulnerabilities Catalog.¹¹

After assessing the potential risks and vulnerabilities to ePHI, the Security Rule risk management provision requires regulated entities to implement security measures to reduce risks and vulnerabilities to a reasonable and appropriate level.¹² Implementing a vulnerability management program is one method to identify and mitigate vulnerabilities in a timely manner. Often, vulnerabilities can be mitigated by applying patches. If a vulnerability has been newly discovered and a patch is unavailable, vendors may suggest actions to take to mitigate or reduce the risk of exploitation of the vulnerability. Regulated entities should apply patches or take other remedial actions as appropriate to reduce risks and vulnerabilities to a reasonable and appropriate level. Patching vulnerabilities is not a one-time event. Over time, new vulnerabilities may be identified in software that was already patched, in software that had previously not needed patching, or in the previously applied patches themselves. Thus, a system hardening process would include regular identification (through the risk analysis process) and mitigation (through the risk management process) of identified vulnerabilities.

Still, it may sometimes be the case that not all identified vulnerabilities can be mitigated by applying patches. A vulnerability may be relatively new such that patches are not yet available,¹³ or the vulnerability may exist on a legacy system¹⁴ for which a patch will not be available. In such cases, additional system hardening activities (discussed below) may help reduce the risks and vulnerabilities posed by such unpatched software.

Removing or Disabling Unneeded Software and Services

Many information systems, especially end-user systems such as desktop computers, laptops, and smart phones, may include software that has never been used but may contain serious vulnerabilities that could be exploited by an attacker. Such software could include, for example, games, messaging apps, social media, or utilities. Unneeded software may be included from the device manufacturer or added by a reseller or other vendor in the supply chain. Some of this software may be unnecessary because it is duplicative of the end-user’s organization’s preferred software solutions or may provide a function or service not needed (or wanted) by the organization. Nonetheless, such unneeded software can increase the number of potential vulnerabilities available for an attacker to exploit.

Most operating systems (e.g., Windows, MacOS, Android, iOS, Linux) include functions to view what software is installed and functionality for uninstalling such software. In addition to unwanted installed software, an operating system itself might include features or services that may be unsecure or not needed by an organization. For example, regulated entities may consider removing pre-installed online gaming and social media software and disabling or blocking unsecure uses of remote access and file transfer services such as RDP, telnet, and ftp. If unwanted features or services cannot be removed by an operating system tool or utility, they can usually be disabled using command line tools running as the administrator or root user.

Some software may use generic or service accounts that are created during the installation process. Such accounts may have the same permissions as a privileged user (e.g., administrator, root) and may also be installed with default passwords that are (or may become) widely known and thus are frequent targets for attackers. For example, various software and hardware products have administrator users using the default password “admin” or guest accounts with a simple password or even no password at all. In instances where default passwords are installed, regulated entities should consider changing such passwords to stronger ones that are unique to the regulated entity. In investigations, OCR has found well-known default passwords in use for various products such as databases, networking software, and anti-malware solutions. Even if default passwords of installed software accounts are changed, such accounts could present risks to the regulated entity if such accounts are never removed, even after the software that installed them has been removed. Therefore, after removing unneeded software, one should verify that accounts created by the removed software have also been removed. For example, an organization may use backup software that, as part of its installation, created a service account using a default password with elevated (i.e., administrator) privileges to facilitate backing up files across different computer systems. After a period of time, the organization switches to a new backup solution and uninstalls the old backup software. However, due to a failure in the uninstallation process, the service account installed by the old backup software is not removed. The organization may not realize that this privileged account remains on their system and could be exploited by an attacker or malicious insider especially if the default password was never changed and becomes widely known. 

Removing or disabling unneeded software and services is an important part of system hardening and reducing a system’s attack surface. These actions can also help reduce risk in instances where vulnerabilities are identified in software but cannot be patched. However, care should be taken when removing or disabling software to ensure that there are not unintended consequences as a result, such as adversely affecting the system’s stability, performance, or security posture. If possible, one should test what effect removing or disabling software has on a system’s operation in a development or test environment before performing such actions on production systems.¹⁵

Testing changes prior to implementing them in production is one way that can help regulated entities evaluate how such changes may affect ePHI. When environmental or operational changes are made that affect the security of ePHI, the Security Rule evaluation standard requires regulated entities to perform technical and non-technical evaluations of their security safeguards to demonstrate and document compliance with their policies and the requirements of the Security Rule.¹⁶¹⁷

Enabling and Configuring Security Measures

Another aspect of system hardening involves ensuring security measures are installed, enabled, and properly configured. This can involve enabling and configuring security measures already included as part of a device, operating system, or software as well as installing and configuring third-party security solutions such as, for example, anti-malware, endpoint detection and response (EDR), or security information and event management solutions (SIEM).

For regulated entities, security measures often found in operating systems, as well as some other software, intersect with some of the technical safeguard standards and implementation specifications of the HIPAA Security Rule, such as, for example, access controls,¹⁸ encryption,¹⁹ audit controls,²⁰ and authentication.²¹ A regulated entity’s risk analysis and risk management plan can inform its decisions regarding the implementation of these and other security measures. For example, a regulated entity’s risk analysis may determine that multi-factor authentication is required to sufficiently reduce the risk of unauthorized access to certain systems, but it is not available as an included authentication option for the target operating system or software, thus requiring installation and configuration of a third-party multi-factor authentication solution. OCR’s cybersecurity newsletter on HIPAA and Cybersecurity Authentication provides additional authentication examples and more detailed information.

Hardening a device’s operating system and other software may involve many configuration settings and additional security software choices. Establishing a security baseline, a set of standardized security controls and settings, as part of a regulated entity’s risk management efforts can be an efficient way to help secure devices and reduce risk. Various resources are available that can assist in understanding, choosing, and even applying security baselines, such as, for example:

• NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations
• Microsoft’s Security Baseline Guide (for Microsoft products)
• Department of Defense Security Technical Implementation Guides (STIGs)

Resources such as NIST’s SP 800-53 can provide an understanding of generalized security measures that can be applied to a regulated entity and its devices, such as the content of audit logs²²(control number AU-3) for monitoring unauthorized access or authenticator management²³ (control number IA-5) for establishing and managing authentication schemes (e.g., passwords, multi-factor authentication). Other resources, such as Microsoft’s security baseline packages and DoD’s STIGs, provide specific implementation details that can be applied to specific versions of various operating systems and applications, such as enabling Object Access audit recording of success or failure of access to removable media on Windows 11 systems or configuring syslog to monitor all remote access methods on Ubuntu 24.04 Linux systems.

If a regulated entity seeks to implement security baselines, whether creating its own or leveraging publicly available security baselines, it should do so in the context of its HIPAA risk analysis and risk management processes to ensure that risks to ePHI are identified and mitigated to a reasonable and appropriate level. Indeed, regulated entities leveraging publicly available security baselines should be encouraged to review and fully understand what they are implementing and tailor, if necessary, such baselines to meet their specific security needs and objectives.

Conclusion

System hardening and security baselines can be an effective means to enhance security, and for regulated entities to protect ePHI. However, defining, creating, and applying system hardening techniques is not a one-and-done exercise. Evaluating the ongoing effectiveness of implemented security measures is important to ensure such measures remain effective over time. As new threats and vulnerabilities evolve and are discovered, and attackers vary and improve their tactics, techniques, and procedures, regulated entities need to remain vigilant to ensure that their implemented security solutions remain effective. Indeed, for regulated entities, the periodic review and modification, as needed, of security measures implemented under the HIPAA Security Rule is a requirement to maintain protection of ePHI.²⁴

Additional Resources

OCR Cybersecurity Guidance Materials:

• https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity/index.html

HHS Security Risk Assessment (SRA) Tool:

• https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool

HHS 405(d) Cybersecurity Resources:

• https://405d.hhs.gov/

CISA Hardening Guidance for MSPs, and Small and Mid-sized Businesses:

• https://www.cisa.gov/sites/default/files/publications/CISA%20Insights_Guidance-for-MSPs-and-Small-and-Mid-sized-Businesses_S508C.pdf [PDF]

NIST SP 800-53B Control Baselines for Information Systems and Organizations:

• https://csrc.nist.rip/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53B_derived-OSCAL.pdf [PDF]

Lawrence Berkeley National Laboratory Cyber Security Awareness: Default Passwords:

• https://it.lbl.gov/cybersecurity-awareness-default-passwords/

* This document is not a final agency action, does not legally bind persons or entities outside the Federal government, and may be rescinded or modified in the Department’s discretion.

Endnotes

¹  An attack surface is the “collection of potential opportunities for an unauthorized user to gain access to a system or network.” See U.S. Cybersecurity and Infrastructure Security Agency. Project Upskill Glossary. Available at https://www.cisa.gov/resources-tools/resources/project-upskill-glossary.

²  A weakness is a “condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.” See National Institute of Standards and Technology. Glossary. Available at https://csrc.nist.gov/glossary/term/weakness.

³  "Vulnerabilities are flaws or weaknesses in a system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat event.” See Jeffery A. Marron (2024) Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule. 
A Cybersecurity Resource Guide. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-66, Rev. 2. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-66r2.pdf [PDF].

⁴  See 45 CFR 164.306(a)(1).

⁵  Hardening concepts can be applied to all types of devices, such as, for example, laptops, workstations, smart phones, servers, routers, and firewalls.

⁶  See 45 CFR 164.308(a)(1)(ii)(A).

⁷  Many technology vendors offer services to notify customers of security alerts for their products. For example, Microsoft and Apple can send security notifications to individuals that sign up to receive such alerts.

⁸  For example, the Health Information Sharing and Analysis Center (H-ISAC) provides members with situational awareness of cyber and physical security threats to the Health Sector so that organizations can detect, mitigate, and respond appropriately to ensure operational resilience.

⁹  Many vendors offer services to identify, and patch known vulnerabilities in their software. For example, Windows Update or Windows Server Update Services (WSUS) from Microsoft. Additionally, there are many vulnerability scan tools and services available to help organizations identify vulnerabilities in their electronic information systems and other electronic devices. For example, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) offers Cyber Hygiene Services that includes web application and vulnerability scanning.

¹⁰  The National Vulnerability Database is the U.S. government repository of standards-based vulnerability management data. See "National Vulnerability Database," National Institute of Standards and Technology, U.S. Department of Commerce, https://nvd.nist.gov.

¹¹  The Known Exploited Vulnerabilities Catalog is the authoritative source of vulnerabilities that have been exploited in the wild. See "Known Exploited Vulnerabilities Catalog," Cybersecurity & Infrastructure Security Agency, U.S. Department of Homeland Security, https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

¹²  See 45 CFR 164.308(a)(1)(ii)(B).

¹³  Vulnerabilities that are generally unknown are often referred to as zero-day vulnerabilities. See U.S. Department of Health and Human Services Office for Civil Rights. Spring 2019 OCR Cybersecurity Newsletter: Advanced Persistent Threats and Zero-Day Vulnerabilities. (Apr. 2019). Available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-spring-2019.

¹⁴  A legacy system is “an information system with one or more components that have been supplanted by newer technology and for which the manufacturer is no longer offering support.” See U.S. Department of Health and Human Services Office for Civil Rights. OCR Cybersecurity Newsletter: Securing Your Legacy [System Security]. (Oct. 2021). Available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-fall-2021.

¹⁵  Test environments should mimic production environments as much as is feasible for an organization. Some organizations may maintain duplicates of their production environments (i.e., test systems use the same hardware, software, and configurations as production) to ensure the accuracy of the impact of changes prior to implementing such changes in production. Other organizations may largely duplicate software while leveraging available older hardware for testing that may not exactly duplicate production, but still provides a basis for testing changes. Still other organizations may create, or refresh test systems periodically or as needed using virtual or cloud solutions.

¹⁶  See 45 CFR 164.308(a)(8).

¹⁷  See “Health Insurance Reform: Security Standards; Final Rule”, 68 Fed. Reg. 8334, 8351 (February 20, 2003).

¹⁸  See 45 CFR 164.312(a)(1).

¹⁹  See 45 CFR 164.312(a)(2)(iv), (e)(2)(ii).

²⁰  See 45 CFR 164.312(b).

²¹  See 45 CFR 164.312(d).

²²  The Security Rule’s audit controls standard requires that regulated entities “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use [ePHI].” See 45 CFR 164.312(b).

²³  The Security Rule’s person or entity authentication standard requires that regulated entities “implement procedures to verify that a person or entity seeking access to [ePHI] is the one claimed.” See 45 CFR 164.312(d).

²⁴  See 45 CFR 164.306(e).

A copy of this cybersecurity newsletter can be found on OCR website at: https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-january-2026/index.html.