Matilda Bailey is a premier networking specialist with a career dedicated to the cutting-edge evolution of cellular, wireless, and next-generation connectivity solutions. With deep expertise in how data flows through both the most modern infrastructures and the rugged, legacy environments of industrial systems, she has become a vital voice in the conversation surrounding the convergence of Information Technology and Operational Technology. Her professional journey involves navigating the complex landscape of vulnerability management, where she often encounters systems that predate modern security standards. Matilda brings a unique perspective on why the industrial sector remains a “thorny” challenge for security practitioners and how the digital transformation of infrastructure is changing the stakes for public safety.
The following discussion explores the distinct quirks of security within the industrial domain, highlighting the stark contrast between traditional IT environments and the physical reality of the factory floor or the utility grid. Key themes include the persistence of legacy systems that lack basic modern defenses, the life-or-death consequences of system downtime, and the immense logistical hurdles involved in patching hardware located in remote or highly regulated areas. The conversation also delves into the ethical dilemmas of vulnerability disclosure and the emerging role of government agencies in securing critical infrastructure against the backdrop of rapidly advancing artificial intelligence.
With your extensive background in next-gen solutions, you’ve mentioned that stepping into an Operational Technology environment can feel like a trip back in time. Why does securing these systems feel so much like hacking in the late nineties?
When you walk into a space like the ICS Village at DEF CON, the atmosphere is thick with a specific kind of nostalgia because, in many ways, we are dealing with a platform species of technology that hasn’t changed its fundamental security posture in decades. Until very recently, the governing philosophy for OT was that the local network was inherently trusted, meaning these systems weren’t built to prompt for passwords or validate the inputs provided by users. This creates a “hacking like it’s 1999” vibe where modern tools easily bypass defenses that simply do not exist. Most of this software runs as compiled objects on hardware with incredibly limited resources, which means there is no room to implement 21st-century protections like Address Space Layout Randomization or Data Execution Protection. For a vulnerability hunter, it is a playground where the classic exploits of yesteryear are still remarkably effective because the equipment lacks the overhead to defend itself.
In the corporate IT world, we often worry about data theft or privilege escalation, but you’ve suggested that the stakes are fundamentally different in an industrial setting. How does the impact of a denial-of-service attack change when we move from servers to physical actuators?
In the IT world, a denial-of-service condition is often an inconvenience that we solve by throwing more CPUs or bandwidth at the problem, but in OT, it is frequently catastrophic. We talk about the “one-packet killer”—a single bit of malicious or garbage traffic that can brick an expensive piece of equipment or cause a safety-control sequence to trip. When an actuator stops or a robot freezes unexpectedly, the results aren’t just a 404 error; they are a direct interruption of physical processes that can put human life and limb hanging in the balance. There is no such thing as a “graceful failure” when you are dealing with a power plant or a chemical processing facility, and since almost nobody has a spare backup factory sitting around, any off-schedule interruption is a massive, high-stakes deal for the operators.
One of the most frustrating aspects for security researchers is the inability to fix a problem once it is found. What are the specific physical and regulatory barriers that make patching an OT device almost impossible compared to a standard software update?
The “icing on the terrible cake” of OT security is that even when a critical bug is identified, the path to a fix is blocked by geographic and logistical nightmares. You might find a vulnerability in code that lives on a control board located hundreds of miles away in the middle of an oil field, making physical access a major operation. Even if you can reach it, many of these devices are not reprogrammable at all, meaning you are looking at a costly “forklift update” where the entire hardware unit must be replaced, and there is no guarantee the new gear will even be compatible with the legacy control plane. Furthermore, strict regulations regarding unscheduled updates mean that even a willing operator might be legally or operationally barred from applying a patch. Often, the only realistic solution is to move the device into a “naughty corner” of the network through segmentation and hope that physical and virtual access can be tightly enough controlled to prevent a disaster.
Given the “apocalyptic” scenarios you’ve described, such as poisoning a community’s water supply or taking hospitals offline, how do you navigate the ethics of disclosing a new vulnerability?
Disclosing a vulnerability in the OT space is a fraught process because the theoretical effects of an attack are so much more severe than a typical data breach. When we describe a bug that could interrupt power delivery or compromise public safety, it’s not just the industry that listens; media outlets and government agencies tend to freak out, which creates a high-pressure environment for the researcher. There is a genuine fear that releasing a full proof-of-concept code could provide a weapon to a bad actor before the industry is ready to defend against it. However, I firmly believe we cannot keep these bugs bottled up forever, especially as OT and IT continue to converge. The best path forward is to utilize established channels, such as reporting through CISA, which has spent years building relationships with major vendors to ensure these reports are taken seriously and handled with the necessary level of coordination.
As we see more industrial systems being connected to the broader internet and the rise of AI-driven threats, what is your forecast for the future of critical infrastructure security?
My forecast for the next few years is that we will see a rapid and somewhat painful maturation of the OT/IT convergence, where the “security by obscurity” or isolation models of the past are rendered completely obsolete by AI-assisted attackers. We are entering a world where frontier AI can identify these “soft targets” and legacy vulnerabilities much faster than a human researcher can, turning what was once an obscure finding into a critical infrastructure weapon. Because of this, the defensive posture must evolve beyond simple network segmentation; we need to see a surge in the adoption of modern tooling and a cultural shift toward proactive reporting and “see something, say something” mentalities. If we don’t bridge the gap between our 30 years of security experience and the unique physical requirements of industrial gear now, we risk a future where someone can “turn off the lights” or worse with the click of a button.
