Healthcare Cybersecurity: Software Security, HIPAA Compliance & Best Practices.

Healthcare organizations faced 410 ransomware attacks worldwide in the first half of 2026, an average of 2.3 attacks per day, up nearly 14% from the 360 attacks recorded in the second half of 2025. 

Healthcare providers reported 770 HIPAA breaches in 2025, the highest annual total on record. 

And according to IBM’s 2026 Cost of a Data Breach Report, healthcare remains the single most expensive industry for a breach, at a global average of $6.6 million per incident, the 13th year in a row it has held that position.

Key Takeaways

• Healthcare faced 410 ransomware attacks in H1 2026, averaging 2.3 attacks per day worldwide.
• Attacks on healthcare businesses rose 35% in H1 2026, while attacks on hospitals rose just 3%.
• HIPAA Security Rule’s MFA and encryption mandate is proposed only, now delayed to July 2027.
• Change Healthcare, Ascension, and Synnovis breaches each show how vendor compromise cascades into patient harm.
• Synnovis’s root cause was one service account without MFA, disrupting care for over three months.

Those numbers describe a sector under sustained, structural pressure, not a bad quarter. And in healthcare, a cyber incident is rarely just a data problem. 

When a ransomware attack takes down an EHR, a lab system, or a scheduling platform, care gets delayed, procedures get canceled, and in the worst cases, patients get hurt. 

That is the core difference between healthcare cybersecurity and cybersecurity everywhere else: downtime is not an inconvenience, it is a patient-safety event.

Three incidents from the last two years make the stakes concrete. 

The February 2024 ransomware attack on Change Healthcare, a UnitedHealth-owned claims processor, exposed more than 100 million records, the largest healthcare data breach ever reported to federal regulators, and cost UnitedHealth well over $2 billion in direct and business disruption costs. 

In May 2024, a ransomware attack on Ascension Health, one of the largest nonprofit health systems in the US, exposed data on 5.6 million patients and forced roughly 140 hospitals back onto paper charting for about five weeks. 

And in June 2024, a ransomware attack on Synnovis, a pathology lab partner to several London NHS trusts, disrupted blood testing and diagnostics for more than three months, delayed over 11,000 outpatient and elective procedures, and was linked to at least one patient death. 

The root cause, according to the NHS’s own review, was a service account that did not have multi-factor authentication enabled.

Security and engineering leaders in healthcare are bombarded with frameworks, vendor claims, and compliance checklists, but rarely get a clear line from “here is the threat” to “here is the control” to “here is what we actually build and operate.” This guide draws that line: the current threat landscape, what is and is not changing in the HIPAA Security Rule, how to use NIST CSF 2.0 and HHS 405d without drowning in overlapping frameworks, concrete software security practices for healthcare applications, and what incident response readiness actually requires.

The Threat Landscape: Ransomware, Supply Chain, and API Risk

Ransomware: volume, targets, tactics

Comparitech’s tracking shows the ransomware picture splitting into two distinct trends. Attacks on direct care providers, hospitals and clinics, rose only about 3% in H1 2026 versus H2 2025. 

Attacks on healthcare businesses, meaning pharmaceutical and device manufacturers, medical billing firms, and healthtech vendors, jumped nearly 35% over the same period, with medical retailers and drug wholesalers seeing the sharpest increase at 67%. 

The clear implication for any healthtech vendor or billing partner reading this: you are now a primary target in your own right, not incidental collateral damage from an attack on a hospital.

Median ransom demands in H1 2026 sat around $310,000 for healthcare providers and $300,000 for healthcare businesses globally, though individual demands have run far higher; one Japanese hospital system faced a $100 million demand in early 2026. 

The Synnovis case above is a useful reminder of where these attacks typically start: a single unprotected credential or service account, not a sophisticated zero-day.

Supply chain and third-party risk

The three headline incidents above share a pattern. Change Healthcare was a claims clearinghouse, not a hospital. Synnovis was a lab partner, not an NHS trust directly. 

