A 180-bed regional hospital in the Midwest lost its EMR at 2:14 a.m. on a Tuesday. The night-shift charge nurse noticed first — the Cerner terminal froze, came back to a lock screen she didn't recognize, then went black. By 2:40, the entire fourth floor was on paper. By 3:15, the ED was running on whiteboards and memory. Nurses were walking lab results between floors because the pneumatic tube system's controller had also gone down — it ran on the same network segment.

The CIO told me later that the part that shook him wasn't the ransomware demand. It was watching his team revert to procedures none of them had practiced since nursing school. He said it felt like watching an episode of Pitt, except the cameras weren't rolling and nobody was going to yell cut.

He wasn't being dramatic. If you've watched Pitt — the Max series set in a Pittsburgh trauma center — you've seen what happens when a hospital's digital infrastructure disappears. Systems go dark. Staff improvise. Patient data lives on sticky notes and shouted vitals. The show treats it as a dramatic set piece. For 389 U.S. hospitals hit by ransomware in 2025 alone, it was a Tuesday.

I keep coming back to this gap between fiction and operations. The entertainment industry has figured out that hospital cyberattacks make great television because the stakes are life and death and the failure mode is visceral — humans scrambling without the tools they've been trained to rely on. What the entertainment industry hasn't figured out, and what most healthcare security vendors haven't either, is that the attack surface making this possible is not the EMR. It's the building.

The systems that fail first and recover last in a healthcare cyberattack are not the clinical applications. They're the operational technology: HVAC controllers, pneumatic tube systems, nurse call stations, infusion pump networks, building management systems, medical gas monitors. These are the systems that turn a ransomware event from a billing disruption into a patient safety crisis. And almost nobody is scanning them.

The building is the attack surface

I spent a week last year walking the basements of three hospitals — two mid-size, one rural critical-access — documenting every networked device that wasn't a workstation or a printer. The list was longer than anyone expected.

Building management systems running BACnet on flat networks with no segmentation. Pneumatic tube controllers on Windows Embedded that hadn't seen a patch since 2019. HVAC units with default credentials accessible from the same VLAN as the nursing stations. Nurse call systems whose firmware update process required a vendor visit that nobody had scheduled in four years. Medical gas monitoring panels with Modbus/TCP interfaces that responded to unauthenticated queries from any device on the subnet.

None of these showed up in any of the three hospitals' IT asset inventories. The IT teams knew about servers, workstations, network gear. The facilities teams knew about the physical plant. Nobody owned the gap between them, and that gap was running on protocols designed in the 1990s for environments where the threat model was "the serial cable might get unplugged."

This is what I mean when I say the building is the attack surface. A ransomware operator who lands on a hospital network and finds BACnet devices responding to unauthenticated read/write requests doesn't just have leverage for a ransom. They have the ability to alter HVAC setpoints in surgical suites, disable nurse call systems, disrupt pneumatic tube routing, and interfere with medical gas monitoring — all without touching a single clinical application. The EMR can stay up and running. The hospital still can't safely operate.

In the Pitt pilot, the chaos starts with monitors going dark. In the real incidents I've reviewed, the chaos starts with the infrastructure nobody thought of as "cyber."

AI made the attacker faster than your patch cycle

The asymmetry in healthcare cybersecurity has always been stark. Attackers move fast; hospitals move slow. But AI has made this gap qualitatively different, not just wider.

I've been tracking the evolution of healthcare-targeting ransomware groups for two years now. The shift started in late 2024 and accelerated through 2025. What changed wasn't the malware itself — it was the reconnaissance. Groups are using LLM-assisted tooling to automate the exact kind of OT discovery I described doing manually in those hospital basements. Automated BACnet enumeration. Automated Modbus device fingerprinting. Automated identification of which building-management protocols are exposed and what default credentials they ship with.

A human operator doing this manually against a single hospital takes days. An AI-assisted pipeline does it against dozens of targets concurrently, triaging which hospitals have the most exposed OT infrastructure and therefore the most operational leverage for a ransom demand. The attacker doesn't need to understand HVAC control systems. The LLM reads the protocol documentation and generates the probe sequences.

This should worry every healthcare CISO, regardless of institution size. The economics of targeting have changed. It used to be that a 50-bed rural hospital wasn't worth the effort compared to a 500-bed academic medical center. When reconnaissance is automated and nearly free, every hospital with an internet-facing IP range is a candidate. The attacker's AI doesn't care about your bed count. It cares about your exposed BACnet port.

The 2025 numbers bear this out. Of those 389 ransomware incidents in U.S. hospitals, 41% were at facilities with fewer than 100 beds. The long tail of small and mid-size hospitals — the ones least likely to have dedicated security staff — is now the primary target pool. The Pitt scenario isn't reserved for large urban trauma centers with dramatic storylines. It's playing out in critical-access hospitals where the nearest backup facility is forty miles away and the IT department is one person who also manages the phone system.

Compliance frameworks know this but compliance alone doesn't fix it

HIPAA's Security Rule has required technical safeguards since 2005. The problem was never the requirement — it was the gap between what the regulation demands and what hospitals actually have the capability to assess.

Ask a compliance officer at a 120-bed community hospital whether they've conducted a risk assessment of their OT infrastructure. Most will tell you their risk assessment covers the EMR, the billing system, the patient portal, and the network perimeter. Maybe the medical devices if they're forward-leaning. Almost never the building management systems, the pneumatic tubes, the nurse call stations, or the HVAC controllers. Not because they don't care, but because they don't have a scanner that speaks BACnet and Modbus, and their compliance framework templates don't have a line item for "building automation system running unauthenticated protocol on clinical network."

