Operating an IIoT Gateway Securely: Correctly Implement Certificates, VPN and User Rights in OT Networks

→ Product category: IIoT solutions

 

A new IIoT gateway is installed in the control cabinet.

The connection to the MQTT broker works, measured values appear in the dashboard and the service technician can remotely access the system when required.

Technically, everything appears to be complete.

However, the default password is still active on the gateway, the web interface can be reached from several networks and the TLS certificate will expire in a few weeks.

A functioning IIoT connection can therefore quickly become an unnecessary security risk.

The central problem:

An IIoT gateway frequently connects two areas with very different security requirements: the operational field level or OT and higher-level IT, cloud or remote maintenance networks.

The security assessment must therefore not be limited to the sensor.

The entire communication chain is decisive:

Sensor / field device → fieldbus → edge gateway → OT firewall / DMZ → MQTT / HTTPS → broker / server / cloud

Administrative access paths are also frequently added:

Service PC → VPN / remote access → approved administrative access → gateway

For secure operation, several layers of protection must therefore work together:

• network segmentation,
• firewall rules,
• encrypted communication,
• certificates,
• unique user accounts,
• roles and rights,
• controlled remote access,
• firmware and patch management,
• logging,
• time synchronization,
• backup and recovery,
• clear responsibilities.

It is particularly important to distinguish between:

TLS ≠ VPN ≠ user authorization

These mechanisms solve different tasks.

TLS protects an individual communication connection, a VPN creates a protected network tunnel and user rights determine what an authenticated person or service is actually permitted to do.

A securely operated IIoT gateway therefore does not require “one security function”, but a coordinated security concept covering the entire lifecycle.

IIoT solutions for connecting sensors, field devices, edge systems and higher-level IT/OT systems can be found at ICS Schneider under IIoT Solutions. Additional industrial field devices and integration options can be found under Siemens Process Instrumentation.

Why the IIoT gateway is a particularly critical network point

A sensor often has only limited communication functionality.

An IIoT gateway, however, can perform several tasks simultaneously:

• query field devices,
• process measured values,
• scale measured values,
• generate timestamps,
• evaluate local alarms,
• buffer data,
• establish MQTT or HTTPS connections,
• enable configuration via a web interface or other administrative services,
• support remote maintenance connections.

The gateway therefore often has communication relationships both in the direction of:

machine / process

and in the direction of:

IT / data center / cloud

The gateway becomes a trust boundary

A compromised gateway could theoretically do more than merely transmit incorrect measurement data.

Depending on its configuration, it could also serve as a starting point for further access to connected networks.

A gateway should therefore generally be considered according to the following principle:

Only permit the communication relationships that are actually required for its specific task.

Logically separate IT, OT and cloud

A typical IIoT architecture should not consist of one large Ethernet network.

It is advisable to separate different security zones.

In simplified form:

Field devices → machine / OT network → edge zone → industrial DMZ → IT / cloud

Why this separation is important

A compromised office PC should not automatically have network access to:

• PLC systems,
• transmitters,
• drives,
• IIoT gateways

.

Conversely, a field device should not be able to establish arbitrary connections to the corporate network.

Define zones and communication paths

The following should be documented for each connection:

Source	Destination	Protocol	Direction	Purpose
Field device	Gateway	Field protocol	local	Acquire measured values
Gateway	MQTT broker	MQTT over TLS	outbound	Transmit measurement data
Gateway	Time server	NTP	outbound	Time synchronization
Service network	Gateway	HTTPS / administrative service	controlled	Administration

This makes it clear which connections are actually required.

Network segmentation instead of a flat network

Network segmentation means that systems with different tasks or protection requirements are operated in separate network areas.

Communication between these areas is controlled.

Example

Unfavorable:

office network + PLC + measuring instruments + gateway + remote maintenance PC = one common subnet

Better:

IT network ↔ firewall / DMZ ↔ OT network ↔ machine cell

Advantage during a security incident

Segmentation can prevent a problem from spreading unrestricted from one area to the next.

It therefore reduces the reachable attack surface.

Segmentation must not exist only on paper

Separate IP address ranges alone do not yet form an effective security boundary.

What matters is that the traffic between the zones is actually controlled.

Configure the firewall according to the allowlist principle

A frequently useful basic concept is:

deny by default → selectively allow only required connections

Do not “open all ports between the gateway and server”

