When Does the New HIPAA Security Rule Take Effect?

It has not taken effect. As of August 2026, the Federal Register's own record for this rulemaking, RIN 0945-AA22, contains exactly one document: the notice of proposed rulemaking HHS published on January 6, 2025 at 90 FR 898, whose comment period closed on March 7, 2025. No final rule has published. Nothing in the proposal is enforceable against you today, and the rule that binds you is the Security Rule as it has stood since 2003, at 45 CFR 164.302 through 164.318. If a vendor has told you that MFA is now mandatory under HIPAA, they are describing a proposal as though it were law.

We are not going to give you a date, because nobody outside HHS has one, and the pages that print a date are guessing. What follows is how to check the status yourself in about a minute, what the proposal says on the record, and the part that matters more: what the current rule already requires from you while everyone waits.

Key takeaways

• It has not taken effect. As of August 2026 the Federal Register record for RIN 0945-AA22 holds one document: the January 6, 2025 proposal at 90 FR 898.
• Nothing in the proposal is enforceable against you. The rule that binds you is the Security Rule as it has stood since 2003, at 45 CFR 164.302 through 164.318.
• The proposal states a compliance date of 180 days after the effective date of a final rule, so the runway starts when a final rule takes effect, not when it publishes, and not now.
• "Addressable" has never meant optional. It gives you three lawful options: implement it, document why it is not reasonable and appropriate and implement an equivalent alternative, or document why neither is.
• The work worth doing does not depend on the rulemaking: get the risk analysis right, build the asset inventory and ePHI data-flow map, and close the addressable items you cannot justify skipping.

How to check the status yourself, in one minute

This is worth learning, because it makes you independent of articles like this one, including this one.

Go to federalregister.gov and search the regulation identifier number, 0945-AA22. Every document HHS publishes under that rulemaking appears there, in order, with its type. A proposed rule is labeled Proposed Rule. A final rule is labeled Rule. Today the search returns one result, the January 6, 2025 proposal, spanning pages 898 to 1022 of volume 90.

Two things follow. First, if that search ever returns a second document typed as a Rule, the overhaul is real and the clock has started. Second, until it does, any date you read anywhere is a forecast. Trade press forecasts have already been wrong once on this rulemaking, and a healthcare compliance program built on a forecast has to be rebuilt when the forecast moves.

Bookmark the search. Check it quarterly. That is the entire freshness process, and it costs you four minutes a year.

What the proposal actually says, on the record

The NPRM's own abstract describes it as a proposal to modify the Security Standards for the Protection of Electronic Protected Health Information under HIPAA and the HITECH Act, motivated by changes in how care is delivered, significant increases in breaches and cyberattacks, common deficiencies the Office for Civil Rights has observed in its Security Rule investigations, other cybersecurity guidance and practice, and court decisions affecting enforcement.

Three specifics are worth quoting because they are the ones that change how a health tech company would budget.

Encryption becomes an express requirement. The Department writes that "By expressly requiring regulated entities to encrypt ePHI, with limited exceptions, the Department's proposal would reflect our expectations in the current cybersecurity environment." Read that sentence carefully: HHS is saying the expectation already exists and the proposal makes it explicit. That is a much better guide to how OCR behaves in an investigation today than the word "addressable" is.

Asset inventory and data-flow mapping move into the risk analysis. The proposal would require a regulated entity to inventory its technology assets and map the movement of ePHI through its information systems, as an input to the risk analysis rather than as a separate nicety.

The compliance date is proposed as 180 days after the effective date of a final rule. In the Department's words, it "proposes to apply the standard compliance date of 180 days after the effective date of a final rule." So the runway starts when a final rule takes effect, not when it publishes, and not now.

The proposal runs from page 898 to page 1022 of volume 90, and its section-by-section analysis is where the detailed technical proposals live, including the security testing and authentication provisions that generated most of the commentary. We are not going to summarize cadences we have not read in the operative text, because a wrong number in a compliance article is worse than no number. If you need the detail, the section-by-section analysis is the part to read, and it is linked above.

What the current rule requires, which is more than most teams think

Here is the part that makes the waiting question mostly moot. The Security Rule in force today is not vague, and its structure is regularly misread.

Every standard in the Security Rule is required. There is no such thing as an optional standard. What varies is the treatment of the implementation specifications underneath each standard, and each one is labeled either Required or Addressable in the regulation text itself.

Under 45 CFR 164.308, the administrative safeguards, these implementation specifications are Required: risk analysis, risk management, sanction policy, and information system activity review (all under the security management process), isolating health care clearinghouse functions, response and reporting under security incident procedures, and the data backup plan, disaster recovery plan and emergency mode operation plan under contingency planning. Assigned security responsibility and evaluation are standards with no implementation specifications, which means they are simply required. The addressable ones include authorization and supervision, workforce clearance, termination procedures, access authorization, access establishment and modification, the four security awareness items, contingency plan testing, and applications and data criticality analysis.

