How can you connect a Siemens S7 PLC to the cloud in 2025?

· 13 min read
13 min read
Lucas Moreau
Lucas Moreau
OT/IT Network Engineer

Siemens S7 PLCs are used in tens of thousands of industrial facilities in France—production lines, treatment plants, and energy infrastructure. For years, these PLCs operated in isolation, communicating only with a local SCADA system. Today, there is strong pressure to connect them to the cloud: remote monitoring, predictive maintenance, centralization of production data, and access for maintenance teams from anywhere.

But connecting an S7 to the cloud isn't something you can just wing. The available protocols vary depending on the PLC generation; the site's network configuration may preclude certain approaches; and the security of remote access to a production PLC is a topic in its own right.

This guide details three proven methods for connecting a Siemens S7 PLC to the cloud in 2025, along with their advantages, limitations, and practical configuration examples.

Why connect an S7 to the cloud?​

Before getting into the technical details, let's lay the groundwork for ROI. Manufacturers who take the plunge consistently cite three main benefits:

Remote monitoring. Access process values, alarms, and line status from a computer or smartphone—without a complex VPN set up by the IT department, and without having to call the on-site team leader. For a machine manufacturer, this means the ability to view the status of each installation at its customers’ sites in real time.

Predictive maintenance. Storing PLC data in a time-series database (InfluxDB, TimescaleDB, Azure Time Series Insights) makes it possible to detect anomalies before they cause a shutdown. A motor whose power consumption gradually increases over three weeks can be detected well before it fails.

Reduced travel. A remote diagnosis eliminates the need for an on-site visit. For a facility located 500 km from the engineering office, this results in direct and immediate savings.

Protocols Available on a Siemens S7 PLC​

The first step is to find out what your PLC supports natively. The answer depends heavily on the generation.

ProtocolS7-300 / S7-400S7-1200 (FW ≥ 4.x)S7-1500
S7COMM (native protocol)Yes (port 102/TCP)YesYes
Modbus TCPVia CP or third-party FBYes (native FB)Yes (native FB)
OPC-UA serverNot nativeNo (client only on FW 4.x)Yes (native server)
PUT/GETYesYes (must be enabled)Yes (must be enabled)
MQTTNoNot native (via gateway)Via LHTTP or gateway

S7COMM: The Native Siemens Protocol​

S7COMM is the proprietary protocol used by TIA Portal for communication between the programming PC and the PLC. It operates on TCP port 102 and can be used by third-party clients (libnodave, python-snap7) to read and write variables. However, this protocol is not recommended for cloud exposure: it does not support authentication, and exposing port 102 to the Internet is a serious security risk.

PUT/GET: Direct Reading from a Third Party​

The PUT/GET function allows an external client to read or write blocks of data to the PLC. It is disabled by default on the S7-1200 and S7-1500 and must be explicitly enabled in the CPU properties in TIA Portal. The same applies from a security standpoint: it should only be used behind a VPN and never exposed directly.

For secure cloud integration, the two recommended approaches are OPC-UA (on the S7-1500) and Modbus TCP (S7-1200 and S7-1500). These are the protocols for which there are proven libraries, cloud connectors, and gateway solutions.

Method 1 — Via OPC-UA (S7-1500)​

OPC-UA is the standard protocol for industrial interoperability. Starting with firmware version V2.0 for the S7-1500, the OPC-UA server is natively integrated into the CPU. This is the cleanest and most future-proof approach for new installations or S7-1500 controllers.

Enabling the OPC-UA Server in TIA Portal​

Step 1 — Open the CPU properties. In the TIA Portal project, select the S7-1500 CPU, then go to Propriétés > OPC UA > Serveur.

Step 2 — Enable the server. Check the Activer le serveur OPC UA box. Leave the port at its default value (4840). You can set a custom port if your network infrastructure requires it.

Step 3 — Configure security. Select at least the SignAndEncrypt security mode with Basic256Sha256. Never use None in production—doing so is equivalent to exposing the PLC's variables without authentication.

Step 4 — Create the OPC-UA nodes. In the data block (DB), check the variables to be exposed via OPC-UA (Accessible depuis OPC UA). Variables that are not checked are not visible from the outside—this serves as a first level of filtering.

Step 5 — Deploy and Test. Upload the project to the CPU. Test it using an OPC-UA client such as UaExpert (free) over the local network before configuring the cloud gateway.

OPC-UA to Cloud Gateway​

The S7-1500's OPC-UA server is waiting for incoming connections. To send data to the cloud without opening an incoming port (security recommendation), a local IoT gateway connects to the OPC-UA server as a client and relays the data via an outgoing HTTPS/MQTT connection to the cloud.

