The proposed 2025 HIPAA Security Rule update: mandatory MFA, encryption, and clinical AI.

What is the 2025 HIPAA Security Rule NPRM, and what would it change?

It is a proposed rule, published January 6, 2025, that would modernize the Security Rule and make most safeguards mandatory rather than addressable.

The HIPAA Security Rule 2025 update is formally a Notice of Proposed Rulemaking issued by HHS Office for Civil Rights and published in the Federal Register on January 6, 2025 under RIN 0945-AA22.^[1] OCR proposed the modernization because the environment in which health care is delivered has changed, breaches and cyberattacks against ePHI have risen sharply, and its own investigations surfaced recurring deficiencies in how covered entities and business associates implement the Security Rule.^[2] The most consequential change is structural: the proposal would remove the long-standing distinction between required and addressable implementation specifications, so nearly all of them would become required, subject only to specific, limited exceptions, and entities would have to keep written documentation of their policies, procedures, plans, and analyses.^{[2][3][7][15]} On top of that structural shift, the NPRM layers specific technical mandates that did not previously exist in explicit form, including MFA, encryption, a technology asset inventory, a network map, network segmentation, anti-malware protection, and regular testing.^[10][11] It is important to state plainly that this is a proposal. The comment period closed on March 7, 2025, OCR reported receiving thousands of public comments, and as of mid-2026 the agency has not published a final rule.^[6][14] Until it does, the current Security Rule governs, and the requirements and dates described in the NPRM may still change. RankShieldMD tracks the direction of the proposal and produces evidence that supports the audit and identity side of it, without making any claim that a health system is compliant with a rule that has not been finalized.

Would multi-factor authentication and encryption become mandatory?

Under the proposal, yes: both would become required with limited exceptions, as the addressable versus required distinction is removed.

The single clearest effect of removing the addressable versus required distinction is on MFA and encryption, the two controls organizations most often treated as addressable under the current rule.^[2] The NPRM would require multi-factor authentication across systems that access electronic protected health information, and it would require encryption of ePHI both at rest and in transit, each subject to narrow, documented exceptions rather than the current framework that lets an entity decline a control if it documents an equivalent alternative or a reason it is not reasonable and appropriate.^[2][3] In practical terms that converts two safeguards from optional-with-paperwork into baseline obligations. Legal analyses of the proposal consistently list mandatory MFA and mandatory encryption of ePHI at rest and in transit among the headline changes, precisely because they represent the biggest departure from current practice for many organizations.^[3][4][9] The NPRM does allow narrow exceptions, including for certain legacy systems and for devices approved by the FDA before March 2023, which is why the mandate is best read as required-with-limited-exceptions rather than absolute.^[9] The essential caveat is that none of this is in force. The proposal has not been finalized, so the existing Security Rule and its addressable model still control, and any organization implementing MFA and encryption today is getting ahead of the proposal rather than complying with a mandate that exists. RankShieldMD is deliberately not an MFA or encryption product, and it does not encrypt your ePHI. What it does is bind a verified actor identity to every access under RFC 9421 and seal a tamper-evident record of it, so the identity and integrity of each access are provable alongside the MFA and encryption controls your own systems enforce. See healthcare identity for how verified actors complement authentication.

What new documentation would the rule require, from asset inventory to audit?

A technology asset inventory, a network map, and regular audit, scanning, and testing, most on defined cadences, all documented in writing.

Beyond MFA and encryption, the proposed rule introduces a set of documentation and testing obligations with explicit intervals, which is a meaningful change from the current rule's more open-ended language.^[2] The NPRM would require a technology asset inventory and a network map that illustrates how ePHI moves through the regulated entity's electronic information systems, reviewed and updated at least once every 12 months and whenever the environment or operations change in a way that affects ePHI.^[2][8] It would require regular audits of Security Rule compliance at least once every 12 months, vulnerability scanning at least every six months, and penetration testing at least once every 12 months, along with incident response plans that are tested and revised on a 12-month cadence.^[3][4][9] The proposal also tightens operational timelines elsewhere, including restoration of certain critical systems within 72 hours and notification to affected parties within 24 hours of an event affecting electronic information systems, and it adds network segmentation, anti-malware protection, and removal of unsupported software to the baseline.^[9][10] On the vendor side it would require covered entities to obtain written documentation from business associates verifying required technical safeguards.^[4][5] Each of these cadences is drawn from the NPRM and is proposed, not final, so treat them as the shape of where the rule may go rather than as current obligations. RankShieldMD does not build your asset inventory, draw your network map, or run your penetration tests. It produces the tamper-evident, PHI-free record that supports the audit and activity-review dimension of these requirements, so that when a review happens, the evidence of who did what to ePHI is verifiable rather than asserted. Our clinical-AI audit trail explainer covers that evidence layer in depth.

What does the proposed rule mean for clinical AI and AI vendors handling ePHI?

AI systems that touch ePHI fall inside the Security Rule, and the proposal would strengthen the controls, audit expectations, and business-associate verification around them.

Clinical AI does not sit outside HIPAA. When an AI system reads charts, drafts orders, or otherwise processes electronic protected health information, it is operating inside the systems the Security Rule governs, and the proposed changes would apply to that path with full force.^[2] If the NPRM is finalized, MFA would be required on the systems that grant AI access to ePHI, encryption would apply to the ePHI those systems move, and a technology asset inventory would reasonably need to account for AI components in the environment.^[3] The audit and activity-review expectations would tighten the requirement to record and examine what happens to ePHI, which now includes what an AI model did, not only what a human did. Just as importantly for the many AI capabilities delivered by vendors, the proposal would require covered entities to obtain annual written verification that their business associates have implemented the required technical safeguards, a provision that reaches AI vendors operating as business associates and puts new weight on business associate agreements.^[5][11] This is the part of the proposal where a PHI-free evidence layer is most useful. RankShieldMD seals a tamper-evident record of every access, human or AI, carrying a verified actor identity, the action, and a one-way digest of the patient reference, so that the who-did-what-to-ePHI record an audit review expects can include AI inferences and can be independently verified. It supports the audit-controls direction the proposal would strengthen. It is proposed, not final, RankShieldMD is PHI-free and non-device, and it does not make an AI vendor or a health system HIPAA compliant. For the provenance angle on AI outputs, see clinical AI provenance.

