HIPAA Technical Safeguards: Proposed Updates Explained

The Department of Health and Human Services (the Department) published a notice of proposed rulemaking (NPRM) on January 6, 2025, to modify the HIPAA Security Rule. The Office of Management and Budget (OMB) currently lists a Final Action date of July 2027. This would provide regulated entities 240 days to comply with the updated requirements. The proposed expansion of 45 CFR 164.312 clarifies that regulated entities must implement and document technical safeguards. Maintenance requirements for specific safeguards require regulated entities to periodically test control effectiveness.

The purpose of this blog is to:

1. Describe the proposed technical safeguards within the HIPAA Security Rule
2. Provide a crosswalk to streamline a HIPAA Security Rule 2013-to-2027 gap analysis
3. This is a part of our HIPAA Security Rule series. See also our guides to the proposed administrative safeguards and physical safeguards.

Crosswalk of 2013 Technical Safeguards to 2027 Updates 

The table above highlights only a fraction of the proposed updates. To view the complete mapping of all Administrative, Technical, and Physical safeguards, download our full HIPAA Security Rule Crosswalk 2013 to 2027 Spreadsheet.

Access control §164.312(a)

The Department proposes modifying the access control standard to incorporate technical controls restricting system access to authorized users and technology assets. The modification goes beyond establishing a policy and procedure. Regulated entities must implement and verify the effectiveness of technical controls, which may include role-based access, user-based access, or other mechanisms deemed appropriate.

The Department proposes eight implementation specifications for the access control standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Unique identification §164.312(a)(2)(i)

The Department renamed the unique user identification implementation specification Unique identification. The proposed update expands the scope to include and technology assets in relevant systems. Unique identifiers enable regulated entities to track activities among all users, hardware, software, and devices.

IA-2 and IA-3 from NIST SP 800-53 support uniquely identifying users and technology assets. IA-4 establishes control over identifier management:

Manage system identifiers by: 

1. Receiving authorization from defined personnel to assign an individual, group, role, service, or device identifier; 
2. Selecting an identifier that identifies an individual, group, role, service, or device; 
3. Assigning the identifier to the intended individual, group, role, service, or device; and 
4. Preventing reuse of identifiers for a defined time period.

Common device identifiers include MAC addresses, IP addresses, or device-unique token identifiers. Typically, individual identifiers are the usernames of system accounts assigned to those individuals.

Administrative and increased access privileges §164.312(a)(2)(ii)

A new administrative and increased access privileges implementation specification separates user identities from privileged access identities. Limiting user access to necessary job functions reduces the risk of unauthorized access through identities with privileged access. 

AC-6(2) from NIST SP 800-53 supports this requirement. AC-6(2) requires users with access to security functions or relevant information to use non-privileged accounts or roles, when accessing nonsecurity functions. 

Emergency access procedure §164.312(a)(2)(iii)

The modified emergency access procedure implementation specification requires written technical procedures permitting an identified set of users to access ePHI during an emergency.

AC-2 of NIST SP 800-53 supports this requirement by enabling organizations to authorize emergency accounts. Emergency accounts are those established in response to crisis situations and with the need for rapid account activation and may bypass normal account authorization processes. Guidance from NIST SP 800-66r2 directs organizations to consider:

• Are there policies and procedures in place to provide appropriate access to ePHI in emergency situations?
• When should users activate emergency access procedures?
• Who is authorized to make the decision? 
• Who has assigned roles in the process?
• Will systems automatically default to settings and functionalities that will enable the emergency access procedure or will a system administrator or other authorized individual activate the procedure? 

Automatic logoff §164.312(a)(2)(iv)

The automatic logoff implementation specification requires terminating sessions after a predetermined period of inactivity. The proposed change replaces the language electronic procedures with technical controls.

The NIST National Online Informative References Program mapped this requirement to AC-12. 

Users initiate logical sessions when accessing organizational systems. AC-12 automatically terminates logical sessions after defined conditions or trigger events. Conditions or trigger events for session termination include defined periods of user inactivity.

Log-in attempts §164.312(a)(2)(v)

A new log-in attempts implementation specification elevates the passive log-in monitoring requirements. Technical controls must disable or suspend access to relevant systems after a defined number of unsuccessful authentication attempts. 

The first part of AC-7 from NIST SP 800-53 enforces an organization-defined limit of consecutive invalid logon attempts by a user during a defined time. This applies to local and network logons and may be enforced at the operating system and application levels.

The second part of AC-7 defines the enforcement action. Exceeding a defined number of unsuccessful attempts automatically executes one or more of the following actions:

• Lock the account or node for an organization-defined time period generally not permitted for high-impact or privileged accounts).
• Lock until released by an administrator 
• Delay the next logon prompt (rate limiting / exponential backoff).
• Notify the system administrator.
• Take other organization-defined actions, such as:
  
  • Prompting the user to answer a secret question in addition to the username and password (note: Pre-registered knowledge tokens now deprecated by NIST SP 800-63B)
  • Invoking a lockdown mode with limited user capabilities (instead of full lockout)
  • Allowing users to only log on from specified Internet Protocol (IP) addresses
  • Requiring a CAPTCHA to prevent automated attacks
  • Applying user profiles such as location, time of day, IP address, device, or Media Access Control (MAC) address.

Network segmentation §164.312(a)(2)(vi)

A new network segmentation implementation specification requires segmenting relevant systems in an appropriate manner. Physical or virtual division of a network into segments creates boundaries to reduce risks. This technical safeguard builds on several administrative safeguards, including mapping network configurations and conducting a risk analysis. 

NIST SP 800-160 presents two types of segmentation that can isolate critical system elements:

• Predefined segmentation - define enclaves, segments, or micro-segments to protect them separately. Examples include:
  
  • Use virtualization to maintain separate processing domains based on user privileges. 
  • Use cryptographic separation for maintenance. 
  • Partition applications from system functionality.
  • Isolate security functions from nonsecurity functions. 
  • Use physical separation (air gap) to isolate security tools and capabilities. 
  • Isolate components based on organizational missions or business functions. 
  • Separate subnets that connect to different security domains. In particular, provide a DMZ for Internet connectivity. 
  • Use cross-domain solutions to separate security domains. 
  • Employ system partitioning. 
  • Implement micro-segmentation using software agents. 
  • Employ process isolation. 
  • Implement sandboxes and other confined environments. 
  • Implement memory protection.
• Dynamic segmentation and isolation - Isolate resources dynamically to reduce transient risks. Examples include:
  
  • Implement dynamic isolation of components. 
  • Implement software-defined networking (SDN), network function virtualization (NFV), and VPNs to define new enclaves. 
  • Create a virtualized sandbox or detonation chamber for untrusted attachments or URLs. 

SC-7 from NIST SP 800-53 supports network segmentation through boundary protection:

1. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system; 
2. Implement subnetworks for publicly accessible system components that are physically or logically separated from internal organizational networks; and 
3. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture

SC-7(21) employs boundary protection mechanisms to isolate defined components.

AC-4 controls the flow of information based on defined information flow control policies. Enforcement occurs in boundary protection devices employing rule sets or establishing configuration settings that restrict system services.

Data controls §164.312(a)(2)(vii)

A new data controls implementation specification requires technical controls to restrict ePHI access. Restrictions are based on the entity’s policies and procedures specified in 45 CFR 164.308(a)(10)(ii)(B). Technical controls permit authorized users and technology assets to access relevant systems and disallows those that are not.

AC-3 from NIST SP 800-53 supports data controls by enforcing logical access to information in accordance with access control policies. Access control policies control access between active entities (i.e., users) and passive entities (i.e., ePHI). Organizations may enforce data controls at the system, application, and service level.

AC-3(7) enforces a role-based access control (RBAC) policy. RBAC controls access to objects based upon users authorized to defined roles.

IA-3 authenticates defined devices before establishing a local, remote, and or network connection. Organizational authenticate devices on local and wide area networks, including:

• Institute of Electrical and Electronics Engineers (IEEE) 802.1x 
• Extensible Authentication Protocol [EAP]
• RADIUS server with EAP-Transport Layer Security [TLS] authentication 
• Kerberos

Maintenance §164.312(a)(2)(viii)

A new maintenance implementation specification requires reviewing and testing access controls. Reviews should occur at least every 12 months and when there is a change in environment or operations that may affect ePHI.

AC-1 from NIST SP 800-53 supports this requirement by establishing a frequency to review and update access control policies and procedures. CA-2 supports this requirement by assessing the control implementation on a specified frequency.

Encryption and decryption §164.312(b)

The Department combined encryption and decryption implementation specifications from the access control and transmission security standards into a new standard. The new standard requires encrypting ePHI in a manner consistent with prevailing standards. Prevailing standards refers to widely accepted standards recommended by authoritative sources. The Department expects regulated entities to deploy updated solutions as standards evolve.

The Department proposes five implementation specifications for the encryption and decryption standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Encryption and decryption §164.312(b)(2)

The encryption and decryption implementation specification requires encrypting ePHI at rest and in transit. The Department's guidance considers ePHI at rest secure when encrypted in a manner consistent with NIST Special Publication 800-111. Valid encryption processes for data in transit are those which are FIPS 140-2 validated or comply, as appropriate, with:

• NIST Special Publication 800-52 (TLS) 
• NIST Special Publication 800-77 (IPsec VPNs); or 
• NIST Special Publication 800-113 (SSL VPNs)

The Department's essential CPG for Strong Encryption includes three relevant practices:

 4.M.C: Data Security 

• Encrypt data in rest 
  
  • When using the cloud-based services, enable native encryption capabilities. 
  • Ensure that full disk encryption is enabled on all workstations and laptops. 
  • Encrypt highly sensitive data stored in filesystem or within applications.
• Encrypt data in transit
  
  • Ensure that websites containing sensitive data use encrypted transport methods, such as HTTPS. 
  • Enable internal encryption methods when moving data in your organization. 
  • Never send unencrypted sensitive data outside your organization.

2.M.A Basic Endpoint Protection Controls

• Full disk encryption
  
  • Enable encryption on new endpoints acquired by your organization.
  • Connect encryption management to endpoint management systems interfacing with mobile and traditional operating systems. 
  • Develop metrics to monitor the status of encryption. 
  • Dispatch field services/desktop support teams to resolve encryption errors. 
  • Use anti-theft cable locks to lock down any device that cannot support encryption. 
  • Leverage NAC to conduct a validation check prior to enabling network access. 
  • Maintain audit trails of this encryption.

1.M.C Email Encryption

• Multiple email encryption techniques exist
  
  • Third-party applications conduct encryption by tagging outbound messages in some form (#encrypt, #confidential).
  • Fully encrypted, transparent email delivery provisioned between the two entities’ email systems. Each system requires TLS encryption when sending or receiving messages from the other.

The NIST OLIR program mapped the encryption requirements to three NIST SP 800-53 controls. SC-13 protects ePHI at rest, SC-8 and SC-12 protect ePHI in transit. 

SC-13: Cryptographic Protection 

1. Determine the defined cryptographic uses; and
2. Implement defined types of cryptography required for each specified cryptographic use.

Generally applicable cryptographic standards include FIPS-validated cryptography and NSA-approved cryptography. 

SC-8: Protect the confidentiality and integrity of transmitted information.

Protecting transmitted information applies to internal and external networks. Physical or logical means can protect the confidentiality and integrity of ePHI. Physical protection uses wireline or fiber-optics telecommunications that includes adequate physical controls. Logical protection can be achieved by employing encryption techniques. 

SC-12: Establish and manage cryptographic keys when employing cryptography within the system in accordance with defined requirements for key generation, distribution, storage, access, and destruction. 

The NIST Cryptographic Module Validation Program (CMVP) and NIST Cryptographic Algorithm Validation Program (CAVP) provide information on cryptographic modules and algorithms.

Exceptions §164.312(b)(3)

Exceptions apply only to ePHI directly affected by one or more of the following:

1. The technology asset in use does not support encryption consistent with prevailing standards. Regulated entities must establish and implement a written plan to migrate ePHI to assets that support encryption consistent with prevailing standards within an appropriate period of time. For example, it would be reasonable and appropriate to establish a plan to migrate ePHI on a single flash drive within 30 days.
2. An individual requests to receive their ePHI in an unencrypted manner. Regulated entities must inform the individual of the risks transmitting unencrypted ePHI. For example, information could be on a standard form, chart note, or checkbox. This exception would not apply when the individual would receive ePHI using technology controlled by the regulated entity.
3. When encryption is infeasible due to an emergency or other occurrence affecting the regulated entity's systems. Regulated entities must implement appropriate compensating controls based on their contingency plan. This exception would only apply for a limited time when encryption is infeasible.
4. The technology asset in use is a medical device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) authorized for marketing by the Food and Drug Administration (FDA), as follows:
   
   1. Pursuant to a submission received by FDA before March 29, 2023. Provided the regulated entity deploys any updates or patches recommended by the manufacturer in a timely manner.
   2. Pursuant to a submission received by the FDA on or after March 29, 2023. Where the device is no longer supported by its manufacturer, provided the regulated entity has deployed any updates or patches recommended by the manufacturer.
   3. Pursuant to a submission received by the FDA on or after March 29, 2023. Where the manufacturer still supports the device. The FDA considers security during the review of marketing submissions. The Department did not find it necessary to require encryption for devices authorized by the FDA on or after March 29, 2023 where the manufacturer still supports the device.

Alternative measures §164.312(b)(4)(i)

Regulated entities must document exceptions and implement compensating controls in real-time. Appropriate compensating controls for exceptions under paragraph (b)(3)(iv)(C) include security measures prescribed by the manufacturer. This includes any updates or patches recommended by the manufacturer of the device. The designated Security Official must approve compensating controls for any other exception and review the effectiveness of compensating controls at least every 12 months and in response to environmental or operational changes.