# Example of an Eziwan gateway configuration — OPC-UA source
sources:
  - type: opcua
    endpoint: opc.tcp://192.168.1.10:4840
    security_mode: SignAndEncrypt
    security_policy: Basic256Sha256
    certificate: /etc/eziwan/opcua_client.pem
    polling_interval: 5s
    nodes:
      - node_id: "ns=3;s=DB1.temperature_process"
        name: temperature_process
        unit: °C
      - node_id: "ns=3;s=DB1.pression_bar"
        name: pression_bar
        unit: bar
      - node_id: "ns=3;s=DB1.etat_ligne"
        name: etat_ligne

destinations:
  - type: mqtt
    broker: mqtt.eziwan.cloud:8883
    tls: true
    topic_prefix: "usine/ligne1"

Method 2 — Via Modbus TCP (S7-1200 / S7-1500)​

Modbus TCP is natively supported on the S7-1200 (firmware 4.x and later) and the S7-1500 via function blocks (FBs) integrated into TIA Portal. This is the preferred approach when your IoT gateway or SCADA system uses Modbus TCP, or when you need to integrate with an existing system that already supports this protocol.

Configuring the Modbus TCP Server on the S7-1200​

Step 1 — Create a data block for the registers. Create a DB named Modbus_Holding_Registers with a WORD array of the desired size (e.g., 100 registers). This array will be accessible for reading and writing by the Modbus client.

Step 2 — Instantiate the MB_SERVER function block. In the OB1 block or in a cyclic task, instantiate the MB_SERVER function block (available in the TIA Portal library).

// Exemple d'instanciation MB_SERVER en SCL
#MB_SERVER_Instance(
    EN_R_JMP    := TRUE,
    DISCONNECT  := FALSE,
    MB_HOLD_REG := "Modbus_Holding_Registers".data,
    NDR         := #NDR,
    DR          := #DR,
    ERROR       := #ERROR,
    STATUS      := #STATUS,
    CONNECT     := #TCON_Param
);

Step 3 — Configure the connection settings. In the TCON_Param data block, specify:

  • InterfaceId: ID of the CPU’s Ethernet interface (usually 64)
  • ID: connection identifier (e.g., 1)
  • ActiveEstablished: FALSE (the S7 waits for connections)
  • RemotePort: 0 (accepts all clients)
  • LocalPort: 502 (standard Modbus port)

Step 4 — Map the variables in the register database. Write the process values to the register array from the PLC program. The IoT gateway reads these registers via Modbus TCP and transmits them to the cloud.

Important Configuration Settings​

ParameterRecommended ValueNote
Port502Modbus TCP Standard
Simultaneous Connections3 maximumS7-1200 default value
Connection timeout30 sAdjust according to the network
RegistersStructured DBAvoid accessing M memory
Register updateCyclic (100 ms)Adapt to process dynamics

Method 3 — Via RS-485 IoT Gateway (all PLCs)​

This method is used when the S7 PLC is not directly accessible from the IP network (no Ethernet interface available, isolated OT network, an older S7-300 without an Ethernet CP) or when you already have an RS-485 Modbus RTU bus on which the PLC is accessible as a slave or master.

Architecture​

In this diagram, an IoT gateway (such as the Eziwan Gateway) physically connects to the RS-485 port of the PLC or field network and communicates via Modbus RTU. The gateway converts the Modbus RTU data to MQTT or HTTP and transmits it to the cloud via its 4G or Ethernet connectivity.

Modbus RTU Configuration on the S7-300​

On an S7-300 with a CP 340 or CP 341 communication module, RS-485 Modbus RTU communication is configured using the Siemens configuration software (USS or Modbus RTU protocol, depending on the module). The registers to be exposed are defined in the CP’s communication database.

This method has one major advantage: it requires no changes to the existing PLC program if the PLC is already configured as a Modbus RTU master or slave. The IoT gateway is transparent to the PLC.

Securing Remote Access to the S7​

Securing access to a production controller is a critical issue. Improper configuration can expose the industrial process to unauthorized access or even attacks (see documented incidents at industrial facilities).

Principle: No ports exposed to the Internet​

Never expose the PLC's ports (TCP 102, TCP 502, TCP 4840) directly to the Internet, even behind a NAT. The correct approach is to use an outbound VPN tunnel.

The IoT gateway establishes an encrypted outbound connection to a cloud-based VPN hub. The PLC, meanwhile, only sees the local network. From outside the network, access is provided through the VPN hub, which authenticates and authorizes each connection.

OpenVPN Configuration​