Under 45 CFR 164.312, the technical safeguards, unique user identification and emergency access procedure are Required. Automatic logoff, encryption and decryption, the mechanism to authenticate ePHI, transmission integrity controls and transmission encryption are Addressable. Audit controls and person or entity authentication are standards, so they are required outright.

Under 45 CFR 164.310, the physical safeguards, disposal and media re-use are Required; the four facility access control specifications, accountability and data backup and storage are Addressable.

"Addressable" does not mean optional, and OCR has never treated it that way

This is the single most expensive misreading in healthcare compliance, and it is why the proposed removal of the category is less consequential than it sounds.

An addressable implementation specification gives you exactly three lawful options. Implement it. Or document why it is not reasonable and appropriate in your environment and implement an equivalent alternative measure. Or document why it is not reasonable and appropriate and why no alternative is either. What you may not do is skip it silently, which is what "addressable" gets treated as in practice.

For a cloud-native health tech company in 2026, the analysis is short. Encryption of ePHI at rest and in transit is technically available, operationally routine, and cheap. There is no defensible write-up that says it is not reasonable and appropriate for you. The category buys you nothing except an obligation to write the memo, and the memo will say yes. That is exactly why HHS wrote, in the passage quoted above, that making encryption express would reflect its existing expectations.

The practical consequence: if you are unencrypted today and telling yourself the proposal is what will force your hand, you have misread your current obligations, not your future ones.

What we would actually do while the rulemaking sits

Three pieces of work, in this order, none of which depends on the rule finalizing.

Get the risk analysis right. It is a Required implementation specification, it is the finding OCR cites most often, and a superficial one is worse than an honest one because it documents that you looked and did not see. Our HIPAA compliance checklist for health tech walks the full safeguard set if you are starting from scratch.

Build the asset inventory and the ePHI data-flow map now. The proposal would require them, but that is not the argument. The argument is that you cannot do a real risk analysis without knowing where ePHI lives and how it moves, so most teams that skip the inventory produce a risk analysis that is really a policy review.

Close the addressable items you cannot justify skipping. Encryption, automatic logoff, transmission security. Then write the memo for the ones you genuinely decline, with the alternative measure named.

Where Top Floor fits, and where we do not

We do HIPAA readiness, risk analysis, and the ongoing program work under our HIPAA practice and Compliance as a Service. Where a company needs the security leadership rather than the assessment, that is vCISO work.

Where we would tell you not to hire anyone: if your only reason for calling is the proposed rule, wait. There is nothing to remediate against, there is no deadline, and a readiness assessment against a proposal is a readiness assessment against a moving target. Call when a customer contract, an enterprise security questionnaire, a funding diligence process, or an honest look at your current risk analysis gives you a real reason. Those reasons exist today for most health tech companies, and none of them require a final rule.

How to decide this week

Search RIN 0945-AA22 on federalregister.gov and see the record for yourself. Two minutes.

Then open your last risk analysis and check the date on it. If it is older than a year, or if it does not name the systems where ePHI actually lives, that is your project, and it is your project whether or not the Security Rule changes.

Then take the addressable list above and mark each item implemented, alternative in place, or nothing. Any item in the third column needs either a control or a memo before your next audit, questionnaire, or incident.

Frequently asked questions

Has the new HIPAA Security Rule taken effect?

No. As of August 2026, the Federal Register record for RIN 0945-AA22 contains one document: the notice of proposed rulemaking HHS published on January 6, 2025 at 90 FR 898, with a comment period that closed on March 7, 2025. No final rule has published, so nothing in the proposal is enforceable. The Security Rule in force is the one at 45 CFR 164.302 through 164.318.

When will the final HIPAA Security Rule be published?

Nobody outside HHS knows, and we will not print a guess. The reliable check takes a minute: search the regulation identifier number 0945-AA22 on federalregister.gov. If the results ever include a document typed as a Rule rather than a Proposed Rule, the overhaul has been finalized. Until then, any date you read is a forecast, and forecasts on this rulemaking have already moved once.

How long would we have to comply after a final rule?

The proposal states that the Department proposes to apply the standard compliance date of 180 days after the effective date of a final rule. Two clocks matter there, not one: a final rule has an effective date some period after publication, and the compliance date as proposed would run 180 days from that effective date. So the runway would begin when a final rule takes effect, not on the day it publishes.

Does HIPAA require multi-factor authentication today?

Not by name. The technical safeguards at 45 CFR 164.312 require unique user identification and an emergency access procedure, and they make automatic logoff and encryption addressable implementation specifications. MFA is not named in the current rule text. It is, however, expected in practice by enterprise customers, cyber insurers, and OCR investigators looking at whether your access controls were reasonable and appropriate, so treating it as optional because the rule does not name it is a bad trade.

Is encryption required under HIPAA or not?

Encryption and decryption is an addressable implementation specification under 45 CFR 164.312(a), and transmission encryption is addressable under 164.312(e). Addressable does not mean optional. It means you implement it, or you document why it is not reasonable and appropriate and implement an equivalent alternative, or you document why neither is. For a modern cloud environment there is no credible write-up that declines encryption, which is why HHS said in the proposal that expressly requiring it would reflect the Department's existing expectations.