Compensating controls §164.312(b)(4)(ii)

Regulated entities should consider several factors when determining compensating controls. These factors include the nature of the exception, operating environment, and other circumstances. For example, limiting physical access to a device in combination with other controls may compensate for the absence of encryption.

Maintenance §164.312(b)(5)

A new maintenance implementation specification requires reviewing and testing encryption controls at least every 12 months. Control reviews and tests may also occur in response to environmental or operational changes. Regulated entities should modify technical encryption controls as appropriate.

Configuration Management §164.312(c)

A new configuration management standard requires establishing and maintaining security baselines. Regulated entities establish baselines for systems and technology assets. Risk analysis and consistent security settings help determine secure baselines.

The Department proposes five implementation specifications for the configuration management standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Anti-malware protection §164.312(c)(2)(i)

The Department proposed renaming protection from malicious software to anti-malware protection. Moving this implementation specification to the technical section aligns with the updated language requiring technology assets or technical controls. Anti-malware tools scan information systems to identify and quarantine malicious software. Endpoint detection and response (EDR) solutions automate rules-based responses based on real-time data.

NIST OLIR previously mapped AT-2 and AT-3 to this administrative requirement. SI-3 from NIST SP 800-53 supports this requirement as a technical control:

1. Implement signature based and/or non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code; 
2. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures; 
3. Configure malicious code protection mechanisms to: 
   
   1. Perform periodic scans of the at system defined frequency and real-time scans of files from external sources at endpoint and/or network entry and exit points as the files are downloaded, opened, or executed in accordance with organizational policy; and 
   2. Block malicious code and/or quarantine malicious code; or take defined action and send alert to defined personnel or roles in response to malicious code detection; and
4. Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system.

System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code may be present in commercial off-the-shelf software and custom-built software. It may be inserted into systems by email, web browsing, portable storage devices, or by exploiting system vulnerabilities.

Malicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection uses heuristics to detect characteristics of malicious code and reputation-based technologies. Nonsignature-based technologies protect against polymorphic code and signatures that do not exist yet.

Organizations determine actions to take in response to the detection of malicious code. Response actions may vary based on malicious code detections (periodic scans vs execution).

Software removal §164.312(c)(2)(ii)

A new software removal implementation specification requires removing extraneous software from relevant systems. Software is extraneous if it is unnecessary for the regulated entity's operations.

CM-7 and CM-7(5) from NIST SP 800-53 support this software removal requirement.

CM-7: Least Functionality

1. Configure the system to provide only defined mission essential capabilities; and 
2. Prohibit or restrict the use of defined functions, ports, protocols, software, and/or services

CM-7(5): Authorized Software - Allow-by-exception

1. Identify defined software programs authorized to execute on the system; 
2. Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and 
3. Review and update the list of authorized software programs defined frequency.

Authorized software programs can be limited to specific versions or from a specific source. Software programs may be decomposed and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries. Organizations may verify the integrity of software using digital signatures, cryptographic checksums, or hash functions. Verification of authorized software can occur either prior to execution or at system startup.

Configuration §164.312(c)(2)(iii)

A new configuration implementation specification would apply secure baselines. Regulated entities determine secure baselines based on their risk analysis. Continuously monitoring systems and technology assets identifies deviations from established baselines.

CM-2 from NIST SP 800-53 supports baseline configurations.

1. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and 
2. Review and update the baseline configuration of the system: 
   
   1. Defined frequency; 
   2. When required due to defined circumstances; and 
   3. When system components are installed or upgraded.

Baseline configurations apply to systems and system components. Configurations include connectivity, operational, and communications aspects. Organizations document, review, and approve baseline configurations to reflect the current enterprise architecture. Maintaining baseline configurations requires creating new baselines as systems change over time.

Network ports §164.312(c)(2)(iv)

The network ports implementation specification requires regulated entities to disable network ports in accordance with their risk analysis.

CM-7 from NIST SP 800-53 supports this network ports requirement.

CM-7: Least Functionality

3. Configure the system to provide only defined mission essential capabilities; and 
4. Prohibit or restrict the use of defined functions, ports, protocols, software, and/or services

Disabling unused or unnecessary physical and logical ports prevents unauthorized connections, transfers of information, and tunneling.

Maintenance §164.312(c)(2)(v)

A new maintenance implementation specification requires reviewing and testing configuration management controls at least every 12 months. Control reviews and tests may also occur in response to environmental or operational changes. Regulated entities should modify configuration management controls as appropriate.

Audit trails and system log controls §164.312(d)