This is where I think the industry has failed healthcare. We've built compliance tools that check boxes against the EMR and call it done. We've built vulnerability scanners that speak HTTP and SSH and call the network "scanned." Neither finds the Siemens HVAC controller with default credentials on the same subnet as the cardiac monitors.

The frameworks themselves are getting better. NIST's Healthcare Cybersecurity Framework, HHS's updated HIPAA Security Rule proposed in 2025, and the FDA's premarket cybersecurity guidance all now explicitly call out connected medical devices and operational technology. But a framework that says "assess your OT" is useless without a tool that can actually do it safely — without disrupting the devices it's scanning, without flooding fragile BACnet networks with traffic they can't handle, and without requiring a protocol expert on-site to interpret the results.

What OT scanning in healthcare actually looks like

This is the problem we built cyprobe to solve. It's a purpose-built OT and SCADA discovery and posture engine — not a network scanner with OT support bolted on as a feature checkbox. A tool that speaks the native protocols — BACnet, Modbus/TCP, EtherNet/IP, DICOM, HL7 MLLP — and understands what the responses mean in a healthcare context.

Here's what a cyprobe scan against a hospital network actually produces. First, it discovers every OT device on reachable subnets using protocol-native probes. No aggressive port scanning. No banner grabbing. It speaks BACnet Who-Is and reads the device's object list. It sends Modbus function code 43 to read device identification. It does DICOM C-ECHO to find imaging endpoints. The output is a typed inventory: device class, manufacturer, firmware version, protocol, authentication status, network segment.

Second, it assesses posture against the device's actual capabilities. Can this BACnet device be written to without authentication? Does this Modbus device respond to function codes that should be restricted? Is this DICOM endpoint accepting associations from any calling AE title? Is this HL7 interface transmitting PHI over an unencrypted channel?

Third, it maps what it finds to the compliance frameworks that matter. Each finding carries references to HIPAA Security Rule sections, NIST CSF subcategories, and the specific controls from whatever framework your compliance team is working against.

The output is not "port 47808 is open." The output is "Siemens Desigo CC building controller at 10.4.12.15 accepts unauthenticated BACnet WriteProperty requests on HVAC setpoint objects for the surgical suite air handling unit. HIPAA 164.312(a)(1) — access control. Risk: an attacker on this network segment can alter surgical suite environmental conditions without credentials."

That's the difference between a network scan and an OT assessment. One tells you a port is open. The other tells you what it means for patient safety.

Posture, not just scanning

Scanning is the beginning, not the end. What I've learned building Cybrium is that healthcare organizations — especially smaller ones — need a platform that turns scan results into a compliance posture they can act on and maintain over time.

A 50-bed critical-access hospital doesn't have a team of five security engineers to triage findings. They might have one IT person who also manages the phone system and the printer fleet. What they need is not a 200-page vulnerability report. They need a prioritized action list that says: here are the three things that will reduce your risk this week, here's exactly what to do for each one, and here's how this maps to the HIPAA requirement your auditor is going to ask about in October.

This is what the Cybrium platform does around cyprobe's scan results. Every finding feeds into a compliance posture dashboard that maps your OT, network, and application security state against HIPAA, NIST CSF, HHS CPGs, and — if you're in scope — PCI DSS and SOC 2. The dashboard is not a checklist. It's a live score that changes as your environment changes, because we run continuous assessments, not annual point-in-time audits that are stale before the PDF is delivered.

For healthcare organizations that need to demonstrate compliance to auditors, insurers, or regulators, the platform generates evidence-backed reports. Not "we believe we are compliant." Instead: here is the scan data, here are the controls it maps to, here is the residual risk, here is what we're doing about it, and here is the timeline. Auditors can drill into the underlying findings. Insurers can see the trend over quarters. Regulators get the artifact they need without the hospital spending six weeks preparing for the review.

We price healthcare at $5 per bed per month. That's deliberate. A 50-bed critical-access hospital pays $250 a month for the same platform, the same scanners, and the same compliance mapping that a 500-bed system gets. The attack surface doesn't care about your revenue. The security tooling shouldn't either.

The recomposition happening in healthcare security

What's happening in healthcare cybersecurity right now is a recomposition of the same kind that's reshaping the rest of the security industry, but with higher stakes and tighter constraints.

For twenty years, hospitals have bought point solutions: one tool for the EMR, one for the network, one for endpoints, and nothing for OT. Each tool produces its own reports, speaks its own language, and gets reviewed by a different person — if it gets reviewed at all. The result is a pile of point-in-time assessments that nobody can synthesize into a coherent picture of institutional risk.

The Pitt scenario — everything goes dark at once — happens precisely because these systems are connected in ways that no single point solution can see. The ransomware that encrypts the EMR server also encrypts the BACnet controller that happens to be on the same network segment because nobody ever segmented it, because no scanning tool ever flagged it as a risk, because no compliance framework ever asked about it specifically enough to force the question.

The recomposition is toward platforms that see all of it. OT and IT. Clinical and facilities. Network and application. Compliance and posture. Not because platforms are inherently better than point solutions — sometimes they're worse — but because in healthcare, the attack chains cross every boundary that point solutions draw, and the risk can only be assessed by something that sees across those boundaries.

That is the bet we've made with Cybrium. One platform that scans your code, your cloud, your network, your web applications, your AI infrastructure, and your operational technology. That maps every finding to the compliance frameworks your auditor cares about. That gives a 50-bed clinic the same quality of security posture visibility that a 500-bed academic medical center gets from a dedicated security team.

If you're running a hospital, a clinic, or a healthcare IT organization of any size and you want to know what your OT attack surface actually looks like — not what you hope it looks like, but what an attacker with an LLM and a free afternoon would see — find me at anand@cybrium.ai. The Pitt scenario makes great television. It makes a terrible incident report.