What the HIPAA 2026 NPRM Means for MSPs and Their Clients

The HIPAA 2026 Notice of Proposed Rulemaking is the most significant update to the HIPAA Security Rule since 2013. This guide explains what is changing, which organizations it affects, what MSPs are now directly responsible for, and what needs to happen before the compliance deadlines arrive.

‍

What the HIPAA 2026 NPRM is and why it matters now

A Notice of Proposed Rulemaking — NPRM — is the formal mechanism the U.S. Department of Health and Human Services uses to propose changes to existing regulations before finalizing them. The HIPAA 2026 NPRM, published by the HHS Office for Civil Rights, proposes the most substantial revision to the HIPAA Security Rule since the original rule was finalized in 2003 and amended in 2013. It is not a minor update. It redefines the floor of what HIPAA compliance requires at the technical implementation level.

The rulemaking process means the NPRM is not yet final regulation — there is a comment period and a finalization process between proposal and enforcement. However, the direction of the changes is clear, the regulatory intent is unambiguous, and the timeline for finalization and compliance is close enough that organizations treating this as a distant future concern are already behind. MSPs serving healthcare clients, healthcare practices managing their own compliance programs, and any organization operating as a HIPAA Business Associate need to understand what is changing and begin implementation planning now.

The core shift of the NPRM can be summarized in a single sentence: the Security Rule is moving from a flexible, judgment-based implementation model to a prescriptive, specific-requirement model where far less is left to organizational discretion.

The end of addressable implementation specifications

The most consequential single change in the HIPAA 2026 NPRM is the elimination of the required versus addressable distinction that has defined HIPAA Security Rule compliance for over two decades.

Under the existing Security Rule, implementation specifications are categorized as either required — meaning they must be implemented as stated — or addressable — meaning covered entities must assess whether each specification is reasonable and appropriate for their environment, and either implement it, implement an equivalent alternative, or document why it is not applicable. In practice, the addressable designation has been widely used to defer, deprioritize, or document away controls that were operationally inconvenient or costly to implement.

The NPRM proposes to eliminate this distinction entirely. Under the proposed rule, all implementation specifications become required. There is no longer an addressable category that permits a covered entity or business associate to substitute an alternative approach or document an exception. Every specification must be implemented as written.

The significance of this change is difficult to overstate. Many organizations that considered themselves HIPAA-compliant under the existing framework — because they had documented their addressable specification decisions and applied reasonable alternatives — will not meet the standard the NPRM establishes. The compliance baseline is rising, and it is rising for every covered entity and business associate simultaneously.

Critical implication: If any part of your current HIPAA compliance program relies on documented addressable specification exceptions — encryption decisions, audit control implementations, automatic logoff configurations — those exceptions will not satisfy the proposed rule. Each one represents an implementation gap that needs to be addressed before the rule is finalized.

Key new technical requirements introduced by the NPRM

Beyond eliminating the addressable distinction, the NPRM introduces specific new technical requirements that have no equivalent in the existing Security Rule. These are not clarifications of existing requirements — they are net-new obligations that organizations must implement from scratch.

Network segmentation

The NPRM proposes a specific requirement for network segmentation — isolating systems that contain or process electronic protected health information from other network segments. Under the existing rule, network architecture was addressed only indirectly through general access control and audit requirements. The proposed rule makes segmentation an explicit, mandatory technical safeguard. Organizations running flat networks — where clinical systems, administrative systems, and internet-connected devices share the same network segment — will need infrastructure changes to comply.

Multi-factor authentication

The NPRM proposes mandatory multi-factor authentication for all access to systems containing electronic protected health information, with very limited exceptions. While MFA has been a widely recommended security control for years, and while many organizations have adopted it voluntarily, the existing HIPAA Security Rule does not explicitly require it. The proposed rule does. Organizations and their Business Associates that have not fully deployed MFA across all ePHI-touching systems — including remote access, administrative portals, and clinical applications — will have a direct compliance gap under the proposed rule.

Encryption requirements

Under the existing rule, encryption of ePHI at rest and in transit was an addressable specification — meaning organizations could document alternative approaches or justify non-implementation. The NPRM proposes to make encryption of ePHI at rest and in transit a required specification with no alternative. Any system storing or transmitting ePHI without encryption will be non-compliant under the proposed rule regardless of what documentation or alternative controls were previously in place.

Vulnerability scanning and penetration testing

The NPRM introduces explicit requirements for vulnerability scanning on a defined frequency and penetration testing on an annual basis. Under the existing rule, technical evaluation of security controls was required but the specific mechanisms were left to organizational discretion. The proposed rule prescribes the types of testing required and, in some provisions, the minimum frequency. Organizations that have not established formal vulnerability management and penetration testing programs will need to build them — not as a best practice, but as a regulatory requirement.