The Department proposes renaming the audit controls standard audit trail and system log controls. The updated standard requires technology assets and/or technical controls to record system activity and monitor all activity in real-time to identify indications of unauthorized persons and activity. Indicators should alert defined workforce members in accordance with the response requirements with the information system activity review standard. The scope expands from information systems containing ePHI to relevant systems that could present a risk to ePHI.

NIST OLIR mapped the first eight Audit and Accountability (AU) controls to the previous audit control standard. While the updated standard still draws heavily on AU controls, the shift towards monitoring now incorporates System and Information Integrity (SI) controls as well. 

The Department proposes five implementation specifications for this updated standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Monitor and identify §164.312(d)(2)(i)

A new monitor and identify implementation specification requires technology assets and/or technical controls to monitor system activity. Real-time monitoring identifies indications of unauthorized activity as determined by the risk analysis. For example, regulated entities should identify activity indicating unauthorized access of a portable workstation. Technology assets and/or technical controls must also alert workforce members. Written information system activity review policies and procedures define this process.

AU-6 and AU-7 are still foundational but SI-4 and SI-4(2) support the new monitoring requirements. AU-6 defines frequencies to review audit records and personnel to report findings to. AU-7 provides an audit record reduction and report generation supports audit record reviews.

SI-4 incorporates monitoring devices to detect indicators of potential attacks and unauthorized use. SI-4(2) leverages automated tools to support near real-time analysis of events.

Record §164.312(d)(2)(ii)

A new record implementation specification requires recording all activity within relevant systems. Capturing real-time activity requires technology assets and/or technical controls.

AU-2, AU-3 and AU-8, AU-12 from NIST SP 800-53 support this implementation specification. AU-2 defines the types of logged events and AU-3 ensures those logs contain the content necessary to support the auditing function. AU-8 ensures internal system clocks generate synchronized time stamps with defined granularity. AU-12 generates audit records for event types defined in AU-2 and log content defined in AU-3.

Retain §164.312(d)(2)(iii)

A new retain implementation specification aligns audit record retention with the retention requirement.

AU-4, AU-5, AU-9 and AU-11 from NIST SP 800-53 support this implementation specification. AU-4 allocates audit log storage capacity to accommodate defined audit log retention requirements. AU-5 alerts defined personnel to take defined actions in the event of logging failures. AU-9 protects audit information and logging tools from unauthorized access, modification, and deletion. AU-11 retains audit records for defined time periods consistent with records retention policy.

Scope §164.312(d)(2)(iv)

A new scope implementation specification clarifies activity to monitor and record. In scope activities include creating, accessing, receiving, transmitting, modifying, copying, or deleting ePHI and relevant systems and the information therein.

AU-2 and AU-3 from NIST SP 800-53 support this implementation specification by defining the event types and content to log.

Maintenance §164.312(d)(2)(v)

A new maintenance implementation specification requires reviewing and testing technical controls from this section in response to environmental or operational changes, or at least every 12 months. Regulated entities should modify technology assets and/or technical controls as appropriate based on the results of that review.

AU-2(e) and CA-2 and from NIST SP 800-53 supports this implementation specification. Part e of AU-2 implements a periodic review of event types selected for logging. CA-2 defines a plan and frequency to assess control effectiveness.

Integrity §164.312(e)

The current standard for integrity requires policies and procedures to ensure integrity of ePH. The modified integrity standard requires technical controls to protect the integrity of ePHI. Integrity protection prevents improper alteration or destruction when at rest and in transit. The standard also requires reviewing and testing integrity controls at least every 12 months or in response to environmental or operational changes. Regulated entities should modify integrity controls as appropriate based on that review.

The Department proposes removing the mechanism to authenticate ePHI implementation specification. Technical controls to corroborate ePHI integrity commonly exist in hardware and protocols today.

NIST OLIR mapped several supporting controls for the current integrity standard. These included CP-9, MP-2, MP-5, SC-8, SI-1, and SI-7. NIST aligned SC-8 and SI-7 to the deprecated mechanism to authenticate ePHI implementation specification.

Authentication §164.312(f)

The Department proposed renaming the person or entity authentication standard authentication. The modified standard requires deploying technical controls to verify an entity’s identity. The subject of this standard has expanded to include a person or technology asset. The standard now covers access to ePHI as well as relevant information systems. 

The Department proposes five new implementation specifications for the authentication standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Information access management policies §164.312(f)(2)(i)

The Department proposed a new information access management policies implementation specification. This is the corresponding technical safeguard for the administrative requirement authentication management. Technical controls would enforce unique passwords consistent with current guidelines of authoritative sources. The Department does not propose defining authoritative sources or best practices. Regulated entities would need to change default passwords and prevent the sharing of passwords.