Instead, a rule should define as specifically as possible:

• source IP or source network,
• destination IP or destination network,
• protocol,
• destination port,
• communication direction.

Example

The gateway is intended to send measured values exclusively to an internal MQTT broker.

It therefore does not automatically require access to:

• arbitrary Internet servers,
• file shares,
• printers,
• domain controllers,
• other machine cells.

Permitted communication should correspond as closely as possible to the actual data flow.

Prefer outbound connections

Many IIoT applications can be designed so that the gateway initiates the outbound connection itself.

Example:

Gateway → MQTT broker

instead of:

external network → direct inbound connection to gateway

Why this is advantageous

An outbound connection can often be controlled much more precisely using firewall rules.

The gateway does not need to be generally reachable from external networks.

Treat administration separately

Data transmission and administrative remote access should be considered as two separate communication relationships.

Just because a gateway is allowed to transmit data to a broker does not mean that its administrative services must be reachable from the same network.

What TLS actually protects

TLS protects data during transmission between two communication partners.

Typical applications include:

• HTTPS,
• MQTT over TLS,
• encrypted API connections.

TLS provides in particular

• encryption of transmitted data,
• protection against undetected manipulation during transmission,
• authentication of at least one communication side using certificates.

TLS does not automatically protect the entire gateway

An encrypted MQTT connection does not, for example, prevent:

• a weak administrator password,
• an unnecessarily reachable administrative service,
• outdated firmware,
• excessive user privileges.

Therefore:

Encryption is an important building block, but it is not a substitute for system hardening and access control.

Manage TLS certificates correctly

A certificate links a digital identity to a cryptographic key.

During a TLS connection, it can be used, for example, to verify:

Am I actually communicating with the intended server?

Typical components of certificate management

For every production gateway, at least the following should be documented:

• device ID,
• hostname,
• certificate used,
• issuing CA,
• valid from date,
• expiration date,
• intended use,
• person responsible for renewal.

Expiration dates are an operational risk

A technically flawless gateway can suddenly stop transmitting data if its certificate is no longer valid.

The following principle should therefore apply:

monitor certificate expiration → renew in good time → test the connection afterwards

Do not permanently ignore certificate warnings

Settings such as:

“disable certificate verification”

are problematic when used merely to make a connection work more quickly.

This disables an essential part of server identity verification.

Use client certificates and mTLS

With standard TLS, the server typically authenticates itself to the client.

With mutual authentication – often referred to as:

mTLS = mutual TLS

– the gateway also has its own client certificate.

Principle

The broker checks:

Is this gateway an authorized client?

and the gateway checks:

Is this the intended broker?

Advantage over a shared password

With individual certificates, each gateway can be assigned its own identity.

If a single device is decommissioned or compromised, its authorization can be revoked specifically without having to change all other gateways at the same time.

Protect private keys

The client certificate itself is not the actual secret.

The associated private key is critical.

It should:

• not be distributed unencrypted on service laptops,
• not be sent by email,
• not be shared by many gateways

.

Operate MQTT securely

MQTT is well suited to IIoT applications because data can be exchanged efficiently between publishers and subscribers.

Security must, however, be configured separately.

Typical security components

• TLS encryption,
• verify the server certificate,
• authenticate the gateway,
• use individual users or certificates,
• restrict topic permissions,
• disable anonymous access where it is not required.

Topic permissions are particularly important

A gateway that only publishes measurement data from one machine does not automatically require access to all MQTT topics in the company.

Instead of:

gateway may publish/subscribe to #

use, for example:

publish: plant/werk1/linie2/maschine4/measurement/#

and only those subscribe permissions that are actually required for the application.

Consider publish and subscribe separately

A pure measurement data logger may need to:

publish

but may not need to receive commands via:

subscribe

at all.

This can significantly restrict its permissions.

Implement user roles and least privilege

Not every user requires administrator privileges.

A sensible role model could, for example, distinguish between:

Role	Typical authorization
Viewer	View status and measured values
Operator	Change operating parameters within approved limits
Service	Diagnostics, backup and defined maintenance functions
Administrator	Change network, users, certificates and security settings

Principle of minimum required privileges

A user should only have the rights actually required for their task.

This principle is often referred to as:

Least Privilege

Why this matters in practice

A service technician who only needs to:

• read diagnostic data,
• check measuring channels,
• create a backup

