Picture the first Tuesday clinic of the month at a district general hospital: twenty-eight outpatient slots booked through a third-party portal, a pathology feed arriving over SFTP from a regional lab, community nurses logging in through a VPN concentrator that was sized in 2019, and a website that quietly stopped being the trust’s problem the day the original web agency took over the domain. Then the portal stops answering. DDoS attacks on healthcare providers rarely succeed because the traffic volume was extraordinary; they succeed because one of those components had no owner, no mitigation and nobody awake to act on it.

This piece does not rehearse sector statistics. It names the six places UK health estates actually break during a denial-of-service event, and what to put in a contract so they do not break twice.

Why health estates fall over at volumes other sectors absorb

A bank runs its own autonomous system, its own IP space and a security operations centre with a rota. A trust runs a federation. The main website might sit with a regional NHS host, the patient portal with a clinical software vendor, e-referral with another, video consultation with a third, the integration engine on a virtual machine in a shared data centre, and the authoritative DNS wherever it was parked a decade ago. Six owners, six contracts, six different answers to the question of who is allowed to phone a mitigation provider at 02:00.

The damaging outcome in a clinical setting is not data theft. It is unavailability. A booking engine that is unreachable for ninety minutes produces paper fallback, phone triage, a clinic list worked from printouts, and a rebooking backlog that is still being cleared weeks later. Ambulance diversion is the extreme case, but the ordinary case is quietly expensive: consultant time burned on a stalled list, administrative overtime, and appointment slots that cannot be recovered because the capacity simply does not exist.

Motive shapes the target, not the size of the pipe

Hacktivist pressure campaigns pick targets for visibility, which means public-facing portals and anything with a recognisable name. The US Department of Health and Human Services’ Health Sector Cybersecurity Coordination Center (HC3) published an analyst note in January 2023 on the pro-Russian group KillNet targeting the health sector with denial-of-service attacks, and pro-Russian groups have since claimed attacks against European public sector sites. Ransom-motivated actors behave differently: they time the disruption around a known pressure point, such as a winter surge or the first working day after a bank holiday, and they test which surface hurts most. Reading the motive early tells you whether to expect a short noisy burst or a sustained campaign, which is the practical value of understanding what hacktivist attack motives predict.

Weak point 1: authoritative DNS that nobody in the trust owns

Ask an information governance lead who manages the trust’s authoritative nameservers and the answer is often a pause. The zone is frequently still with the agency that built the original site, or inside a legacy hosting account whose billing contact left in 2018. Domain Name System (DNS) is the layer most reliably left unmanaged in health estates, and it is the one with the widest blast radius.

A query flood against a single authoritative provider does not take down one website. It takes down every name in that zone at once: the patient portal, staff email routing, the identity provider used for single sign-on, and any API hostname your suppliers resolve. Web application firewalls and reverse proxies are irrelevant at that point, because nothing ever resolves far enough to reach them.

Three practical steps. Inventory every zone the organisation depends on, including the ones registered by departments and charities under your name. Check whether you have genuinely diverse authoritative nameservers (two providers, separate anycast networks, not two hostnames on one platform). Set time-to-live values you can actually work with during an incident, because a 24-hour TTL means your emergency change takes a day to propagate. The detail of provider selection is covered in this buyer’s guide to authoritative DNS protection.

Questions worth putting to your DNS host in writing: what query-per-second capacity do you provision per customer, how many points of presence carry our zone, and who answers the phone at 02:00 on Boxing Day?

Weak point 2: origin IP leakage behind the patient portal

Proxy bypass is the most common way a protected site falls over, and it is almost never a capacity problem. The attacker has simply found a route that goes around the proxy entirely.

Health estates leak origins in predictable places: an old A record for a decommissioned booking subdomain that still points at the real server, a UAT or staging environment on the same subnet, a mail host sharing the range, a certificate transparency log entry naming an internal hostname, or a PDF and imaging endpoint serving large files straight from the origin because someone excluded it from the proxy for performance. Attackers enumerate those first. Appointment booking and repeat prescription ordering are the endpoints they probe hardest, because both are expensive per request on the back end.