Many of the NIST OLIR mapped controls apply to this new implementation specification. IA-2, IA-3, IA-8, and IA-9 support authenticating various entities: 

• IA-2 - organizational users and processing acting on behalf of authorized users
• IA-3 - devices
• IA-8 - authenticates non-organizational users 
• IA-9 - authenticates defined system services and applications 

IA-5 and IA-5(1) support the requirements by enforcing unique passwords aligned with current recommendations of authoritative sources.

Multi-factor authentication §164.312(f)(2)(ii)

A new multi-factor authentication (MFA) implementation specification requires MFA on all technology assets. Regulated entities may deploy MFA in different ways to address the risk posed by each asset. For example, MFA enabled single sign-on (SSO) may allow access to local applications and cloud services. Regulated entities must also use MFA for any action that would change a user’s privileges. Modifying privileges may provide users with unauthorized access or the ability to remove security measures protecting ePHI.

IA-2(1) and IA-2(2) from NIST SP 800-53 support MFA requirements. IA-2(1) provides MFA for privileged accounts and IA-2(2) for non-privileged accounts. MFA requires the use of two or more different factors to achieve authentication. NIST defines the authentication factors as follows: 

• something you know (e.g., a password or personal identification number [PIN]), 
• something you have (e.g., a physical authenticator such as a cryptographic private key), or
• something you are (e.g., a biometric)

Regulated entities should deploy MFA in a manner consistent with its risk analysis. MFA may be applied at the system or application level, covering all types of access (i.e., local, network, remote).

Exceptions §164.312(f)(2)(iii)

Exceptions apply only to MFA deployments in any of the following circumstances:

1. A technology asset does not support MFA. The regulated entity must implement a written plan to migrate ePHI to an asset that supports MFA within an appropriate period of time.
2. During an emergency other occurrences in which MFA is infeasible. The regulated entity must implement compensating controls according to its emergency access procedures and contingency plan.
3. The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) authorized for marketing by the Food and Drug Administration, as follows:
   
   1. Pursuant to a submission received before March 29, 2023. Provided the regulated entity deploys any updates or patches recommended by the manufacturer.
   2. Pursuant to a submission received on or after March 29, 2023. Where the device is no longer supported by its manufacturer, provided the regulated entity deploys any updates or patches recommended by the manufacturer.
   3. Pursuant to a submission received on or after March 29, 2023. Where the manufacturer still supports the device.

Alternative measures §164.312(f)(2)(iv)

regulated entities must document applicable exceptions and implement compensating controls in real-time. Appropriate compensating controls for exceptions under (f)(2)(iii)(C)(3) include security measures prescribed by the manufacturer. This includes any updates or patches recommended by the manufacturer of the device. The designated Security Official must approve compensating controls for any other exception and review the effectiveness of compensating controls at least every 12 months and in response to environmental or operational changes.

Maintenance §164.312(f)(2)(iv)

A new maintenance implementation specification requires reviewing and testing MFA controls in response to environmental or operational changes, or at least every 12 months. Regulated entities should modify MFA controls as appropriate based on the results of that review.

CA-2 and from NIST SP 800-53 supports this implementation specification by defining a plan and frequency to assess control effectiveness.

Transmission security §164.312(g)

The Department proposes modifying the transmission security standard. The updated standard requires technical controls to guard against unauthorized access to ePHI transmitted over an electronic network. For example, regulated entities should use encryption, integrity message protection or trusted connections. Regulated entities must review and test the effectiveness of transmission security controls at least every 12 months or in response to environmental or operational changes.

The Department incorporated the integrity controls implementation specification into the transmissions security standard. The encryption implementation specification moved into the encryption and decryption standard.

NIST OLIR mapped SC-8 and SI-7 to the previous integrity controls implementation specification. SC-8 protects the confidentiality and integrity of transmitted information. SI-7 employs integrity verification tools to detect unauthorized changes to the defined software, firmware, and information.

Vulnerability management §164.312(h)

A new vulnerability management standard requires identifying technical vulnerabilities. Addressing vulnerabilities should be consistent with patch management policies and procedures. This standard aligns with the Cybersecurity Testing and Third Party Vulnerability Disclosure CPGs.

Vulnerability management activities should include all devices deployed on the regulated entity's network. This includes all medical devices and workstations within its relevant information systems. A regulated entity can identify technical vulnerabilities in multiple ways, including:

• Subscribing to CISA alerts and bulletins.
• Subscribing to alerts from the HHS Health Sector Cybersecurity Coordination Center.
• Participating in an
  
  • information sharing and analysis center (ISAC) or 
  • information sharing and analysis organization (ISAO).