does not necessarily require authorization to:

• delete users,
• change firewall rules,
• replace certificates.

Avoid default passwords and shared accounts

A gateway should not be put into production with factory default credentials.

Problem with shared accounts

If ten employees use the same account:

admin

it is later almost impossible to determine:

Who changed the setting?

Better

• individual user accounts,
• clearly defined roles,
• central password management or password vault,
• secured process for emergency access,
• promptly disable accounts of employees who have left.

Document service accounts

Technical accounts for:

• MQTT,
• API access,
• backup,
• remote maintenance

should also be clearly assigned to a specific purpose.

Remote maintenance via VPN or controlled remote access

Direct Internet access to an IIoT gateway should be avoided.

A typical remote maintenance concept instead uses a controlled access path.

Example:

Service technician → authenticated remote access / VPN → defined OT zone → specific gateway

No blanket network access

A VPN user should not gain access to the entire production network merely because authentication was successful.

Additional rules should define:

• which user,
• to which system,
• using which protocol,
• at which time

access is permitted.

Remote access only when required

Depending on the system concept, it may be useful to enable external maintenance access only:

• for a defined time window,
• after approval by the operator,
• for a specific machine

.

Multi-factor authentication

If supported by the remote access solution used, an additional authentication layer can be useful for external access.

In this case, not only a password but an additional authentication factor is required.

Why VPN alone is not sufficient

A VPN encrypts and authenticates a network tunnel.

However, it does not automatically answer the question:

What is the user permitted to do once the tunnel has been established?

Example

Unfavorable:

VPN connected → entire OT network reachable

Better:

VPN connected → firewall rule → only approved gateway reachable via the required administrative service

TLS inside a VPN remains useful

A VPN is not a reason to operate application communication without encryption.

Where technically appropriate, for example:

MQTT over TLS within the secured network architecture

can be used.

This maintains protective mechanisms at several layers.

Reduce ports and services to what is necessary

Every active network service generally expands the reachable functional surface of the system.

It should therefore be checked:

• is an administrative shell access required?
• is a web interface required?
• is a file transfer service required?
• is a local MQTT broker required?
• is a serial network bridge required?

Disable unnecessary services

If a function is not used, it should be checked whether it can be disabled.

Particularly critical

Systems that have evolved over time sometimes contain services that were only enabled for:

• commissioning,
• test operation,
• temporary troubleshooting

.

After the project is completed, however, they may remain permanently active.

Security acceptance before handover

Before handover to operations, a list should therefore be created:

service → port → purpose → required communication partner → permanently required?

Distinguish between Secure Boot and signed firmware

The terms:

Secure Boot

and:

signed firmware update

are not identical.

Secure Boot

Secure Boot generally refers to a mechanism that checks during startup whether the software components to be executed originate from a trusted or authorized source.

Signed firmware

With a signed update, the device can verify before installation whether:

• the firmware package is authentic,
• the package has not been altered without detection.

Check on a device-specific basis

Not every gateway supports both functions.

The specific device and firmware documentation should therefore be checked for:

• which boot security functions are available,
• how updates are validated,
• which settings are required.

Organize firmware and patch management

A gateway often remains installed in a machine or system for many years.

The software environment, however, continues to change.

It must therefore be clarified

• who monitors security advisories from the manufacturer,
• who evaluates new firmware,
• how updates are tested,
• when they are installed in the production system,
• how a rollback is performed in the event of problems.

Do not install every update immediately without testing

OT systems have particular requirements regarding:

• availability,
• protocol compatibility,
• drivers,
• application software.

A security update should therefore not be ignored, but it should also not be installed directly into a running production system without assessment.

Typical process

receive advisory → check relevance → assess risk → backup → test → maintenance window → update → functional test → document

Set up security logging and an audit trail

In the event of a fault or security incident, it is essential to be able to trace what happened beforehand.

Useful log events

• successful login,
• failed login,
• user change,
• role change,
• configuration change,
• firmware update,
• certificate replacement,
• connection loss to the broker,
• gateway restart,
• VPN or remote maintenance connection.

Local logs alone may be insufficient

If the gateway only has a small internal ring buffer, older events can quickly be overwritten.

Where available and appropriate, logs can therefore also be transmitted to a central system.

Logging requires the correct time

An event log such as:

Login failed – 01.01.1970 00:02

is of little use for later analysis.