The fix is unglamorous. Lock the origin firewall to the proxy’s published address ranges, deny everything else, then verify it from outside your network rather than assuming the rule works. Re-verify after every migration. Application-layer protection is only as good as the path discipline underneath it, which is the recurring theme of these application layer protection gaps.

Weak point 3: clinical SaaS and integration layers outside your contract

Most clinical availability depends on networks the trust does not control. Booking engines, e-referral, remote patient monitoring, pathology result delivery, prescription services and video consultation platforms all sit on someone else’s infrastructure, often in shared tenancy where an attack aimed at a neighbour can degrade your service.

Protection so belongs in supplier contracts, not only in your own hosting arrangement. Insist on four things in writing: the named mitigation provider and the underlying network doing the scrubbing; a stated time to mitigate with the conditions under which the clock starts; a notification duty within a defined window when the supplier is under attack; and a written post-attack report with a vector breakdown.

Then do the mapping exercise. Take each clinical pathway and ask what happens if that one supplier is unreachable for two hours on a weekday morning. Some pathways degrade gracefully. Others stop. The ones that stop are the ones to argue about at contract renewal.

Weak point 4: remote clinician access and the network edge

VPN concentrators, remote desktop gateways and session brokers are low-capacity choke points sitting in front of high-value work. A state exhaustion attack fills the session table or the TLS handshake queue while using a fraction of the link’s bandwidth. Your monitoring shows the circuit at 12 per cent utilisation and the clinicians cannot log in. That combination causes more wasted triage time than any volumetric flood.

Reverse proxy protection does nothing here, because none of this is HTTP traffic you can route through a content delivery network. If your organisation holds its own IP space and autonomous system number, Border Gateway Protocol (BGP) based scrubbing covers the whole range, including SFTP result feeds, HL7 interfaces and API endpoints. If it does not, you need per-service protection from whoever owns the addresses, and you need to know that before an incident rather than during one.

Weak point 5: on-demand mitigation that misses clinical timeframes

On-demand mitigation sounds economical. Detection, then a BGP announcement, then route convergence, then traffic actually arriving at the scrubbing centre. Each step costs real minutes, and minutes map directly onto cancelled slots during a running clinic.

Read the service level agreement for what triggers the clock. A “15 second time to mitigate”usually assumes always-on traffic baselining, pre-agreed thresholds and signed-off authorisation; without those, the clock starts when a human on your side raises a ticket and gets authenticated. Ask who in your organisation is authorised to trigger mitigation out of hours, and check that person exists on an August bank holiday weekend. Many escalation matrices name a role rather than a rota.

Diversion has trade-offs worth stating openly: added latency on every clinical session, asymmetric routing that can break stateful appliances, and services (voice, some VPN tunnels, IP-allowlisted supplier feeds) that fail when source addresses change. Test those before you need them, not at 09:15 on a Monday.

Weak point 6: a ‘managed’ contract that is really a portal login

The dividing line is simple. Managed means onboarding and rule tuning against your real traffic, a tested runbook, a named escalation path and an engineer empowered to change policy during the attack without waiting for your ticket. If nobody on the provider’s side can act without your sign-off, you have bought monitoring, not management, and out of hours that means nobody acts at all.

In public sector procurement the resale chain matters. The logo on the quote is often not the network doing the scrubbing; capacity, peering and support hours frequently belong to a provider two steps down the chain. Ask who operates the scrubbing centres, where they are, and whether support is in-house or subcontracted overnight. Then judge on evidence: sample post-attack reports with real vector breakdowns, references from organisations of comparable size, and a straight answer on how false positives are handled.