In both cases, compromising one vendor cascaded into disruption across dozens of downstream healthcare organizations that had no direct control over that vendor’s security posture. 

As ransomware groups increasingly recognize that a single compromised billing company, interface engine provider, or managed service provider can expose far more organizations than attacking one hospital at a time, third-party and supply chain risk has moved from a compliance checkbox to a primary attack vector.

API and application-layer risk

Modern healthcare software is built on APIs: FHIR interfaces to EHRs, HL7 feeds from lab systems, integrations with pharmacies, payers, and identity providers. 

Each of those integration points is also a potential attack surface, particularly when API tokens are over-permissioned, FHIR scopes are too broad, or bulk data exports are possible through a single compromised credential. 

As breach volumes climb and business associates increasingly sit at the center of the largest incidents, API and integration security has become a core, explicit component of HIPAA’s required risk analysis, not an optional technical nicety layered on top of it.

These threats map directly onto the technical safeguards structure of the HIPAA Security Rule and onto the Identify, Protect, Detect, Respond, Recover, and Govern functions of NIST CSF 2.0, which is exactly why the next two sections translate threat into control.

HIPAA Security Rule: What Is Actually Changing, and When

This is the section where accuracy matters most, because the regulatory timeline has shifted since the original proposal.

In January 2025, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking (NPRM) to overhaul the HIPAA Security Rule for the first time in more than a decade, the largest proposed update since the 2013 Omnibus Rule.

The proposal would eliminate the old distinction between “required” and “addressable” safeguards, making virtually every listed safeguard mandatory. 

Keyproposed changes include: encryption of ePHI at rest and in transit with only narrow exceptions, mandatory multi-factor authentication for all access to ePHI, vulnerability scanning at least every six months, penetration testing at least once every twelve months, mandatory network segmentation, written technology asset inventories and network maps, and consistent, ongoing verification of business associates’ compliance.

As of this writing, the rule remains proposed, not final. Public comment closed in March 2025 with roughly 4,000 submissions, and reporting in mid-2026 indicates OCR has delayed finalizing the rule from an originally expected date in May 2026 to July 2027, following organized pushback from more than 100 hospital systems and provider associations over implementation cost and timeline. 

Do not build a compliance program that assumes this rule is already in force. It is not, and the timeline has already moved once.

That said, three things make the direction of travel worth building toward now rather than waiting for a final rule. 

First, OCR’s own enforcement posture and its Risk Analysis Initiative have already increased scrutiny of exactly the gaps the NPRM targets: missing MFA, unencrypted ePHI, and stale risk assessments. Second, every major incident referenced above, including Synnovis’s root cause, traces back to a control the proposed rule would make mandatory. 

Third, hospital and payer security reviews increasingly treat MFA, full encryption, and current risk assessments as baseline expectations for any vendor today, regardless of what the federal rule technically requires yet.

Table 1: HIPAA Security Rule, current baseline vs. proposed rule

The five technical safeguards, translated to software controls

The existing Security Rule’s technical safeguards, at 45 CFR §164.312, already give engineering teams a concrete structure, independent of what the NPRM ultimately requires.

Access control: unique user IDs, emergency access procedures, automatic session logoff, and encryption. In practice: enforce MFA for every account touching ePHI, apply role-based access control at least privilege, and revoke access promptly, ideally within an hour, of role change or termination.

Audit controls: mechanisms to record and examine ePHI access and activity. In practice: centralized logging across applications, APIs, databases, and admin consoles, with audit logs retained for at least six years and protected from tampering.

Integrity: policies to ensure ePHI is not improperly altered or destroyed. In practice: checksums and versioning on critical data, immutable backups, and change management workflows with approval and rollback.

Person or entity authentication: verifying that whoever is requesting access is who they claim to be. In practice: MFA everywhere feasible, including for service accounts, strong password policy, and passkeys or hardware tokens for high-risk administrative roles.