Time synchronization therefore becomes an important part of the security concept itself.

Consider time servers and certificate validation

A correct system time is required for IIoT gateways for several reasons.

Among other things for:

• timestamps of measurement data,
• audit logs,
• alarm history,
• certificate validity.

Incorrect time can prevent TLS connections

A certificate has a defined validity period.

If the gateway time is incorrect, an otherwise valid certificate may, for example, be interpreted as:

not yet valid

or:

already expired

.

Use a defined time source

Instead of allowing every gateway to use arbitrary Internet time servers, a defined time architecture should be planned in industrial networks.

Example:

internal time server → OT time server → gateways

Back up configurations and key material

After a hardware failure, a gateway can potentially be replaced comparatively quickly.

The greater challenge is often:

How can the original configuration be restored reliably?

Depending on the system, a backup should contain

• network configuration,
• field device assignment,
• data model,
• MQTT topics,
• alarm thresholds,
• user and role configuration,
• certificate information,
• firmware version.

Do not back up secrets without protection

A complete configuration backup may also contain:

• passwords,
• API keys,
• private keys

.

Such backups must be stored with appropriate protection.

Test the restore process

A backup only becomes truly valuable if it is known how to restore it.

A documented recovery process should therefore exist at least for critical gateways.

Protect passwords, API keys and private keys

In addition to user passwords, IIoT systems often contain other credentials.

Examples include:

• MQTT password,
• API key,
• cloud token,
• VPN key,
• private TLS key.

These data do not belong

• in freely accessible spreadsheets,
• in unencrypted project folders,
• in publicly accessible source code repositories,
• on labels attached to the control cabinet.

Use individual credentials

A single password for:

all gateways in all plants

significantly increases the impact of a single compromised credential.

Where possible, identities and secrets should therefore be assigned individually.

Consider cybersecurity and system availability together

OT security has one particular characteristic:

A security measure must not endanger system availability in an uncontrolled manner.

Example: certificate renewal

A new certificate is installed.

However, the broker does not yet trust the new CA.

Result:

security formally changed → telemetry completely unavailable

Example: firewall

A rule is tightened and accidentally blocks:

NTP

After a restart, the gateway has an incorrect system time.

The TLS connection then fails as a result.

Therefore perform changes in a controlled manner

Security-related changes should include:

• change request or documentation,
• prior backup,
• defined maintenance window,
• functional test,
• rollback option.

Define responsibilities between IT, OT and service

Many IIoT problems are not caused by missing technology, but by unclear responsibilities.

Typical questions

• Who renews the gateway certificate?
• Who manages the firewall rules?
• Who assigns service accounts?
• Who reviews firmware updates?
• Who monitors failed login attempts?
• Who disables external access after the end of a project?
• Who owns the configuration backup?

Example of a responsibility matrix

Task	Typical responsibility
OT network architecture	OT / automation together with IT security
Firewall rules	Network / security personnel
Gateway configuration	Automation / system integrator
Certificate management	Clearly defined IT / OT responsible person
Firmware assessment	Operator together with manufacturer / integrator
Remote maintenance approval	System operator
Service access	Personalized and documented

The specific allocation depends on the organization.

What matters is that every task is clearly assigned.

Typical security and configuration errors

Observation	Possible cause	Recommended check
Gateway is directly accessible from the Internet	Port forwarding instead of controlled remote access	Check network architecture and firewall rules
All service technicians use the same administrator credentials	Default or shared account not replaced	Set up individual accounts and roles
MQTT connection only works without certificate verification	CA, hostname or certificate incorrectly configured	Check certificate chain and server identity
Data transmission suddenly stops on a specific date	Certificate expired	Check validity date and certificate monitoring
New gateway reports “certificate not yet valid”	Incorrect system time	Check NTP and time zone
VPN user can reach all OT systems	Remote access permissions too broad	Restrict firewall and access roles
Gateway can reach arbitrary Internet addresses	No egress filtering	Restrict outbound communication destinations
It is impossible to determine who changed the configuration	Shared user account	Use personalized accounts and audit logs
No measurement data after firmware update	Compatibility problem or changed configuration	Check backup, release notes and functional test
Gateway has several unknown open ports	Factory or temporary services active	Create service list and disable unnecessary functions
Certificate was renewed but the connection remains interrupted	New CA or certificate chain is not trusted	Check trust store on both sides
Logs show events in the wrong order	Clocks not synchronized	Check NTP concept
Replacement gateway cannot be commissioned quickly	No current backup available	Introduce backup and restore process
External service access remains permanently active	No time-limited approval or offboarding	Check remote access process

