HHS proposed mandatory annual penetration testing for all HIPAA-covered entities. Here’s what the rule requires, when it takes effect, and how to prepare.
| Update — May 26, 2026: OCR projected May 2026 as the finalization date for the proposed HIPAA Security Rule. That date has come and gone without a final rule, but this isn’t unusual. The requirements outlined in this article reflect the proposed rule as written, and the 240-day compliance window will apply once it’s final. We’ll update this post as new developments arise. |
| Update: July 13, 2026: HHS has moved this rulemaking to a “long-term action” on its federal regulatory agenda, pushing the expected final rule date from May 2026 to July 2027. Several independent firms have confirmed this update, citing Reginfo.gov. Keep in mind, this is just a planning estimate and could change again. This update doesn’t change the guidance below. HHS has made it clear that risk analysis, MFA, encryption, and vulnerability management are already required under the current Security Rule, no matter the NPRM’s status. Instead, use this extra time to build a thorough readiness plan rather than putting off action. |
On February 21, 2024, Change Healthcare’s systems went dark. Within hours, pharmacies across the country couldn’t process prescriptions. Hospitals couldn’t verify patient insurance. Prior authorizations stopped moving. For weeks, clinicians worked around paper processes they hadn’t used in years.
The numbers are almost hard to absorb. The breach ultimately affected approximately 100 million Americans, according to reporting by the American Hospital Association and IBM. UnitedHealth Group’s total cost landed near $2.87 billion. A separate survey of roughly 1,000 hospitals found that 94% reported direct financial impact. (AHA, March 2024)
Change Healthcare’s impact was so damaging due to the scale, a cascading effect through interconnected systems. One vendor, one attack, and suddenly half the healthcare payment infrastructure in the United States stopped working. The attackers found a path in, moved laterally, and got to the most sensitive systems before anyone raised an alarm. That’s a penetration testing problem. It’s also an architecture problem, a third-party risk problem, and a monitoring problem.
HHS had been watching these trends accumulate for years before the rule changed. By January 2025, HHS sought to enact real change.
The original HIPAA Security Rule dates to 2003. Healthcare IT in 2003 looked nothing like it does today. The rule’s framework survived two decades largely intact, while the threat environment transformed completely. Large healthcare breaches increased 102% between 2018 and 2023. The Healthcare and Public Health sector has been the most targeted critical infrastructure sector since at least as far back as 2015. (HHS OCR NPRM preamble, Federal Register 2024-30983, January 2025)
This showcases a structural failure of a compliance framework that treated security controls as optional when inconvenient.
The breach picture by the numbers:
OCR enforcement tells the same story from a different angle. In 2024, OCR completed 22 HIPAA enforcement actions, the second-highest total in the agency’s history, collecting $9.9M in penalties. The most frequently cited violation: inadequate risk analysis, appearing in 13 of 22 enforcement matters. (LegalHIE, January 2025)
HHS published the proposed HIPAA Security Rule update in the Federal Register on January 6, 2025 (document 2024-30983). The proposal is the most significant update to the Security Rule since it was enacted. It converts many previously “addressable” standards, meaning organizations could choose alternatives or skip them with documentation, into specific, required controls with defined timelines. (Federal Register 2024-30983)
The proposed rule would require all covered entities to conduct penetration testing at least once every 12 months, codified at 45 CFR 164.312(h)(2)(iii). Testing must be performed by a “qualified person(s)” with knowledge of “generally accepted cybersecurity principles.” The rule does not prescribe a specific certification or methodology, but it sets the floor: annual, qualified, documented.
Before this proposal, penetration testing appeared nowhere in the HIPAA Security Rule as a specific requirement. Organizations could satisfy risk analysis obligations without ever running an actual attack simulation. Many did.
Separate from penetration testing, the proposed rule requires automated vulnerability scanning at a minimum of every six months. These are different activities with different purposes: vulnerability scanning identifies known weaknesses, while penetration testing exploits them to demonstrate real-world impact. Both are now in scope, allowing for organizations to fully understand the risks within their environment.
The proposed rule mandates multi-factor authentication for all access to systems containing electronic protected health information (ePHI). There are limited exceptions for legacy medical devices manufactured before March 2023, where hardware constraints may make MFA technically impossible. Outside that narrow carve-out, the rule removes ambiguity.
Encryption follows the same logic. The proposal eliminates the “addressable” classification for encryption at rest and in transit. Every covered entity will need to demonstrate actual encryption implementation, not just a documented rationale for why they chose something else.
Covered entities must maintain a written technology asset inventory, updated at least annually or whenever infrastructure changes. Alongside the inventory, the rule requires network maps showing how ePHI enters, exits, and moves through the organization’s systems.
These requirements exist because you cannot protect what you can’t see. In our experience, assessment teams frequently discover systems containing ePHI that their own IT teams didn’t know about. The inventory requirement will force that accounting.
The proposed rule introduces specific, measurable timelines that replace vague “reasonable” language. The key deadlines:
The 15-day patch window for critical vulnerabilities deserves particular attention. Many healthcare organizations operate on quarterly or semi-annual patch cycles. That cadence doesn’t survive this rule if it’s finalized.
Healthcare breaches cost 60% more per incident than financial sector breaches, and more than twice the global average, according to the IBM Cost of a Data Breach Report 2024. The $9.77M average reflects the compounding cost of downtime, notification, legal exposure, and regulatory penalties that healthcare uniquely absorbs.
The NPRM was published on January 6, 2025. The comment period closed March 7, 2025, with more than 4,700 public comments submitted. (HIPAA Journal) OCR’s regulatory agenda projects finalization in May 2026. Once the final rule is published, covered entities have 240 days to achieve compliance, placing the hard deadline in early 2027. (Alston & Bird NPRM Analysis)
There is real regulatory uncertainty here. The Trump administration issued a broad regulatory freeze in early 2025, and healthcare industry groups, including CHIME, raised concerns about implementation cost, which HHS estimates at approximately $9.3B in the first year. (HHS NPRM Regulatory Impact Analysis) OCR has maintained its timeline despite that friction.
Waiting for the final publication is the wrong call. 240 days is not a long runway when you factor in what actually happens in that window. You need to identify and engage a qualified penetration testing vendor. You need to schedule the assessment around your operational calendar. You need to remediate findings. You need to document everything. Then you need to be ready to do it again in 12 months.
A penetration test is not a vulnerability scan. A vulnerability scan runs automated tooling against your systems to identify known weaknesses and misconfigurations. It’s valuable, but not sufficient on its own. Penetration testing takes those identified weaknesses and attempts to exploit them, chaining vulnerabilities together the way an actual attacker would, to demonstrate real-world risk. Furthermore, penetration tests often identify vulnerabilities that are not detectable by vulnerability scans — such as misconfigurations without Active Directory.
The proposed rule requires both penetration testing and vulnerability scanning, on separate schedules.
To truly mirror a real-world adversary, an assessment needs to go beyond a simple “point-and-click” scan. It requires simulating the entire attack lifecycle. As shown in the diagram above, this includes testing how an attacker might pivot from a remote entry point through the network boundary, or even how a “local attacker” (such as a malicious actor with physical access or a compromised workstation) might escalate privileges within your Active Directory to reach high-value targets like database servers.
A HIPAA-aligned penetration test should cover the full attack surface relevant to ePHI.
That means:
The deliverable from a qualified penetration test should include an executive summary suitable for board and C-suite consumption; a technical findings report with severity ratings and supporting evidence; remediation guidance prioritized by risk; and attestation documentation suitable for regulatory review.
What We’ve Learned Working Inside HHS
BreakPoint Labs has conducted penetration testing for the Department of Health and Human Services, the same agency proposing this rule, for over six years. That work has taken us through a wide range of Healthcare systems and given us a view into the security challenges that health organizations grapple with directly. The patterns we observe mirror what we see across covered entities in the field.
Third-party connections are the most reliable attack path. Almost every meaningful escalation we’ve achieved in healthcare environments started with a vendor connection, a partner integration, or a legacy API that predated the current security team. These connections are often trusted implicitly. They shouldn’t be.
Encryption policy and encryption reality are different things. Organizations document encryption requirements. They implement encryption on new systems. They miss decommissioned servers, backup repositories, test environments, and older infrastructure that hasn’t been touched in three years. The gap between the policy and the deployment is where ePHI exposure actually lives.
Medical devices are the hardest conversation to have. Clinical teams resist security controls on devices they use for patient care, and they’re not wrong to flag the operational implications. But a networked infusion pump running an unpatched OS is a lateral movement opportunity. We find exploitable medical device vulnerabilities in almost every healthcare environment we test.
Risk analysis is treated as a document, not a process. The most common failure pattern we observe matches what OCR cited in 13 of 22 enforcement actions last year: a risk analysis that was completed once, filed, and not revisited. A risk analysis that doesn’t evolve with the environment isn’t protecting anyone. It’s just paperwork.
Workforce access controls break down at departure. The proposed 1-hour termination window sounds aggressive. In practice, we routinely find active credentials belonging to employees who left months earlier. The manual coordination between HR, IT, and security fails predictably under operational pressure.
You don’t need to wait for the final rule publication to begin.
Five steps you can take right now:
The proposed rule isn’t final yet, but the direction is clear. Annual penetration testing, mandatory MFA and encryption, strict remediation timelines, and documented asset inventories will all be required for every HIPAA-covered entity. The 240-day compliance window after finalization sounds like breathing room. It isn’t, once you account for procurement, scheduling, assessment, remediation, and documentation.
If your organization hasn’t conducted a penetration test recently, or if your last assessment didn’t cover medical devices, cloud environments, and business associate connections, now is the time to close that gap.
BreakPoint Labs works with healthcare organizations navigating exactly this challenge. Our team brings direct experience conducting penetration tests inside federal health environments and understands what regulators look for when they review documentation. If you’d like to talk through your current posture and what a HIPAA-aligned assessment would look like for your organization, contact us.
Yes. HHS originally projected a final rule in May 2026. That date passed without action, and HHS has since reclassified the rulemaking as a “long-term action” on its federal regulatory agenda, with a new anticipated final action date of July 2027. This is reported independently by multiple trackers, including Clark Hill, Davis Wright Tremaine, and HIPAA Journal. It’s worth noting that this new date is a planning estimate, not a binding deadline, and HHS hasn’t publicly explained its reasoning. The delay doesn’t change what’s already expected of covered entities under the current Security Rule, and it isn’t a reason to pause cybersecurity improvements in the meantime.
Yes. The proposed rule applies to all HIPAA-covered entities, regardless of size. Small practices, solo providers, and rural clinics are subject to the same requirements as large health systems. HHS estimates compliance costs at approximately $9.3B industry-wide in the first year, which reflects the breadth of organizations in scope [HHS NPRM Regulatory Impact Analysis] https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html.
The proposed rule requires penetration testing by a “qualified person(s)” with knowledge of “generally accepted cybersecurity principles.” It does not mandate a specific certification. In practice, organizations should look for testers with demonstrated healthcare experience, familiarity with clinical environments, and the ability to produce documentation that satisfies regulatory review. Credentials like OSCP, CEH, or equivalent provide a reasonable baseline signal.
Willful neglect violations carry penalties of up to $73,011 per day per violation, with an annual cap of $2,134,831 for the same violation category [HHS OCR]https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/data/enforcement-highlights/index.html. In 2024, OCR completed 22 enforcement actions, collecting $9.9M in penalties. Inadequate risk analysis, which maps directly to the new testing requirements, was cited in 13 of those 22 matters [LegalHIE, January 2025] https://www.legalhie.com/a-look-back-at-2024-hipaa-enforcement-year-in-review/.
The proposed rule explicitly references NIST frameworks and aligns with the HHS 405(d) Health Industry Cybersecurity Practices (HICP). The 405(d) Cybersecurity Performance Goals already recommend annual penetration testing as a high-priority practice. Organizations that have adopted the HICP framework will find significant overlap with the new requirements. NIST CSF alignment won’t get you all the way there, but it puts you ahead of starting from scratch.
No. A vulnerability scan uses automated tools to identify known weaknesses in systems and software. Penetration testing goes further: a qualified tester actively attempts to exploit those weaknesses, chain vulnerabilities together, and demonstrate real-world impact. The proposed rule requires both. Vulnerability scanning happens every six months. Penetration testing happens annually. They serve different and complementary purposes.
Sources referenced in this article:
In previous installments of The Attacker’s Playbook, we explored how human error (Part 1) creates the initial opportunity and how attackers exploit forgotten physical and digital entry points (Part 2).
But truth be told, we don’t always have to work that hard. Often, the “keys to the kingdom” are left right out in the open, in the form of default passwords, reused credentials, and sensitive data stored in the wrong places.
The simplest access control failures are often the most effective. We operate under the principle that default credentials are the same as having no authentication at all.
The Flaw: We find these “ghost keys” everywhere, from routers and medical software to printers. One of the most glaring examples involved finding cameras in medical rooms with live feeds of patients, accessible to anyone who knew the default password.
However, the risk extends beyond defaults. Attackers also hunt for the obscure Active Directory (AD) attribute known as “PassNotReq” (Password Not Required). If this is set to true, the user can circumvent password policies and set any password they want—including a blank one.
We use specialized tools like AD-RECON, an Active Directory reconnaissance tool developed by BreakPoint Labs, to quickly triage Bloodhound data and identify accounts with this attribute, as they are likely configured with weak or nonexistent passwords.
The Attack: An attacker will always start by checking for default credentials and password reuse. They look for exposed configuration files or scripts, such as a PowerShell script that sets the same local admin password across the network, which is essentially a reusable key to the entire kingdom.
In one engagement, we found a Domain Admin account from 2003 with a completely blank password. It’s important to note that this blank password wasn’t a default setting; It was a human-configured error that had remained undetected since its inception in 2003. Why did it persist for so long? Because vulnerability scanners generally don’t check AD password complexity or perform brute-force attacks, and pentesters often assume “blank” won’t work, so they don’t even try it.
The Result: A single default password can allow an attacker to gain a critical foothold, view sensitive patient video, or even achieve full domain takeover.
Mitigation Strategies: Basic security hygiene is non-negotiable.
So, why discuss passwords and data in the same post? Because they are the two halves of the “Keys to the Kingdom.” Passwords are the key, and the data is the treasure inside the chest. Once an attacker uses those weak credentials to get in, they immediately start hunting for the data you forgot about.
The Flaw: It’s extremely common to find Protected Health Information (PHI) and PII on systems where it has no business being. This data sprawl is typically the result of human error and a lack of training or convenience, like a doctor bypassing the secure network to use the Guest WiFi for faster internet access. We often find ourselves asking, “Why is there an exposed network share containing not just PHI, but old ransomware artifacts?”
The Attack: An attacker with internal access will hunt through these misplaced files. In one instance, we discovered dumps of email communications between thousands of students and their school’s healthcare center, filled with vast amounts of PHI and left on an easily accessible share.
The Result: This lack of data governance creates a massive, hidden risk. A single compromised workstation can lead to a catastrophic data breach if that station has access to years of forgotten, sensitive files.
Mitigation Strategies: Data governance is a critical, often-overlooked security control.
Leaving keys and sensitive documents out in the open is an invitation to attackers. Whether it’s a text file, an unlocked port, or a default password, poor security hygiene is an attacker’s best friend.
Key Takeaways:
PassNotReq) are invisible risks that standard scanners miss.Beyond compliance, protecting patient data is about resilience. Our security assessments simulate how attackers exploit these weaknesses, helping you find and fix them before they’re used against you.
So what happens once we’ve got the keys? That’s when the real damage begins. In the final chapter, we dive deep into the maze of internal trust—exploiting complex Active Directory paths that scanners can’t see. Part 4 is where persistence and privilege collide.
In July 2025, the U.S. Department of Health and Human Services’ Office of Inspector General (HHS-OIG) released a cybersecurity audit of a large Northeastern hospital.
The findings revealed a sobering truth: even hospitals with robust defenses, like firewalls, disaster recovery, and security training, remain vulnerable if basic configuration and authentication controls are not consistently enforced.
To provide the technical testing for this audit, OIG engaged BreakPoint Labs (BPL) to conduct penetration testing, web application reviews, and vulnerability scanning under a signed Rules of Engagement. Our work demonstrated how minor weaknesses in internet-facing systems can escalate into significant risks to patient safety and data integrity.
Healthcare providers remain at the center of the cyber threat landscape.
Together, these numbers reinforce the OIG’s audit findings: healthcare is too often playing defense against adversaries who only need to find one overlooked gap.
The OIG audit validated that many of the hospital’s defenses were effective. Employees successfully resisted phishing attempts, and the web application firewall blocked most malicious traffic. However, BPL’s technical assessment identified exploitable weaknesses that highlight where hospitals remain at risk:
OIG issued five recommendations, all accepted by the hospital:
Hospitals and healthcare organizations can use this roadmap to harden their defenses quickly:
Days 0–30: Close Obvious Gaps
Days 31–60: Prove Controls in Practice
Days 61–90: Make Security Durable
As OIG’s trusted technical partner in this hospital audit, BreakPoint Labs brings proven expertise in offensive security testing tailored for healthcare environments. Our services help you proactively identify and fix the same types of vulnerabilities found in this engagement.
Our healthcare cybersecurity services include:
Cybersecurity is patient safety. Don’t wait for an audit to find your blind spots.
Request a consultation with BreakPoint Labs today, and let’s build a perimeter-hardening plan that works.
Note: This post summarizes lessons learned from an OIG audit without naming the hospital or exposing sensitive details. Recommendations are sector-wide best practices suitable for public use.