If a managed IT provider is pitching your practice or health system on urgent "2026 HIPAA readiness," the pitch has a dating problem. HHS has delayed final action on its overhaul of the HIPAA Security Rule until at least July 2027, and the rulemaking's status on the federal tracking site shifted from "final rule stage" to long-term actions — the bureaucratic signal that a final version is well over a year out, not weeks. Any deadline-driven urgency built around a 2026 compliance date is selling against a schedule that no longer exists.
That does not make the underlying work worthless. It makes the framing a useful diagnostic. A provider who tracks their own regulatory claims accurately is demonstrating something about how they'll handle your environment; a provider still running last year's deck is demonstrating something too.
What Actually Happened to the Rule
HHS's Office for Civil Rights issued the Notice of Proposed Rulemaking on December 27, 2024, published in the Federal Register on January 6, 2025. The comment period closed March 7, 2025, drawing more than 4,000 stakeholder comments. It would be the first substantial update to the Security Rule since 2013. The target for final action was May 2026; that has now moved to at least July 2027, with OCR continuing to work through the comment volume.
Two clarifications matter more than the date itself. First, the existing Security Rule remains fully in effect and enforceable — the delay concerns the replacement, not the incumbent. Nothing about your current obligations changed. Second, HHS is moving ahead separately on a HIPAA Privacy Rule update; a provider conflating that with the Security Rule overhaul is describing two different rulemakings as one.
Why the proposal still matters to your roadmap
The proposed rule is directionally significant even at long-term-actions status, because its central move is structural: eliminating the "addressable" safeguard category. Under the current rule, a covered entity can document a reasoned decision not to implement an addressable specification. The proposal converts a set of those into requirements. As proposed, that includes mandatory encryption of ePHI at rest and in transit with limited documented exceptions, mandatory multi-factor authentication for systems housing ePHI, a technology asset inventory and a network map of ePHI flows reviewed at least every 12 months, an explicit annual risk-analysis cadence, audit logging, penetration testing, and verification of business associate safeguards rather than reliance on a signed agreement alone.
Every one of those is a security practice a healthcare organization arguably should have regardless of whether a rule compels it. That is precisely why the delay should change your urgency and your sequencing, not whether you do the work. Which brings us to how to read a vendor pitch.
Seven Questions for an MSP Selling HIPAA Readiness
1. "What is the current status of the Security Rule NPRM?"
The correct answer names the July 2027 delay and, ideally, the shift to long-term actions. An MSP that says "the new rule takes effect in 2026" is either not tracking the rulemaking or is knowingly using a stale deadline as a closing tool. Both are disqualifying for a compliance-adjacent engagement — you are hiring them partly for regulatory awareness.
2. "Which of these are current obligations and which are proposed?"
Hand them the list — encryption, MFA, asset inventory, annual risk analysis, penetration testing, business associate verification — and ask them to sort it. A capable provider distinguishes cleanly: risk analysis is a longstanding requirement under the current rule; mandatory MFA and mandatory encryption without the addressable escape hatch are proposed changes. A provider who cannot separate current from proposed cannot tell you what you are actually exposed on today.
3. "What are we non-compliant with right now, under the rule as it exists?"
This reframes the conversation onto the enforceable standard. Current-rule gaps — a risk analysis that was never completed or is years stale, missing audit controls, no documented decisions on addressable specifications — carry real enforcement exposure today. OCR enforcement activity has consistently centered on missing or inadequate risk analyses. A provider whose gap assessment is entirely about future requirements is skipping your actual liability.
4. "Are you a business associate under this arrangement, and will you sign a BAA?"
An MSP that creates, receives, maintains, or transmits ePHI on your behalf is a business associate and must execute a business associate agreement. This is not negotiable and not a formality. Hesitation, or an attempt to characterize their access as incidental when their tooling reaches ePHI-hosting systems, is the most serious red flag on this list. Our guide to HIPAA and IT services covers the boundary in more detail.
5. "How would you satisfy business associate verification if it becomes mandatory?"
The proposal would require covered entities to verify that business associates have implemented required safeguards, rather than accept a signed BAA as sufficient. Ask what evidence they could produce today — a current SOC 2 Type II report, a completed HIPAA security assessment, penetration test results with remediation tracking. An MSP whose only artifact is the BAA itself will be a compliance problem for you under the proposed regime, and is a weaker vendor under the current one. See SOC 2 Type I vs Type II for why the distinction between the two reports matters here.
6. "Can you produce an ePHI network map for our environment?"
This is the question that separates providers who understand your environment from providers who monitor it. The proposed asset inventory and ePHI-flow mapping requirement is operationally demanding precisely because ePHI in a real practice moves through email, imaging systems, billing platforms, cloud storage, backups, and vendor integrations in ways nobody has ever fully documented. An MSP that can scope this work credibly — and tell you where it expects to find surprises — is doing security engineering. One that treats it as a checkbox has not tried it.
7. "What in this proposal would change your own architecture?"
A provider with real exposure to the proposed rule should be able to name something: MFA enforcement on their own privileged access paths, encryption of ePHI-containing backups they hold, log retention changes. An MSP who says nothing would change for them is claiming either an unusually mature posture — ask for the evidence — or has not thought about their own side of the boundary.
What to Actually Do With the Extra Time
The delay is a genuine opportunity if you sequence by enforcement risk rather than by proposal urgency.
Fix current-rule gaps first. A current, thorough, documented risk analysis is the highest-value compliance artifact you can hold, because it is both a longstanding requirement and the foundation for everything the proposal would add. If yours is stale or nonexistent, that is today's exposure, not 2027's.
Then do the durable work from the proposal. MFA on ePHI-accessing systems, encryption at rest and in transit, and an asset inventory with ePHI flow mapping are worth doing on their own merits and are the least likely elements to disappear from a final rule — they are broadly consistent with where every other security framework has landed. Spending 2026 on those is not speculative compliance; it is closing the gaps a ransomware incident would exploit.
Defer the mechanism-specific items. Anything whose value depends on the precise final text — specific documentation formats, particular attestation workflows, exact review cadences — can wait. Build the security capability, not the paperwork shaped to a proposal that received 4,000 comments and will very likely change.
Put the vendor-verification question into contracts now. If business associate verification becomes mandatory, you will need evidence from every business associate. Adding a clause obligating providers to furnish current security assessment evidence on request costs nothing at renewal time and saves a scramble later.
The practical takeaway: use "what is the current status of the Security Rule NPRM?" as your opening question with any MSP pitching healthcare compliance. The answer tells you within thirty seconds whether you are talking to a provider who tracks the regulatory environment or one who repackaged a 2025 deck. Then spend the recovered urgency on a current risk analysis and on MFA, encryption, and ePHI mapping — the three items that hold their value whatever July 2027 eventually produces.
Frequently Asked Questions
Is the HIPAA Security Rule update cancelled?
No. Final action is delayed to at least July 2027, and the rulemaking moved from "final rule stage" to "long-term actions" on the federal tracking site. That signals a substantially longer timeline rather than abandonment. OCR is still working through the 4,000-plus comments received on the proposal.
Do we still have HIPAA Security Rule obligations right now?
Yes. The existing Security Rule remains fully in effect and enforceable. The delay concerns the proposed replacement, not the current standard — including the risk analysis requirement that OCR enforcement has consistently focused on.
Should we implement MFA and encryption before the rule is final?
Both are worth doing on security merits alone and are among the least likely proposed requirements to be dropped. Implementing them now is closing real risk rather than speculative compliance work — unlike proposal-specific documentation formats, which are better deferred until the final text exists.
Does our MSP need a business associate agreement?
If they create, receive, maintain, or transmit ePHI on your behalf — which includes managing systems where ePHI lives, holding backups that contain it, or having help-desk access to workstations that process it — they are a business associate and a BAA is required. Reluctance to sign one is a reason to disqualify a provider.
← CIRCIA's 72-Hour Reporting Clock | HIPAA-Compliant IT Services →