The Office for Civil Rights (OCR) at the U.S. Department of Health and Human Services has had the HIPAA Security Rule update on its regulatory agenda for finalization in May 2026. That deadline has arrived, and as of mid-May 2026, OCR has not published a final rule.

This is not surprising, and it is not necessarily permanent. Proposed rules frequently slip past target publication dates. Industry pushback during the comment period — which closed March 7, 2025 — was significant, and the Trump administration has generally approached new regulatory requirements in healthcare with more caution than its predecessors. The rule may be finalized in modified form, substantially delayed, or ultimately shelved.

What covered entities and business associates should not do is interpret this uncertainty as a reason to pause their security compliance programs.

OCR’s enforcement posture has been consistent throughout 2025 and into 2026: the agency is actively pursuing penalties for violations of the existing Security Rule, has maintained its risk analysis enforcement initiative, and has expanded its focus on tracking pixels and other third-party technology tools that implicate HIPAA’s security and privacy requirements. The proposed rule’s provisions — mandatory MFA, mandatory encryption, enhanced audit requirements — were not invented by the rulemaking process. They reflect existing expectations that OCR has been enforcing under the “addressable” framework for years.

This article explains what OCR is actively enforcing under the current Security Rule, what the proposed rule would mandate that organizations should implement regardless of final rule status, and what a practical 2026 compliance action plan looks like.

The Current Security Rule: A Refresher

The HIPAA Security Rule, originally effective April 21, 2003 and last materially updated by the 2013 Omnibus Rule, establishes requirements for protecting electronic protected health information (ePHI). The rule applies to covered entities — healthcare providers, health plans, and healthcare clearinghouses — and to business associates that create, receive, maintain, or transmit ePHI on behalf of covered entities.

The Security Rule organizes its requirements into three categories:

Administrative safeguards: Policies and procedures for managing security, including workforce training, designated security officials, access authorization, and sanctions for violations.

Physical safeguards: Controls governing physical access to facilities and devices that contain ePHI, including workstation use policies and device disposal procedures.

Technical safeguards: Controls governing electronic access to ePHI, including access controls, audit controls, integrity controls, and transmission security.

Within each category, requirements are classified as either required or addressable. Required specifications must be implemented; there is no flexibility. Addressable specifications must be implemented if they are “reasonable and appropriate” given the organization’s size, complexity, capabilities, technical infrastructure, and the probability and criticality of the risks they address. Critically, “addressable” does not mean optional — it means that if the specification is not implemented, the organization must document why, and must implement an equivalent alternative measure.

The proposed Security Rule update’s central change on MFA and encryption is converting those specifications from addressable to required. This shift matters enormously in enforcement. An organization that has not implemented MFA under the current framework can defend the choice by documenting its risk-based rationale. Under the proposed rule, no such defense exists.

What OCR Is Actively Enforcing in 2026

Risk Analysis Failures

OCR launched a dedicated risk analysis enforcement initiative in recent years, and it remains active and productive in 2026. Risk analysis failures are among the most consistently penalized HIPAA Security Rule violations across the agency’s enforcement history, and for good reason: a complete, accurate, and organization-wide risk analysis is the foundation of the entire Security Rule framework.

The Risk Analysis requirement (45 CFR § 164.308(a)(1)) mandates that covered entities and business associates conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI they hold. The common failure modes OCR has cited repeatedly:

  • Risk analyses that cover only a subset of the organization’s ePHI holdings (one system or one department) rather than the complete enterprise
  • Risk analyses that have not been updated following significant operational changes, system migrations, or incident discoveries
  • Risk analyses that identify risks but do not include corresponding risk management plans with measurable implementation milestones
  • Risk analyses that exist as documents but were not actually conducted — created to satisfy audit requests rather than to drive security decision-making

OCR’s enforcement settlements in 2024 and 2025 included multiple cases where the inadequate risk analysis was the primary violation, with associated penalties ranging from tens of thousands to several million dollars. The agency does not require an organization to have zero vulnerabilities; it requires evidence that the organization has assessed its risks systematically and is managing them.

Tracking Pixel Enforcement

One of OCR’s most active enforcement areas in 2025 and 2026 has been tracking pixels — third-party JavaScript tags embedded in websites that transmit user behavior data to advertising platforms such as Meta, Google, and others. In 2022, OCR issued guidance clarifying that when tracking pixels on healthcare provider and health plan websites transmit information that could identify a patient or their health condition to third parties, that transmission may constitute a disclosure of PHI without authorization.