Incident response plan specificity

The NPRM proposes significantly more prescriptive requirements for incident response planning, including specific elements that plans must contain, defined timelines for response activities, and requirements for incident response testing. Organizations with high-level incident response policies that have never been tested or that lack the specific elements the proposed rule requires will need to revise and test their plans before the compliance deadline.

Asset inventory and network mapping

A new requirement under the NPRM calls for organizations to maintain an accurate, current inventory of all technology assets and a map of the network environments in which ePHI is processed. Many organizations — particularly smaller healthcare practices and SMBs — do not have formal asset inventories. The proposed rule makes this a baseline compliance requirement rather than a security best practice.

Who is directly affected — and who carries indirect exposure

The HIPAA Security Rule applies to covered entities — healthcare providers, health plans, and healthcare clearinghouses that conduct covered transactions electronically — and to business associates, which are entities that create, receive, maintain, or transmit electronic protected health information on behalf of a covered entity.

The NPRM applies to both categories with equal force. A healthcare practice that is a covered entity and the MSP that manages its IT infrastructure as a business associate are both subject to the same proposed requirements. The compliance obligation follows the data, not just the organization that originated it.

Indirect exposure extends further. Subcontractors of business associates — an MSP's cloud hosting provider, a software vendor whose product processes ePHI, a third-party backup service — are also considered business associates if they handle ePHI in performing their services. The chain of compliance obligation runs through every organization that touches the data, regardless of how many layers of vendor relationship exist between them and the original covered entity.

What the NPRM means specifically for MSPs and MSSPs

MSPs and MSSPs serving healthcare clients are business associates by definition when their services involve access to or management of systems containing ePHI. This has always been true under the existing HIPAA framework. What the NPRM changes is the specificity and the floor of what that business associate obligation requires.

Under the proposed rule, an MSP managing a healthcare client's IT environment is directly responsible for ensuring that the infrastructure it manages meets the new technical requirements — including network segmentation, MFA enforcement, encryption at rest and in transit, vulnerability scanning, and asset inventory. These are not client-side obligations that the MSP can point to as the covered entity's responsibility. They are technical controls implemented in the environment the MSP manages, which makes their implementation the MSP's operational responsibility regardless of where the contractual accountability sits.

MSPs that have positioned their HIPAA compliance service offering around the existing Security Rule framework — addressable specification documentation, general access control policies, annual risk assessments without specific testing requirements — will need to significantly expand both the scope and the specificity of what they deliver to healthcare clients under the proposed rule.

This creates both a compliance obligation and a service opportunity. MSPs that develop the capability to implement and evidence the new NPRM requirements for healthcare clients — MFA deployment, network segmentation assessment, vulnerability scanning programs, asset inventory management, incident response testing — are positioned to offer a higher-value, higher-margin service to a client base that now has a regulatory mandate to purchase it.

Business Associate Agreement implications

Every MSP serving a healthcare client should have a Business Associate Agreement in place. The NPRM has direct implications for the content and enforceability of those agreements.

Existing BAAs written against the current Security Rule framework reference the existing implementation specification structure — including the required versus addressable distinction that the NPRM proposes to eliminate. When the final rule is published, BAAs that reference the old framework may need to be updated to reflect the new obligations. MSPs that allow BAAs to remain in their current form after the rule is finalized carry contractual and regulatory risk: the agreement may not accurately represent the obligations either party is now subject to.

The NPRM also reinforces the direct liability that business associates carry for Security Rule violations. Under the existing enforcement framework, OCR has pursued business associates directly for Security Rule failures — not just covered entities. The more prescriptive requirements of the NPRM create a clearer evidentiary standard for what constitutes a violation, which may make business associate enforcement actions both more common and more straightforward to establish.

MSPs should treat the NPRM as a trigger to audit their existing BAAs, confirm that the technical obligations they have agreed to are ones their service delivery can substantiate, and identify any agreements that need renegotiation or update before the final rule takes effect.

How this changes what MSPs owe their healthcare clients

The practical effect of the NPRM on the MSP-client relationship is that the compliance conversation with healthcare clients needs to move from general assurances to specific, documented, evidence-backed implementation records. Clients who were previously satisfied with a statement that their MSP "handles HIPAA compliance" will face auditors and regulators asking for specific evidence of specific controls — and that evidence needs to exist in the MSP's delivery record, not just in a policy document.

Healthcare clients need to know:

• Whether MFA is enforced across every system in their environment that touches ePHI — not just their email platform, but clinical applications, remote access solutions, administrative portals, and any system the MSP uses to manage their environment
• Whether their data at rest and in transit is encrypted, and whether the MSP can produce evidence of that encryption on demand rather than on request before an audit
• Whether the network infrastructure the MSP manages is segmented in a way that isolates ePHI systems from broader network access
• Whether vulnerability scanning is occurring on a schedule that will meet the NPRM's proposed frequency requirements and whether findings are being tracked and remediated
• Whether the organization has an asset inventory that is current, accurate, and maintained as part of normal operations rather than assembled before an audit

