On December 27, 2024, the HHS Office for Civil Rights (OCR) issued a Notice of Proposed Rulemaking to amend the HIPAA Security Rule for the first time in substantial form since 2013. The NPRM was published in the Federal Register on January 6, 2025 (90 FR 898) with a 60-day comment period closing March 7, 2025. OCR received approximately 4,500 public comments. The proposed amendments end the long-standing distinction between "required" and "addressable" implementation specifications, mandate encryption of ePHI at rest and in transit, require multi-factor authentication on all systems accessing ePHI, and impose semi-annual vulnerability scanning and annual penetration testing. For healthcare entities and their business associates, this is the most consequential change to HIPAA cybersecurity practice since the 2009 HITECH Act.
What does "removing addressable" actually mean?
Under the current Security Rule (45 CFR Part 164 Subpart C), implementation specifications are designated either "required" (must be implemented) or "addressable" (must be assessed; entities may implement an alternative if the original is not reasonable and appropriate). Of the 22 implementation specifications under the Technical Safeguards alone, 14 are addressable. The 2025 NPRM removes the addressable category. All specifications become required, subject to specific, narrow exceptions enumerated in the rule. The shift is significant. Encryption of ePHI, currently addressable under 164.312(a)(2)(iv) and 164.312(e)(2)(ii), becomes required with limited exceptions. Audit controls, currently addressable under 164.312(b), become required. The change forces implementation decisions that have, in practice, been deferred for two decades.
What encryption is specifically required?
The NPRM at 164.312(a)(2)(iv) and 164.312(e)(2)(ii) requires regulated entities to encrypt ePHI at rest and in transit using "a method that complies with the National Institute of Standards and Technology (NIST) approved encryption algorithms with key strengths of at least 256 bits." The proposed rule includes three narrow exceptions: (1) when the entity has documented that encryption is technically infeasible, with annual review; (2) during emergency access scenarios where the regulated entity has implemented a compensating control documented in policy; (3) certain limited research uses subject to IRB review. The infeasibility exception is the one that will be most contested. OCR's preamble cautions that legacy systems are not, by themselves, a basis for infeasibility.
How does the MFA requirement work?
Under proposed 164.312(d)(1), regulated entities must "deploy multifactor authentication for all technology assets in the relevant electronic information systems." The definition of "multifactor authentication" is given at proposed 164.304: authentication requiring two or more of (i) knowledge factor (password or PIN), (ii) possession factor (security token, smartphone), and (iii) inherence factor (biometric). The rule excludes SMS-based authentication from the possession factor, citing CISA and NIST guidance against SMS as a sole second factor for sensitive systems. Three exceptions are proposed: technology assets that cannot support MFA (must be documented and reviewed annually), break-glass emergency access (must be logged and reviewed within 24 hours), and specific FDA-regulated medical devices for which MFA would interfere with clinical workflow (subject to compensating controls).
# Proposed HIPAA technical safeguards summary (90 FR 898)
encryption:
at_rest: required # NIST-approved, >= 256-bit
in_transit: required
exceptions: [technical_infeasibility, emergency_access, irb_research]
mfa:
applicability: all_technology_assets
factor_combinations: [knowledge+possession, knowledge+inherence, possession+inherence]
excluded_factors: [sms_based]
vulnerability_management:
scanning_frequency: every_180_days_minimum
penetration_testing: annual_minimum
patch_management: required_with_documented_timeline
network_segmentation:
required_between: [ePHI_systems, non_ePHI_systems]
What about vulnerability scanning and penetration testing?
The NPRM at proposed 164.308(a)(7) creates a new implementation specification requiring "automated vulnerability scanning at least every 180 days" of all technology assets in the relevant electronic information systems, with documented remediation timelines. At proposed 164.308(a)(8), the rule requires "penetration testing of relevant electronic information systems at least once every 12 months" by qualified individuals not directly responsible for the systems being tested. Both requirements are net-new to HIPAA. The OCR preamble cites the 2024 Change Healthcare ransomware incident as supporting evidence that current "reasonable and appropriate" risk analyses have failed to drive sufficient practice.
What is the business associate impact?
Business associates are subject to the same Technical Safeguards as covered entities under 164.314. The NPRM extends this directly. A business associate's existing Business Associate Agreement (BAA) will need to be updated to reflect the new requirements, and the NPRM proposes that BAAs include explicit terms requiring the business associate to (a) certify annually that it meets the Security Rule requirements, (b) notify the covered entity within 24 hours of any activation of contingency plans, and (c) provide the covered entity with documentation upon request. The 24-hour contingency notification is the operational shock for cloud vendors, who currently rely on the existing 60-day breach notification timeline under the Breach Notification Rule (45 CFR 164.404) for most incident communications.
What is the timeline if the rule becomes final?
OCR's NPRM proposes that the final rule would be effective 60 days after publication and that the compliance date would be 180 days after the effective date. Combined, regulated entities would have approximately 240 days from publication to compliance, with no general extension authority. The final rule has not been published as of late 2025. Industry expectation is that OCR finalizes in the first half of 2026, with compliance required by late 2026 or early 2027. Business associates with multiple covered entity customers should not assume that one customer's grace period extends to others; each BAA carries independent compliance obligations.
How does this interact with the 405(d) Health Industry Cybersecurity Practices (HICP)?
The Cybersecurity Act of 2015 Section 405(d) directed HHS to publish voluntary cybersecurity practices for the health sector. The 405(d) HICP was updated in 2023 and revised in April 2024 to align with NIST CSF 2.0. The HIPAA NPRM at preamble Section II.B explicitly notes that adherence to the 405(d) HICP can serve as evidence of "recognized security practices" under 42 U.S.C. § 1320d-2 note, which OCR may consider as a mitigating factor in enforcement actions. The relationship is mutually reinforcing: implementing the HICP positions an entity to satisfy most of the NPRM's technical specifications, and documenting that implementation reduces enforcement risk.
How Safeguard Helps
Safeguard inventories every system processing ePHI and maps each against the proposed HIPAA Technical Safeguards: encryption-at-rest posture per database and bucket, MFA enforcement state per identity and asset, vulnerability scan freshness with the 180-day clock visible, and last penetration test date. Griffin AI generates the documented infeasibility exceptions the rule requires when legacy systems cannot meet encryption or MFA mandates, with the annual review schedule built in. SBOM-driven scanning surfaces components in clinical applications that have known CVEs, tied directly to the proposed 164.308(a)(7) vulnerability management timeline. For business associates managing multiple covered entity BAAs, the platform produces the annual certification artifact in a format each customer can ingest, and the 24-hour contingency-activation notification workflow that the proposed BAA terms require.