• Implementing a vulnerability scanner to detect vulnerabilities. 
• Periodically conducting penetration tests to identify weaknesses.

CISA has compiled a list of cybersecurity services and tools to identify vulnerabilities. CISA's Cyber Hygiene Services include both vulnerability scanning and web application scanning.

Known vulnerabilities should be identified through monitoring of authoritative sources for known vulnerabilities. Patch management programs should define procedures for applying patches or implementing compensating controls. The vulnerability management standard verifies the effectiveness of the patch management program. Vulnerability scans and penetration testing identify missing patches or compensating controls.

The Department proposes four new implementation specifications for the vulnerability management standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Vulnerability scanning §164.312(h)(2)(i)

A new vulnerability scanning implementation specification requires automated scans to identify technical vulnerabilities. Vulnerability scans detect vulnerabilities such as obsolete software and missing patches. Regulated entities conduct vulnerability scans no less frequently than once every six months. Regulated entities must assess, prioritize, and mitigate identified vulnerabilities. Regulated entities must also review and test the effectiveness of vulnerability scans at least every 12 months or in response to environmental or operational changes.

RA-5 and from NIST SP 800-53 support this implementation specification:

1. Monitor and scan for vulnerabilities in the system and hosted applications at a defined frequency and/or randomly and after identifying new vulnerabilities 
2. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: 
   
   1. Enumerating platforms, software flaws, and improper configurations; 
   2. Formatting checklists and test procedures; and 
   3. Measuring vulnerability impact; 
3. Analyze vulnerability scan reports and results from vulnerability monitoring; 
4. Remediate legitimate vulnerabilities within defined response times in accordance with an organizational assessment of risk; 
5. Share information obtained from the vulnerability monitoring process and control assessments with defined personnel to help eliminate similar vulnerabilities in other systems; and 
6. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned.

Monitoring §164.312(h)(2)(ii)

A new monitoring implementation specification requires ongoing monitoring of authoritative sources for vulnerabilities. Regulated entities must remediate identified vulnerabilities based on their patch management program. The Department does not specify a time interval or specific sources. Authoritative sources include NIST’s National Vulnerability Database and CISA’s Known Exploited Vulnerabilities Catalog. CISA recently ended their Weekly Vulnerability Bulletin but one practitioner we follow provided drop-in free replacement.

SI-5 from NIST SP 800-53 supports this implementation specification. 

1. Receive system security alerts, advisories, and directives from defined external organizations on an ongoing basis;
2. Generate internal security alerts, advisories, and directives as deemed necessary;
3. Disseminate security alerts, advisories, and directives to defined personnel and/or elements within the organization
4. Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance

Penetration testing §164.312(h)(2)(iii)

A new implementation specification requires penetration testing at least every 12 months. Penetration tests identify vulnerabilities by mimicking real-word attacks. The proposal requires testing conducted by a qualified person. A qualified person has appropriate knowledge and experience with generally accepted cybersecurity principles. Qualified persons include those with “ethical hacking” or “offensive security” credentials.

CA-8 from NIST SP 800-53 supports this implementation specification by conducting penetration testing on a defined frequency for defined systems or components. 

Patch and update installation §164.312(h)(2)(iv)

A new patch and update installation implementation specification requires timely installation of software patches and critical updates. This is the technical implementation of the patch management program.

SI-2 from NIST SP 800-53 supports this implementation specification.

1. Identify, report, and correct system flaws; 
2. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation; 
3. Install security-relevant software and firmware updates within a defined time period of the release of the updates; and 
4. Incorporate flaw remediation into the organizational configuration management process.

Data backup and recovery §164.312(i)

A new data backup and recovery standard requires maintaining exact retrievable copies of ePHI. This change elevates the existing data backup and storage implementation specification to a standard. The Department removed the limitation that it applied before moving equipment. NIST directs regulated entities to consider the following questions regarding these activities:

• Is the frequency of backups appropriate for the environment? 
• Are backup logs reviewed and data restoration tests conducted? 
• Is at least one copy of the data backup stored offline?
• Are backups or images of operating systems, devices, software, and configuration files included?

The Department proposes four new implementation specifications for this standard. Regulated entities achieve the standard by satisfying the underlying implementation specifications.

Data backup §164.312(i)(2)(i)

The data backup implementation specification requires regulated entities to maintain accessible copies of ePHI. Data backups must be no more than 48 hours older than the ePHI maintained in their systems. This is the corresponding technical safeguard for the data backups administrative requirement.

The NIST OLIR program mapped the data backup plan to three NIST SP 800-53 controls. Two of these three controls  (CP-6 and CP-9) support this implementation specification:

CP-6: Alternate Storage Site

1. Establish an alternate storage site, including necessary agreements to permit the storage and retrieval of system backup information; and 
2. Ensure that the alternate storage site provides controls equivalent to that of the primary site.

CP-9: System Backup

1. Conduct backups of user-level information contained in defined system components at defined frequency; 
2. Conduct backups of system-level information contained in the system at defined frequency; 
3. Conduct backups of system documentation, including security- and privacy-related documentation at defined frequency; and 
4. Protect the confidentiality, integrity, and availability of backup information

CP-10 also supports the new recovery point objectives of the updated requirement. System reconstitution provides for the recovery of the system to a known state within a defined time consistent with recovery time and point objectives after a disruption, compromise, or failure.

Monitor and identify §164.312(i)(2)(ii)

A new monitor and identify implementation specification requires real-time monitoring, and alerting workforce members about ePHI backup failures and error conditions.

SI-4 and SI-4(2) support this implementation objective.

Part c of SI-4 uses internal monitoring capabilities strategically within the system to collect determined information. Part d of SI-4 analyzes detected events and anomalies and part g provides monitoring information to defined personnel as needed. 

SI-4(2) employs automated tools to support near real-time analysis of events. Host-based, network-based, transport-based, and storage-based event monitoring tools or security information and event management (SIEM) technologies can provide real-time analysis of alerts and notifications generated by organizational systems.

Record §164.312(i)(2)(iii)

A new record implementation specification requires regulated entities to record the success, failure, and any error conditions of required backups.

AU-2, AU-9 and CP-9 from NIST SP 800-53 support this implementation specification. 

Testing §164.312(i)(2)(iv)

A new implementation specification requires testing and documenting the effectiveness of its backups at least monthly. Regulated entities would be required to restore a sample of backed up ePHI and document the results. Tests should include verifying the ability to access ePHI from a remote location.

CP-9(1) from NIST SP 800-53 supports this implementation specification by testing backup information at a defined frequency to verify media reliability and information integrity.

Information systems backup and recovery §164.312(j)

A new information systems backup and recovery requires maintaining backups of relevant systems. This standard also requires reviewing and testing the effectiveness of backup and recovery controls at least every six months or in response to environmental or operational changes. This proposed standard reduces potential data gaps across relevant systems. The Department would not require regulated entities to test every relevant system. Regulated entities may review relevant log files and test a representative sample of relevant systems. 

CP-9 and CP-9(1) from NIST SP 800-53 support this implementation specification. 

Crosswalk Resource

We created this crosswalk resource by reading through each proposed standard and implementation specification. The Department often identified corresponding safeguards from the current Security Rule. We evaluated the nature of the relationship between the related concepts using the Supportive Relationship mapping style. This process determined whether supporting concepts from 2013 requirements satisfied the updated 2027 requirements. The resource contains the results of this analysis within the column H. Other supporting columns include:

Column A: 2027 HIPAA Security Rule Section identifier 

Column B: 2027 HIPAA Domain 

Column C: 2027 Standard 

Column D: 2027 Implementation Specification Name

Column E: 2027 HIPAA Implementation Specification Description

Column F: 2013 HIPAA Section identifier

Column G: 2013 HIPAA Requirement Description

Column H: NIST IR 8477 categorization of supporting relationships

‍

Conclusion

The proposed HIPAA Security Rule update would change how regulated entities approach technical safeguards. All the 2013 standards, including access control, audit controls, integrity, person or entity authentication, and transmission security remain in some form. The proposed rule adds a new standard for vulnerability management and elevates several implementation specifications as new technical standards. As the crosswalk shows, most 2013 provisions only partially satisfy their 2027 counterparts. The Department added considerable specificity to the technical section, with 36 implementation specifications describing 10 standards.

With OMB listing a final action date of July 2027 and a proposed 240-day compliance window, the time to start is now, not when the final rule is published. A practical first step is a gap analysis that maps your existing policies, procedures, and documentation to the proposed requirements, identifies what is missing or undocumented, and prioritizes remediation.

K2 GRC can help you get there. Our HIPAA Security Rule Crosswalk 2013 to 2027 Spreadsheet gives you a starting point, covering the Administrative, Technical, and Physical safeguards.

Within the K2 GRC platform, you can go further:

• The updated HIPAA Security Rule framework
• Built on the proposed changes
• Lets you crosswalk your existing 2013 requirements to the new ones in one place.
• Our HIPAA policy templates give you a head start on the written policies and procedures the proposed rule calls for, so you can close documentation gaps and set up the 12-month review cycle before the rule is final.

To get started, download the full crosswalk or contact K2 GRC to see how the platform can support your preparation.