Biotech Automation Security: The Blind Spot Hiding in Plain Sight in Every Lab
In February 2021, hackers broke into a biochemistry research lab at the University of Oxford. It was running COVID-19 studies at the time. They got as far as the pumps and pressure controls, and demonstrated they could disable a pressure alarm.
Nobody was hurt, and the researchers caught it. But the incident made a point that most security teams still haven't absorbed: a laboratory is not just a room full of scientists anymore. It is a network, and biotech automation security is now as much a network security problem as it is a lab management one.
Lab instruments were never built to be networked
Walk into a modern molecular biology lab and most of what you see is now connected to something. Sequencers, analysers, liquid handling robots, even the incubators, all report data somewhere, and increasingly they can be controlled remotely too. That's the point of them. Faster processing, fewer manual errors, full traceability for audits.
The problem is that almost none of it was designed with security in mind. A lot of laboratory equipment still runs on operating systems that stopped receiving patches years ago. Manufacturers rarely release firmware updates for older instruments, and when they do, the update itself is often the weak point: many devices transmit firmware over unencrypted channels, with no digital signature to confirm the update came from the vendor at all.
Add default or shared logins, protocols like FTP and SMBv1 that were considered insecure a decade ago, and you get equipment that's effectively been sitting exposed the whole time, just not connected to anything that could reach it. Now it is.
The attack surface is bigger than IT realises
Security teams are used to thinking about laptops, servers, and cloud accounts. Lab hardware rarely makes that list, and that's the gap. A modern liquid handler, for instance, isn't a standalone pipetting machine anymore. It runs on embedded software, connects to a network for protocol updates and data logging, and in newer models even carries an onboard camera for computer vision-based calibration.
That's a fully networked, software-driven device sitting on the same infrastructure as everything else in the building, and it rarely shows up on an asset inventory the way a laptop would. Multiply that by every sequencer, analyser, and robotic system in a working lab, and the attack surface stops looking like a handful of edge cases. It starts looking like an entire category of infrastructure nobody has been counting.
When lab hardware gets compromised, the consequences are physical
This is where cyberbiosecurity diverges from ordinary IT risk. A compromised laptop usually means a data breach. A compromised piece of lab equipment can mean altered results, ruined samples, or a shut-down production line, and sometimes all three.
The clearest example remains NotPetya. The 2017 attack that hit Merck wasn't aimed at a laboratory specifically, but it tore through the company's networks and disrupted vaccine and drug production for months. Merck's own accounting of the damage came to 1.4 billion US dollars, factoring in downtime, lost product, and recovery costs. That's what happens when malware doesn't distinguish between an office network and the systems keeping a bioreactor running.
Smaller-scale incidents are arguably more common and less discussed. Firmware tampering on lab sensors can quietly shift the readings a device reports, which sounds abstract until you consider what that means for a molecular analyser feeding data into a clinical trial.
And research from Check Point found the education and research sector logged over 1,600 attacks per organisation per week in 2021, a 75 percent jump from the year before. Laboratories sit inside that sector, and most of them are not resourced the way a hospital IT department is.
Building real biotech automation security starts with visibility
None of this means ripping out lab equipment or halting automation. It means treating it the way mature organisations already treat industrial control systems.
Start with visibility. Most security teams cannot list every networked instrument in a lab, which makes it impossible to defend. An asset inventory that includes lab hardware, not just workstations, is the unglamorous first step that actually moves the needle.
Segmentation comes next. Lab devices that cannot be patched, and many can't, should sit behind a dedicated network zone or gateway rather than talking directly to the corporate network. It's a cheap control relative to what it prevents, and it doesn't require replacing hardware that's still doing its job.
Then there's the vendor conversation. Ask what a manufacturer's firmware update process actually looks like. Is it signed? Encrypted in transit? Does the vendor commit to ongoing support, or does the device ship once and never get touched again?
The FDA's 2025 guidance on medical device cybersecurity pushed manufacturers toward publishing a software bill of materials for exactly this reason, so buyers can see what's inside a device and trace vulnerabilities when they surface. Biotech procurement teams should be asking for the same thing, even where it isn't yet mandated.
Lab automation isn't going away, and it shouldn't. But it stopped being purely a productivity story the moment it started running on a network. Security teams that are still treating the lab as somebody else's problem are the ones who'll be reading about it in an incident report.