Systematic security commissioning of an IIoT gateway

A structured procedure is recommended for commissioning.

1. Clearly inventory the gateway: Document device, serial number, location, IP address and responsible person.
2. Define network zones: Distinguish field, OT, DMZ, IT and cloud connections.
3. Document data flows: Define source, destination, protocol and communication direction.
4. Change default credentials: Replace factory passwords before production operation.
5. Set up user roles: Separate viewing, operating, service and administrator rights as required.
6. Disable unnecessary accounts: Remove or lock test and installation accounts.
7. Disable unnecessary services: Check open ports and network services.
8. Define firewall rules: Allow only required communication relationships.
9. Avoid direct Internet accessibility: Do not configure unnecessary port forwarding to the gateway.
10. Configure TLS: Encrypt MQTT, HTTPS and other suitable connections.
11. Enable certificate verification: Use a trusted CA and correct server identity.
12. Define gateway identity: If provided, configure an individual client certificate or mTLS.
13. Restrict MQTT permissions: Permit only required publish/subscribe topics.
14. Set up remote access: Use VPN or a defined remote access solution instead of direct Internet access.
15. Restrict remote access rights: Limit user, target system and protocol.
16. Check time synchronization: Use a defined NTP or time server.
17. Enable logging: Log logins, changes, errors and connection events.
18. Document firmware status: Record the current and approved version.
19. Define an update procedure: Assign responsibility and establish a maintenance process.
20. Create a backup: Save a defined baseline state after successful commissioning.
21. Document the restore procedure: Define the procedure for a replacement device or hardware failure.
22. Document certificate expiration: Set up reminders or monitoring before expiration.
23. Perform a functional test: Check measurement data, alarms, broker connection and local functions.
24. Perform a security test: Practically verify unauthorized access attempts and user permissions.
25. Document acceptance: Record network diagram, users, certificates, ports, firmware and backup status.

Practical example: MQTT connection fails after certificate expiration

An IIoT gateway acquires measurement data from a production system.

The measured values are transmitted to a central broker via MQTT.

Initial situation

The system has operated without problems for almost two years.

On Monday morning, all measured values suddenly disappear from the dashboard.

The connected sensors themselves are operating correctly.

Step 1: Check field communication

The gateway continues to read the connected measuring instruments correctly.

The connection:

Sensor → Gateway

is therefore functioning.

Step 2: Check the network

The gateway can reach the intended broker over the network.

The firewall is not blocking the connection.

Step 3: Check the gateway log

A TLS error appears in the event log.

The connection is terminated during certificate negotiation.

Step 4: Check the certificate

The gateway’s client certificate expired over the weekend.

There was:

• no automatic renewal,
• no reminder,
• no centrally maintained certificate inventory.

Step 5: Renew the certificate

A new valid certificate is issued according to the intended PKI process and installed on the gateway.

Step 6: Check broker authorization

The broker accepts the new gateway identity and the intended topic permissions are checked.

Step 7: Restore the connection

The MQTT connection is re-established and measurement data is transmitted again.

The actual cause

The technical problem was:

expired certificate

However, the organizational cause was:

no certificate lifecycle management

Improved solution

The following are subsequently documented for all gateways:

• device ID,
• certificate ID,
• expiration date,
• responsible person,
• renewal process.

In addition, a warning is generated several weeks before expiration.

Additional security check

During the analysis, it is discovered that the gateway is also still using a shared administrator password.

This is replaced with:

• individual user accounts,
• role-based rights,
• a documented emergency access

.

Result

The example shows:

IIoT cybersecurity is not a one-time configuration during commissioning. Certificates, users, firmware and remote access must be managed throughout the entire gateway lifecycle.

Suitable ICS products for IIoT applications

Siemens SITRANS MS200 – IIoT vibration and temperature sensor

A specific IIoT product from the current ICS portfolio is the Siemens SITRANS MS200 with article number:

7MP2210-2AB21-2AB1

The SITRANS MS200 is a wireless IIoT sensor for measuring:

• vibration,
• temperature.

It is particularly intended for condition monitoring applications and machine condition monitoring.