Healthcare tuning has one rule generic providers get wrong. Never rate-limit a clinician into a locked-out state. Hospital networks present hundreds of users behind a handful of NAT addresses, kiosk browsers carry odd user agents, and automated feeds (results, device telemetry, interoperability polling) look exactly like scripted abuse to a default ruleset. Allowlist them deliberately, by source and by behaviour, before go-live. General principles on how denial-of-service attacks work and how they are mitigated are a useful grounding for the governance papers that accompany this sort of procurement.

Building the business case and surviving the first hour

Price the downtime before you price the protection. Take one cancelled outpatient list: the lost slots, consultant and nursing time spent on paper fallback, administrative overtime, out-of-hours recovery, and the rebooking backlog that spreads across the following weeks. Put a figure against it using your own costing data, then set that beside an annual protection contract. That comparison persuades finance directors; fear does not.

UK managed protection is usually priced on a committed bandwidth or protected-IP basis with a monthly fee, plus onboarding, and often with burst or overage charges once attack traffic exceeds a threshold. The line items buyers forget at first invoice are additional protected subnets, extra portal users, out-of-scope incident response hours and the cost of a second mitigation point for DNS. The breakdown in this guide to what UK DDoS protection actually costs is a reasonable starting point for a budget paper.

For the first hour, work in sequence. Confirm it is an attack rather than a failed deployment or an upstream fault, using the approach in this piece on telling a DDoS apart from an ordinary outage. Check three surfaces in order: DNS resolution, the proxy or edge, then the origin and the remote access concentrators. Notify affected clinical suppliers and ask them to confirm their own status. Capture evidence as you go (packet samples, flow records, timestamps, portal screenshots), because reconstruction afterwards is always worse.

Governance follows. Inform the on-call director and the information governance lead, log the incident against the NHS Data Security and Protection Toolkit processes your organisation already uses, and consider obligations under the Network and Information Systems Regulations 2018 if your organisation is designated an operator of essential services. UK GDPR Article 32 expects availability and resilience of processing systems, so a sustained outage is a security matter, not only an operational one. Denial-of-service attacks are offences under the Computer Misuse Act 1990, which is the basis for reporting to Action Fraud and, for significant incidents, to the National Cyber Security Centre.

Frequently Asked Questions

Why are healthcare providers targeted by DDoS attacks?

Visibility and urgency. Hacktivist groups choose targets whose disruption gets reported, and health services qualify; HC3 in the United States issued an analyst note in January 2023 about pro-Russian actors targeting the sector. Extortion-motivated attackers pick healthcare because the tolerance for downtime is close to zero, which increases the chance of a fast payment or a fast concession.

Can a DDoS attack on a hospital affect patient care directly?

Yes, indirectly but materially. If booking, e-referral, results delivery or remote clinician access is unreachable, staff revert to paper and telephone, lists slow down and appointments get cancelled. The clinical risk sits mostly in delayed care and the backlog, rather than in any loss of patient data.

Does a patient portal behind a reverse proxy still need network-level protection?

Usually, yes. A proxy only protects traffic that goes through it, so a reachable origin, an exposed UAT host or a mail server on the same range reopens the direct path. Non-HTTP services (VPN, SFTP feeds, HL7 interfaces) are not covered by a web proxy at all.

How much does managed DDoS protection cost for an NHS trust or private hospital group?

Pricing varies by committed clean bandwidth, number of protected IP ranges, always-on versus on-demand, and support hours, so there is no single figure worth quoting. Build the comparison from your own downtime cost per cancelled clinic list, and ask every bidder to quote onboarding, overage and out-of-scope incident hours separately.

What should we do in the first hour of a suspected DDoS attack on a clinical system?

Confirm it is an attack rather than a deployment or upstream failure, then check DNS, the edge and the origin in that order. Notify your mitigation provider and any affected clinical suppliers, start the clinical fallback process, and record evidence with timestamps for reporting to Action Fraud and the NCSC and for any later contractual or legal action.