Transmission security: guarding ePHI in transit over networks. In practice: TLS 1.2 or higher, preferably 1.3, on every connection, web, mobile, API, and service-to-service, with AES-256 or equivalent encryption at rest.

Layered on top of the technical safeguards, teams should run a documented risk analysis at least annually and after major architecture changes, maintain a living inventory of every system, API, and interface engine that touches PHI, and treat business associate agreements as living documents that require ongoing evidence of compliance, not a one-time signature.

Frameworks That Work Together: NIST CSF 2.0, HHS 405d, HITRUST

Do not try to implement every framework simultaneously. Layer them deliberately.

HIPAA Security Rule is your compliance floor, non-negotiable, legally required for covered entities and business associates.

NIST Cybersecurity Framework 2.0 is your operating model, organized around six functions: Identify (asset inventory including medical devices, risk assessment, supply chain risk), Protect (MFA, encryption, RBAC, secure configuration, awareness training), Detect (SIEM, endpoint detection, anomaly detection, API monitoring), Respond (incident response playbooks, tabletop exercises), Recover (tested backups and disaster recovery), and Govern, the function CSF 2.0 added specifically to address risk appetite, oversight, and accountability at the leadership level. CSF 2.0 gives teams a current-state versus target-state profile they can track progress against over time, rather than a pass or fail audit.

HHS 405d Health Industry Cybersecurity Practices (HICP) is a voluntary, healthcare-specific set of practices developed by HHS with sector input, covering email protection, endpoint security, asset management, access management, data protection, security awareness, and vendor management. It gives providers, payers, and vendors a shared vocabulary, and OCR and cyber insurers increasingly reference it as a practical baseline.

HITRUST CSF is a certifiable framework layered on top of HIPAA, NIST, and ISO standards, purpose-built for healthcare. Many hospitals and payers now require it of vendors directly. It demands a broader, more rigorous control set than HIPAA alone, and a heavier evidence burden.

A practical sequencing: treat HIPAA as the floor everyone must clear, adopt NIST CSF 2.0 as the operating model you track internally, layer in HHS 405d HICP for healthcare-specific practices, and pursue HITRUST when a key customer requires it or when you need a differentiator against competitors who have not made the investment.

Software Security Best Practices for Healthcare Applications

Secure design and threat modeling

Classify data flows by PHI sensitivity before a line of code is written. Threat-model every interface point explicitly, EHR and FHIR/HL7 integrations, interface engines, and third-party APIs for payments, identity, and analytics. 

For connected medical devices, align with the FDA’s Secure Product Development Framework expectations: threat modeling, security risk assessments, architecture documentation, and testing reports integrated directly into your quality management system.

Access control and identity

Enforce MFA on every account with PHI access, including service and integration accounts wherever technically feasible, since an unprotected service account is exactly what enabled the Synnovis breach.

 Build RBAC around clinical and administrative roles, not individuals, default to least privilege (a scheduling app has no legitimate need for write access to lab results), and recertify access on a fixed cadence, quarterly at minimum, plus immediately on any role change or termination.

API and integration security

Inventory every API and flag which ones touch PHI before any integration goes live. Use OAuth 2.0, OIDC, and SMART on FHIR correctly: confidential, server-to-server clients should use the client credentials grant with secrets stored in a managed secret manager and rotated regularly; public clients such as mobile apps or single-page apps should use the authorization code grant with PKCE. 

Keep access tokens short-lived, five to sixty minutes, use refresh tokens for re-authentication, and never store tokens in localStorage or unsecured cookies. Encrypt every connection with TLS 1.2 or higher, including internal service-to-service traffic, route everything through an API gateway for token validation, schema validation, and rate limiting, and alert on bulk export patterns and other token-theft indicators.

Secure coding and testing

Run static analysis in CI and dynamic analysis in staging for every PHI-handling workflow. Use parameterized queries against SQL injection and allowlist validation for HL7 segments, FHIR fields, and form inputs. Pair automated scanning with manual penetration testing on any workflow that touches PHI. For medical device software specifically, maintain a Software Bill of Materials covering every third-party and open-source component, and update it as the product evolves.

