Q&A with Tom Hu on Protecting OT Systems in an Always-Connected World

1. SOCI ACT has been running since 2018. How has this Government regulation been influencing the decision criteria and project requirements for system integrators and OEMs in terms of cybersecurity?
 

TH: Back in 2018, the definition of critical infrastructure was expanded. It went from just four sectors, water, maritime ports, electricity, and gas, to 11 sectors. That now includes areas like food and grocery, transport, and the broader energy sector, which still covers electricity. What that means is asset owners in these sectors are now required to put in place a Critical Infrastructure Risk Management Program, and it has to take what’s called an ‘all‑hazards’ approach. So it’s not just about physical risks. It also includes supply chain risks, as well as cyber and information security.

By 17 August 2023, these programs were required to be fully adopted and operational. Asset owners aren’t just planning anymore. They’re actively identifying and managing these risks. Now, across most of these sectors, industrial control systems are everywhere. And as system integrators and OEMs, that means we should expect more questions from our customers around how their control networks are protected and secured.

And it’s important to point out that the SOCI Act doesn’t just affect asset owners who are classified as critical. It also impacts the wider supply chain, including organisations like ours that design, supply, and support industrial control systems and services.
 

2. What’s a misconception about industrial cybersecurity that you still see influencing decisions on projects today?

TH: If I had to leave you with one key takeaway, it would be this: there’s no single security solution that gives you 100% protection.

I often see network engineers rush to put a firewall in place and then assume the system is secure. But in reality, cybersecurity isn’t just a technology problem. It’s about people, processes, and technology all working together.

Before you start adding security controls, you really need to understand what assets you actually have, how data moves through the network, and what visibility you have to assess and monitor what’s going on. Once you have that picture, you can start making sensible decisions about security controls based on risk versus cost, for example, which systems are more critical than others.

In practice, what makes a big difference is adopting a defensible network architecture. That means using multiple layers of security and proper network segmentation to limit the blast radius when something goes wrong. This is especially important in OT environments, because many incidents don’t come from the outside. They come from access we’ve already allowed and people and devices we’ve let in. Designing the OT network with that in mind can help to improve resilience and reduce the impact of incidents.
 

3. In IT and OT, there are different standards and frameworks. The IEC 62443 OT standard is often referenced but not always well understood in practice. What’s a practical takeaway for someone to start actioning today?
 

TH: As system integrators and OEMs, we’re now expected to deliver control systems that don’t just meet the functional requirements anymore. They also need to meet security requirements. That means Factory Acceptance Tests and User Acceptance Tests are no longer just about whether the system works, but also whether it meets the security requirements.

When we look at IEC 62443, the first thing we really need to understand is what security level the asset owner actually requires. The standard gives us some good guidance here, especially through the seven foundational requirements in IEC 62443‑3‑3. If you’re not familiar with those, The Ultimate Guide to IEC 62443 for OT Security is well worth a read.

When you’re designing a system, you should keep those requirements in the back of your mind and, just as importantly, document what you’ve put in place to meet them. One thing about IEC 62443 is that it’s very much outcomes‑based. It tells you what you need to achieve, but not exactly how to do it. That makes it flexible and adaptable, although sometimes it would make life a bit easier if it were more prescriptive.

From an SI and OEM point of view, my recommendation is to aim for Security Level 1 as a baseline. That’s what I’m seeing more and more asset owners expect, and it’s becoming fairly common across many industries.
 

4. As connectivity increases across OT environments, how should SI/OEMs approach system design so they’re enabling access and data without increasing risk?

TH: When it comes to network design, if I had to simplify it right down, it comes back to one core idea: deny by default, and only open by exception. That’s really one of the key principles behind IEC 62443.

In the era of digitalisation, connectivity is often the top priority. Everything needs to talk to everything else, and before long, you end up with a network that looks like a bowl of spaghetti. So when someone asks for a new connection between networks, the first question shouldn’t be ‘sure, why not?’. It should be ‘what exactly do you need?’ What IP address? What port? What’s the purpose of the connection? And nothing more than that.

Once you’ve got that baseline in place, you can start building on it. Depending on the security requirements, that might include things like firewalls with deep packet inspection, network monitoring, intrusion detection, or even intrusion prevention. When you put these layers together, you end up with a structured, defence‑in‑depth approach that makes the network much easier to secure, manage, and trust over the long term.
 

5. We have seen many requests for secure remote access for asset owners. What could be the best practices for SI and OEM when they are challenged by IT departments?

TH: Yes, operational efficiency is really important. And a lot of the time, it comes down to the time and cost savings we get from being able to remotely access industrial control systems, especially when we’re trying to minimise downtime.

But if we’re talking about secure remote access, the solution needs some strong fundamentals in place. First of all, the service provider should be ISO 27001 certified, so there’s confidence in how they manage information security. A secure remote access solution must support multi‑factor authentication, and it’s even better if it integrates with single sign‑on, which improves both security and user experience.

You also need strong user and device access management. That allows you to enforce least‑privilege access and role‑based controls. Ideally, you should be able to clearly define which IP addresses and ports are accessible through the VPN platform, nothing more than what’s actually required.

Features like just‑in‑time access are really important too, where user access automatically expires when it’s no longer needed. The same goes for on‑demand access, where the asset owner explicitly approves each connection. And of course, you need comprehensive audit logs, so asset owners can monitor and trace exactly who accessed what, and when.

Depending on your network architecture and the required security level, I’d also recommend placing a firewall behind the VPN gateway. This helps with network segmentation and controls what the VPN gateway can access locally. A firewall with deep packet inspection can be especially effective. For example, enforcing online‑only rules for PLC communication, so remote write, upload, and download actions are blocked. Any PLC program modification should always require explicit approval from the asset owner.

At the local level, it’s also best practice to monitor and record remote access sessions, particularly when you’re dealing with critical assets. And if you loop this back to IEC 62443, you’ll find that all of these features map neatly to some of the requirement enhancements across the seven foundational requirements. We also have a very wordy white paper for your bedtime reading: here.
 

6. Looking ahead, what do you think will separate SI/OEMs who are seen as trusted partners in cybersecurity from those who aren’t?

TH: I think what really separates SIs and OEMs who are seen as trusted cybersecurity partners from those who aren’t is being proactive rather than reactive. That means being upfront and confident when it comes to industrial control system security, instead of waiting for customers to ask. It also means building real capability in OT network security and designing control systems that are ready to meet Security Level 1 from day one.

Another key factor is engaging end users early, asking them what data they actually need, who needs access, and how they want to connect, whether that’s local access, remote access, or integration with other systems. And if remote support is part of your service contract, it’s important to clearly demonstrate how you’ll do that securely, while still giving the end user control and visibility.

Most importantly, security needs to be treated as part of the system scope, not an afterthought or an optional add‑on. When you can show how your approach aligns with the customer’s security processes and procedures, and reference a recognised standard like IEC 62443, it gives you credibility.