On the ICS product page, the SITRANS MS200 is explicitly described for use in combination with the:

SITRANS CC220 Gateway

.

This results in a typical IIoT structure:

SITRANS MS200 → SITRANS CC220 → higher-level monitoring system

Why this architecture is relevant to cybersecurity

In such an application, several communication areas should be considered separately.

These include:

• local communication between sensor and gateway,
• communication between the gateway and higher-level systems,
• administrative access to the gateway,
• user and service access.

Security should therefore not be limited to the sensor alone.

The complete communication chain from the field device to the higher-level system is decisive.

Further information can be found under Siemens SITRANS MS200 at ICS Schneider.

Siemens IIoT weighing electronics for SIMATIC IOT2050

Another IIoT product listed directly by ICS is the Siemens:

IIoT weighing electronics 7MH4647-0KK00-0AA2

for use with the SIMATIC IOT2050 gateway.

The weighing electronics have one channel for connecting a:

load cell / full-bridge strain gauge with 1 … 4 mV/V

and are used to convert the analog weighing signal for digital processing within an IIoT architecture.

Typical IIoT structure

Such an application can be structured in simplified form as:

Load cell → IIoT weighing electronics → SIMATIC IOT2050 → higher-level system

Here too, connecting local measurement acquisition with higher-level data processing creates an interface between different levels of the automation architecture.

Do not limit security to the measurement function

For cybersecurity, the following are relevant in addition to the actual weighing function:

• network segmentation,
• permitted communication connections,
• user access,
• administrative services,
• firmware and software versions,
• configuration backup.

Further information can be found under Siemens IIoT Weighing Electronics 7MH4647-0KK00-0AA2 at ICS Schneider.

Which ICS products are suitable for the topic?

Application	Suitable ICS product
Wireless vibration and temperature monitoring	Siemens SITRANS MS200 – 7MP2210-2AB21-2AB1
IIoT connection of a load cell / full-bridge strain gauge	Siemens IIoT weighing electronics – 7MH4647-0KK00-0AA2
Condition monitoring application with wireless sensor	SITRANS MS200 in the combination with SITRANS CC220 described on the ICS website
Digitalization of a weighing measurement	7MH4647-0KK00-0AA2 for SIMATIC IOT2050

Always check security functions for the specific system

Which cybersecurity functions are actually available depends on:

• gateway,
• hardware version,
• firmware or operating system,
• installed software,
• network architecture

.

Functions such as:

• Secure Boot,
• mTLS,
• VPN,
• role-based user management,
• signed firmware updates,
• centralized security logging

should therefore not be attributed to a device merely because it is used as an IIoT or gateway component.

For specific planning, the actually supported security functions must be verified using the respective device, firmware and software documentation.

IIoT solutions at ICS Schneider

Additional products and solutions for IIoT applications can be found under IIoT Solutions at ICS Schneider.

Additional Siemens products for industrial process instrumentation can be found under Siemens Process Instrumentation at ICS Schneider.

Conclusion

An IIoT gateway is much more than a protocol converter.

It frequently connects:

field technology ↔ OT ↔ IT ↔ cloud

and therefore becomes a particularly important element within the security architecture.

An effective protection concept begins with the network structure.

Instead of a flat network:

• field devices,
• machine cells,
• gateways,
• IT systems,
• external access paths

should be logically separated and connected via defined communication paths.

Firewalls should only permit connections that are actually required.

Architectures in which the gateway itself establishes a defined outbound connection to the broker or server and is not generally reachable from external networks are often particularly advantageous.

TLS is a key element for MQTT and HTTPS connections.

Encryption alone, however, is not sufficient.

Certificates must be:

• correctly verified,
• clearly assigned,
• renewed before expiration

.

With individual client certificates or mTLS, each gateway can additionally receive its own cryptographic identity.

Permissions within the MQTT broker should also be limited.

A gateway does not automatically require access to all topics.

The same principle applies to users:

as many rights as necessary – as few as possible

Shared administrator access and unchanged default passwords make both security and traceability more difficult.

Remote maintenance should be performed via a controlled access path such as VPN or a suitable remote access solution.

However, successful VPN authentication must not automatically mean that the user can access the entire OT network.

The following must also be considered throughout the lifecycle:

• firmware updates,
• security advisories,
• certificate lifetimes,
• user changes,
• audit logs,
• time synchronization,
• backups,
• recovery.

