Modbus shows up in a lot of systems. It’s familiar, widely used, and continues to do its job. In recent years, more of these systems have been connected to enterprise networks and cloud platforms.

While that hasn’t changed Modbus, the expectations around connectivity and security have.

Today’s systems are often integrated into enterprise networks. Secure, authenticated connectivity is now commonly expected, data frequently needs to move beyond the building with encryption and X.509 certificate-based identity verification, and IT personnel are more likely to be involved in projects that used to stay on the controls side.

This is where the gap between Modbus and current security requirements can start to show.

Modbus was developed before many current security practices became standard, so it doesn’t natively include built-in encryption, authentication, or access control. That’s because Modbus was developed for environments that were often treated as trusted networks – which does not always align with how systems are configured today.

What Creates Security Challenges in Modbus Systems

Most of the time, Modbus challenges show up in the day-to-day decisions:

• Secure connectivity to cloud platforms is often required but X.509 certificate-based authentication, rather than simply opening ports, is often what IT and security teams expect.
• Data is increasingly expected to move to a cloud platform, but sending raw Modbus traffic across a network does not always meet IT or security requirements.
• Systems need to stay segmented from the rest of the network while still sharing selected data where appropriate.

Modbus does not directly address many of these requirements, so integrators look for other ways to handle them. That’s where a gateway can play a key role.

How Gateways Support Secure Modbus Connectivity

In many systems, Modbus devices are not being replaced. They’re already installed and may be expected to remain in service for years.

Because these needs can be handled without changing the devices themselves, the gateway often becomes the layer where requirements are addressed.

It wasn’t that long ago when a gateway was in place simply to translate the protocol so the data could get from point A to point B.

That’s no longer the only role of a gateway.

Now it sits between OT (operational technology) and IT (information technology), helping govern how data leaves the network, how access is managed, and how much of the system is exposed.

In many projects, the gateway can become an important part of meeting IT and security requirements.

Here’s what this shift in how connections are handled and controlled can look like:

• Connections are typically initiated outbound instead of requiring inbound access.
• Traffic can be encrypted once it leaves the device network.
• Field devices remain segmented from the main network while still sharing data where needed.
• Access is managed through defined user roles instead of shared credentials.

These are common approaches on the IT side. The difference now is that they’re being applied more consistently in environments that were not originally designed for them.

How MSA FieldServer Modbus IoT Gateway Updates Support These Requirements

On the FieldServer Modbus IoT Gateway, connectivity, access, and data movement are handled in the following ways. The goal isn’t to change Modbus itself, but to support how Modbus systems need to connect in more modern environments.

Security and access

• Designed to support TLS encryption for data leaving the local network
• Supports role-based user access (Admin, Operator, and Viewer) to help manage who can view or change configurations
• Supports X.509 certificate-based authentication as part of secure deployment models, including connections to AWS IoT Core, Azure IoT Hub, and Ignition
• Allows Certificate Signing Requests (CSRs) and key pairs to be generated directly on the device, helping ensure private keys are not exposed
• Stores passwords and credentials securely for use in MQTT and OPC UA authentication
• Can notify users 30 days before a certificate expires, supporting proactive certificate lifecycle management
• Provides visibility into user activity and configuration changes through system logs, event logging, and diagnostic captures

Network behavior

• Uses outbound HTTPS connections, avoiding the need for inbound ports to be opened
• Connects using standard web communication protocols, aligning with typical enterprise firewall expectations
• Offers configurable routing and network behavior at the device level
• Can be deployed in configurations that help keep Modbus devices on a separate network segment

Cloud and data movement

• Supports MQTT for lightweight data publishing to platforms such as AWS IoT Core and Azure IoT Hub
• Supports OPC UA for structured data exchange, including secure, certificate-based connections to Ignition

Note: OPC UA is limited to one server connection; however, multiple clients can connect to that server.

• Offers additional integration options for connecting with applications and platforms, depending on deployment needs
• Allows selective data points to be sent upstream, without exposing broader device networks
• Manages key pairs and certificates through an on-device Secrets Manager, providing a centralized location for credential and certificate handling

Deployment and configuration

• Web-based configuration reduces the need for custom development
• Reusable templates support repeatable and scalable deployments
• Provides live visibility into data during setup, commissioning, and troubleshooting
• Firmware updates are managed through the web interface
• Diagnostic captures and device snapshots are available to support troubleshooting and remote support workflows
• Remote device management is available through the MSA Grid – FieldServer Manager

Best Practices for Secure Modbus Connectivity

For teams working with Modbus in connected environments, the question is often not whether the data can move. It’s whether the gateway can be deployed in a way that fits the network, the access model, and the security review that comes with it.

A few practices may be worth considering early on.

Plan early for secure connectivity.
If cloud or external connectivity will be part of the deployment, it helps to decide up front how X.509 certificate-based authentication will be handled and whether it aligns with the customer’s IT and security expectations.

Limit what needs to be exposed.
Not every device or data point may need to be visible upstream. In many cases, it makes sense to expose only the data needed for monitoring, alarms, analytics, or integration.

Keep segmentation in mind from the start.
A gateway can move data between networks, but that does not mean everything should sit on the same segment. It’s worth deciding early where separation needs to be maintained.

Use defined access controls.
Shared credentials may be simple in the short-term, but they’re harder to manage in the long-term. Role-based access tends to fit better in environments where multiple teams are involved.

Match the gateway to the deployment.
Some projects need MQTT. Others need OPC UA, REST, or webhook support. Some care most about cloud connectivity, while others are more focused on local access or serviceability. The gateway works best when it fits the environment it’s being deployed into.

Think past startup.
A gateway is not only there to get a system online. It also becomes part of how that system is accessed, supported, and maintained after deployment.

That’s where gateway decisions may start to carry more weight. The protocol may stay the same, but the way the system connects, exposes data, and supports access can shape how well it fits the environment around it.

Conclusion

Modbus often continues to serve the same core role it has for years. What may be changing is the environment around it.

As more systems connect beyond the local network, the gateway may no longer serve only as a translation layer. It may also become part of how the system aligns with security, access, and network expectations.

That’s one reason gateway updates may matter more in these deployments.

For integrators and OEMs planning connected Modbus deployments, it may be worth evaluating gateway options with both interoperability and security requirements in mind.