MSPs that can answer these questions with documented evidence — not verbal assurances — are delivering a genuinely NPRM-ready service. MSPs that cannot will find their healthcare clients increasingly exposed as enforcement of the new requirements begins and auditors start asking for the specific evidence the new rule requires.

Common gaps the NPRM will expose in existing compliance programs

Most existing HIPAA compliance programs — whether managed by MSPs or maintained internally by covered entities — will have gaps when measured against the NPRM's proposed requirements. The gaps that appear most consistently are predictable.

• Partial MFA deployment. Many organizations have deployed MFA for email and remote access but not for clinical applications, on-premise systems, or administrative platforms that also process ePHI. The NPRM does not recognize partial MFA deployment as compliant — it applies to all access to ePHI systems.
• Unencrypted data at rest. Organizations that relied on the addressable specification exception to defer encryption of ePHI stored on local servers, workstations, or backup media will have a direct gap. The proposed rule makes encryption mandatory without exception.
• Flat network architecture. Healthcare environments that have not implemented network segmentation — where clinical systems, IoT medical devices, administrative workstations, and internet-connected devices share network access — will require infrastructure assessment and remediation.
• No formal vulnerability management program. Organizations that address vulnerabilities reactively — patching when issues are reported rather than scanning for them systematically — will need to establish a formal program with defined scanning frequency and documented remediation tracking.
• Untested incident response plans. Incident response policies that have never been exercised through a tabletop or simulation exercise do not meet the NPRM's proposed testing requirements. A documented plan that has never been tested is not demonstrably functional.
• Absent or outdated asset inventories. Organizations without a current, maintained record of all technology assets in their ePHI environment will need to build one — and establish a process for keeping it current as the environment changes.

What to do before the compliance deadlines arrive

The window between the NPRM proposal and the enforcement of a final rule is the implementation window. Organizations that use it productively will be in a substantially better position than those that wait for the final rule before beginning remediation. Some of the changes the NPRM requires — network segmentation, MFA deployment across all ePHI systems, formal vulnerability management programs — are not things that can be implemented in days. They require planning, procurement, technical implementation, and documentation that takes weeks to months depending on the size and complexity of the environment.

• Conduct a gap assessment against the NPRM requirements now. Map your current controls against each proposed requirement and identify which ones are not yet implemented, partially implemented, or implemented in a way that relied on the addressable specification exception. The gap list is your implementation roadmap.
• Prioritize MFA and encryption remediation first. These are the two areas where the NPRM's changes are most absolute — both eliminate the addressable exception entirely — and both have the longest implementation timelines in complex environments. Start immediately.
• Commission a network segmentation assessment. Engage a qualified network security resource to assess the current network architecture and identify the changes required to isolate ePHI systems as the NPRM requires. Budget for the infrastructure changes the assessment will identify.
• Establish a formal vulnerability management program. Define the scanning frequency, the tools in use, the process for reviewing and prioritizing findings, and the remediation tracking mechanism. Document it as a policy. Begin scanning and retain the results as evidence.
• Test your incident response plan. Schedule a tabletop exercise or simulation against a realistic ePHI breach scenario. Document the exercise, the findings, and any updates made to the plan as a result. This documentation is your evidence of compliance with the testing requirement.
• Build or update your asset inventory. Document every technology asset in environments where ePHI is processed, stored, or transmitted. Establish a process — ideally automated — for keeping the inventory current as the environment changes.
• Review and update Business Associate Agreements. Audit existing BAAs against the new requirements and identify agreements that reference outdated framework language or do not capture the obligations the NPRM introduces. Begin the renegotiation or update process for those agreements before the final rule takes effect.

For MSPs specifically: The NPRM creates a time-bounded opportunity to proactively reach every healthcare client in your portfolio with a specific, evidence-backed assessment of their current posture against the new requirements. MSPs that initiate that conversation now — before the final rule is published — are positioned as trusted advisors. MSPs that wait until clients ask will be responding to urgency rather than leading through it.

The HIPAA 2026 NPRM represents a fundamental shift in what HIPAA compliance requires at the technical implementation level. The elimination of the addressable specification category, the introduction of prescriptive new technical requirements, and the reinforcement of direct business associate liability collectively raise the compliance floor for every covered entity and business associate in the healthcare ecosystem. For MSPs, the NPRM is simultaneously a compliance obligation, a service delivery challenge, and a market opportunity — for those prepared to lead their healthcare clients through it rather than follow them into it.

‍