For practical implementation:

Inventory the gateway → define IT/OT zones → document communication paths → segment the network → configure the firewall according to the allowlist principle → secure default accounts → assign individual roles → enable TLS → manage certificates and expiration dates → restrict MQTT permissions → control remote access → disable unnecessary services → manage firmware status → configure logging and time servers → prepare backup and restore → define responsibilities → regularly reassess security.

FAQ: IIoT Gateway, TLS, VPN and OT Cybersecurity

Why is an IIoT gateway security-critical?

Because it often has communication relationships between field technology or OT and higher-level IT or cloud systems. It therefore connects areas with different protection requirements.

What is network segmentation?

Network segmentation means dividing systems into separate network zones and controlling communication between these zones.

Why should an IIoT gateway not be operated directly in the office network?

A shared network zone can result in office and production systems being unnecessarily reachable from one another. A segmented architecture reduces this attack surface.

What does Defense in Depth mean?

Defense in Depth is a multi-layered security concept in which several measures work together, including network segmentation, firewalls, access control, system hardening and monitoring.

What is an industrial DMZ?

An industrial DMZ is a separate network zone between OT and other networks through which defined services and data can be exchanged in a controlled manner.

What does allowlisting mean for a firewall?

It means that only communication explicitly approved for a known purpose is permitted by default.

Should an IIoT gateway be directly accessible from the Internet?

Direct Internet accessibility should be avoided wherever possible. Controlled and authenticated remote access methods are preferable for remote maintenance.

Why are outbound connections often preferable?

If the gateway establishes the connection itself to a defined broker or server, no generally accessible inbound service has to be provided for telemetry alone.

What is TLS?

TLS is a cryptographic protocol for securing network communication. It provides encryption, integrity protection and authentication of communication partners using certificates.

What does MQTTS mean?

It is commonly used to refer to MQTT communication secured with TLS.

Is MQTT automatically encrypted?

No. Encryption must be configured accordingly within the respective architecture.

What is a TLS certificate?

A certificate links a digital identity with a cryptographic key and can be used, among other things, to verify whether a communication partner is trusted.

What is a CA?

CA stands for Certificate Authority. It issues certificates or acts as a trust anchor within a PKI.

What happens when a gateway certificate expires?

Depending on the configuration, the authenticated or encrypted connection may no longer be established afterwards.

Why must certificate expiration be monitored?

So that certificates can be renewed in good time and unplanned communication failures are avoided.

What is mTLS?

mTLS stands for Mutual TLS. Both communication partners authenticate each other using certificates.

Why should every gateway have its own certificate?

So that devices can be uniquely identified and permissions can be changed or revoked for an individual gateway when necessary.

Is a client certificate secret?

The certificate itself does not necessarily need to be kept secret. However, the associated private key must be particularly well protected.

What are MQTT topic permissions?

They define which topics a client is permitted to publish data to or subscribe to.

Should a gateway have access to all MQTT topics?

Normally only if this is actually required for its task. Permissions should be restricted as closely as possible to the required topic areas.

What does Least Privilege mean?

A user, service or device receives only the permissions required for its specific task.

Which user roles are useful on a gateway?

Depending on the device, viewer, operator, service and administrator roles may be appropriate.

Why are shared administrator accounts problematic?

Because changes can no longer be clearly attributed to a specific person, and a compromised shared password affects several users or systems.

Should the default password be changed during commissioning?

Yes. Factory default credentials should not be retained for production operation.

What is a VPN?

A VPN establishes an authenticated and encrypted tunnel between communication partners or networks.

Is a VPN sufficient for secure remote access?

Not by itself. User rights, reachable target systems, firewall rules and the security of the endpoint device used must also be considered.

Why should a VPN user not be able to reach the entire OT network?

Because remote maintenance access is normally only required for specific systems and tasks. Restricting access reduces the impact of compromised credentials or service devices.

Is TLS still useful within a VPN?

Yes. Both mechanisms protect different layers and can be combined as part of a multi-layered security concept.

What is Zero Trust?

Zero Trust is a security principle in which access is not trusted solely because of network location. Identity, authorization and communication relationships are explicitly verified.

Which ports should an IIoT gateway have open?

Only those services and ports required for the specific application. The exact selection depends on the gateway, protocols and network architecture.

Should an administrative network service remain permanently enabled?

