Podcast: How exploitable gaps in popular networking devices show how far OT cybersecurity still has to go

Trae Mazza and his team at RMC Global found and reported hidden cyber weaknesses in common Siemens industrial networking devices. Mazza wrote this month for Smart Industry about the flaws, which Siemens has patched, and joins the podcast to review the investigation and preview how exposed to intrusion manufacturing OT really is.

Scott Achelpohl

Oct. 28, 2025

6 min read

What you'll learn:

Security gaps in industrial networks and devices crop up due to vendor constraints, financial limitations, “legacy” technologies and operational demands that prioritize uptime over cybersecurity.
Technical problems such as firmware, I/O subsystems or communications stacks that include legacy code or weak input validation also impair security.
So do broader, systemic issues, such as software that is difficult to patch due to uptime requirements or systems that require older, more vulnerable versions of software to function.

68ff91b255bf4453821346d6 Shutterstock 2566534519gq

Trae Mazza and Smart Industry have a lengthy history at this point, the entire month of October, in fact.

We debuted his article on Oct. 1 on his and his company RMC Global’s investigation, after a “penetration” test for a client, of two hidden cybersecurity gaps in Siemens’ RuggedCom ROXOS II industrial network devices.

And here we are, almost to Halloween, and we’re debuting a podcast featuring Mazza and his recollections about the case and broader observations about OT cybersecurity.

On this episode of Great Question: A Manufacturing Podcast, he revisits the Siemens case and discusses what other common industrial gear could be vulnerable to cyber intrusion unless, like the Siemens devices, this equipment is monitored and patched.

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 into just how vulnerable OT is.

We had a terrific follow-up conversation with Trae, about how industrial networks are supposed to be engineered for resilience but so often are simply not.

This often happens for technical reasons (he mentions firmware, I/O subsystems or communications stacks that might include legacy code or weak input validation) but also because of broader, systemic issues, such as their software is difficult to patch due to uptime requirements or their systems require older, more vulnerable versions of software to function. Many OT devices were built without modern cybersecurity in mind, he also offered during the “pod.”

So, please give a listen!

Below is an excerpt from the podcast:

Scott Achelpohl: 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.

Trae Mazza: Absolutely. But 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. So 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 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 big deal because it was the only system in this environment that crossed the IT/OT boundary, and so there should be another [common vulnerability and exponsure] 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: 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 come under very heavy scrutiny—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 most 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 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.

About the Author

Scott Achelpohl

Head of Content

I've come to Smart Industry after 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. I'm 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. I'm a wordsmith by nature, and I edit Smart Industry and report and write all kinds of news and interactive media on the digital transformation of manufacturing.