The enforcement pattern has been aggressive. Multiple healthcare systems have faced investigations, resolution agreements, and civil monetary penalties for deploying tracking pixels on pages where patients could enter symptoms, search for conditions, or schedule appointments — and having those interactions transmitted to advertising platforms under existing pixel configurations.

The proposed Security Rule update does not directly address tracking pixels, but OCR’s existing Privacy Rule and Security Rule enforcement framework is sufficient to address them. The relevant compliance questions for covered entity websites:

  • Are tracking pixels deployed on any web pages where users might enter or access health-related information?
  • Has the organization assessed whether the data transmitted by each pixel constitutes PHI under HIPAA?
  • If PHI is transmitted to third-party vendors through tracking pixels, is there a business associate agreement with each vendor that receives it?
  • Has the organization implemented technical controls to prevent pixels from firing on pages or in contexts where PHI is present?

A healthcare organization that has not conducted this assessment in 2025 or 2026 is overdue. The technology ecosystem that tracking pixels operate in has continued to evolve, and a pixel inventory conducted two years ago may not reflect current deployments.

Technical Safeguard Enforcement

While MFA is currently an addressable specification under the existing Security Rule, OCR’s enforcement actions demonstrate that it views the failure to implement MFA as a significant indicator of inadequate technical safeguards — particularly in cases where the absence of MFA contributed to a breach.

Organizations that have suffered credential-based breaches and did not have MFA protecting the compromised accounts face a difficult defense. “MFA is addressable and we assessed it as not reasonable and appropriate” is a credible position for an organization that has documented a reasoned, risk-based rationale. It is not a credible position for an organization that simply never considered the question.

The same analysis applies to encryption. Encryption of ePHI at rest and in transit is currently addressable, but the absence of encryption on laptops, mobile devices, external drives, and transmission channels has been a recurring element of OCR enforcement settlements involving breached portable devices.

What the Proposed Rule Would Require

Understanding the proposed Security Rule update is valuable for two reasons: it signals where OCR’s enforcement attention will be concentrated, and its provisions represent security practices that organizations should implement regardless of whether the rule is finalized.

The January 6, 2025 proposed rule would make the following changes, among others:

MFA as a Required Specification

Under the proposed rule, multi-factor authentication would be required — not addressable — for all access to systems that store or process ePHI. This includes EHR systems, billing platforms, scheduling systems, imaging archives, secure messaging platforms, and cloud storage containing PHI.

The requirement would not specify which MFA methods are required, allowing organizations to implement authenticator apps, hardware tokens, or biometric verification depending on their context. But the requirement to use some form of MFA would be absolute. Organizations that currently authenticate ePHI system access with username and password alone would face a compliance gap requiring remediation.

Implementation timeline if finalized as proposed: 180 days from the rule’s effective date, which is 60 days after Federal Register publication. A May 2026 publication would yield a compliance deadline of approximately February 2027.

Encryption as a Required Specification

Encryption of ePHI at rest and in transit would move from addressable to required. The rule would permit narrow exceptions for specific documented technical circumstances, but those exceptions would require significantly more documentation than the current addressable standard.

For most covered entities, this means:

  • Full-disk encryption on all devices capable of storing ePHI, including workstations, laptops, mobile devices, and backup media
  • Encryption of ePHI in databases and file systems
  • TLS 1.2 or higher for all ePHI transmission
  • Encrypted email for transmissions containing PHI

Network Segmentation

The proposed rule would require covered entities to implement network segmentation that limits the ability of a breach in one part of the network to propagate to ePHI systems. This reflects OCR’s experience reviewing breach incidents where attackers gained access through a low-security network segment and laterally moved to EHR systems.

Vulnerability Scanning and Penetration Testing

The proposed rule would require covered entities to conduct vulnerability scans at defined intervals (at least every six months) and penetration tests at least annually. Many larger covered entities already conduct these assessments; smaller organizations and business associates may not have formalized programs.

Enhanced Audit Controls

The proposed rule would require more specific logging and monitoring of ePHI system access, including the ability to detect and respond to anomalous access patterns. Audit logs must be retained and must be reviewed at defined intervals.