Only if the service is actually required and appropriately secured. Administrative services that are not needed should be disabled.

What is Secure Boot?

Secure Boot is a mechanism that verifies the trustworthiness or authenticity of software components to be executed during startup.

What does signed firmware mean?

A device can use a digital signature to verify that a firmware package originates from an authorized source and has not been modified.

Does every IIoT gateway have Secure Boot?

No. Whether this function is available must be checked for the specific gateway and its hardware or firmware version.

Why do IIoT gateways need to be updated?

Firmware updates can correct errors, improve functions and address known security issues. In OT environments, updates should be assessed, tested and documented in a controlled manner.

Should every firmware update be installed immediately?

The urgency depends on the security risk, application and manufacturer information. In production systems, compatibility, backup, maintenance windows and rollback options should be considered.

Which events should a gateway log?

Particularly useful events include logins, failed access attempts, configuration changes, user changes, certificate replacements, updates and communication errors.

Why is an audit log important?

It allows events and changes that occurred before a fault or security anomaly to be reconstructed afterwards.

Why does an IIoT gateway need a time server?

A correct system time is required for measurement timestamps, logs, alarm histories and certificate validity checks.

Can an incorrect system time interfere with TLS?

Yes. With an incorrect device time, a valid certificate may incorrectly be considered not yet valid or already expired.

What should be backed up from a gateway?

Depending on the device, particularly network, communication, measuring point, user and certificate configurations as well as the firmware version used.

Should private keys be included in a normal backup?

If key material must be backed up, appropriate protection measures must be used. Private keys must not be stored or distributed without protection.

What is an API key?

An API key is an access key that allows an application to identify or authenticate itself to a service.

Should all gateways use the same API key?

If the architecture supports individual identities, separate keys or credentials are generally easier to manage securely and can be revoked selectively.

What is the most important security measure for an IIoT gateway?

There is no single measure that covers all risks. What matters is the combination of segmentation, controlled communication, secure identities, authorization management, updates and monitoring.

What role does IEC 62443 play?

The IEC 62443 series is an important framework for cybersecurity in industrial automation and control systems and addresses, among other things, security processes, system architectures, zones and technical requirements.

Is a gateway with TLS automatically IEC 62443 compliant?

No. A single technical function such as TLS is not sufficient to demonstrate the cybersecurity of a complete system or compliance with a comprehensive standards framework.

What is the Siemens SITRANS MS200?

The SITRANS MS200 with article number 7MP2210-2AB21-2AB1 is an IIoT sensor listed by ICS for vibration and temperature monitoring. The ICS product page describes its use in combination with the SITRANS CC220 Gateway.

What is the SITRANS CC220 used for in connection with the SITRANS MS200?

On the ICS product page for the SITRANS MS200, the SITRANS CC220 is mentioned as the associated gateway for the IIoT application. This allows the sensor data to be integrated into a higher-level condition monitoring or IIoT architecture.

What is the Siemens IIoT weighing electronics 7MH4647-0KK00-0AA2?

The IIoT weighing electronics listed by ICS are used to connect a load cell or full-bridge strain gauge with 1 … 4 mV/V and convert its analog signal for digital processing. On the ICS product page, it is intended for the SIMATIC IOT2050 gateway.

How is the SIMATIC IOT2050 used on the ICS website?

On the ICS product page for the IIoT weighing electronics 7MH4647-0KK00-0AA2, the SIMATIC IOT2050 is named as the associated gateway platform for this application.

Do I need to check security functions for the specific gateway?

Yes. Functions such as Secure Boot, mTLS, user roles, VPN or signed updates depend on the hardware, firmware, operating system and software used and must not be assumed across the board.

Where can I find the Siemens SITRANS MS200 at ICS Schneider?

Further information can be found under Siemens SITRANS MS200 at ICS Schneider.

Where can I find the Siemens IIoT weighing electronics for SIMATIC IOT2050 at ICS Schneider?

Further information can be found under Siemens IIoT Weighing Electronics 7MH4647-0KK00-0AA2 at ICS Schneider.

Where can I find IIoT solutions at ICS Schneider?

An overview can be found under IIoT Solutions at ICS Schneider.

Where can I find Siemens process instrumentation at ICS Schneider?

Additional Siemens field devices and process instrumentation can be found under Siemens Process Instrumentation at ICS Schneider.