OpenVPN is the recommended VPN protocol for industrial IoT deployments: it traverses firewalls via TCP port 443, reconnects quickly after a network outage (critical on 4G), and authenticates using X.509 certificates. IPSec (IKEv2) remains available for regulated environments.

# OpenVPN Configuration on the Field Gateway (`.ovpn` Profile)
client
dev tun
proto udp
remote vpn.eziwan.cloud 1194
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
keepalive 10 60
persist-tun
# Server-pushed route entries: 10.10.1.0/24
# X.509 client certificate automatically injected by Zero-Touch Provisioning

With this configuration, the gateway maintains a permanent tunnel to the cloud. The S7 PLC remains on the local network 192.168.x.x and is never directly exposed. The maintenance engineer connects to the cloud VPN hub and accesses the PLC through the tunnel.

Network Segmentation​

Separate the OT network (PLCs) from the IT network (office systems, cloud) using an industrial firewall or a dedicated VLAN. The IoT gateway is the only authorized bridge between the two zones, with strict traffic rules (only the necessary protocols and destinations).

Example of a Complete Deployment​

Background: A production line equipped with an S7-1500, with about 100 process variables to be monitored from headquarters (300 km away) and logged for performance analysis.

Deployed architecture:

  1. S7-1500 on the line — OPC-UA server enabled, 87 variables exposed in 3 data blocks. OPC-UA security in SignAndEncrypt mode.

  2. Eziwan Gateway in the line cabinet — connected via local Ethernet to the S7-1500. OPC-UA client that polls variables every 5 seconds. Permanent OpenVPN/IPSec VPN connection to the Eziwan cloud. Dual-SIM failover if the factory’s Ethernet connection goes down.

  3. Cloud Eziwan — MQTT data reception, storage in a time-series database, hourly/daily aggregation. REST API available for third-party systems.

  4. Grafana Dashboard at headquarters — connection to the Eziwan cloud API, display of production KPIs (TRS, throughput, OEE), email and SMS alerts when thresholds are exceeded.

  5. Remote Maintenance Access — Maintenance engineers connect to the Eziwan VPN from their workstations. They can view the S7-1500 as if they were on the plant's local network, with direct access to TIA Portal for diagnostics.

Result: Commissioned in 4 hours. No changes to the existing PLC program. No open ports on the customer's firewall.

Common Mistakes​

  1. Enable PUT/GET without a VPN. The PUT/GET function provides direct access to the PLC's databases. Without a VPN, anyone who can access the OT network can read and write production variables. This is the most dangerous configuration encountered in the field.

  2. Using S7COMM from the cloud. The native Siemens protocol (port 102) is not designed for external exposure. Third-party libraries that implement it do not support modern security mechanisms.

  3. Neglecting the return flow. Cloud-based monitoring that sends commands to the PLC (setpoints, start commands) requires enhanced security analysis. Clearly define which variables are read-only and which are read/write in the OPC-UA server or Modbus mapping.

  4. Check the S7 firmware version. The built-in OPC-UA server is only available starting with a certain firmware version, depending on the model. On the S7-1500, verify that the firmware version is ≥ V2.0 before planning an OPC-UA integration.

  5. Undersizing the gateway. A gateway that polls 500 OPC-UA variables every second while maintaining a VPN tunnel and managing a 4G connection requires sufficient CPU and memory resources. Validate performance with a load test before production deployment.

FAQ​

Can my S7-300 with an Ethernet CP be connected to the cloud? Yes, but the options are more limited. The S7-300 does not natively support OPC-UA. Possible approaches include: Modbus TCP via a third-party fieldbus or dedicated CP, S7COMM via a third-party library (to be used only behind a VPN), or RS-485 Modbus RTU with an IoT gateway (method 3).

Can an S7 be connected to the cloud without modifying the PLC program? Often yes, particularly via the RS-485/gateway method (if the PLC already has an RS-485 Modbus port) or via read-only OPC-UA (existing variables are exposed without modifying the program). The Modbus TCP server method requires only minor modifications (adding the MB_SERVER function block and a register database).

What is the latency between a process value and its display on the cloud dashboard? With 5-second OPC-UA polling, MQTT transmission, and a 5-second dashboard refresh rate, the total latency is 5 to 15 seconds under normal conditions. This is not suitable for real-time control (which remains the role of the PLC), but it is perfectly adequate for monitoring and maintenance.

Does remote access via VPN require TIA Portal on the engineer's PC? Yes, to edit the PLC program (which requires TIA Portal). No, for monitoring variables, which can be done via the cloud dashboard without any Siemens software installed.

Further Reading​

Would you like to connect your Siemens S7 PLCs to the cloud without opening any ports or modifying your program? Contact our team — free compatibility assessment within 48 hours.

Additional Resources​