Podcast: How exploitable gaps in popular networking devices show how far OT cybersecurity still has to go
Key Highlights
- OT devices still ship with weak defaults, giving attackers easy entry if onboarding controls are weak.
- Legacy protocols and flat networks widen the attack surface for industrial operations.
- Layered defenses and segmentation help reduce risk when patching isn’t feasible.
- OT/IT convergence demands security practices that protect uptime without breaking systems.
In this episode of Great Question: A Manufacturing Podcast, Scott Achelpohl speaks with Trae Mazza, who is Senior Security Engineer at RMC Global, about the growing exposure of OT networks and the real-world vulnerabilities uncovered during penetration testing. The discussion explores how legacy technologies, weak authentication, and flat architectures create risk in industrial environments. Scott and Trae also examine the challenges created by IT/OT convergence and the importance of layered defenses in protecting operational assets. The conversation offers practical insight for manufacturers navigating modern cybersecurity threats.
Below is an excerpt from the podcast:
SA: Hello, everyone, and welcome to another great episode of the Great Question in Manufacturing podcast, another one brought to you by Smart Industry. I'm Scott Achelpol, SI's Head of Content, and I'm joined for this episode by Trae Mazza, who is Senior Security Engineer at RMC Global, where he specializes in offensive security with a focus on embedded device assessments. Based in Arlington, Virginia, RMC provides industrial cybersecurity, risk management, and resiliency solutions for critical infrastructure and critical missions for government and commercial organizations.
RMC this month received two significant certifications: CMMC Level 2 and ISO 9001:2015. We first encountered Trae when he gave us a proposed contributed story on his and his company's investigation after a penetration test for a client in early 2025 into two hidden cybersecurity gaps in Siemens’ RuggedCom Roxos II industrial-built network devices, which are commonly used in harsh environments to support critical infrastructure communications.
Thanks to Trae and RMC, the gaps were reported to the U.S. Cybersecurity and Infrastructure Security Agency, or CISA, and patched this spring with cooperation from Siemens. We published Trae's story with Siemens' response and thanks on October 1st. The piece was a fascinating case study into the security gaps in industrial networks and devices due to vendor constraints, financial limitations, legacy technologies, and operational demands that prioritize uptime over cybersecurity.
It was an amazing peek at just how vulnerable OT is and what needs to be done to correct it. I'll note the breaking news of a BitSight report that global exposure of industrial control systems and IT devices surged from 160,000 devices visible each month to 180,000 devices visible just last year. This rise reverses years of reduction and is expected to exceed 200,000 by the end of the year.
This means the attack surface in industrial OT is wider than ever. The problem is that organizations still rely on enterprise IT-grade firewalls and endpoint tools that were never designed to secure factory environments, where uptime is the top priority over data privacy. The gap between IT and OT leaves assets exposed and hard to secure.
So we invited Trae to join us on the podcast to review how the case with the Siemens network device came about and what else he’s seeing with vulnerabilities in OT equipment of this type. At Smart Industry, we're covering cybersecurity — especially on the OT side, but also IT quite often now. So Trae, welcome to the program.
TM: Thanks, Scott. I really appreciate the invite to the pod. It's great to be here. So this penetration test — or pen test, for short — on the RuggedCom device was an interesting one for us at RMC. It really highlighted how small oversights in industrial gear and applications can turn into really big cybersecurity risks.
The RuggedCom device that I was assessing was a RuggedCom RX1400, which is often used as a gateway into industrial networks, as it has router, firewall, and switch features. So, as an authenticated user to the embedded web UI on the device, and with the ability to upload configuration files and run network utilities, I was able to chain together an arbitrary file upload in the “install files” feature — which was discovered by my coworker, Zach Levine (shout out to Zach) — with an operating system command/argument injection in the device's TCPdump utility that led to full root access on the underlying device operating system.
So, really excited to be here and talk about what we learned and how it connects to the broader OT security landscape as a whole.
SA: Industrial networks are supposed to be engineered for resilience, but the case of the RuggedCom RoxOS II security gaps is by no means the only flaw found and patched. Describe some other cases you're working on right now for RMC, in as much detail as you can give us.
TM: First, for the audience’s sake, let me take a step back and explain how I even get ahold of these devices and find these kinds of issues or vulnerabilities.
RMC is embedded within the procurement process of a few critical infrastructure companies, specifically within the utility sectors like power and gas. So when they plan to bring in a new device or application or any kind of system into their operational networks — whether that be electrical substations, power generation plants, or a SCADA environment — they'll have us come in, they'll have RMC come in, and perform a pen test to find any vulnerabilities or security shortcomings on their devices.
Generally in the past, the vulnerabilities that we find have been reported to our clients and then disclosed to the vendors privately. But I've been pushing more and more for transparent reporting of vulnerabilities with our clients, and I've started to make headway with that effort — this RuggedCom issue being one of the first times.
So, back to your question: my team and I just wrapped up an assessment on a SCADA system where we were able to break out of a read-only monitoring application and compromise the underlying Windows host. This was a pretty big deal because it was the only system in this environment that crossed the IT/OT boundary, and so there should be another CVE coming out for this in the near future. So keep your eyes on the CISA CVE feed.
Right now, I’m working on another industrial networking device that suffers from some of the very common vulnerabilities that plague the OT and embedded device space, such as no password policies for users — so a user could just make a password that’s the letter “A” — lack of brute-force limiting, and vendor test accounts that are hidden or present in production releases. While these may be less critical in the attack chain than what we discovered in RuggedCom, they're still important to find, discover, and report.
SA: Trae, in your story for us you talked about built-in diagnostic tools becoming dangerous entry points when paired with weak input validation. Is this part of OT systems that must be continually assessed? Where else might intruders gain access?
TM: Anywhere the device or system or application can take input from users should be under very heavy scrutiny from a security perspective — especially if the input is passed to an underlying process running as the operating system’s root or admin user, or even as a standard user for that matter. The TCPdump utility that we used to exploit the attack on the RoxOS device was on the device’s embedded web server, and this is where the majority of serious findings that I uncover on devices come from. And to feedback off that, TCPdump is a utility that’s on a lot of networking devices, and there’s a long history of issues with TCPdump utilities.
SA: What about authentication — which your story talked about — weak or default credentials being a common risk factor. What needs to change here?
TM: Organizations implementing devices should have policies and procedures in place that require new devices placed on the network to have their default passwords changed to strong passwords that meet the organizational requirements. From an organizational perspective, companies should have some form of a checklist for a device being onboarded into the network, and one of the checks should be changing all the known passwords on the device.
That said, policies and procedures without technical controls from the vendor are not always followed or enforceable. So there could be a simple mistake in the deployment process where someone didn’t change the passwords — or even just an undocumented account that the OT company doesn’t know about, that was put there by the vendor.
For device or application vendors, they should kind of shift left, which in the security space means that security should be baked into the device development process at the earliest stages. For authentication specifically, randomized passwords out of the factory — or requiring the end user to change the password at first login — should be the standard. Additionally, vendors should have a baseline password complexity requirement that can be modified by users to fit their individual standards and needs.
Smart Industry covers the digital transformation of manufacturing and the IIoT for industrial professionals.
SA: Tell me what's meant in OT hardware and software when people talk about layered defenses. We see this term a lot.
TM: Layered defenses is basically the idea that you don't want to rely on just one thing to keep OT networks safe — that means stacking protections to keep your important systems up. Things like segmenting your control networks, locking down remote access, keeping devices patched (which can be hard in OT networks), and then monitoring for unusual traffic, just to name a few. You could go on and on and on. But essentially, each layer in a layered defense catches something different, so even if one fails, the attacker doesn't immediately get to the critical systems or the crown jewels.
SA: What are recent advisories from CISA saying about vulnerabilities in industrial control devices?
TM: What we're seeing from CISA’s recent advisories is a pretty clear message that industrial devices are not immune to what we typically think of as more IT vulnerabilities. Some of this is due to expanded features and functionality on many OT devices.
Just this month, CISA published advisories for vendors like Siemens, Rockwell, and Hitachi related to command execution, adversary-in-the-middle, and HTML injection attacks — just to name a few.
So when we're talking about OT security, I think the takeaway is something like this: threat vectors have kind of converged between IT and OT. Devices that were designed for robustness and longevity are still being deployed, but their firmware, input/output subsystems, or communication stacks might include legacy code, weak input validation, etc. And because these systems often sit in environments where patching is pretty difficult — due to uptime requirements or some other operational constraint — they pose a risk that can linger for an extended amount of time.
From a manufacturing operations perspective, the thing to emphasize is layered defenses. You have to assume that a vulnerability like this could be present. So if you can't immediately patch every device, you need to segment it, monitor traffic, restrict remote access, and perform device hardening as much as you can to limit the services required for the device to function in your environment. That gap between when the vulnerability is published or discovered and when it’s patched becomes your operational risk window — and in the OT environment, that window’s often a lot longer than it would be in the IT environment.
SA: Trae, we've talked and written a lot about the top vulnerabilities in OT overall. Do you have any insight into that?
TM: Yeah, that's a great question. It's hard to say exactly, but I think what I can say is that in OT environments we see some pretty consistent themes, at least from the testing that I've done — and especially in OT environments that have been there for a while.
So first, obviously, it’s vulnerabilities that have CVEs tied to them and the inability to patch them, either due to uptime requirements or systems requiring older versions of software to function. Many OT devices were built without modern security in mind. So you'll find things like I/O controllers, PLCs, HMIs, or general networking gear that still use insecure communication protocols.
For example, we still see unencrypted or unauthenticated variants of Modbus or DNP3 in the electric sector. So when an attacker can sniff or intercept traffic or hijack a session or issue commands and affect real-world systems — because the protocol wasn’t designed with security in mind — that becomes a big risk.
Second — which we've discussed already — is weaker default credentials. Often, in the OT environments I’ve assessed at least, even if the passwords are changed from vendor defaults to something that could be considered a strong password, it often gets reused or slight variations get used on multiple systems, and they follow a very predictable pattern a lot of times.
Third is the lack of segmentation — or a flat network, if you will. So in many industrial operations, the OT network is effectively connected to the IT network or even to the internet with very limited separation. That means that once an attacker gets a foothold into the OT network, they can perform lateral movement and have persistence over control systems, and it becomes much easier for the attacker to stay there and stay hidden. So a misconfigured firewall or remote access link — such as a VPN or jump host without strong controls — opens the door for attackers to get an initial foothold in the network.
As OT networks converge with IT and become more connected — with things like internet-accessible remote management, cloud connectivity, and more interoperability with the IT side — the threat or attack surface begins to grow. Vulnerabilities that are network-accessible (that is, exploitable remotely without needing physical access to the device) become more critical.
So putting it all together, you get scenarios where a device in an OT environment might be running outdated, vulnerable firmware or software, using insecure protocols, connected to a flat OT network with a vendor remote access link or reachable from the internet. So if an attacker is able to find a vulnerability — or there's a known vulnerability in that system, say something like remote code execution or a memory corruption fault — they could exploit it, potentially move laterally throughout that flat network, interrupt operations, and compromise, you know, the safety or availability of the system that’s being controlled there.
SA: You mentioned OT networks in one of your other answers as they converge with IT. OT/IT convergence is something that we cover a lot — it's one of our core issues. Can you expand on the special cybersecurity challenges you see in your role with OT and IT convergence?
TM: Yeah, definitely. So one of the biggest challenges that I see in OT and IT convergence is that we're merging two worlds that were built with very different priorities. IT systems generally are designed around data confidentiality, integrity, and availability — the CIA triad — while OT systems are designed around safety and availability.
If you've ever been to an OT security conference, there's usually a bunch of talks about how OT needs to shift away from the “AAA” — availability, availability, availability — model and move more toward a CIA, or confidentiality, integrity, and availability, model where availability is not the entire focus.
When those networks and ideologies start to overlap, the controls that make sense for one environment can completely disrupt the other. For example, applying frequent patching or protection policies that are standard in an IT environment can cause unexpected downtime in an OT network on devices that have been running the same firmware or software for 10-plus years.
On the other side, the visibility and monitoring that IT teams take for granted often just don't exist in OT networks, so threat actors can persist for a longer amount of time. There's also a cultural element where IT and OT teams often speak different languages — different technical languages — and have different risk tolerances. So bridging the gap requires both sides to understand the other's constraints and perspectives.
So the main challenge with OT and IT convergence from a security-specific perspective is finding that middle ground by introducing modern cybersecurity controls into OT networks without breaking the reliability and safety that those systems depend on.
About the Podcast
Great Question: A Manufacturing Podcast offers news and information for the people who make, store and move things and those who manage and maintain the facilities where that work gets done. Manufacturers from chemical producers to automakers to machine shops can listen for critical insights into the technologies, economic conditions and best practices that can influence how to best run facilities to reach operational excellence.
Listen to another episode and subscribe on your favorite podcast app
About the Author
Scott Achelpohl
Scott Achelpohl is the managing editor of Smart Industry. He has spent stints in business-to-business journalism covering U.S. trucking and transportation for FleetOwner, a sister website and magazine of SI’s at Endeavor Business Media, and branches of the U.S. military for Navy League of the United States. He's a graduate of the University of Kansas and the William Allen White School of Journalism with many years of media experience inside and outside B2B journalism.