How can a health system get ahead of the rule with verifiable, PHI-free evidence?

By implementing MFA and encryption now, keeping a current inventory and map, and putting tamper-evident, PHI-free audit trails behind every human and AI access.

Even though the rule is not final, its direction is stable enough to act on, because it points where healthcare security has been heading regardless: verified identity, encryption everywhere, current asset visibility, and audit evidence that can withstand scrutiny.^[2] A health system that wants to get ahead can implement MFA and encryption on ePHI systems now rather than waiting, maintain a technology asset inventory and network map on a rolling basis, run vulnerability scanning and penetration testing on a defined cadence, and put tamper-evident audit trails behind both human and AI access to ePHI.^[3][4] Acting early also hedges against uncertainty in the rulemaking itself: more than 100 hospital systems and provider associations have urged HHS to withdraw or heavily revise the proposal on cost and timeline grounds, so the final text and deadlines remain genuinely unsettled.^[12][13] The last of those readiness steps is where RankShieldMD contributes. It binds a verified actor identity to every access under RFC 9421, then seals a PHI-free, tamper-evident record of that access to an append-only log an auditor can independently verify, without RankShieldMD ever holding names, MRNs, or other identifiers.^[1] That gives an activity review or an OCR inquiry a record of who did what to ePHI that cannot be silently rewritten, and it does so without adding another concentrated store of protected data to defend. RankShieldMD is not an MFA product and not an encryption product; it provides the verified-actor and tamper-evident-audit layer that complements MFA and encryption. The honest boundary is firm: this is a readiness aid built on a proposed rule, it is not legal advice, and no software by itself makes an organization HIPAA compliant. RankShieldMD produces evidence that supports HIPAA compliance; it does not guarantee it. See our security overview and HIPAA compliance software for how the evidence layer fits a broader program.

Where each safeguard stands today, and where the proposal would move it. Proposed, not final.

Check the controls the proposed rule would make mandatory. Your score updates as you go. Proposed, not final.

References

1. [1] Federal Register (Jan 6, 2025). HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM, RIN 0945-AA22). federalregister.gov/documents/2025/01/06/2024-30983
2. [2] HHS Office for Civil Rights. HIPAA Security Rule NPRM to Strengthen Cybersecurity for ePHI: fact sheet. hhs.gov/hipaa/…/hipaa-security-rule-nprm/factsheet
3. [3] Paul Hastings LLP. HHS OCR Releases Proposed Updates to HIPAA Security Rule. paulhastings.com/insights/ph-privacy/…hipaa-security-rule
4. [4] Buchalter. Significant New HIPAA Obligations On Their Way For 2025. buchalter.com/insights/significant-new-hipaa-obligations…
5. [5] HIPAA Journal. The Impact of Proposed Changes to the HIPAA Security Rule for Business Associates. hipaajournal.com/hipaa-security-rule-business-associates
6. [6] HIPAA Journal. OCR Update on the Proposed HIPAA Security Rule and current status (proposed, not final). hipaajournal.com/ocr-gives-update-on-proposed-hipaa-security-rule
7. [7] McDermott Will & Schulte. HHS OCR Proposes Significant Modifications to HIPAA Security Rule. mcdermottlaw.com/insights/hhs-ocr-proposes-significant-modifications…
8. [8] Compliancy Group. The Proposed HIPAA Security Rule Update: What It Would Change and How to Prepare. compliancy-group.com/proposed-hipaa-security-rule-update-2026
9. [9] Bradley. Top 10 Takeaways From the New HIPAA Security Rule NPRM (MFA on all assets, network segmentation, anti-malware, 72-hour restoration, 24-hour notification). bradley.com/insights/publications/2025/03/top-10-takeaways…
10. [10] Avertium. HIPAA Notice of Proposed Rulemaking: A New Era of Healthcare Cybersecurity & Compliance. avertium.com/blog/hipaa-notice-of-proposed-rulemaking…
11. [11] MetricStream. 2025 HIPAA Updates: Key Changes Every Organization Must Know. metricstream.com/blog/hipaa-updates-2025-key-changes
12. [12] HIPAA Journal. Over 100 Hospital Systems and Provider Associations Call for Withdrawal of Proposed HIPAA Security Rule Update. hipaajournal.com/hospitals-provider-associations-withdrawl…
13. [13] TechTarget. Providers Urge HHS to Scrap Proposed HIPAA Security Rule Updates. techtarget.com/healthtechsecurity/…/Providers-urge-HHS-to-scrap…
14. [14] Triage Health Law. HHS Publishes NPRM to Amend HIPAA Security Rule Requirements, Comments Due March 7, 2025. triagehealthlawblog.com/hipaa/hhs-publishes-notice-of-proposed-rulemaking…
15. [15] Buchanan Ingersoll & Rooney PC. A Fresh Look at HIPAA's Security Rule: What to Expect From HHS' Notice of Proposed Rulemaking. bipc.com/a-fresh-look-at-hipaa-security-rule…

The January 6, 2025 HIPAA Security Rule NPRM is proposed, not final. RankShieldMD produces evidence that supports HIPAA compliance; it is not legal advice and does not make an organization HIPAA compliant.