A hospital's public website is rarely what an attacker wants to take down. It is just the address they can find.
What sits behind that address decides whether the attack is an embarrassment or a clinical incident. On many sites the brochure pages, the patient portal, the cloud-hosted health record, the pharmacy's prescription feed and the switchboard all leave the building through the same circuit.
Healthcare also has something most industries lack: a rehearsed way to keep working without the computers. Wards have downtime forms and pharmacies have manual procedures. The question a test answers is whether your systems hand staff over to those procedures in time, or keep them waiting at a spinner while patients queue.
What is DDoS testing for healthcare?
DDoS testing for healthcare is an authorised test of whether patient-facing and clinical services hold up under attack, and where they do not, whether they fail clearly enough for staff and patients to switch to the fallback. It covers portals, telehealth, booking, e-prescribing paths and the internet edge those share. The pass mark is the share of patient encounters that either complete or move cleanly to the downtime procedure.
This page assumes the general method of an engagement, which is written up once in the complete guide to DDoS testing. Its own subject is hospitals, practices, pharmacies and the shared services that connect them.
| What is attacked | What patients or staff lose | What to measure |
|---|---|---|
| Public site and portal | booking, results, repeat prescriptions | completed bookings, error clarity |
| Shared internet circuit | the record, imaging, lab results, phones | which clinical flows share the path |
| A national or regional service | prescriptions, identity, record sharing | time to a clear error on your side |
| Telehealth | the appointment slot | consults connected within the slot |
| Over-eager mitigation | access for the patients least able to retry | false blocks by patient group |
The encounter is the unit, and most encounters have a paper path
Downtime minutes are the wrong count for a hospital. The count that matters is encounters: a prescription at the counter, a result a clinician needs before deciding, a consult booked for 10:30.
Clinical work was built to survive outages
Hospitals have run downtime procedures for as long as they have had computers. Paper charting, read-only copies of the record on standalone PCs, phoned-through lab results and manual dispensing records exist precisely so care continues when systems do not.
So a hospital test has two acceptable outcomes, not one. The service stays up, or it fails and staff are on the fallback within minutes.
A slow failure is the dangerous one
The bad outcome sits between those two. A request that hangs for ninety seconds and then half-loads gives nobody a reason to declare downtime. Staff retry, call the service desk, try another PC, and the queue at the counter grows.
A flood rarely produces a clean outage. It produces slowness, partial loads and intermittent timeouts, which is exactly the state in which nobody declares anything.
What to test
For every clinical flow that leaves the building, measure the time from losing the dependency to an unambiguous message on a clinician's screen. Timeouts set in minutes, silent retries and a generic "something went wrong" all count against you.
Circuit breakers and short timeouts are the engineering side of this, and the microservices post covers how to exercise them. The healthcare side is the screen: the error has to say which system is unavailable, so a nurse knows which downtime form to pick up.
One circuit carries the website and the clinical record
The attacker chose the website because it is public. What they hit is whatever shares its path to the internet.
What shares the pipe
On a typical hospital or practice site, look at what crosses the same internet circuit and firewall as the public web presence:
- sessions to a cloud-hosted or remotely hosted electronic health record
- e-prescription messages to pharmacies and national prescription services
- imaging exchange with other sites and outsourced reporting
- result and order interfaces to outside laboratories
- the switchboard, if its trunk is SIP over the same connection
- clinician remote access, which the VPN post treats in depth
A volumetric flood fills the circuit before the on-site firewall can drop a single packet. Every flow in that list degrades at once, whichever address the attacker aimed at.
Healthcare websites are a documented target
In April 2014 Boston Children's Hospital was hit by a DDoS campaign tied to a public custody case; the hospital took some of its internet-facing services offline to protect the rest, and the man responsible was later convicted in federal court. In early 2023 the US health department's sector cybersecurity centre (HC3) warned hospitals that the pro-Russian KillNet group was running DDoS campaigns against US healthcare organisations.
Neither campaign needed patient data or a vulnerability. It needed a hostname and a reason, and hacktivist campaigns supply the reason.
What to test
Start on paper. List every public address on the site's circuits, then every clinical flow using those circuits, and draw the overlap. Most organisations have never drawn it.
Then test the separation. Where the public site and portal sit behind a provider's edge, confirm that the hospital's own public addresses are protected upstream as well, because the edge protects a hostname and the flood can be aimed at the prefix. Whether that upstream protection is always on or swung in on detection is the trade covered in DDoS protection in the path. In a hospital, measure the swing time against the downtime-declaration time from the previous section.
Shared national services you must not test
Healthcare runs on shared services that no single provider owns: national e-prescription services, patient identity and login services, health information exchanges, claims and eligibility clearing houses.
Concentration is the risk
The February 2024 attack on Change Healthcare was ransomware, not a DDoS, yet it showed what losing one shared dependency does. Pharmacies across the US struggled to process prescriptions and claims for weeks, and many providers found out only then how much of their revenue cycle ran through one company.
A DDoS on a shared service, or on the network path to it, produces the same shape of failure for as long as it lasts.
Test your side of the dependency
Those services are not yours, so you do not flood them. Ever. What you can test is your own behaviour when one is slow or unreachable: block egress to it in a test environment, or add latency with a fault-injection proxy, and watch what your systems and screens do.
Three things to look for:
- How long until the user sees a clear error naming the service.
- Whether outgoing messages queue locally, and whether anyone can see the queue.
- How the queue drains when the service returns. A thousand stored prescriptions resent in one second is your own flood on a service that is just recovering. Pace it.
When the portal fails, patients phone
Patients who cannot book online do not give up. They call, and then they turn up.
The morning rush
Many practices open booking at a fixed hour, and demand on the first hour is heavy enough that waiting on the phone at 8 a.m. is a familiar complaint in British general practice. Online booking exists partly to take that load off the phones.
A flood at that hour does not reduce demand. It moves it to a channel with a fixed number of lines and people.
The arithmetic
Take 1,200 booking attempts between 08:00 and 09:00, three minutes per call, and 30 lines staffed. Concurrent calls equal calls per minute times minutes per call.
With 80% booking online, 240 calls arrive in the hour: 4 a minute, 12 lines busy. With 60% online it is 24 lines. If the portal is down and all 1,200 phone, it is 20 a minute and 60 lines, double what is staffed.
The worst case is the slow failure again. If the portal hangs for twenty minutes before people give up on it, the same 1,200 calls arrive in forty minutes: 30 a minute, 90 lines.
The phones may be on the same circuit
If the practice or hospital phone system uses a SIP trunk over the internet connection under attack, the channel patients shift to is degraded by the same flood. A SIP flood is a separate risk; this one needs no SIP-aware attacker at all, only a full pipe.
Test it directly: during an off-hours test against the site's public prefix, place calls into the switchboard and measure call setup and audio quality.
Over-blocking a patient is a clinical event
In retail, a false block is a lost sale. In healthcare it can be a missed appointment, an unrequested repeat prescription or a result nobody read.
The patients least able to retry
Patient populations skew towards people who find extra steps hardest: older users, people using screen readers or switch access, people on old phones, people using a shared family device. Many of them reach the portal through carrier NAT, where per-IP limits misfire for reasons the mobile backend post explains.
Challenges are an accessibility barrier
Attack modes often turn on a CAPTCHA or a JavaScript challenge. The W3C has documented for years that CAPTCHAs exclude people with visual, cognitive and motor impairments, and a challenge that loops forever on an older browser locks that patient out completely.
A healthcare portal can still use challenges. It has to know who they stop.
Lockout as a side effect
Credential-stuffing waves that ride along with a flood can trip per-account lockout, and a locked patient account is a phone call at best. Count lockouts on test accounts during any L7 test, and check whether lockout is per account only or reacts to the pattern across many accounts.
What to test
Run real assistive technology through the portal with attack-mode controls switched on: NVDA or JAWS on Windows, VoiceOver on iOS, an older Android phone on a mobile network. Book an appointment, request a repeat prescription, read a result.
Then measure the false positive rate by group, not as one number. A 1% average can hide 15% for the patients on one carrier or one browser.
Telehealth: the slot either connects or is lost
A video consult is booked for a time and a clinician. If it does not connect in the first few minutes, the clinician moves to the next patient, and the slot is gone.
Session setup is the weak moment
A consult needs signalling, a media path, and usually a relay (TURN) server for patients behind restrictive NAT. Established media flows tend to tolerate stress better than session setup does, so an attack that degrades signalling or relay allocation stops new consults while running ones carry on. Monitoring that watches active sessions sees nothing wrong.
Signalling often runs over WebSockets, and its connection-level failure modes are in the WebSocket post.
What to measure
The measure is the share of consults that connect within, say, three minutes of the slot starting, split by patient network type. Then check the fallback: does the clinician get a clear signal to switch to a phone consult, and does the patient get the call?
Regulators ask about contingency, not DDoS
Few healthcare rules mention DDoS by name. Most ask whether you can keep operating, and whether you have tested that you can.
In the US, the HIPAA Security Rule's contingency-plan standard (45 CFR 164.308(a)(7)) requires an emergency mode operation plan and lists testing and revision of contingency plans as an addressable specification. In the EU, NIS2 lists healthcare providers among sectors of high criticality. In England, NHS organisations report against the Data Security and Protection Toolkit, and the UK's NIS Regulations cover parts of the health sector; the UK DDoS testing post covers that wider landscape.
The useful reading for a test: results that show how long each clinical flow takes to reach its fallback are evidence of a tested contingency plan, not only of a tested firewall. This is a summary, not legal advice; check the current text and your own obligations with your compliance team.
Where a healthcare test must never point
Some targets are simply off limits, whatever the authorisation says.
Out of scope, always
- medical devices and anything on a clinical device network
- on-site clinical systems directly, rather than the internet edge in front of them
- national and regional shared services, and other organisations' systems
- live patient accounts
Running it safely
Hospitals do not have a quiet hour, so pick the lowest-acuity window the clinical teams agree to, brief the site's on-call managers and clinical safety lead, and keep downtime procedures ready to invoke. The traffic-side safeguards are the usual ones, set out in testing without disrupting production.
The healthcare addition is a stop rule anyone clinical can call: if a ward, pharmacy or emergency department reports a system slowing down, the test stops, no discussion. Rehearsing the downtime declaration itself is better done as a tabletop exercise first.
A healthcare DDoS testing checklist
- Draw which clinical flows share an internet circuit and firewall with public addresses.
- Confirm upstream protection covers the hospital's own prefixes, not only portal hostnames.
- For each clinical flow, measure time from dependency loss to a clear, named error on screen.
- Simulate each shared national service as unreachable, in a test environment, and watch queues form and drain.
- Confirm queued messages resend at a paced rate.
- Model phone-line demand at the booking peak with the portal down and with it hanging.
- Check whether the phone system rides the same circuit, and test call quality under load.
- Walk the portal with assistive technology and older devices while attack-mode controls are on.
- Measure the share of telehealth consults connected within the slot, by network type.
- Agree a clinical stop rule and the out-of-scope list in writing before any traffic is sent.
FAQ
Is DDoS testing safe for a hospital?
It can be, if it targets the internet edge rather than clinical systems, excludes medical devices and shared national services, runs in an agreed low-acuity window and has a stop rule that clinical staff can invoke. Much of the most useful work, such as mapping shared circuits and simulating lost dependencies, involves no flood at all.
Does HIPAA require DDoS testing?
HIPAA does not name DDoS. Its Security Rule requires a contingency plan, including emergency mode operation, and treats testing of contingency plans as an addressable specification. DDoS test results can serve as evidence for that testing. This is not legal advice.
Why would attackers target a hospital website?
Mostly for visibility. Hacktivist groups pick targets that make news, and healthcare does; HC3 warned US hospitals about KillNet DDoS campaigns in 2023. The website matters less than what shares its network path.
Should a patient portal use CAPTCHA during an attack?
It can, but test who it stops. CAPTCHAs and some JavaScript challenges exclude users of assistive technology and older devices, who are over-represented among patients. Measure false blocks per group with the challenge switched on.
What should a healthcare DDoS test measure?
Encounters, not uptime: bookings completed, prescriptions sent, consults connected within their slot, and for each clinical flow the time it takes to reach a clear error and the downtime procedure. Add phone-line load and false blocks by patient group.
Clinicians already know how to work offline
Most industries treat their systems as the service. Healthcare never fully did, and its paper procedures are a reminder that the system was always a means to an encounter.
So the durable question is narrower than whether the portal survives the next flood. It is how quickly the systems admit they are down, so that people who already know how to work without them can begin.