Data protection and cryptography

Encrypt ePHI at rest with AES-256 or equivalent, backed by proper key management through a KMS or HSM. Where required, use FIPS-validated cryptographic modules, and secure wireless device communication with WPA3 Enterprise or equivalent. Implement immutable backups and actually test restoration under realistic conditions on a regular schedule, not just on paper.

Medical device and IoT security

Maintain an authoritative inventory of every connected medical device: model, firmware version, connectivity type, and protocol. Segment clinical device networks from general IT networks using VLANs, firewalls, and DMZs, and consider air-gapping the most critical devices. Require MFA for any administrative access to device configuration or firmware update functions, and fold device risk directly into enterprise risk management rather than treating it as a separate IT concern.

Incident Response and Breach Notification: What Teams Must Have Ready

Prevention is necessary but not sufficient. A documented incident response plan needs defined roles across security, IT, legal, compliance, communications, and clinical leadership, plus specific playbooks for ransomware, data exfiltration, API compromise, and medical device incidents. 

Run tabletop exercises that include realistic clinical scenarios, an EHR outage, a network isolation event on infusion pumps, not just generic IT scenarios.

On breach notification, HIPAA requires notifying affected individuals and HHS OCR, and in larger breaches the media, within defined timelines, and business associate agreements should specify notification timelines between partners so no one downstream learns about an incident from the news. 

Treat ransomware as a presumed breach unless you can affirmatively demonstrate a low probability that PHI was compromised. Engage law enforcement early, IBM’s own research has found that involving law enforcement in a ransomware case reduces the average cost of the breach, and coordinate closely with cyber insurance from the outset rather than after the fact.

After any incident, run a genuine root-cause analysis, update the risk assessment and controls accordingly, and share appropriate lessons learned with business associates and stakeholders. The Synnovis case is again instructive here: a specific, identifiable, fixable gap (MFA on a service account) led to months of cascading harm across an entire regional health system.

Common Pitfalls and How to Avoid Them

Treating MFA and encryption as optional. They are the direction every recent framework and every major 2024 incident points toward, regardless of final rule status. Fix: enforce both now, everywhere feasible, and keep evidence that they are actually configured and operating.

Incomplete asset and API inventories. You cannot protect what you do not know exists, and the API attack surface in particular tends to be undercounted. Fix: maintain a living inventory of every app, API, interface, and device touching PHI, reviewed at least annually.

Over-reliance on perimeter defenses. Firewalls and antivirus are necessary but insufficient against credential abuse and ransomware. Fix: adopt zero-trust principles, least privilege, and continuous monitoring as the default posture, not the exception.

Ignoring medical device and IoT risk. Devices are routinely excluded from general IT risk assessments despite carrying the highest clinical impact when compromised. Fix: fold device risk directly into enterprise risk management and network segmentation planning.

Untested incident response and backup restoration. Plans that exist only on paper reliably fail under real pressure. Fix: run realistic drills on a fixed schedule, and actually test backup restoration rather than assuming it will work.

From Compliance Checklist to Resilient Security Posture

Healthcare cybersecurity in 2026 is not primarily about passing an audit. It is about protecting patients, care delivery, and organizational viability, and the incidents at Change Healthcare, Ascension, and Synnovis all show what happens when that protection fails. 

Use the current HIPAA Security Rule as your compliance floor, watch the NPRM’s July 2027 timeline rather than assuming it is already law, and layer NIST CSF 2.0, HHS 405d HICP, and HITRUST where they genuinely add operating maturity or customer requirements.

For engineering teams specifically, the throughline across every framework in this guide is the same: embed security into design, coding, testing, and operations from the start, with particular weight on access control, API security, and data protection, since those are exactly where the last two years of major healthcare breaches began.

Reviewing your security posture against the 2026 threat landscape? TechAhead’s healthtech engineering team is glad to walk through your architecture and controls.