The Case for Acting Without the Final Rule

The practical argument for implementing MFA, encryption, network segmentation, and vulnerability management now — without waiting for the final rule — is not primarily regulatory. It is risk-based.

The 2026 Verizon DBIR, published May 19, 2026, found that 31% of all breaches began with vulnerability exploitation and that ransomware was involved in 48% of confirmed breaches. Healthcare remains one of the most targeted sectors, with a 2026 analysis placing the average ransom demand in healthcare ransomware incidents at $1.69 million. The technical controls the proposed Security Rule would require are controls that reduce the actual probability of a breach — not compliance checkboxes disconnected from operational reality.

An organization that implements MFA across its ePHI systems before the final rule is published has reduced its credential attack surface regardless of whether OCR ever finalizes the rule. An organization that encrypts its portable devices does not suffer data breach notification obligations when a laptop is stolen — the encryption renders the data unreadable and removes it from the breach notification framework.

The argument for not acting — “let’s wait and see if the rule is finalized before investing” — implicitly treats these security investments as costs incurred solely for regulatory compliance, rather than as risk management measures that reduce the probability of an incident that would cost orders of magnitude more than the preventive investment.

2026 HIPAA Security Rule Action Plan

Immediate (Complete by Q3 2026)

Risk analysis update: If your organization’s risk analysis has not been updated in the past 12 months, or has not been updated following significant system changes or incidents, initiate an update now. This is the single most consistently penalized HIPAA Security Rule failure and the one OCR actively looks for during investigations.

Tracking pixel inventory: Conduct a complete inventory of all third-party scripts, pixels, and tags deployed across your web properties. For each, document what data is transmitted, whether PHI is included, and whether a BAA exists with the receiving vendor. Remove or reconfigure pixels that transmit PHI without appropriate authorization or BAAs.

MFA gap assessment: Map your current MFA coverage. Identify every system that accesses or stores ePHI. Determine which use MFA and which do not. Build an implementation roadmap with realistic timelines for full MFA coverage.

Device encryption audit: Inventory all portable devices — laptops, tablets, mobile phones, external drives — that can access or store ePHI. Verify encryption status and ensure that lost or stolen devices cannot be accessed without credentials.

Near-Term (Complete by Q4 2026)

MFA implementation: Complete MFA rollout for all ePHI-accessing systems, prioritizing internet-accessible systems, privileged access accounts, and remote access pathways.

Vulnerability scanning program: Establish a regular vulnerability scanning cadence covering all systems within your ePHI scope. Document scan results, remediation actions, and exceptions.

Business associate agreement audit: Review your BAA inventory for completeness. Third-party vendors that receive ePHI without a BAA create both a compliance gap and a liability if those vendors experience a breach.

Ongoing

Penetration testing: Commission an annual penetration test from a qualified third party. Internal vulnerability scans and external penetration tests measure different things — both are necessary.

Incident response testing: Conduct tabletop exercises simulating ransomware and data exfiltration scenarios at least annually. The goal is not to test whether your incident response plan documents are complete; it is to verify whether your team knows what to do and can execute under pressure.

Workforce training: Annual HIPAA security training is a required administrative safeguard, but its effectiveness depends on content that reflects current threat patterns. Training that does not address phishing, social engineering, credential hygiene, and ePHI handling outside the clinical setting is inadequate for the current threat environment.

Conclusion

OCR’s May 2026 target for finalizing the HIPAA Security Rule update may slip. The final rule may emerge in modified form, or be delayed further by administrative priorities and industry pressure. Organizations that have built their 2026 security compliance programs around that deadline are now in a position of uncertainty about when the new requirements will arrive.

The correct response to that uncertainty is not to pause implementation. It is to implement the controls that the proposed rule would require — MFA, encryption, network segmentation, vulnerability management — on the basis that these are sound security investments regardless of regulatory compulsion, and that OCR’s active enforcement posture under the existing rule makes inadequate technical safeguards a concrete liability.

The covered entities and business associates that will face the smallest adjustment burden when the final rule does arrive — whether in 2026 or 2027 — are the ones that have been implementing security improvements based on risk rather than waiting for mandatory deadlines.

This article is provided for informational purposes only and does not constitute legal advice. Organizations should consult qualified legal counsel for guidance on their specific HIPAA compliance obligations.