Choosing the right M2M SIM for your fleet of industrial IoT devices is a critical decision: network coverage, pay-as-you-go rates, SLAs, international roaming, APN security, LTE-M/NB-IoT compatibility, and—an often-overlooked factor—the planned phase-out of 2G and 3G, which will render thousands of already-deployed modems obsolete. This 2026 comparison, based on the most recent ARCEP data, analyzes the offerings of major French carriers, specialized MVNOs (1NCE, Tele2 IoT), and multi-carrier SIMs, to help you make a choice that will stand the test of time over the next 10 years.
\nBefore getting into the details, here are the key takeaways for decision-makers who are pressed for time:
\nAn M2M SIM (Machine-to-Machine), now more commonly referred to as an IoT SIM, is a SIM card designed specifically for industrial and connected devices. It differs from a smartphone SIM in almost every way:
\n| Feature | Consumer SIM | M2M IoT SIM |
|---|---|---|
| Operating Temperature | 0 °C to +40 °C | −40 °C to +85 °C |
| Lifespan | 2–3 years | 10–15 years |
| Format | Nano SIM (4FF) | Industrial 2FF/3FF solderable (MFF2), eSIM |
| Resistance | Standard | Vibration, humidity, corrosion |
| Data allowance | Unlimited (shared) | Low (1 MB–5 GB/month) |
| Roaming | EU “Roam Like Home” | Dedicated M2M contracts (≠ RLH) |
| Private APN | No | Available |
| Static IP | No | Optional |
| Monitoring | No | Dashboard / Fleet API |
| eUICC (remote profile) | No | Available |
| Cancellation | Monthly | 12–36-month contracts |
Industrial SIM format: IoT gateways and routers most often include a SIM slot in the 2FF (mini-SIM, 25×15 mm) or 3FF (micro-SIM), or even a soldered eSIM (MFF2) for high-vibration environments. This must be verified before placing any order—an incorrect format will halt the entire deployment.
\n\n\nKey Takeaway: An M2M SIM card isn't just a \"cheap plan.\" It's an industrial component designed to last as long as the machine it's installed in.
\n
Coverage is the most important factor when choosing an M2M SIM card. Here is the actual state of the network, based on ARCEP data from Q4 2025 (published in March 2026), rather than on the operators’ marketing claims.
\nThanks to the mandatory requirements of the 2018 New Deal Mobile, the four carriers now cover more than 99% of the French population with 4G. The battle is therefore no longer about population coverage, but rather about:
\nAn important factor for network resilience: SFR and Bouygues Telecom share part of their network in less densely populated areas (a network-sharing agreement known as the “Crozon” agreement). In practice, in these areas, choosing SFR or Bouygues may amount to connecting to the same physical antenna—which reduces the value of a failover between these two providers and increases the value of a failover that includes Orange (an independent network). Free, for its part, benefits from roaming on the Orange network in areas it does not yet cover.
\n| Band | Frequency | IoT Use |
|---|---|---|
| B28 | 700 MHz | Long range, indoor penetration, rural |
| B20 | 800 MHz | Rural coverage, basements |
| B8 | 900 MHz | Extended coverage |
| B3 | 1800 MHz | Urban capacity, data rate |
| B1/B7 | 2100/2600 MHz | High urban density |
| n78 | 3.5 GHz (5G) | Very high data rates, dense areas |
For a sensor located underground or in a rural area, it’s the low bands (700/800 MHz) that matter—not the urban 5G highlighted in advertisements.
\nThis is the most underestimated aspect of an IoT deployment in 2026, and it deserves its own section.
\nDirect consequence: Any 2G-only modem or IoT module (still very common in older meters and alarms) will stop working as of fall 2026. A 2G/3G module without 4G fallback will stop working around 2028.
\nWhat should I do?
\n\n\nEziwan Tip: Eziwan gateways and SIM cards support 4G/LTE-M with fallback, designed to withstand these outages without requiring on-site intervention.
\n
Orange is the incumbent carrier with the most extensive coverage, particularly in rural areas and overseas territories.
\nM2M Plans:
\nKey Strengths:
\nWeaknesses:
\nEstimated rates (data only, excluding add-ons):
\n| Data Allowance / Month | Estimated Price / SIM / Month |
|---|---|
| 1–5 MB | 2–4 € |
| 50–100 MB | 4–8 € |
| 500 MB – 1 GB | 8–15 € |
SFR offers competitive M2M plans, providing good value for money on large-scale deployments and a popular pooling system.
\nM2M Plans:
\nKey strengths:
\nWeaknesses:
\nEstimated rates:
\n| Data Allowance / Month | Estimated Price / SIM / Month |
|---|---|
| 10 MB | €1.50–3 |
| 100 MB | €3–6 |
| 1 GB | €6–12 |
Bouygues has significantly improved its coverage and often offers the lowest rates on the market for large data plans.
\nM2M Offerings:
\nStrengths:
\nWeaknesses:
\nEstimated rates:
\n| Data Allowance / Month | Estimated Price / SIM / Month |
|---|---|
| 10 MB | €1.20–2.50 |
| 100 MB | €2.50–5 |
| 1 GB | €5–10 |
For low-power, low-data-rate applications (remote water/gas meter reading, asset tracking, environmental sensors), LoRaWAN is an alternative to cellular networks:
\n\n\nNote: The LoRaWAN ecosystem is evolving (acquisitions, strategic repositioning of players). Verify the long-term viability of the network and the commercial offering before making a long-term commitment.
\n
1NCE offers a radical model: a one-time payment of about $10/$12 for 500 MB of data + 250 text messages valid for 10 years, on the Deutsche Telekom network and its partners (including Orange in France), with coverage in 170+ countries. The SIM supports 2G, 3G, 4G/LTE-M, NB-IoT, and is advertised as “5G-ready.”
\nFor:
\nCons:
\n\n\n1NCE is excellent for simple, straightforward applications. For industrial monitoring, regular VPN remote access, or video, you'll need a single-carrier or multi-carrier solution.
\n
European operators specializing in IoT, with attractive multi-country offerings for international deployments and mature fleet management.
\neUICC / multi-IMSI solutions that allow switching between carriers based on coverage, with a unified core network—ideal for deployments across multiple countries and for avoiding vendor lock-in.
\nA multi-carrier SIM (multi-IMSI / eUICC) is a card capable of automatically connecting to the carrier with the best signal at each location and switching back in the event of a network outage.
\n| Criterion | Single-carrier SIM | Multi-carrier SIM |
|---|---|---|
| National coverage | Operator-dependent | Best of the 3 networks |
| Operator dead zone | Outage | Automatic failover |
| Operator network outage | Total outage | Fallback to another network |
| Overall resilience | Low | High |
| Cost | Low | Slightly higher (+10–20%) |
| Management | 1 contract | 1 multi-operator contract |
| EU Roaming | Variable / optional | Often included |
| “Blind” deployment | Risky (coverage must be verified site by site) | Secure (the best network is selected on-site) |
Ideal use cases: pumping stations, wind and solar farms, agricultural sites, multi-site remote meter reading, moving vehicles, multi-country deployments, and any site where checking carrier coverage on a carrier-by-carrier basis before installation would be too costly.
\n\n\n“Crozon” Reminder: For true redundancy, the failover must include Orange (an independent network) and not just SFR and Bouygues, which share their network in sparsely populated areas.
\n
The Eziwan SIM is a multi-carrier M2M SIM included in our plans:
\nThe private APN (Access Point Name) creates a dedicated virtual network between your SIM cards and your cloud infrastructure, without going through the public internet.
\n\nTraffic never passes through the public internet: a dedicated tunnel between the SIM and the data center; a static IP address is available per SIM.\nAdvantages of a private VPN:
\nPublic APN vs. Private APN:
\n| Public APN | Private APN | |
|---|---|---|
| Internet exposure | Yes | No (dedicated tunnel) |
| Fixed IP | Rare | Possible |
| Client Isolation | No | Yes |
| NIS2 Compliance | Insufficient on its own | Recommended |
| Additional Cost | — | ~+1–3 €/SIM/month |
Availability: Orange, SFR, and Bouygues all offer private APNs; the Eziwan SIM includes one by default.
\nChoosing a plan that’s just the right size helps you avoid overpaying (or running out of data). Observed ranges:
\n| Use Case | Variables | Polling | Monthly Usage |
|---|---|---|---|
| Remote meter reading | 3–5 | 15 min | 1–5 MB |
| Pumping station (M340 PLC) | 10–20 | 30 s | 10–50 MB |
| Energy monitoring | 20–50 | 10 s | 50–200 MB |
| Multi-device SCADA | 100–500 | 1 s | 200–500 MB |
| 720p video surveillance | — | Continuous | 3–10 GB |
| VPN remote access (idle) | — | — | 5–20 MB (keepalive) |
| VPN remote access (30-min session) | — | — | 50–500 MB depending on activity |
Optimization through edge computing: A gateway that filters data locally (dead band, aggregation, compression) before transmission reduces 4G data usage by 70 to 95%. An M340 site with 30 variables can go from ~150 MB/month to 15–25 MB/month — which, across 500 sites, means switching from a “200 MB” plan to a “50 MB” plan and achieving substantial savings across the entire fleet.
\nFor equipment deployed outside of France:
\nEuropean Union: Please note that M2M plans do not automatically qualify for the “Roam Like Home” benefit, which is reserved for consumer plans. M2M roaming is subject to specific contractual terms: always check your carrier’s M2M terms and conditions (data allowances, permitted duration of permanent roaming, and restrictions on “permanent roaming”).
\nOutside the EU: Charges per MB can be very high (in the range of +0.5 to 2 €/MB). For international deployment, opt for a local SIM or a global multi-IMSI SIM (Eziwan, Tele2 IoT, Onomondo) that negotiates network access on a country-by-country basis.
\nPermanent roaming: Some countries (and some host operators) restrict or prohibit permanent roaming for fixed devices. A sustainable deployment abroad must rely on a multi-IMSI plan or a local SIM card, not on “tolerated” roaming.
\n| Criterion | Orange | SFR | Bouygues | 1NCE | SIM Eziwan |
|---|---|---|---|---|---|
| Coverage in France | ★★★★★ | ★★★★ | ★★★★ | ★★★★ (via partners) | ★★★★★ |
| Price | ★★★ | ★★★★ | ★★★★★ | ★★★★★ (low data usage) | ★★★★ |
| Private APN | ✅ | ✅ | ✅ | ❌ | ✅ included |
| Multi-carrier | ❌ | ❌ | ❌ | ❌ (single carrier via partner) | ✅ |
| LTE-M / NB-IoT | ✅ | ✅ | ✅ | ✅ | ✅ |
| eSIM / eUICC | ✅ | ✅ | Partial | ✅ | ✅ |
| Fleet dashboard | ✅ | ✅ | ✅ | ✅ | ✅ integrated |
| Fixed IP | ✅ optional | ✅ optional | ✅ optional | ❌ | ✅ optional |
| EU M2M roaming | ✅ optional | ✅ optional | ✅ optional | ✅ 170+ countries | ✅ included |
| Min. order | ≈100 SIMs | ≈50 SIMs | ≈50 SIMs | 1 SIM | 1 SIM |
| Contract term | 24–36 months | 12–24 months | 12–24 months | None (one-time purchase) | No contract |
| Dedicated IoT support in French | ✅ | ✅ | ✅ | Premium | ✅ |
★ = Eziwan's estimated rating; adjust based on your geographic location and volume.
\nIn any case: at least 4G/LTE-M modules (never 2G/3G alone) and a private APN whenever the data is sensitive.
\nCan I use a consumer SIM card in an IoT gateway?\nTechnically, yes, but it’s not recommended. Consumer SIM cards support a limited temperature range (0–40 °C), have a shorter lifespan, and do not offer a private APN, fleet monitoring, or an industrial SLA. For a fleet deployed in the field, the additional cost of an M2M SIM is more than offset by the reliability and centralized management it provides.
\nWill my 2G or 3G devices continue to work?\nNo, eventually. Orange is shutting down its 2G network between September 22 and October 20, 2026; other carriers will follow suit, and 3G will be phased out around 2028. Any 2G-only module will be out of service as of fall 2026; a 2G/3G module without 4G fallback will be out of service around 2028. For any new project, insist on 4G / LTE-M / NB-IoT hardware.
\nWhat is the minimum data usage of an M2M SIM in standby mode?\nWithout business traffic, an M2M SIM only consumes data for network maintenance signals (keep-alive, heartbeat): depending on the carrier and configuration, 1–10 MB/month. With a private APN and a VPN tunnel (OpenVPN/IPSec) maintained continuously, expect 5–15 MB/month in keep-alive traffic, excluding application data.
\nCan you switch carriers without having to reconfigure everything?\nWith an eUICC (eSIM), yes: the carrier profile is reconfigured remotely, without any on-site intervention. With a standard physical single-carrier SIM, you have to physically replace the card. Eziwan’s multi-carrier SIM eliminates this problem: a single SIM automatically manages all three French networks.
\nWhat is the difference between LTE-M and NB-IoT?\nLTE-M offers higher data rates, low latency, and supports mobility (moving objects, voice capable)—making it suitable for asset tracking and real-time telemetry. NB-IoT is designed for very low-power, stationary devices (such as underground meters), offering excellent signal penetration but lower data rates and higher latency. Both technologies will survive the phase-out of 2G/3G.
\nDo M2M SIM cards comply with French regulations?\nYes. M2M plans offered by French carriers are regulated by ARCEP. IoT data SIM cards do not require end-user identification (no ID required), except for plans that include voice calls or outgoing text messages to consumer numbers.
\nHow do you manage 500 SIM cards spread across 500 locations?\nThrough a fleet management portal: real-time data usage per SIM, detection of inactive or over-consuming SIMs, remote activation/deactivation, signal monitoring (RSRP/RSRQ), and threshold alerts. The Eziwan portal integrates this management into the same dashboard as your equipment monitoring, eliminating the need to switch between multiple interfaces.
\nIs a multi-carrier SIM much more expensive?\nGenerally 10% to 20% more than an equivalent single-carrier SIM. For a critical site, this additional cost is negligible compared to the cost of an outage or a technical visit caused by a coverage gap that wasn’t properly anticipated.
\nFor a personalized recommendation based on your network and geographic areas, contact our team — we’ll perform a free coverage analysis of your sites, operator by operator.
\nGrafana has become the go-to tool for industrial data visualization. Free, open-source, and extensible, it transforms your Modbus, OPC-UA, or MQTT data into operational dashboards. This guide shows you how to design a comprehensive industrial monitoring system with Grafana—or how Eziwan can provide it to you as a turnkey solution.
\nGrafana has established itself in the industry for several reasons:
\nCompared to a traditional SCADA system:
\n| Grafana (+ IoT stack) | Wonderware/Ignition SCADA | |
|---|---|---|
| License cost | 0 (open source) | 5,000–50,000€ |
| Hosting cost | 50–200€/month (cloud) | Dedicated server + maintenance |
| Unlimited variables | ✅ | ❌ (billed per tag) |
| Native web interface | ✅ | ✅ (Ignition) / ❌ (Wonderware) |
| Mobile-ready | ✅ | Partially |
| Cloud integration | Native | Complex |
The complete stack for monitoring Modbus PLCs in Grafana:
\n\nAlternative for large volumes:
\n\nEziwan Solution (all-in-one):
\nEziwan includes the complete stack (Modbus/OPC-UA data collection, cloud time series, preconfigured Grafana dashboards, SMS/email alerts) without requiring you to install and maintain the components individually.
\n# docker-compose.yml
version: '3.8'
services:
influxdb:
image: influxdb:2.7
ports:
- \"8086:8086\"
environment:
DOCKER_INFLUXDB_INIT_MODE: setup
DOCKER_INFLUXDB_INIT_USERNAME: admin
DOCKER_INFLUXDB_INIT_PASSWORD: mot_de_passe_securise
DOCKER_INFLUXDB_INIT_ORG: eziwan
DOCKER_INFLUXDB_INIT_BUCKET: industrie
DOCKER_INFLUXDB_INIT_RETENTION: 1825d # 5 ans
volumes:
- influxdb_data:/var/lib/influxdb2
grafana:
image: grafana/grafana:10.4.0
ports:
- \"3000:3000\"
environment:
GF_SECURITY_ADMIN_PASSWORD: grafana_securise
volumes:
- grafana_data:/var/lib/grafana
depends_on:
- influxdb
telegraf:
image: telegraf:1.29
volumes:
- ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
depends_on:
- influxdb
volumes:
influxdb_data:
grafana_data:
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = [\"tcp://localhost:1883\"]
topics = [\"usine/#\"]
qos = 1
data_format = \"json\"
# Parsing the MQTT topic: factory/site/station/variable
[[inputs.mqtt_consumer.topic_parsing]]
topic = \"usine/+/+/+\"
tags = \"_/_/station/_\"
fields = \"_/_/_/value\"
[[outputs.influxdb_v2]]
urls = [\"http://influxdb:8086\"]
token = \"votre_token_influxdb\"
organization = \"eziwan\"
bucket = \"industrie\"
To view the pressure trends for a station over time:
\nInfluxDB (Flux) Query:
\nfrom(bucket: \"industrie\")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r[\"_measurement\"] == \"mqtt_consumer\")
|> filter(fn: (r) => r[\"station\"] == \"station1\")
|> filter(fn: (r) => r[\"_field\"] == \"pression\")
|> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
|> yield(name: \"mean\")
Panel settings:
\nTime seriesbar (Pressure)To display the current value of a variable:
\nInfluxDB Query:
\nfrom(bucket: \"industrie\")
|> range(start: -1m)
|> filter(fn: (r) => r[\"station\"] == \"station1\" and r[\"_field\"] == \"pression\")
|> last()
Panel settings:
\nGaugebarTo view the OEE or a production counter:
\nInfluxDB Query:
\nfrom(bucket: \"industrie\")
|> range(start: -24h)
|> filter(fn: (r) => r[\"_field\"] == \"pieces_produites\")
|> sum()
Panel settings:
\nStatpcs (custom)Background (red if < target)To view the status of all your sites in real time:
\nfrom(bucket: \"industrie\")
|> range(start: -5m)
|> filter(fn: (r) => r[\"_field\"] == \"pression\" or r[\"_field\"] == \"debit\" or r[\"_field\"] == \"etat\")
|> last()
|> pivot(rowKey: [\"_time\", \"station\"], columnKey: [\"_field\"], valueColumn: \"_value\")
Result: a table with columns for Station, Pressure, Flow Rate, and Status, with one row per site.
\nIn Grafana 10+ (Unified Alerting):
\nEdit → AlertCondition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
maintenance@usine.frTo avoid \"alert storms\" when multiple sites go down at the same time:
\n# alertmanager.yml
route:
group_by: ['alertname', 'site']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
receiver: 'maintenance-team'
receivers:
- name: 'maintenance-team'
email_configs:
- to: 'maintenance@usine.fr'
send_resolved: true
webhook_configs:
- url: 'https://api.sms-provider.fr/send'
Add automatic annotations to graphs when alarms occur:
\n// Create an InfluxDB annotation when a failure occurs
from(bucket: \"industrie\")
|> range(start: v.timeRangeStart)
|> filter(fn: (r) => r[\"_field\"] == \"defaut\" and r[\"_value\"] == 1)
|> map(fn: (r) => ({r with _value: \"Défaut détecté sur ${r.station}\"}))
Template Variables let you create a generic dashboard that can be reused across all your sites.
\nDashboard Settings → Variables → New Variable:
siteQueryimport \"influxdata/influxdb/schema\"
schema.tagValues(bucket: \"industrie\", tag: \"station\")
from(bucket: \"industrie\")
|> range(start: v.timeRangeStart)
|> filter(fn: (r) => r[\"station\"] == \"${site}\")
|> filter(fn: (r) => r[\"_field\"] == \"pression\")
The operator can now select the site from a drop-down menu at the top of the dashboard.
\n┌─────────────────────────────────────────────────────────────────┐
│ Station: [dropdown] │ Period: [6h|24h|7d|30d] │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│ Pressure │ Flow Rate │ Level │ Pump Status │
│ [gauge] │ [gauge] │ [gauge] │ [stat 🟢/🔴] │
├──────────────┴──────────────┴──────────────┴────────────────────┤
│ 24-Hour Trends: Pressure / Flow / Level │
│ [time series graph] │
├─────────────────────────────────────────────────────────────────┤
│ Active Alarms │ Latest Actions │
│ [table] │ [table annotations] │
└─────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────────────┐
│ Vue globale — 15 sites │
├──────────┬──────────┬──────────┬──────────┬──────────┬────────────┤
│ Site 1 │ Site 2 │ Site 3 │ Site 4 │ Site 5 │ ... │
│ TRS: 87% │ TRS: 91% │ TRS: 73% │ TRS: 94% │ TRS: 82% │ │
│ 🟢 OK │ 🟢 OK │ 🔴 Alrm │ 🟢 OK │ 🟡 Warn │ │
├──────────┴──────────┴──────────┴──────────┴──────────┴────────────┤
│ 24-Hour Cumulative Production: Target vs. Actual [bar chart] │
└────────────────────────────────────────────────────────────────────┘
Eziwan offers two ways to integrate with Grafana:
\nThe Eziwan platform natively integrates Grafana. Your Modbus/OPC-UA data is already stored in our time-series database hosted in France. You can access the dashboards directly from your browser, with:
\nIf you already have an internal Grafana instance:
\nGET /api/v1/variables/{id}/historyCan Grafana replace a SCADA system in production?\nFor visualization and alerts, yes, in many cases. For real-time control (writing to a PLC, control sequences), a SCADA system or a dedicated HMI system is still recommended. Grafana excels at data archiving, trend analysis, and multi-site monitoring.
\nWhich database should you use to store industrial data in Grafana?\nInfluxDB is the standard choice for industrial time series (high frequency, native compression, powerful Flux queries). TimescaleDB (a PostgreSQL extension) is a good fit if you already use PostgreSQL. Prometheus is well-suited for infrastructure metrics but less relevant for process data.
\nHow do I secure access to Grafana from the Internet?\nPlace Grafana behind a reverse proxy (Nginx/Traefik) with TLS, enable OIDC/LDAP authentication, disable anonymous access, and configure alerts for failed login attempts. Never expose InfluxDB directly to the Internet.
\nCan Grafana handle 1,000 sites and 100,000 variables?\nYes, with the right architecture. InfluxDB 2.x supports billions of data points. Grafana Enterprise handles clustering. For very large volumes, consider using Apache Kafka upstream for streaming, along with differentiated retention policies (1-second data retained for 30 days, 1-minute data retained for 5 years).
\nCan I display a P&ID diagram in Grafana?\nYes, with the Flowcharting plugin (based on draw.io). You draw your P&ID diagram, attach Grafana variables to each piece of equipment, and the values are displayed in real time on the diagram, with colors changing based on the status.
\nWant Grafana dashboards without having to manage the infrastructure? Try Eziwan free for 30 days — get your Modbus data into Grafana in less than an hour.
\nOPC-UA (OPC Unified Architecture) has become the standard protocol for interoperability in Industry 4.0. However, its apparent complexity still hinders many implementations. This practical guide demystifies OPC-UA: architecture, security, NodeId, Python/Node.js implementation, and cloud integration.
\nOPC-UA (IEC 62541) is a platform-independent communication protocol designed for the secure exchange of industrial data. Unlike its predecessor, OPC-DA (Windows-only, DCOM), OPC-UA runs on any operating system (Linux, Windows, embedded RTOS) and over any network (Ethernet, 4G, Wi-Fi).
\nThe basic OPC-UA model is client-server:
\n\nA single device can act as both a server and a client at the same time (e.g., a gateway that aggregates data from multiple PLCs and exposes the consolidated data).
\nThe Address Space is the information tree exposed by an OPC-UA server. Each node has a unique NodeId:
\n\nNodeId Format:
\nns=2;i=1234 — namespace 2, integer identifier 1234ns=2;s=Station_1.Pression — namespace 2, string identifierns=0;i=2258 — namespace 0 (standard), ServerStatusNamespaces:
\nns=0: standard OPC-UA namespace (types, methods)ns=1: often the manufacturer's namespacens=2+: application namespaces (your data)| Mode | Description | Use Case |
|---|---|---|
| Read | One-time read of a node | Polling every N seconds |
| Subscription | Subscription to changes (MonitoredItem) | Events, alarms |
| Browse | Browsing the Address Space | Configuration, discovery |
| Write | Writing a value | Setpoints, commands |
| Method Call | Method call | Complex actions |
| Pubsub | MQTT or UDP publish/subscribe | Large-scale cloud architectures |
Subscriptions are the right approach for real-time monitoring: instead of polling every second, the client subscribes to a node and receives a notification only when the value changes beyond a configurable threshold (DeadbandValue).
\nSecurity is one of OPC-UA's strengths—and also one of the sources of its complexity. Here are the key concepts.
\n| Mode | Confidentiality | Integrity | Authentication | Usage |
|---|---|---|---|---|
None | None | None | None | Testing, isolated network |
Sign | No | Signature | Certificate | Secure network |
SignAndEncrypt | AES-256 | Signature | Certificate | Internet, cloud |
Never use SecurityMode: None in a production environment on a network accessible from the outside.
OPC-UA uses X.509 certificates for mutual client-server authentication:
\n\nCreating a self-signed certificate for testing:
\n# Avec OpenSSL
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \\
-keyout client_key.pem -out client_cert.pem \\
-subj \"/CN=EziwanGateway/O=Eziwan/C=FR\" \\
-extensions v3_req \\
-config <(cat /etc/ssl/openssl.cnf; echo \"[v3_req]\"; echo \"subjectAltName=URI:urn:eziwan:gateway:client\")
In production: Use an internal PKI or a recognized CA. Certificates must be exchanged manually between the client and the server the first time.
\nIn addition to machine certificates, OPC-UA supports user authentication:
\nThe python-opcua library (or its fork, asyncua) is the go-to choice in Python.
\npip install asyncua
import asyncio
from asyncua import Client
async def main():
url = \"opc.tcp://192.168.1.10:4840/freeopcua/server/\"
async with Client(url=url) as client:
# Read a node by NodeId
node = client.get_node(\"ns=2;s=Station_1.Pression\")
value = await node.read_value()
print(f\"Pression: {value} bar\")
# Read Multiple Nodes in a Batch
nodes = [
client.get_node(\"ns=2;s=Station_1.Pression\"),
client.get_node(\"ns=2;s=Station_1.Debit\"),
client.get_node(\"ns=2;s=Station_1.Defaut\"),
]
values = await client.read_values(nodes)
for node, val in zip(nodes, values):
print(f\" {node}: {val}\")
asyncio.run(main())
import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler
class DataChangeHandler(SubHandler):
def datachange_notification(self, node, val, data):
print(f\"[CHANGE] {node} = {val}\")
def event_notification(self, event):
print(f\"[EVENT] {event}\")
async def main():
url = \"opc.tcp://192.168.1.10:4840\"
async with Client(url=url) as client:
handler = DataChangeHandler()
subscription = await client.create_subscription(500, handler) # 500ms
nodes = [
client.get_node(\"ns=2;s=Station_1.Pression\"),
client.get_node(\"ns=2;s=Station_1.Debit\"),
]
monitored_items = await subscription.subscribe_data_change(nodes)
print(\"Subscriptions actives, attente changements...\")
await asyncio.sleep(30) # Listen for 30 seconds
await subscription.unsubscribe(monitored_items)
asyncio.run(main())
from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.crypto.cert_man import CertificateManager
async def connect_secure():
client = Client(\"opc.tcp://192.168.1.10:4840\")
await client.set_security(
SecurityPolicyBasic256Sha256,
certificate=\"./client_cert.der\",
private_key=\"./client_key.pem\",
server_certificate=\"./server_cert.der\"
)
await client.connect()
# ... your operations
await client.disconnect()
The node-opcua library is the go-to choice for JavaScript/TypeScript.
\nnpm install node-opcua
const opcua = require(\"node-opcua\");
const client = opcua.OPCUAClient.create({
endpointMustExist: false,
connectionStrategy: { maxRetry: 5, initialDelay: 2000 }
});
const endpointUrl = \"opc.tcp://192.168.1.10:4840\";
async function main() {
await client.connect(endpointUrl);
const session = await client.createSession();
const nodeToRead = {
nodeId: \"ns=2;s=Station_1.Pression\",
attributeId: opcua.AttributeIds.Value
};
const dataValue = await session.read(nodeToRead);
console.log(`Pression: ${dataValue.value.value} bar`);
console.log(`Timestamp: ${dataValue.serverTimestamp}`);
await session.close();
await client.disconnect();
}
main().catch(console.error);
The S7-1500 supports native OPC-UA server functionality starting with firmware version 2.0:
\nDevice Configuration → OPC UA → ServerThe S7-1200 has supported OPC-UA since firmware version 4.1.
\nM580: OPC-UA via the BMENOC0311 module (firmware ≥ V2.0)\nM340: No native OPC-UA support → Modbus TCP recommended, or an OPC-UA to Modbus gateway (e.g., Kepware KEPServerEX)
\nRockwell PLCs do not natively support OPC-UA. Options:
\nTwinCAT 3 includes a native OPC-UA server via TF6100 (OPC-UA module). Configuration is performed via TwinCAT System Manager.
\nMost modern PLCs from these manufacturers support OPC-UA. Check the firmware and enable the server in the network configuration.
\nOPC-UA PubSub (IEC 62541-14) is the extension that makes OPC-UA compatible with cloud-based IoT architectures:
\nSupported transport protocols:
\nEncodings:
\nExample of an OPC-UA PubSub JSON message:
\n{
\"MessageId\": \"abc123\",
\"PublisherId\": \"urn:station1:plc\",
\"DataSetWriterId\": 1,
\"MetaDataVersion\": {\"MajorVersion\": 1, \"MinorVersion\": 0},
\"Timestamp\": \"2026-08-14T10:30:00.000Z\",
\"Payload\": {
\"Station_1.Pression\": {\"Value\": 4.2, \"StatusCode\": 0, \"SourceTimestamp\": \"2026-08-14T10:29:59.950Z\"},
\"Station_1.Debit\": {\"Value\": 125.3, \"StatusCode\": 0, \"SourceTimestamp\": \"2026-08-14T10:29:59.950Z\"}
}
}
If you have systems running OPC-DA (OPC Classic, Windows DCOM), migrating to OPC-UA offers:
\nMigration tool: OPC UA Wrapper (e.g., Kepware) creates an OPC UA server that exposes data from an existing OPC DA server, enabling a phased migration.
\nThe Eziwan Gateway includes an OPC-UA client capable of connecting to the OPC-UA servers on your devices:
\nNone, Sign, and SignAndEncrypt security modesKey benefit: You don't need to write an OPC-UA client yourself. The gateway handles this and exposes a REST API to your SCADA or ERP system.
\nIs OPC-UA more complex than Modbus?\nYes, but it’s justified for multi-vendor installations and Industry 4.0 projects. For an installation with 2–3 PLCs from the same manufacturer, Modbus TCP may be sufficient. OPC-UA is the way to go when you have heterogeneous equipment, safety requirements, or ERP/MES interoperability needs.
\nDoes port 4840 need to be open on my firewall?\nIn a \"zero-inbound-port\" architecture (such as Eziwan), the gateway initiates the connection to the OPC-UA server internally. No ports are open to the outside. The encrypted VPN tunnel carries the data to the cloud.
\nCan OPC-UA replace MQTT in an IoT architecture?\nOPC-UA PubSub with MQTT transport combines the best of both worlds: OPC-UA’s semantic information model with MQTT’s lightness and scalability. This is the direction taken by the Industry 4.0 reference frameworks (Industry 4.0 Architecture Reference Model, IDS-R).
\nWhat performance can you expect from an embedded OPC-UA server?\nA Siemens S7-1500 CPU 1515 can process ~10,000 OPC-UA read nodes per second. For less powerful PLCs (M221, small WAGO models), limit OPC-UA polling to 100–500 nodes per second. Subscriptions are much more efficient than polling for large volumes.
\nAre there any free OPC-UA servers available for testing?\nYes: ProsysOPC UA Simulation Server (free, Windows), Node-RED with node-red-contrib-opcua (free, cross-platform), python-opcua in server mode (example in the GitHub documentation). These allow you to test a client without a physical PLC.
Need help connecting your OPC-UA servers to the cloud? Request a free demo — our team will guide you from proof of concept through deployment.
\nYour Schneider Electric Modicon M340, M221, or M580 PLCs have been running for years, but monitoring remains local—on-site operator panel, no remote access, no historical trends. This guide shows you how to connect them to the IoT cloud without modifying your PLC program or interrupting production.
\nSchneider Electric's Modicon series PLCs are used in thousands of industrial facilities in France: water treatment, pumping stations, food processing, and packaging lines. Robust and reliable, they often have a service life of 15–20 years.
\nBut their native communication capabilities are limited:
\nThe solution: an industrial IoT gateway that reads the Modbus data from your M340/M221 and sends it to the cloud, without modifying the PLC program.
\nThe M221 (TM221CE16R, TM221CE24T, etc.) features a native Modbus RTU port on its RJ45 connector (RS-485 via a TM3TI4 adapter or a specific cable) and a Modbus TCP port on its Ethernet port.
\nAccessible registers:
\n%MW0 to %MW255 — memory words%QW — analog outputs%IW — analog inputs%M — memory bits (coils 0–255)Modbus Slave Configuration on the M221:
\nIn EcoStruxure Machine Expert - Basic:
\nConfiguration → Modbus Serial or Modbus TCPThe M340 (BMX P34 2020, BMX P34 2030, etc.) features a Modbus RTU serial port (RS-485, 9-pin SUB-D connector) and an ETH module (BMX NOE 0100 or BMX NOC 0401) for Modbus TCP.
\nRegisters accessible via Modbus:
\n| PLC Zone | Modbus Type | Read Function | Range |
|---|---|---|---|
%MW | Holding Registers | FC03 | 400001–465535 |
%IW | Input Registers | FC04 | 300001–365535 |
%M | Coils | FC01 | 000001–065536 |
%I | Discrete Inputs | FC02 | 100001–165536 |
Modbus Address → Unity Pro Address:
\n%MW0%MW99%MW500The M580 features native Modbus TCP on its CPU Ethernet port and supports the same register tables as the M340, plus:
\nPrerequisites:
\nAdvantages:
\nFor the M221: Use the TCSMCNAM3M002P cable (RJ45 to RS-485) or the VW3A8306 adapter, depending on the model.
\nFor the M340: 9-pin SUB-D connector on the PLC side; pins 3 (+) and 8 (-) for RS-485.
\nM221/M340 Serial Settings (Default):
\nOnce the gateway is connected, you can configure it from the Eziwan cloud interface with just a few clicks.
\nFlotte → Site → + Équipement192.168.1.10 (or your M340’s address)5021| Variable | Modbus Register | Type | Description |
|---|---|---|---|
| Tank Level | %MW10 → 400011 | Holding (FC03) | 0-100% |
| Pump Flow | %MW20 → 400021 | Holding (FC03) | 0–500 m³/h |
| Pressure | %IW0 → 300001 | Input (FC04) | 0–16 bar |
| General fault | %M0 → 000001 | Coil (FC01) | Boolean |
| Pump on | %M1 → 000002 | Coil (FC01) | Boolean |
Conversion engineering: Apply a multiplier if the PLC returns a raw value (e.g., ×0.01 to convert from 1500 to 15.00 bar).
| Criticality | Polling | Use Case |
|---|---|---|
| Real-time | 1 s | Safety, critical processes |
| Monitoring | 5 s | Production, energy |
| Trends | 30 s | Meter readings, statistics |
| Archive | 5 min | Simple remote meter reading |
As soon as the gateway connects for the first time, data is transmitted in real time to the Eziwan dashboard:
\nSet up specific alerts for each variable:
\nAlert: Tank Level
Condition : %MW10 < 10 (niveau bas)
Canal : SMS + Email
Recipients: equipe@maintenance.fr, astreinte@maintenance.fr
Acquittement : requis
Alert: Pump Failure
Condition: %M5 = 1 (fault bit active)
Channel: Instant SMS
Priority: Critical
All data is archived for 5 years as standard, at no additional cost. You can:
\nBackground: A local government agency manages 12 pumping stations equipped with 2020 M340 BMX P34 units. Current maintenance: 3 field rounds per week, 2 technicians.
\nDeployed Configuration:
\nResults after 6 months:
\nIf you are using SoMachine (M221) or Unity Pro (M340/M580), no changes to the PLC program are necessary. The Eziwan gateway connects in read-only mode by default.
\nIf you also want to write commands (setpoints, commands) from the cloud:
\n%MW200-MW220)Writing to a PLC from the cloud must be subject to a risk analysis (HAZOP). Critical addresses (emergency stop, safety instructions) must be protected with read-only access.
The Eziwan gateway is compatible with EcoStruxure in several ways:
\nThe gateway reads the same registers as your EcoStruxure SCADA system, without any interference. Ideal for adding:
\nIf your EcoStruxure Plant license is nearing the end of its lifecycle, you can migrate in phases:
\n| M221 | M340 | M580 | |
|---|---|---|---|
| Native Modbus RTU | ✅ (via cable) | ✅ (SUB-D 9) | ✅ |
| Native Modbus TCP | ✅ (ETH port) | ✅ (BMX NOE module) | ✅ native |
| Max Eziwan variables | 128 | 512 | 1024 |
| Min. polling interval | 1 s | 1 s | 500 ms |
| Register write | ✅ FC06 | ✅ FC06/FC16 | ✅ FC06/FC16 |
| Store-and-forward compatibility | ✅ | ✅ | ✅ |
Do I need to modify the SoMachine/Unity Pro program?\nNo. The Eziwan gateway connects as a Modbus master to the slave PLC. No code is added to the PLC. If the PLC is already configured as a Modbus slave (which is the default setting), the connection is established immediately.
\nMy M340 already has a Unity Pro SCADA system—is it compatible?\nYes. Multiple Modbus TCP masters can query the same slave simultaneously. The Eziwan gateway and your SCADA system can coexist without conflict, provided you configure a reasonable polling frequency (≥ 1 s).
\nCan I monitor analog input modules (BMX AMI 0410)?\nYes. The analog modules are addressed in the %IW (inputs) and %QW (outputs) tables. Refer to the Unity Pro documentation for the register mapping of your specific modules.
Does the gateway work if the 4G network is down?\nYes. The Eziwan gateway includes an SD card buffer: data continues to be collected locally and is transmitted in batches once connectivity is restored (store-and-forward). Local alerts (direct SMS) remain operational without the cloud.
\nIs it compatible with the Zelio Logic product line?\nThe Zelio Logic Smart Relay supports a limited version of Modbus RTU. Depending on the model (SR2/SR3), access to internal registers may be restricted. Please contact us to confirm compatibility with your specific model.
\nDo you have an M340, M221, or M580 on-site and want to verify the cloud connection?
\nEziwan offers a free 30-day POC that includes:
\nStart the free POC → | Calculate your ROI →
\nDo you use other Schneider Electric product lines (Altivar, Easergy, PowerLogic)? Contact us to verify compatibility with your specific equipment.
\nChoosing a wireless communication protocol is one of the most important decisions in an industrial IoT project. LoRaWAN, Zigbee, 4G LTE, or Wi-Fi: each technology has its strengths, weaknesses, and ideal use cases. Choosing the wrong technology can make your deployment impossible to scale, too expensive to operate, or insufficiently reliable for your industrial environment.
\nThis guide compares the four main wireless technologies used in industrial IoT in France, with practical recommendations for each use case.
\nBefore getting into the details, here’s the gist in one sentence for each technology:
\n| Criterion | LoRaWAN | Zigbee | 4G LTE | Wi-Fi 802.11n/ac |
|---|---|---|---|---|
| Range | 1–15 km (rural) / 0.5–3 km (urban) | 10–100 m (mesh up to 300 m) | 0.5–30 km | 30–150 m |
| Data Rate | 250 bps to 50 Kbps | 20–250 Kbps | 5–100 Mbps | 50–1000 Mbps |
| Latency | 1–10 s | 10–30 ms | 30–100 ms | 1–10 ms |
| Power consumption | Very low (µA in standby) | Low (µA–mA) | Medium (mA–W) | High (W) |
| Battery life | 5–15 years | 1–5 years | 6–24 months | Days to weeks |
| Infrastructure cost | Low (LoRa hub) | Medium (coordinator + mesh) | Low (M2M SIM) | High (AP + switches) |
| Cost per node | 10–80 € | 20–150 € | 100–500 € | 50–300 € |
| Frequency | 868 MHz (EU) | 2.4 GHz | 700/800/1800/2600 MHz | 2.4 / 5 GHz |
| Native security | AES-128 | AES-128 | 3GPP (TLS, SIM) | WPA3 |
| Standardization | LoRa Alliance | Zigbee Alliance (CSA) | 3GPP | IEEE 802.11 |
| Topology | Star (via hub) | Mesh | Point-to-point (via mobile network) | Star (via AP) |
| Number of nodes per gateway/AP | 2,000 to 10,000 | 65,000 (Zigbee 3.0) | N/A (carrier network) | 30–100 active clients |
LoRaWAN is ideal for scenarios where you need very long ranges and very low power consumption, but where the data rate is low (a few bytes per message every few minutes to hours).
\nIdeal industrial use cases for LoRa:
\nLoRaWAN Advantages:
\nLoRaWAN Limitations:
\nTypical Industrial LoRa Architecture:
\n\nZigbee is ideal for dense indoor sensor networks with short ranges, particularly in buildings (smart buildings) and factories where distances are short but the number of nodes is high.
\nIdeal Industrial Use Cases for Zigbee:
\nZigbee Advantages:
\nZigbee Limitations:
\n4G LTE is the technology of choice for long-distance WAN connections, remote sites without network infrastructure, and applications requiring sufficient bandwidth for monitoring and remote access.
\nIdeal industrial use cases for 4G:
\nBenefits of Industrial 4G LTE:
\n4G LTE Limitations:
\nWi-Fi is suitable for sites with existing network infrastructure, devices requiring high-speed connectivity, and areas with full coverage from access points.
\nIdeal Industrial Use Cases for Wi-Fi:
\nBenefits of Industrial Wi-Fi:
\nLimitations of Industrial Wi-Fi:
\n| Sector | Primary Recommendation | Secondary | Avoid |
|---|---|---|---|
| Water/Sewage (remote facilities) | 4G LTE | LoRaWAN (meters) | Wi-Fi |
| Water/Sewage (urban network) | LoRaWAN | 4G LTE | — |
| Renewable Energy (rural farms) | 4G LTE | LoRaWAN (weather) | Wi-Fi |
| Manufacturing (indoor factory) | Wi-Fi / 4G | Zigbee | LoRaWAN |
| Warehouse logistics | Wi-Fi / Zigbee | 4G LTE | LoRaWAN |
| Agriculture (rural farms) | 4G LTE | LoRaWAN | Wi-Fi |
| Smart buildings (commercial) | Zigbee / Wi-Fi | LoRaWAN | 4G LTE |
| Remote maintenance (remote access) | 4G LTE | — | LoRaWAN, Zigbee |
In practice, mature industrial IoT deployments use a combination of technologies, selected based on the nature of each piece of equipment.
\nExample of a hybrid architecture: a 10-hectare industrial site
\n\nThe Eziwan gateway acts as a multiprotocol hub: it communicates via Modbus on the local OT network, is compatible with LoRa and Zigbee hubs for wireless sensors, and transmits all data to the cloud via 4G LTE. One subscription, one dashboard.
\n| Criterion | LoRaWAN (public network) | Zigbee (private network) | 4G LTE | Industrial Wi-Fi |
|---|---|---|---|---|
| Hardware per node | 30–60 € | 50–120 € | 300–500 € | 100–250 € |
| Infrastructure | 0 € (public network) | 500–2,000 € (hub) | 0 € | 3,000–15,000 € (APs) |
| Subscription per node/year | 5–15 € | 0 € | 120–240 € | 0 € |
| Total hardware for 100 nodes | 3,000–6,000 € | 5,000–14,000 € | 30,000–50,000 € | 10,000–25,000 € |
| Total 5-year subscription | 2,500–7,500 € | 0 € | 60,000–120,000 € | 0 € |
| 5-year TCO (100 nodes) | €5,500–13,500 | €5,000–14,000 | €90,000–170,000 | €13,000–40,000 |
Note: 4G LTE is significantly more expensive per node, but provides long-distance WAN connectivity that LoRa and Zigbee cannot offer. This comparison applies only to data-collection sensors, not to industrial gateways that must provide an internet connection.
\nThere is no single \"best\" universal IoT technology. The choice depends on three fundamental criteria:
\nThe Eziwan solution is optimized for 4G LTE as an industrial WAN connection technology, as it is best suited for gateways that need to connect local OT networks (Modbus, OPC-UA) to the monitoring cloud. It can be supplemented with LoRaWAN or Zigbee concentrators for low-power sensors.
\nNeed help choosing the right architecture for your project? Contact our team of engineers for a free assessment of your situation.
\nCan LoRaWAN and 4G LTE be combined at the same site?\nYes—it’s even recommended. Battery-powered LoRaWAN sensors (water meters, environmental probes, level sensors) transmit data via a LoRa hub. The Eziwan 4G LTE gateway consolidates data from local LoRa sensors and Modbus devices and sends it to the cloud. 4G is used only for the WAN connection, not for each individual sensor.
\nIs LoRaWAN reliable for critical industrial monitoring?\nLoRaWAN is suitable for non-critical monitoring (meter readings, environmental data, presence detection). For critical monitoring (pump alarms, process values), 4G LTE is preferable due to its low latency and reliability. The two protocols often coexist: LoRaWAN for auxiliary sensors, and 4G for critical PLCs and HMIs.
\nWhat is the difference between LoRa and LoRaWAN?\nLoRa is the radio technology (Semtech's CSS modulation). LoRaWAN is the network protocol based on LoRa: it defines the network architecture (nodes → concentrators → Network Server → Application Server), address management, security (AES-128), and device classes (A, B, C). LoRa without LoRaWAN can operate in a proprietary point-to-point mode—which is less interoperable.
\nCan Zigbee be used in an industrial environment with electromagnetic interference?\nZigbee (2.4 GHz) is sensitive to industrial radio interference (motors, variable-speed drives, welding). In highly disrupted environments, prioritize Zigbee channels at 915 MHz (available in a sub-GHz version) or use wired connections (RS-485 Modbus) for the most critical equipment. The Zigbee mesh network improves resilience but does not eliminate physical limitations.
\nIs industrial Wi-Fi suitable for moving machinery (AGVs, conveyors)?\nWi-Fi with 802.11r roaming (Fast Transition) is used for AGVs (automated guided vehicles) and conveyors. A network of access points covering the entire route enables rapid handover (<50 ms) between APs. This deployment is more complex and costly than a fixed network, but it is the standard solution for moving machines in indoor environments.
\nEziwan specializes in 4G LTE industrial IoT connectivity. Our multi-protocol gateway (Modbus, OPC-UA, MQTT, LoRaWAN, Zigbee) integrates seamlessly with your existing architecture. Learn more about the Eziwan gateway →
\nThe machine you deliver today generates revenue only once. The same connected machine generates recurring revenue throughout its lifetime—from maintenance, subscriptions, and firmware upgrades.
\nFor an industrial machinery manufacturer (OEM), integrating remote maintenance is not just a sales pitch. It is a transformation of the business model. This article provides the technical, economic, and contractual foundations needed to successfully carry out this transformation.
\nTen years ago, offering remote maintenance was a competitive advantage. Today, in many industries, it is a prerequisite for entering certain markets.
\nFood and Beverage: Modern production lines operate 20 hours a day, 6 days a week. An unplanned shutdown costs between €5,000 and €50,000 per hour, depending on capacity. Clients require commitments to resume operations within 2 to 4 hours, which is impossible to meet without remote diagnostics.
\nPharmaceuticals and Cosmetics: Equipment is subject to qualification procedures (IQ/OQ/PQ). Any modification or intervention must be documented. Remote maintenance with full traceability of sessions fully meets this requirement.
\nAutomotive and Mechanical Engineering Industries: Major corporate clients are incorporating equipment connectivity into their selection criteria for requests for proposals. Non-connected equipment is excluded outright in some specifications.
\nRenewable Energy: wind turbines, solar power plants, industrial heat pumps—preventive maintenance based on operational data is a key factor in competitiveness.
\nManufacturers that have incorporated remote maintenance into their offerings report significant business impacts:
\nThe most effective approach is to integrate the Eziwan gateway as a standard component of the machine, just like the variable-frequency drive or the HMI unit. It is listed in the bill of materials, the electrical schematic, and the manual.
\nThis integration from the design stage onward avoids retroactive integration issues (such as adapting the wiring and justifying the cost to the buyer) and makes it possible to offer remote maintenance seamlessly as a standard feature of the machine.
\n┌──────────────────────────────────────────────────────────────────┐
│ Machine industrielle (OEM) │
│ │
│ [Capteurs et actionneurs] │
│ ├── Températures, pressions, débits │
│ ├── Moteurs, variateurs, servomoteurs │
│ └── Codeurs, capteurs de position │
│ ↓ Analogique / TOR │
│ [Automate / Motion controller] │
│ ├── Programme de production (protégé Know-How) │
│ ├── Variables de process (accessibles supervision) │
│ ├── Compteurs et historique local │
│ └── Codes défaut et diagnostics │
│ ↓ Modbus TCP ou RS-485 │
│ [Gateway Eziwan] ← Intégrée en standard dans l'armoire │
│ ├── Collecte Modbus (poll 1-60s configurable) │
│ ├── Bufferisation locale (perte 4G jusqu'à 48h) │
│ ├── 4G LTE Dual SIM (SIM multi-opérateurs incluse) │
│ └── Tunnel OpenVPN sortant → zéro port entrant │
└──────────────────────────────────────────────────────────────────┘
│ Tunnel OpenVPN chiffré
▼
[Cloud Eziwan]
↙ ↘
[Espace OEM] [Espace client]
- Toutes variables - Variables autorisées
- Firmware update - Supervision process
- Diagnostics - Alertes et historique
- Accès toutes machines - Ses machines seulement
The separation between the OEM space and the customer space is one of the most important aspects of the architecture. It addresses two conflicting needs:
\nProtected variables (OEM only):\nCalibration parameters, manufacturing recipes, PID control parameters, internal protection thresholds.
\nShared variables (visible to the client):\nProcess temperatures, pressures, flow rates, machine statuses, production counters, generic error codes.
\nYour customers always ask the same question: \"If you have remote access to my machine, how can I be sure you can't see my confidential production data?\"
\nAnd sometimes they ask the opposite question: \"If a hacker compromises your manufacturer account, can they access my device?\"
\nThe technical solution to these two questions is cryptographic partitioning.
\nIndependence of Access Spaces:\nThe OEM space and the customer space use completely separate credentials that are unrelated to one another. Compromising a customer credential does not grant access to the OEM space, and vice versa.
\nFine-grained selection of visible variables:\nThe gateway configuration explicitly defines which variables are visible to each access level:
\nvariables:
- nom: \"Temperature_Etuve\"
modbus_addr: 100
access_oem: read_write # OEM peut lire et modifier
access_client: read # Client peut lire
- nom: \"PID_Kp_Etuve\"
modbus_addr: 200
access_oem: read_write
access_client: hidden # Client ne voit pas ce paramètre
- nom: \"Compteur_Cycles\"
modbus_addr: 300
access_oem: read
access_client: read # Les deux peuvent lire les compteurs
Traceability of OEM Access at the Customer Site:\nThe customer can see in their dashboard when OEM technicians logged in to their machine, for how long, and which variables they accessed. This transparency builds trust.
\nRegardless of the gateway, it is recommended that you enable the PLC's native security features:
\nSiemens S7-1500:
\nSchneider M340:
\nWhen your machine is in production at 100 customer sites, you have access to something unique: real-world operational data, collected under a variety of conditions over an extended period. This is a valuable resource that R&D teams at large companies spend millions to obtain.
\nActual Component Lifespan:\nStatistically speaking, after how many hours of operation does the ball bearing on your machine’s Y-axis fail? Data from your fleet of 100 machines provides a precise answer to this question. What you thought was an MTBF of 8,000 hours may actually be 6,500 hours in real-world production, or 12,000 hours if operators follow lubrication procedures properly.
\nCorrelation Between Parameters and Incidents:\nWhat combination of ambient temperature, motor load, and cycle time precedes a thermal regulator failure? These correlations will help improve preventive maintenance algorithms for future generations.
\nActual Use vs. Intended Use:\nIs your machine being used according to its specifications? Some customers push the machine beyond its rated limits. Others use it well below those limits. This information guides design decisions (such as oversizing a component that is consistently operating at 95% of its capacity).
\nFleet Segmentation:\nSome customers have default rates three times higher than average. Why? Analyzing operational data can reveal correlations with environmental factors (temperature, humidity, vibrations) or with operator practices.
\nRemote maintenance paves the way for an annual connected maintenance subscription. This model transforms the business relationship:
\nTraditional Model:
\nConnected model:
\n──────────────────────────────────────────────────────────────────
OFFRE STANDARD — Supervision opérationnelle
• Tableau de bord client en temps réel
• Alertes SMS/email sur défauts machine
• Historique 1 an
• 2 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE MAINTENANCE CONNECTÉE
• Tout le Standard +
• Accès technicien OEM à distance (illimité)
• SLA : diagnostic à distance sous 4h ouvrées
• Mise à jour firmware automate à distance
• Historique 3 ans
• 5 utilisateurs client inclus
──────────────────────────────────────────────────────────────────
OFFRE PERFORMANCE GARANTIE
• Tout le Maintenance Connectée +
• Rapport mensuel de performance machine
• Analyse prédictive (détection dérive)
• Engagement disponibilité machine
• Accès API données pour intégration client
──────────────────────────────────────────────────────────────────
For an OEM with 150 machines installed, assuming an average of 1.8 corrective service calls per machine per year:
\n| Metric | Without remote support | With remote support |
|---|---|---|
| Service Calls/Year | 270 | 108 (60% resolved remotely) |
| On-site Service Call Cost | €1,200 (travel + 4 hours of technician time) | €200 (1-hour remote session) |
| Corrective maintenance cost | €324,000 | €128,600 |
| Annual savings | ~€195,400 |
These are indicative estimates. The actual ROI depends on the location of the facility, the nature of the outages, and the internal organization.
\nDedicated Power Supply:\nTap 24 V DC from a continuous power source (before the machine's main switch). The gateway must remain accessible even when the main machine is turned off—it is precisely at these times that remote diagnostics are most useful.
\nPLC Network:\nConnect the gateway to a dedicated Ethernet port (separate from the HMI port if possible). On single-port PLCs (S7-1200 CPU 1211C, M221, etc.), use a manageable industrial switch to separate the HMI, gateway, and engineering traffic.
\n4G Antenna:\nFor steel cabinets, always provide a cable passage for a remote antenna. Indoors with a closed cabinet, the signal is often insufficient. A 3-meter LMR-200 cable with a directional antenna mounted outside the cabinet is sufficient in the vast majority of cases.
\nEziwan provides OEM partners with documentation to include in your machine manuals:
\nSee also the dedicated page: OEM Machine Manufacturers for detailed information on the architecture and terms of the partner program.
Can the customer disable the remote maintenance gateway on their machine?
\nTechnically, yes—the customer can physically disconnect the gateway. From a contractual standpoint, the answer depends on the maintenance contract: OEMs that offer SLAs with a 4-hour response time may make that SLA contingent on remote maintenance being permanently enabled. In practice, customers rarely disable the gateway because they also use it to monitor their production.
\nHow can we protect the PLC program (OEM know-how) while still allowing the customer to monitor it?
\nTwo complementary levels of protection: (1) At the PLC level, enable Know-How protection (S7-1500) or password protection (M340) to prevent the program from being read, even via TIA Portal. (2) At the Eziwan level, configure variables such as access_client: hidden for confidential parameters. The customer sees only the process variables, not the configuration parameters.
How many machines can be managed under a single Eziwan OEM account?
\nThere is no fixed limit—OEM accounts are designed for industrial fleets (ranging from tens to thousands of machines). The OEM dashboard allows you to filter by customer, machine model, and status (alert, normal, offline), and to compare performance across machines of the same model.
\nHow should we bill customers for the remote maintenance subscription when reselling Eziwan?
\nEziwan offers an OEM partner program with wholesale pricing. The OEM integrates connectivity into its own maintenance subscription, with the margin of its choice. The end customer is unaware of the relationship with Eziwan—they sign up for a “connected maintenance subscription” with the OEM.
\nWhat happens when a maintenance contract expires: Is OEM access discontinued?
\nYes, if the contract includes this clause. From the OEM dashboard, access to a customer’s account can be disabled immediately (due to contract termination or a dispute) or transferred to another service provider. The customer’s historical data remains in their account and belongs to them—it is not lost.
\nDo you manufacture industrial machinery and want to incorporate remote maintenance into your next production run?
Join the OEM Partner Program →
Qualification interview (30 min), presentation of partner rates, and delivery of a starter kit (development gateway + access to a test OEM account).
Pumping stations—for wastewater lift stations, drinking water supply, irrigation, and industrial drainage—face a common challenge: they are scattered across vast areas, often in hard-to-reach yet critical locations. An undetected pump failure can cause an overflow, an interruption in service, or significant property damage.
\nRemote monitoring is no longer a luxury for these facilities: it is an operational necessity and, in certain regulated sectors (drinking water, wastewater treatment), a compliance requirement.
\nAn operator managing multiple pumping stations typically oversees between 20 and 200 sites, with a team of a few maintenance technicians covering hundreds of square kilometers. The stations are often:
\nWithout remote monitoring, the system operates on a reactive basis: a user call, a local alarm (siren, red light), or a periodic patrol signals the problem. Response time is measured in hours, and sometimes in days for the most remote sites.
\nUnnecessary Service Calls:\nBetween 30 and 50% of service calls triggered by alarms are \"false alarms\"—the technician arrives on site only to find that the problem has resolved itself (automatic pump restart, a temporary power outage) or that the issue does not require immediate attention. A callout costs between €400 and €700 (vehicle, time, and allowances).
\nPoorly Prepared Service Calls:\nWithout a remote diagnosis, the technician doesn't know what to expect and can't bring the right replacement parts. An extra round trip to pick up a part can double the cost of the service call.
\nLate Detection of Incidents:\nA pump that is cavitating (sucking in air), running dry, or whose impeller is beginning to deteriorate can operate for several days in a degraded state before suffering a complete failure. During this time, the pump’s service life is reduced, and the risk of sudden shutdown increases.
\nChallenges with Regulatory Compliance:\nProducing annual service quality reports (RPQS for drinking water, operator’s annual report for wastewater treatment) requires a significant amount of manual data consolidation if the data is not automatically archived.
\n┌──────────────────────────────────────────────────────────────────┐
│ Station de pompage SP-42 │
│ │
│ [Capteurs de mesure] │
│ ├── Niveau bâche : sonde à ultrasons ou pression relative 4-20mA │
│ ├── Débit : débitmètre électromagnétique (impulsions ou 4-20mA) │
│ ├── Courant moteur P1 : transformateur de courant (TA) │
│ ├── Courant moteur P2 : transformateur de courant │
│ └── Présence alimentation : contact sec sur TGBT │
│ ↓ │
│ [Coffret de régulation / Automate] │
│ ├── Siemens LOGO! 8 / S7-1200 │
│ ├── Schneider M221 / M241 │
│ ├── Wago PFC200 │
│ └── Coffret \"vrai de vrai\" relais + télémesure ancienne │
│ ↓ Modbus TCP ou RTU │
│ [Gateway Eziwan] ← Rail DIN, 24V DC │
│ └── 4G LTE Dual SIM ──────────────────────────────────────────┤
│ │
└──────────────────────────────────────────────────────────────────┘
│ Tunnel OpenVPN
▼
[Cloud Eziwan]
├── Base time-series (données horodatées)
├── Moteur d'alertes
└── Tableau de bord web + app mobile
│
▼
[Salle de conduite — téléopération]
[Application mobile — astreinte]
[Email/SMS — responsable exploitation]
| PLC | Protocol | Notes |
|---|---|---|
| Siemens S7-1200 (firmware V4+) | Modbus TCP | MB_SERVER in OB1 |
| Siemens LOGO! 8 (firmware ≥ 1.80) | Modbus TCP | Enable in LOGO! Soft Comfort |
| Schneider M221 / M241 | Modbus TCP | EcoStruxure Machine Expert |
| Schneider M340 | Modbus TCP | EcoStruxure Control Expert |
| Wago PFC100 / PFC200 | Modbus TCP or MQTT | Native MQTT on PFC200 |
| Older PLCs without Ethernet | Modbus RTU (RS-485) | Via the gateway’s RS-485 port |
| Relay cabinets without a PLC | Direct digital inputs | Via the Eziwan expansion module |
For the many small lift stations that do not have a programmable logic controller—just a starter panel with contactors and relays—the Eziwan gateway can be connected directly to field signals via a digital I/O expansion module:
\n[Contact sec \"Pompe 1 en marche\"] ──→ [Entrée TOR 1 gateway]
[Contact sec \"Défaut thermique\"] ──→ [Entrée TOR 2 gateway]
[Sonde niveau 4-20mA] ──→ [Entrée analogique gateway]
This approach makes it possible to retrofit existing stations without modifying the wiring or installing a controller.
\nFor a station with two pump sets (the most common configuration), here are the minimum variables to monitor:
\nStatus variables (Boolean values):
\n%MW300 bits :
bit 0 : Pompe 1 en marche
bit 1 : Pompe 2 en marche
bit 2 : Défaut thermique pompe 1 (disjoncteur déclenché)
bit 3 : Défaut thermique pompe 2
bit 4 : Défaut disjoncteur général
bit 5 : Alimentation électrique présente
bit 6 : Niveau haut bâche atteint (pré-alarme)
bit 7 : Niveau très haut bâche (alarme)
bit 8 : Niveau bas bâche (risque fonctionnement à sec)
bit 9 : Mode manuel activé (maintenancier sur place)
bit 10 : Défaut sonde niveau (valeur hors plage ou absence signal)
Analog variables (16- or 32-bit registers):
\n%MW100 : Niveau bâche (% × 10 → ex. 752 = 75.2%)
%MW101 : Débit instantané (L/min)
%MW102-103 : Volume journalier pompé (m³ × 1000, int32 sur 2 registres)
%MW104 : Courant moteur pompe 1 (A × 10 → ex. 142 = 14.2 A)
%MW105 : Courant moteur pompe 2 (A × 10)
%MW106 : Nombre de démarrages pompe 1 (compteur)
%MW107 : Nombre de démarrages pompe 2 (compteur)
%MW108-109 : Durée de marche cumulée P1 (minutes, int32)
%MW110-111 : Durée de marche cumulée P2 (minutes, int32)
%MW112 : Tension secteur (V × 10)
%MW113 : Code défaut détaillé (bitfield constructeur)
Monitoring motor current is the most informative indicator for preventive maintenance of pumps:
\nCavitation Detection: A pump that is drawing in air has a lower-than-normal motor current (the fluid is less dense). This is an early indicator of a level or suction problem.
\nDry-run detection: The current drops sharply below the rated no-load current. There is a risk that the mechanical seal could be damaged within a few minutes.
\nRotor Deterioration: A worn or fouled rotor consumes more current for the same flow rate. A gradual increase in current at a constant flow rate indicates that maintenance is needed.
\nPower Supply Issue: An unbalanced current between phases (on a three-phase pump) may indicate a faulty cable or a problem with the site's electrical system.
\nSet up an alert in Eziwan for motor current: trigger an alert if the current exceeds 115% of the reference value (overload) or falls below 60% (cavitation/dry running). These two thresholds help detect the most common problems before a failure occurs.
An effective alarm system for a pumping station must be calibrated to prevent alarm fatigue (too many alarms → operators ignore them) while ensuring that critical incidents are reported immediately.
\nLevel 1 — Information (team leadership email):
\nDémarrage pompe 2 alors que pompe 1 est déjà en marche
→ Information uniquement (situation normale en pointe)
Niveau bâche > 75% alors que les deux pompes sont en marche
→ Vérification débit entrant inhabituellement élevé
Level 2 — Pre-alarm (email + mobile app notification):
\nNiveau bâche > 85%
→ Situation anormale, surveiller l'évolution
Courant moteur > 110% de la valeur de référence pendant > 2 minutes
→ Surcharge légère, vérifier à la prochaine ronde
Aucune mise en marche des pompes depuis > 24h alors que niveau > 30%
→ Pompes peut-être en défaut silencieux
Level 3 — Alarm (SMS + email + on-call webhook):
\nNiveau bâche > 95%
→ Risque de débordement, intervention urgente
Défaut thermique pompe 1 ET pompe 2 simultanément
→ Station hors service, intervention immédiate
Courant moteur < 40% de la valeur nominale pendant > 30 secondes
→ Fonctionnement à sec probable, arrêt automatique conseillé
Perte d'alimentation électrique
→ Toutes les pompes s'arrêtent, vérifier groupe électrogène si disponible
Perte de connectivité gateway > 15 minutes
→ Impossible de savoir l'état de la station
Alerts can be configured with time ranges and escalation rules:
\nDéfaut thermique pompe :
Heure ouvrée (8h-18h) → SMS technicien de service
Nuit / week-end → SMS astreinte + email responsable
Si pas d'acquittement en 30 minutes :
→ Appel téléphonique (webhook vers système de téléphonie)
→ SMS responsable de service
A pumping station's historical data is a valuable operational asset that accumulates over time:
\nLong-Term Trend Analysis:\nCompare the motor current curves for Pump 1 in January 2024 and January 2025. An 8% increase indicates that the rotor is wearing out—schedule preventive maintenance before a failure occurs, during the winter shutdown.
\nCorrelation Between Rainfall and Inflow:\nFor wastewater pumping stations, the correlation between rainfall events and inflow helps determine storage capacity and identify instances of extraneous water entering the system.
\nOptimizing Control Parameters:\nAnalyze start/stop cycles: A pump that starts more than 15 times per hour indicates a sizing issue (pump too powerful, tank too small) or a control issue.
\nFor operators under a public service delegation (DSP) or a lease agreement, several reporting requirements apply:
\nRPQS — Report on Price and Service Quality:\nRequired annually by the General Code of Local Authorities (CGCT) for drinking water and wastewater services. Must include performance indicators: water quality compliance rate, service interruption rate, volume produced/distributed, and network efficiency.
\nThe Eziwan dashboard automatically generates the raw data for these metrics (pumped volumes, downtime, number of incidents).
\nRequired Monitoring Reports:\nCertain water intake or discharge facilities require periodic reports to be submitted to the DREAL (Regional Directorate for the Environment, Planning, and Housing). Historical data from Eziwan can be exported as CSV files to populate these reports.
\nData Retention:\nFor drinking water, monitoring data must be retained for at least 5 years. Eziwan allows you to configure data retention for up to several years, depending on your subscription plan.
\nAn intermunicipal wastewater management authority in the Pays de la Loire region oversees 65 pumping stations spread across an area of 1,500 km². Before the Eziwan deployment:
\nField visits avoided thanks to remote diagnostics:
\nMeasured results:
\nOur customers who operate pumping stations see an average reduction of 35 to 55 percent in travel within the first 12 months after deployment.
\nFor secure remote access configuration on pumping station PLCs, see Industrial VPN vs. TeamViewer and How to Connect to an S7 Remotely.
Does the gateway work with older lift control panels that don't have a programmable logic controller?
\nYes. Using the digital I/O expansion module, the gateway can directly read the dry contacts on electromechanical starter cabinets: pump status, thermal fault, and power supply presence. For 4–20 mA analog level sensors, a direct analog input is available. This approach eliminates the need to install a PLC at existing stations.
\nHow many variables can be monitored on a small station (LOGO! 8 or M221)?
\nThe Siemens LOGO! 8 supports up to 64 configurable Modbus blocks, and the Schneider M221 supports up to 100 %MW words in Modbus TCP. For a standard station with two pumps, the monitoring plan described in this article (approximately 20 variables) is well within the limits of these PLCs. The Eziwan gateway itself has no practical limit on the number of variables it can collect.
\nAre the pumped volume data accurate enough for RPQS reports?
\nThis depends on the accuracy of the installed flow meter (typically ±0.5% to ±2% for an electromagnetic flow meter). The gateway collects and time-stamps the pulses or the analog value from the flow meter with a configurable resolution (every second if necessary). The Eziwan history can be exported to CSV with all raw measurements for the integrated volume calculations required by the RPQS.
\nHow can we deal with frequent power micro-outages at certain rural sites?
\nThe Eziwan gateway boots up in less than 30 seconds after a power outage and automatically reestablishes the VPN tunnel. Data collected before the outage is already transmitted to the cloud. If the outage lasts longer than 30 seconds, the gateway buffers the data as soon as it restarts and retransmits it. For sites with very frequent outages (several times a day), a small-capacity 24 V DC UPS (with a few minutes of runtime) is sufficient to handle micro-outages.
\nIs it possible to send remote commands to the pumps (reset, start)?
\nYes, by writing to Modbus registers (FC=06 or FC=16). This feature must be explicitly enabled in the Eziwan configuration and protected by restrictive access rights (only certain accounts are allowed to write). Full traceability is ensured: each register write is logged with the operator’s ID and a timestamp.
\nDo you operate scattered pumping stations and want to set up centralized monitoring?
See the solution for multi-site operators →
Overview of the architecture, features designed for water and energy operators, and subscription plans tailored to fleets of 10 to 500 sites.
Modbus TCP is the most widely used PLC data collection protocol in French industry. It is used in tens of millions of devices that have been installed over the past 40 years. If you’re incorporating remote connectivity into your projects, you’ll encounter Modbus TCP—so you might as well gain a thorough understanding of it.
\nThis guide covers the essentials for practitioners: history, byte-by-byte frame structure, function codes, a comparison with competing protocols, performance optimization, security, and a complete, working Python code example.
\nModbus was created in 1979 by Modicon (now part of Schneider Electric) to enable communication between the first Modicon 084 programmable logic controllers. It was a serial (RS-232 and later RS-485) master/slave protocol designed for a single purpose: to read and write numerical values to field devices.
\nSimplicity was the fundamental design principle:
\nModbus RTU (Remote Terminal Unit): a compact binary protocol for RS-485. Data is transmitted in binary format, with a 16-bit CRC for error detection. Still widely used in field instruments (energy meters, pressure sensors, variable-frequency drives).
\nModbus ASCII: ASCII-readable version, for RS-232 connections. Less efficient (2 bytes per data byte), obsolete in new installations.
\nAround 1996–1999, as Ethernet became widespread in factories, Modbus TCP encapsulated the protocol within TCP/IP frames. The revision was precise:
\nThe advantage: Any existing equipment compatible with Modbus RTU could be migrated to Modbus TCP with minimal changes. The disadvantage: The original security vulnerabilities remained.
\n┌─────────────────────────────────────────────────────────────────────┐
│ Trame Modbus TCP │
├──────────────────────────────────────────┬──────────────────────────┤
│ MBAP Header (7 octets) │ PDU │
├──────────┬──────────┬──────────┬─────────┼────────────┬─────────────┤
│ Trans.ID │ Proto.ID │ Length │ Unit ID │ Func.Code │ Data │
│ 2 bytes │ 2 bytes │ 2 bytes │ 1 byte │ 1 byte │ n bytes │
└──────────┴──────────┴──────────┴─────────┴────────────┴─────────────┘
Transaction Identifier (2 bytes):\nA number freely chosen by the client, which is returned exactly as entered in the response. This allows responses to be correlated with requests in the case of persistent connections with multiple requests in progress. In practice, most clients use a simple counter (00 01, 00 02, 00 03...) or a fixed identifier (00 00) if they operate in sequential request/response mode.
\nProtocol Identifier (2 bytes):\nAlways 00 00 for Modbus. This constant exists to allow for a possible extension to other protocols via the same port, but has never been used.
Length (2 bytes):\nNumber of bytes that follow, in big-endian format. Includes the Unit ID and the PDU, but not the first 4 bytes of the MBAP Header. For an FC=03 request with 10 registers: 6 bytes (1 Unit ID + 1 FC + 2 addresses + 2 counts) → 00 06.
Unit Identifier (1 byte):\nModbus slave identifier. On directly connected PLCs (S7-1200 with MB_SERVER, M340 with built-in Modbus server), the value is typically 1 or 255. On Modbus RTU→TCP gateways, this identifier corresponds to the RTU slave’s address on the RS-485 bus.
\nReading 10 holding registers starting at address 100 (e.g., %MW100 on the Schneider M340):
\nRequête client (hex) : 00 01 00 00 00 06 FF 03 00 64 00 0A
Décodage byte par byte :
00 01 → Transaction ID = 1
00 00 → Protocol ID = 0 (Modbus standard)
00 06 → Length = 6 (Unit ID + FC + 2 adresse + 2 count)
FF → Unit ID = 255 (0xFF = CPU locale M340)
03 → Function Code = Read Holding Registers
00 64 → Starting Address = 100 (0x0064 en big-endian)
00 0A → Quantity = 10 registres (0x000A)
Réponse automate (hex) : 00 01 00 00 00 17 FF 03 14 [20 octets]
Décodage :
00 01 → Transaction ID = 1 (même que la requête — corrélation)
00 00 → Protocol ID = 0
00 17 → Length = 23 (1 UID + 1 FC + 1 ByteCount + 20 données)
FF → Unit ID = 255
03 → Function Code = 3 (confirme que c'est une réponse normale)
14 → Byte Count = 20 (10 registres × 2 octets = 0x14 hex)
[suivi de 20 octets de données — 10 valeurs uint16 big-endian]
When the bot cannot process a request, it returns an exception code:
\nRéponse exception (hex) : 00 01 00 00 00 03 FF 83 02
83 → FC + 0x80 = 3 + 128 = 131 → indique une réponse d'exception sur FC=3
02 → Exception code : Illegal Data Address
| Code | Name | Meaning | Common Cause |
|---|---|---|---|
| 01 | Illegal Function | Unsupported FC | PLC does not support this FC |
| 02 | Illegal Data Address | Out-of-range address | Register > PLC limit |
| 03 | Illegal Data Value | Invalid data value | Count > 125 (FC=03) |
| 04 | Server Device Failure | Internal error | Modbus server not initialized |
| 05 | Acknowledge | Long-running process | Rare in practice |
| 06 | Server Device Busy | Server busy | Too many simultaneous connections |
| 0A | Gateway Path Unavailable | Gateway path unavailable | RTU slave unreachable |
| 0B | Gateway Target Device Failed | Slave not responding | RTU slave powered off or failed |
FC=01 : Read Coils → bits de sortie (écriture autorisée)
FC=02 : Read Discrete Inputs → bits d'entrée (lecture seule)
Requête : FC AddrH AddrL QuantH QuantL
01 00 00 00 00 00 10 (lecture 16 coils depuis @0)
Réponse : FC ByteCount Coil_Data
01 02 [2 bytes = 16 bits d'état]
Note : les coils sont packés en bits, LSB first.
Byte1 bit0 = Coil@0, Byte1 bit1 = Coil@1, etc.
Read/write access to 16-bit registers. Limit: 125 registers maximum per request.
\nSame as FC=03, but for the \"input\" registers (read-only). On the Schneider M340, this corresponds to the %IW registers. On most PLCs, this is rarely used because the analog measurements are copied to the %MW (Holding Registers).
FC=06 : Write Single Register
Requête : FC AddrH AddrL ValueH ValueL
06 00 64 00 64 01 F4 (écriture 500 à l'adresse 100)
FC=16 : Write Multiple Registers (jusqu'à 123 registres par requête)
Requête : FC AddrH AddrL CountH CountL ByteCount Values...
10 00 64 00 05 01 2C [données]
Caution when writing (FC=06, FC=16): Only write to registers if you are certain of the addressing and the impact on the PLC program. Writing to a setpoint register immediately changes the process behavior. Always test on a development PLC or a non-production PLC before deployment.
These three protocols coexist in modern IIoT architectures. They serve different layers and are not in direct competition with one another.
\n| Criterion | Modbus TCP | OPC-UA | MQTT |
|---|---|---|---|
| Year Introduced | 1979 (RTU), ~1996 (TCP) | 2008 | 1999 |
| Model | Client/Server (polling) | Client/Server + Pub/Sub | Pub/Sub (broker) |
| Layer | Field communication | Systems interoperability | IoT/cloud transport |
| Native security | None | TLS + certificate authentication | TLS + authentication |
| PLC CPU Load | Very low | High | Low to medium |
| Legacy PLCs | Universal (40 years) | Modern PLCs only | Via gateway |
| Automatic Discovery | No | Yes (OPC namespace) | No |
| Structured data | No (flat registers) | Yes (types, structs, arrays) | Yes (JSON/CBOR) |
| Latency | Low (polling) | Very low (pub/sub) | Very low |
Use Modbus TCP if:
\nUse OPC-UA if:
\nUse MQTT for cloud transport if:
\nThe target architecture for cloud-based IIoT:
\n[Automate] ──Modbus TCP / OPC-UA──→ [Gateway] ──MQTT over TLS──→ [Cloud]
The gateway converts and transmits data. It bridges the OT world (Modbus/OPC-UA) and the cloud world (MQTT/REST).
\nModbus TCP has no native security mechanisms:
\nPractical implication: If your PLC is accessible from the Internet (port 502 open), it is completely vulnerable. If someone connects to your OT network (physically or through a security breach), they can read and modify all the registers.
\nNetwork segmentation (primary measure):\nContain Modbus TCP traffic within an isolated OT network. The Eziwan gateway is located within this OT network; communication with the cloud occurs via a VPN tunnel, not by exposing port 502.
\nIP Filtering on the PLC (Secondary Measure):\nSome newer PLCs (Schneider M340 firmware ≥ 2.60, Siemens S7-1200 firmware V4.x with FIREWALL functions) support IP filtering: Only the IP address of the Eziwan gateway is authorized to connect to port 502.
\nModbus Security (advanced measure):\nIn 2018, the Modbus Organization released a \"Modbus Security\" extension (TLS transport for Modbus TCP) on port 802. This extension is not yet widely supported by PLCs on the market, but is available on some newer devices.
\nThe golden rule: group reads into contiguous blocks. Reading 100 contiguous registers in a single query is much more efficient than 100 queries, each reading a single register:
\nConfiguration inefficace (100 requêtes) :
Lire %MW0 → 1 requête (2 octets de données)
Lire %MW50 → 1 requête
Lire %MW99 → 1 requête
... 97 requêtes supplémentaires ...
Latence totale : 100 × (aller-retour réseau) ≈ 100 × 5ms = 500ms
Configuration optimisée (1 requête) :
Lire %MW0 à %MW99 → 1 requête (200 octets de données)
Latence totale : 1 × 5ms = 5ms
The Eziwan gateway automatically groups configured variables into contiguous ranges. To maximize this grouping, organize your monitoring variables in adjacent memory areas.
\nEach Modbus TCP request received is processed by the PLC at the end of the program cycle. On an M340 with a 10-ms cycle time, 10 simultaneous Modbus requests can extend the cycle time by 1 to 3 ms.
\nRecommendation: Do not exceed 1 Modbus request per PLC cycle for real-time applications. Reduce the polling frequency if the cycle time increases.
\n\"\"\"
Collecte Modbus TCP industrielle avec gestion d'erreurs robuste
Compatible Schneider M340, Siemens S7-1200, Wago, Allen-Bradley...
Testé avec pymodbus >= 3.0
Installation :
pip install pymodbus loguru
\"\"\"
from pymodbus.client import ModbusTcpClient
from pymodbus.exceptions import ModbusException, ConnectionException
from loguru import logger
import struct
import time
from dataclasses import dataclass
from typing import Optional
# ─── Configuration ────────────────────────────────────────────────────────────
HOST = \"192.168.1.20\" # IP automate Schneider M340
PORT = 502 # Port Modbus TCP
UNIT_ID = 255 # 255 pour CPU locale M340, 1 pour S7-1200
TIMEOUT = 3 # Timeout en secondes
RETRIES = 3 # Nombre de tentatives avant abandon
# ─── Structure de données ─────────────────────────────────────────────────────
@dataclass
class VariablesProcess:
temperature_c: float = 0.0
debit_lmin: int = 0
pression_bar: float = 0.0
pompe_1_marche: bool = False
pompe_2_marche: bool = False
code_defaut: int = 0
compteur_production: int = 0
timestamp: float = 0.0
# ─── Client Modbus avec reconnexion automatique ───────────────────────────────
class ModbusCollecteur:
\"\"\"Collecteur Modbus TCP avec gestion de reconnexion et retry.\"\"\"
def __init__(self, host: str, port: int = 502, unit_id: int = 1):
self.host = host
self.port = port
self.unit_id = unit_id
self.client: Optional[ModbusTcpClient] = None
self._connexions_ok = 0
self._connexions_echec = 0
def connecter(self) -> bool:
\"\"\"Établit la connexion TCP vers l'automate.\"\"\"
try:
self.client = ModbusTcpClient(
self.host,
port=self.port,
timeout=TIMEOUT,
retries=1, # Retries gérés par notre code
reconnect_delay=0, # Pas de reconnexion automatique
)
if self.client.connect():
self._connexions_ok += 1
logger.info(f\"Connecté à {self.host}:{self.port}\")
return True
else:
self._connexions_echec += 1
logger.warning(f\"Connexion refusée par {self.host}:{self.port}\")
return False
except Exception as e:
logger.error(f\"Erreur connexion : {e}\")
return False
def deconnecter(self):
if self.client:
self.client.close()
self.client = None
def lire_holding_registers(
self, adresse: int, count: int
) -> Optional[list[int]]:
\"\"\"Lit des registres avec retry automatique.\"\"\"
for tentative in range(1, RETRIES + 1):
try:
if not self.client or not self.client.is_socket_open():
if not self.connecter():
time.sleep(1)
continue
result = self.client.read_holding_registers(
address=adresse, count=count, slave=self.unit_id
)
if result.isError():
exception_code = getattr(result, 'exception_code', '?')
logger.warning(
f\"Erreur Modbus addr={adresse} count={count} \"
f\"exception_code={exception_code}\"
)
# Exception 04 (server busy) → attendre avant retry
if exception_code == 6:
time.sleep(0.5)
self.deconnecter()
continue
return result.registers
except ConnectionException:
logger.warning(f\"Connexion perdue (tentative {tentative}/{RETRIES})\")
self.deconnecter()
time.sleep(0.5)
except Exception as e:
logger.error(f\"Erreur inattendue : {e}\")
self.deconnecter()
time.sleep(1)
logger.error(f\"Échec lecture après {RETRIES} tentatives — addr={adresse}\")
return None
@staticmethod
def registres_to_float32_abcd(reg_high: int, reg_low: int) -> float:
\"\"\"Décode 2 registres 16-bit en float32 IEEE754 big-endian (ABCD).\"\"\"
raw = struct.pack(\">HH\", reg_high, reg_low)
return struct.unpack(\">f\", raw)[0]
@staticmethod
def registres_to_int32(reg_high: int, reg_low: int) -> int:
\"\"\"Décode 2 registres en entier 32-bit signé big-endian.\"\"\"
raw = struct.pack(\">HH\", reg_high, reg_low)
return struct.unpack(\">i\", raw)[0]
# ─── Lecture des variables process ───────────────────────────────────────────
def lire_variables(collecteur: ModbusCollecteur) -> Optional[VariablesProcess]:
\"\"\"
Lecture optimisée : 1 seule requête Modbus pour toutes les variables.
Plan mémoire (M340 EcoStruxure) :
%MW100 : Temperature (int16, ×0.1 → °C)
%MW101 : Débit (int16, L/min)
%MW102-103 : Pression (float32 ABCD, bar)
%MW104 : États machine (bits 0-7)
%MW105 : Code défaut actif
%MW106-107 : Compteur production (int32)
\"\"\"
# 1 requête pour %MW100 à %MW107 (8 registres)
registres = collecteur.lire_holding_registers(adresse=100, count=8)
if registres is None:
return None
vars_process = VariablesProcess(
temperature_c = registres[0] * 0.1, # %MW100
debit_lmin = registres[1], # %MW101
pression_bar = ModbusCollecteur.registres_to_float32_abcd( # %MW102+103
registres[2], registres[3]),
pompe_1_marche = bool(registres[4] & 0x0001), # %MW104 bit0
pompe_2_marche = bool(registres[4] & 0x0002), # %MW104 bit1
code_defaut = registres[5], # %MW105
compteur_production = ModbusCollecteur.registres_to_int32( # %MW106+107
registres[6], registres[7]),
timestamp = time.time(),
)
return vars_process
# ─── Boucle principale ────────────────────────────────────────────────────────
def main():
collecteur = ModbusCollecteur(HOST, PORT, UNIT_ID)
INTERVALLE = 5 # secondes entre chaque collecte
logger.info(f\"Démarrage collecte Modbus TCP — {HOST}:{PORT} — cycle {INTERVALLE}s\")
while True:
try:
vars_process = lire_variables(collecteur)
if vars_process:
logger.info(
f\"T={vars_process.temperature_c:.1f}°C \"
f\"Q={vars_process.debit_lmin}L/min \"
f\"P={vars_process.pression_bar:.2f}bar \"
f\"P1={'ON' if vars_process.pompe_1_marche else 'OFF'} \"
f\"Défaut={vars_process.code_defaut}\"
)
# Ici : publier via MQTT, API REST, ou base time-series
# mqtt_client.publish(\"usine/ligne3/variables\", vars_process)
else:
logger.warning(\"Collecte échouée — attente 10s avant retry\")
time.sleep(10)
continue
time.sleep(INTERVALLE)
except KeyboardInterrupt:
logger.info(\"Arrêt demandé.\")
collecteur.deconnecter()
break
if __name__ == \"__main__\":
main()
This code demonstrates best practices for Modbus TCP data collection in Python: batching reads, exception handling, automatic reconnection, and decoding complex data types. In production, the Eziwan gateway handles all these functions natively—without requiring a Python script on-site.
Why is the Modbus TCP port 502 and not a standard port like 80 or 443?
\nPort 502 was officially assigned to Modbus by the IANA (Internet Assigned Numbers Authority) when Modbus TCP was standardized in the 1990s. At the time, there was no reason to reuse existing IT application ports. It is a registered port (< 1024), so using it as a server requires root privileges on Linux—which industrial firmware handles natively.
\nWhat is the limit on the number of registers that can be read in a single FC=03 query?
\nThe limit is 125 registers per FC=03 (Read Holding Registers) request, as defined in the official Modbus specification. This equates to a maximum of 250 bytes of payload data per request. For FC=16 (Write Multiple Registers), the limit is 123 registers per request. The Eziwan gateway automatically splits the request if the requested range exceeds these limits.
\nDoes Modbus TCP support multiple simultaneous client connections?
\nYes, but it’s the PLC that sets the limit. The Schneider M340 supports up to 16 simultaneous connections, while the Siemens S7-1200 supports up to 8 (via MB_SERVER). Beyond that, the PLC returns a 06 exception (Server Busy). In practice, a data collection gateway + a diagnostic tool + a local SCADA system can easily reach 3 simultaneous connections—so keep an eye on that.
\nCan Modbus TCP be encrypted?
\nThe native Modbus TCP standard (port 502) is not encrypted. A \"Modbus Security\" extension on port 802 using TLS has been available since 2018, but is rarely supported by current PLCs. The practical solution is to confine Modbus TCP to an isolated OT network and route all external communication through an encrypted VPN tunnel (such as Eziwan’s OpenVPN)—encryption is handled by the transport layer, not by Modbus itself.
\nIs pymodbus the only Python library for Modbus TCP?
\nNo. The main alternatives are minimalmodbus (simpler for Modbus RTU), umodbus (lightweight, small memory footprint), and pyModbusTCP (purely TCP, no dependencies). For industrial projects in Python, pymodbus >= 3.0 remains the most comprehensive choice, offering exception handling, reconnection, and support for both modes (RTU and TCP).
How do you debug a Modbus TCP communication without access to the PLC?
\nUse Modbus Slave (Windows) as a local PLC simulator, or diagslave (command line, cross-platform). These tools simulate a Modbus TCP server that responds to configurable addresses. Ideal for testing a data collection configuration without risking interference with a PLC in production.
\nDoes your PLC support Modbus TCP, but you're not sure if it's compatible with your firmware version?
Check your PLC's compatibility →
See also: Modbus TCP with a Schneider M340 and the Siemens S7 documentation for specific configurations.
France is Europe’s leading agricultural nation. However, French farms are facing increasing pressure: rising energy costs, stricter environmental regulations, a shortage of skilled labor, and traceability requirements in the agri-food sector. The Industrial Internet of Things (IIoT) offers concrete solutions to these challenges.
\nThis guide outlines the main use cases for agricultural IoT in France, compatible equipment, costs, and ROI, and explains how to implement a robust agricultural monitoring solution in rural areas—even without a fiber connection.
\nModern agriculture already uses a wide range of electronic and electromechanical equipment: automated irrigation systems, fans in livestock buildings, milk cooling tanks, storage silos, climate-controlled greenhouses, and well pumps. The vast majority of these devices have communication interfaces (Modbus RTU, 4–20 mA, pulse outputs) that enable an IoT connection without the need for replacement.
\nWhat the IoT Brings to Agriculture:
\nOff-the-ground livestock facilities (pig barns, chicken coops, dairy barns) are particularly well-suited for IoT monitoring. The critical parameters to monitor are:
\nBuilding Climate Conditions:
\nVentilation Equipment:
\nFeed and Water:
\nCompatible sensors and interfaces:
\n| Parameter | Recommended Sensor | Interface |
|---|---|---|
| Building Temperature/Humidity | Sensirion SHT31, Rotronic HF5 | Modbus RS-485 or 4-20 mA |
| CO₂ | Senseair S8, COZIR-Blink | Modbus RTU or UART |
| NH₃ (ammonia) | Membrapor NH3/M-100, Winsen ZE07 | 4–20 mA or Modbus |
| Silo Level | Pepperl+Fuchs UC6000, SICK UM30 | 4-20 mA or IO-Link |
| Water Flow Meter | Sontex Supercal 5, Itron Actaris | Pulse or Modbus |
Typical alert thresholds for livestock buildings:
\n| Parameter | Green Zone | Orange Zone (Alert) | Red Zone (Emergency) |
|---|---|---|---|
| Temperature in finishing pig barn | 18–22°C | < 15°C or > 26°C | < 10°C or > 30°C |
| Humidity in poultry house | 50–70% | > 80% | > 90% |
| CO₂ in poultry house | < 3000 ppm | > 3000 ppm | > 5000 ppm |
| NH₃ in swine | < 10 ppm | > 10 ppm | > 20 ppm (regulatory threshold) |
Cooling milk is a regulatory requirement (amended decree of September 15, 2004): cow's milk must be cooled to 8°C within 2 hours of milking and kept at a maximum of 4°C until it is picked up.
\nFailure to comply with these temperatures results in:
\nIoT Monitoring of the Milk Tank:
\nMost modern milk tanks (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) have an RS-232 or RS-485 Modbus port for monitoring. Accessible parameters include:
\nThe Eziwan Gateway connects to the tank via RS-232 or RS-485 and uploads data to the cloud at a configurable 5-minute polling interval. An SMS alert is sent if the temperature exceeds 8°C for more than 15 minutes.
\nCustomer Case Study: A dairy farmer in Brittany who manages 3 milk tanks (a 120-cow operation) avoided 2 collection rejections in 6 months thanks to nighttime text alerts (compressor failure detected at 2 a.m., repair completed at 4 a.m. before the 6 a.m. pickup). Savings: 2 × 800 L × €0.40/L = €640 in avoided losses, plus quality penalties.
\nHorticultural greenhouses represent a significant investment (50 to 300 €/m²), and their profitability depends on maintaining optimal climatic conditions. IoT monitoring helps detect issues—such as heating failures, blocked ventilation, or torn plastic sheeting—before they cause irreversible damage to crops.
\nParameters to monitor in a greenhouse:
\n| Parameter | Importance | Interface |
|---|---|---|
| Air temperature (°C) | Critical | PT100/PT1000 or Modbus |
| Relative humidity (%) | High | Modbus RS-485 |
| Solar radiation (W/m²) | Medium | 4–20 mA (pyranometer) |
| Ambient CO₂ (ppm) | High (if CO₂ enrichment) | Modbus RS-485 |
| Leaf temperature (°C) | Optional | Thermocouple |
| Irrigation water consumption (m³/day) | High | Pulse or Modbus |
| Nutrient solution temperature (°C) | High (soil-less) | PT100 or 4–20 mA |
| Nutrient solution EC (mS/cm) | High (soil-less) | 4–20 mA |
| Nutrient solution pH | High (soil-less) | 4–20 mA |
Greenhouse equipment that can be monitored:
\nROI for vegetable greenhouse monitoring:\nFor a 5,000 m² tomato greenhouse (annual production ~500 t, resale price ~0.80€/kg = 400,000€ in annual revenue), an undetected heating failure at night in March can destroy an entire crop—resulting in a loss of €100,000 to €200,000. The cost of an Eziwan gateway with SMS alerts: €500 + €100/year for the subscription. Immediate ROI.
\nIrrigation accounts for 45% of industrial water consumption in France. Regulations are becoming stricter (decrees imposing restrictions during low-flow periods, water fees), making precise irrigation management essential.
\nIoT-Based Irrigation Monitoring:
\nRegulatory Compliance:\nFacilities that withdraw more than 1,000 m³/year of groundwater or surface water must report their withdrawals (Article L214-1 of the Environmental Code). Eziwan automatically generates monthly withdrawal reports for submission to the DDT/DREAL.
\nGrain storage is a major economic issue. Inadequate storage conditions (temperature, humidity) can lead to the formation of mycotoxins (aflatoxins, DON) or mold, which can degrade the quality of the grain or render it unsellable.
\nParameters to monitor:
\nInterface: Most modern silo control systems (Superchief, GSI Fan Controller, Brock NECO) have a Modbus RS-485 output or an RS-232 port.
\nThe vast majority of French farms do not have fiber-optic connectivity. 4G LTE covers 99.2% of French municipalities (source: Arcep 2025), but coverage inside buildings can be poor.
\nSolutions for areas with poor coverage:
\nExternal directional 4G antenna: gain of 9 to 15 dBi, range of up to 30 km in direct line of sight, compatible with all carriers. Mounts on the edge of a building’s gable or on a mast.
\nEziwan Multi-Carrier SIM: Tests all three French carriers (Orange, SFR, Bouygues) and connects to the best available signal. Significantly improves coverage in rural areas.
\nLoRa + 4G Gateway: For sensors with very low power consumption and located at great distances (up to 15 km), a LoRaWAN architecture with a LoRa concentrator connected via 4G through the Eziwan Gateway can cover an entire facility.
\nSatellite connection (last resort): For locations with no 4G coverage, a satellite option (Starlink low-latency or Eutelsat ViaSat) can be integrated with the Eziwan Gateway. Latency is 20–40 ms with Starlink.
\nEuropean Directive 2008/120/EC (pigs), 2007/43/EC (broiler chickens), and 1999/74/EC (laying hens) require minimum standards for temperature, space, ventilation, and lighting. IoT monitoring makes it possible to:
\nFarms located in nitrate-vulnerable zones are subject to the Regional Action Program (PAR). Monitoring of manure application and effluent management (flow meter on the spreader boom, tank level) facilitates compliance with application bans and the calculation of application rates.
\nMany industry standards (Label Rouge, AOP, IGP, organic farming) require traceability of farming or growing conditions. Eziwan’s IoT data is archived and can be exported to feed into traceability tools (Bluerex, Kite Consulting, OAD-Systèmes).
\n| Equipment | Estimated Cost |
|---|---|
| Eziwan Gateway + M2M SIM | 350–500 € |
| External 4G antenna (if needed) | 80–150 € |
| Temperature/humidity sensors (×3) | 150–400 € |
| RS-485 cabling (50 m) | 40–80 € |
| Installation (2 hours by a technician) | 200–400 € |
| Total installation (1 building) | 820–1,530 € |
| Subscription | Annual Cost |
|---|---|
| Eziwan Platform (1 gateway) | 120–240 € |
| M2M SIM (200 MB/month plan) | 60–120 € |
| Annual Total | €180–360 |
The France 2030 plan and PCAE (Farm Competitiveness and Adaptation Plan) grants partially fund equipment for digital agricultural modernization. Subsidy rates vary by region and program (30 to 50% of eligible investments). Contact your chamber of agriculture or your FranceAgriMer advisor to find out which programs apply to your project.
\nIndustrial IoT is now accessible to French farms, thanks to widespread 4G coverage, standardized Modbus sensors, and cost-effective cloud platforms like Eziwan. The technical and financial barriers that had been holding back adoption have been significantly reduced.
\nFor an initial investment of €1,000 to €2,000 per building and a subscription fee of less than €400 per year, a farmer benefits from 24/7 monitoring of their critical equipment, immediate SMS alerts, and a documented history to meet their regulatory obligations.
\nNext step: Contact the Eziwan team for a free feasibility study tailored to your farm and your type of production.
\nIs 4G available in rural agricultural areas of France?\n4G coverage in metropolitan France reaches over 99% of the population but only ~80% of the country’s total land area—some farms in “white spots” remain without coverage. For these areas: the NB-IoT (NarrowBand-IoT) network offers better penetration inside buildings and greater range, and satellite solutions (Starlink) are becoming available for completely isolated sites. It is essential to verify coverage at the exact site beforehand before any deployment.
\nCan an existing grain silo or cooperative warehouse be connected without replacing the equipment?\nIn the vast majority of cases, yes. Modern silos have temperature and humidity sensors with 4–20 mA or RS485 Modbus outputs—an IoT gateway connects directly to them. For older equipment without a digital interface, replacement sensors compatible with Modbus RTU are available starting at €50 to €100 per measurement point.
\nWhat regulatory requirements can IoT monitoring help document?\nIn livestock farming: health traceability requirements (preventive measures, animal identification, transport conditions—EU Regulation 2016/429), animal welfare (temperatures, ventilation, stocking density), and DPE/PAC inspections can rely on IoT data histories as evidence. The automatic log of all measurements with a certified timestamp is a significant advantage during inspections.
\nEziwan helps farmers, cooperatives, and storage facilities monitor their operations using IoT technology. Our solution integrates with existing equipment without requiring replacement, featuring 4G connectivity optimized for rural areas. Discover our solutions →
\nThis question comes up regularly in industrial remote access projects: \"Why not just use TeamViewer? That's what we already do for IT support.\"
\nThe short answer: OT networks are not IT networks. The controllers running on them operate physical machines—an erroneous command or an intrusion can have industrial—or even human—consequences. Consumer-grade tools were designed for a radically different context.
\nThis article goes beyond a simple answer. It explains the actual threat model, details the requirements of the IEC 62443 standard, and presents the technical criteria for evaluating an industrial remote access solution.
\nTo understand why OT remote access is different, you need to be familiar with the Purdue model (Purdue Enterprise Reference Architecture), the international standard for industrial network segmentation.
\nNiveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
Industrial remote access typically involves Levels 1 and 2—PLCs and engineering tools. These levels must never be directly accessible from higher levels without control, and certainly not from the Internet.
\nSegmentation between network layers is the first line of defense. Remote access, by definition, crosses this segmentation—hence the enhanced security requirements.
\nA typical OT network includes:
\nThis equipment was designed for reliability in isolated environments, not to withstand network attacks. The Modbus protocol does not provide for any authentication. S7Comm (Siemens) historically had no encryption. Profinet, EtherNet/IP—most industrial protocols assume a trusted network.
\nHere's how an unsecured industrial remote access system is typically compromised:
\nPhase 1 — Reconnaissance (automatic, passive):\nAn automated scanner (Shodan, Censys, or a custom script) identifies the plant’s public IP address and discovers an open port (standard VPN on UDP 1194, Modbus port 502, S7Comm port 102). This phase does not generate any suspicious logs and lasts a few seconds.
\nPhase 2 — Exploiting the Access:\nIf the VPN is protected only by a weak password (or if the credentials have been stolen through phishing), the attacker gains access. If it is a directly exposed Modbus port, the attacker can read and write without any authentication.
\nPhase 3 — Internal Reconnaissance:\nOnce access has been gained, the attacker maps the OT network: which PLCs are accessible, which variables can be read, and which process zones are controlled.
\nPhase 4 — Malicious Action:\nActions may be immediate (shutting down production, changing parameters) or covert (gradually changing setpoints to degrade product quality without triggering an alarm).
\nThe most dangerous attacks are not the most spectacular ones. A change of ±5% in a dosing setpoint at a chemical or pharmaceutical facility may go undetected for days, with potentially catastrophic consequences for the quality of the finished product.
ANSSI and CISA (Cybersecurity and Infrastructure Security Agency, United States) regularly document incidents involving poorly secured industrial remote access systems:
\n[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
This model exposes an Internet access point. Whether it is a VPN port (UDP 1194 for OpenVPN, UDP 500/4500 for IPsec) or an application port (502, 102, 443), this port is constantly monitored.
\nLife Cycle of an Exposed Port:
\n[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
What’s fundamentally different:
\nIf the Eziwan cloud infrastructure were compromised (a hypothetical scenario), an attacker would not be able to bounce through to the factory network—the connection is one-way from the perspective of the initiator.
\nTeamViewer does use a cloud relay (the attacker does not connect directly to the factory), but the structural issues are different:
\n| Issue | Explanation |
|---|---|
| Third-party infrastructure | Sessions pass through TeamViewer servers. If TeamViewer is compromised (as it was in 2016), your sessions are too. |
| Audit trail dependent on subscription | Full logs are only available with premium subscriptions. In the free version, there are no exportable logs. |
| Inadequate authentication model | A 9-digit code exchanged via email does not constitute strong authentication. |
| No OT isolation | TeamViewer grants access to the Windows machine running it—and from that machine, potentially to the entire OT network. |
The IEC 62443 standard defines cybersecurity requirements for industrial systems. For remote access, Security Level 2 (SL2)—the recommended level for most industrial facilities—requires:
\nSR 1.1 — Human Identification and Authentication:\nEvery user accessing the system must be individually identified and authenticated. Shared accounts (a single \"maintenance\" account for the entire team) are explicitly prohibited.
\nSR 1.7 — Enhanced Authentication (Enhancement SL2):\nTwo-factor authentication (MFA) is required for remote access at the SL2 level. A password alone is not sufficient.
\nSR 2.6 — Access via Untrusted Networks:\nAll access from the Internet to the OT network must be encrypted, authenticated, and logged. This requirement is the normative equivalent of an outbound tunnel + MFA + audit logs.
\nSR 6.2 — Continuous Monitoring:\nRemote access must be logged continuously—who logged in, when, from which IP address, and for how long.
\nANSSI publishes guides specifically for industrial systems. Its five principles for industrial remote access are:
\nANSSI publishes these recommendations in its guide \"Managing Digital Risk in Industrial Systems,\" which can be downloaded for free at ssi.gouv.fr. All industrial maintenance managers are encouraged to read it.
Not all VPNs are created equal when it comes to gateways embedded on ARM CPUs with reconnection and memory constraints.
\n| Criterion | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Transport | UDP or TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Firewall / NAT traversal | Excellent (TCP 443 gets through everywhere) | Average (NAT-T required) | Variable |
| Reconnection after 4G disconnection | Fast (persist-tun, ~2–5 s) | Excellent (MOBIKE, virtually transparent) | Slow (15–60 s) |
| Cryptographic primitives | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Weak (PPTP/MS-CHAPv2 not recommended) |
| Authentication | X.509 certificate per client | PSK or X.509 certificates | Username / password |
| CPU load (ARM Cortex-A) | Moderate | Low (hardware acceleration possible) | Low |
| Maturity / Certifications | Extensively audited, widely adopted | FIPS 140-2 certified | Outdated (PPTP should be avoided) |
The key point for businesses: traversing firewalls and reconnecting after a 4G outage. OpenVPN encapsulates the tunnel within TLS on TCP port 443—the same port used by HTTPS—allowing it to pass through where other protocols are blocked (carrier firewalls, corporate proxies). When combined with persist-tun, the tunnel reestablishes itself within seconds after a Dual SIM switch, without requiring a full renegotiation.
Each technician has their own X.509 certificate, which can be revoked individually from the cloud dashboard—a key requirement for NIS2 traceability.
\nIPSec remains the standard in enterprise and regulated industrial environments that require FIPS 140-2-certified protocols. Its MOBIKE mechanism handles IP address changes in a virtually transparent manner—making it particularly well-suited for Dual SIM failover. Configuration is more complex (PKI, X.509 certificates, SA policies), but interoperability with existing network equipment is maximized. The Eziwan Gateway also supports L2TP, PPTP, and GRE for legacy interoperability scenarios.
\nThe Eziwan architecture applies the above principles systematically:
\nIf you are currently using TeamViewer on industrial monitoring workstations, here is a step-by-step migration process:
\nPhase 1 — Parallel Deployment (Weeks 1–4):
\nPhase 2 — Phased Rollout (Weeks 5–8):
\nPhase 3 — Uninstallation and Cleanup (Week 9+):
\nAfter deploying Eziwan, check the following:
\n| Criterion | TeamViewer / AnyDesk | Traditional VPN (site-to-site) | Eziwan |
|---|---|---|---|
| Inbound ports exposed | No (third-party cloud relay) | Yes | No |
| Session traceability | Partial (subscription) | Depends on the device | Full + export |
| IEC 62443 SL2 compliance | ✗ | Partial | ✓ |
| ANSSI recommendation compliance | ✗ | Partial | ✓ |
| Integrated MFA authentication | Optional | Optional | Integrated |
| On-site network intervention | No | Yes | No |
| Full OT isolation | ✗ | Partial | ✓ |
| Exportable audit logs | Premium subscription | Depends on equipment | Standard |
| Reconnection after 4G disconnection | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Deployment without network expertise | Yes | No | Yes (ZTP) |
For practical implementation on a Siemens S7 PLC, see How to Connect to an S7 Remotely Without Opening a Port. For detailed information on IEC 62443 requirements, see IEC 62443 and Industrial Remote Access.
Isn't TeamViewer sufficient if you're only accessing a monitoring workstation, not the PLC directly?
\nNot necessarily. The supervisory workstation typically has access to the Level 1 network (PLCs) via SCADA software. A compromise of the workstation—whether via TeamViewer or another vulnerability—indirectly grants access to the PLCs. OT isolation must be considered in terms of the network, not the application.
\nIs WireGuard a viable alternative to OpenVPN for industrial gateways?
\nWireGuard offers superior performance and a smaller (better-audited) codebase, but it has one limitation: it runs only over UDP, with no TCP option. In networks where UDP is blocked (such as by certain mobile carriers or corporate proxies), WireGuard may fail where OpenVPN over TCP 443 would work. For industrial 4G gateways with potentially unreliable connections, OpenVPN remains the most versatile choice.
\nCan we use an existing corporate IPsec VPN solution instead of Eziwan?
\nYes, if the existing solution meets the IEC 62443 SL2 criteria (named accounts, MFA, exportable logs, least privilege). A recurring issue with enterprise site-to-site VPNs used in the OT environment is the lack of granularity: the VPN grants access to an entire network segment rather than to a specific device. Eziwan can complement an enterprise VPN solution by adding granularity and audit logs.
\nDoes ANSSI maintain a list of approved remote access solutions for the OT?
\nANSSI does not publish a list of \"approved\" solutions, but rather evaluation criteria. For OIVs and OSEs, PRIS-certified service providers (Security Incident Response Providers) can conduct a formal assessment. The ANSSI criteria are consistent with the IEC 62443 SL2 requirements described in this article.
\nHow long does it take to migrate from TeamViewer to an industrial VPN solution?
\nFor a network of fewer than 20 sites, the migration can be completed in 2 to 4 weeks: parallel deployment, team training, and a phased switchover. The critical step is training technicians on the VPN client—allow 1 to 2 hours per person. The process is detailed in Section 6 of this article.
\nDoes your organization currently use TeamViewer or a traditional VPN connection on an OT network?
Download the OT Cybersecurity White Paper →
The document details the recommended target architecture, the migration process from an existing system, and the criteria for evaluating a solution that complies with IEC 62443.
Modernizing the remote management of drinking water networks has become a priority for French local governments. Faced with increasing regulatory requirements (self-monitoring, NIS2, GDPR), aging remote monitoring equipment from the 2000s, and the performance requirements of public service delegation contracts, water utilities must rethink their monitoring architecture.
\nThis practical guide is intended for technical managers, water and wastewater directors, and chief information officers (CIOs) at local government entities—water districts, municipal utilities, and intermunicipal associations—that oversee drinking water systems.
\nRemote management of drinking water networks in France currently relies heavily on equipment installed between 2000 and 2015. The dominant technologies are:
\nOrange has officially announced that it will shut down its 2G network in 2026 (after several delays). SFR has already shut down its 2G network in several areas. Bouygues Telecom is following the same path.
\nSOFREL S4W modems and other 2G/GPRS RTUs used at water towers, pumping stations, and lift stations will no longer work after these shutdowns.
\nThis is a major opportunity to modernize by transitioning to 4G LTE solutions with a centralized cloud-based monitoring platform.
\n| Site Type | Key Parameters | Field Equipment |
|---|---|---|
| Pumping station | Discharge flow rate, pressure, tank level, operating hours, power consumption | Schneider M340 or Siemens S7-1200 PLC, 4-20 mA sensors |
| Water tower / reservoir | Water level, inlet/outlet pressure, fill valve | Ultrasonic or pressure level sensor, Modbus flow meter |
| Treatment plant | Turbidity, residual chlorine, pH, conductivity, temperature, treated flow rate | YSI, Hach, and WTW multiparameter sensors via Modbus RS-485 |
| Booster station | Downstream pressure, flow rate, pump status, motor faults | Modbus variable frequency drives, local PLC |
| Utility meter | Flow rate, meter reading, nighttime leak detection | MID-compliant meter with pulse or Modbus output |
The SOFREL S4W is the most widely used modem on French water networks. The migration to the Eziwan Gateway is designed to be non-invasive.
\nMigration Steps:
\nCompatibility: The Eziwan Gateway reads all Modbus registers configured on your PLC (Schneider M340, Siemens S7-1200, Lacroix E30, etc.). The migration does not require any modifications to the field PLC.
\nMigration Cost: The Eziwan Gateway is less expensive than a new SOFREL S4W and offers expanded features (VPN, multi-protocol support, OTA). For a fleet of 50 stations, the return on investment compared to purchasing new S4W units is immediate.
\nWhen a project is brought back under direct municipal management or there is a change in the contractor, the local government often loses access to the outgoing operator’s proprietary monitoring system. The transition can result in weeks or months without centralized monitoring.
\nEziwan's Approach to DSP Transitions:
\nThe decree of July 21, 2015, amending the decree of May 2, 2007, imposes self-monitoring requirements on wastewater treatment plants (WWTPs) and drinking water production units (DWPUs):
\nParameters to Monitor and Log (UPEP):
\nArchiving Requirements:
\nHow Eziwan Meets These Requirements:
\nThe transposition of the NIS2 Directive into French law (Law of April 16, 2024) classifies water operators into categories based on their size:
\nKey Entities:
\nSignificant Entities:
\nNIS2 requirements relevant to remote water management:
\n| Requirement | Requirement | How Eziwan Meets It |
|---|---|---|
| OT/IT network segmentation | OT gateway isolated from the office network | Gateway operates in the OT zone; no incoming traffic |
| Remote access control | MFA + logging | OpenVPN/IPSec VPN + MFA + full session log |
| Vulnerability management | Patch management | Automatic OTA firmware updates for the gateway |
| Incident notification | < 24 hours to ANSSI | Exportable incident log, documented procedure |
| Subcontracting chain | Vendor audit | Eziwan ISO 27001 certified, hosting in France, GDPR compliant |
Background: An intermunicipal association manages 80 pumping stations (12 to 350 m³/h) and 6 water towers across a rural area comprising 45 municipalities. Existing equipment: SOFREL S4W 2G modems, limited local monitoring, 3 technicians.
\nIssues:
\nEziwan Deployment:
\n6-Month Results:
\n| Protocol | Compatible Meters | Collected Parameters |
|---|---|---|
| M-Bus (EN 13757) | Sensus iPERL, Itron Actaris BDE, Landis+Gyr E120, Sagemcom | Reading (m³), instantaneous flow rate, alarms (tampering, dry run) |
| Pulse (digital input) | Any meter with a pulse output (reed switch output) | Cumulative reading, calculated flow rate (number of pulses × volume per pulse) |
| Modbus RTU | Endress+Hauser Promag, Krohne Optiflux, Siemens Sitrans FM | Flow rate (m³/h), velocity (m/s), temperature, cumulative reading |
| MBUS LoRaWAN | LoRaWAN meters for areas without coverage | Via LoRaWAN concentrator + Eziwan gateway (MQTT) |
| Parameter | Compatible Sensors | Interface |
|---|---|---|
| Residual Chlorine | Hach CL17sc, YSI MultiLab, Bürkert Type 8905 | Modbus RS-485 or 4-20 mA |
| pH/ORP | WTW IQ SensorNet, Endress+Hauser CPS11D | Modbus RS-485 or 4–20 mA |
| Turbidity | Hach TU5200, Yokogawa FLXA21 | Modbus RS-485 |
| Conductivity | Endress+Hauser Liquiline CM44 | Modbus RS-485 |
| Level | Vega Vegapuls, Endress+Hauser FMR51, Keller Series 26 | 4–20 mA or Modbus |
| PLC | Interface | Compatibility |
|---|---|---|
| Schneider Electric M340 | Modbus RTU RS-485 | ✅ Tested and validated |
| Schneider Electric M221/M241 | Modbus RTU RS-485 + Modbus TCP | ✅ Tested and validated |
| Siemens S7-1200/S7-1500 | Modbus TCP (via Ethernet) | ✅ Tested and validated |
| Lacroix Tbox LT2 / MS3 | Modbus RTU / TCP | ✅ Compatible |
| Wago 750-860 | Modbus TCP | ✅ Compatible |
| CODESYS Modbus Slave | Modbus RTU / TCP | ✅ Compatible |
Technician Service Calls:
\nDamage Avoided (Leaks, Failures, Overflows):
\nOn-Call Duty:
\nRegulatory Compliance:
\n| Item | Annual Value |
|---|---|
| Avoided travel | 40,750 € |
| Early detection of leaks | 15,000 € |
| Reduction in on-call fees | 15,000 € |
| Avoided regulatory non-compliance | 10,000 € |
| Total estimated annual savings | 80,750 € |
| Investment | Amount |
|---|---|
| 80 Eziwan gateways + installation | 48,000 € |
| Cloud subscription (80 sites/year) | 14,400 € |
| 4G M2M SIM cards (80 sites × 10€/month) | 9,600 € |
| Total investment for Year 1 | 72,000 € |
ROI in Year 1: 80,750 − 72,000 = +8,750 € in the first year\nROI starting in Year 2: 80,750 − (14,400 + 9,600) = +56,750 €/year
\nProjects to modernize remote management systems for drinking water networks may be eligible for ERDF (European Regional Development Fund) funding under the 2021–2027 regional operational programs, specifically under the \"Digital Transition of Public Services\" priority axis.
\nThe six French water agencies (Artois-Picardie, Rhine-Meuse, Seine-Normandy, Loire-Brittany, Adour-Garonne, Rhône-Mediterranean-Corsica) offer grants to modernize water network management. Eligibility criteria include reducing leaks (network efficiency), regulatory compliance, and digital transformation.
\nContact your local water agency to find out about current programs and the subsidy rates applicable to your project.
\nThe DSIL and the DETR (Fund for Rural Infrastructure) can provide funding for digital projects in rural communities. Projects to modernize water networks using IoT technology align with the “local services” and “digital transition” objectives of these funding programs.
\nIs IoT monitoring eligible for the France Relance Plan or regional grants?\nYes, several programs may apply. The DSIL (Local Investment Support Grant) funds local governments’ digital projects. The DETR (Rural Areas Infrastructure Grant) covers rural municipalities. Water agencies (Seine-Normandy, Loire-Brittany, etc.) have specific programs for reducing water loss and self-monitoring. A technical proposal with a quantified ROI (savings from reduced leaks, avoided costs) is generally required.
\nIs migrating from an existing SOFREL system disruptive?\nNo. The Eziwan gateway connects in parallel with existing SOFREL equipment via Modbus RTU/TCP or 4–20 mA. There is no need to shut down the existing system during the transition. The migration can be carried out in phases: first, data reading; then, a gradual switchover of pilot stations; and finally, complete replacement according to your equipment replacement schedule.
\nHow does the solution meet the ARS self-monitoring reporting requirements?\nThe Eziwan platform allows self-monitoring data to be exported in the required formats (CSV, Excel) with certified timestamps. Performance indicators (loss rates, nominal vs. actual flow, pressure incidents) are automatically calculated from the meter readings and can be extracted for the time periods requested by the ARS.
\nModernizing remote management systems for drinking water is no longer an option for French municipalities. The phase-out of 2G networks, NIS2 requirements, ARS self-monitoring requirements, and pressure to reduce operating costs are all converging to make this investment essential.
\nThe good news: ROI is quick (usually less than 18 months), migration from existing systems (SOFREL, etc.) is well-documented and non-invasive, and modern solutions (4G gateway + cloud) are significantly less expensive than first-generation proprietary equipment.
\nYour next steps:
\nContact the Eziwan team for a free audit of your remote water management infrastructure.
\nEziwan partners with local governments, water utilities, and municipal agencies to modernize their remote management systems. We support DSP transitions and migrations from SOFREL, Lacroix, and other water RTU systems. Learn more about our water solution →
\nCloud or on-premises? That’s the question most industrial automation managers and CIOs are asking themselves today. SCADA monitoring is evolving: SaaS cloud solutions are gaining ground over traditional on-premises installations, but the choice isn’t always clear-cut.
\nThis guide objectively compares the two architectures based on seven key criteria—total cost, security, latency, scalability, compliance, maintainability, and resilience—to help you make the right decision based on your industrial context.
\nOn-premises (traditional) SCADA:\nPhysical server(s) installed on your premises or in your server room. SCADA software installed locally (Wonderware InTouch/System Platform, Ignition, PCVue, WinCC). Data history stored on a local SQL server. Access via the local area network (LAN) or via VPN for remote access.
\nCloud-based SCADA / IIoT SaaS:\nA platform hosted in the cloud (AWS, Azure, GCP, or a French sovereign cloud). On-site industrial gateways that collect field data and send it to the cloud. Dashboard accessible from any browser. Historical data stored in the cloud. Examples: Eziwan, Axonize, Samsara, Siemens MindSphere, AWS IoT SiteWise.
\n| Item | Cost (3 years) |
|---|---|
| SCADA software licenses (Wonderware System Platform, 10 connections) | 45,000 – 80,000 € |
| Physical servers (2 redundant servers) | 18,000 – 30,000 € |
| Network infrastructure (managed switches, routers) | 8,000 – 15,000 € |
| Installation and configuration (system integrator) | 20,000 – 40,000 € |
| Annual maintenance and support (15–20% of the license cost) | €20,000 – €45,000 |
| Major updates (1 version every 3 years) | €15,000 – €25,000 |
| Internal IT resources (administration, backups) | 15,000 – 30,000 € |
| 3-Year Total | 141,000 – 265,000 € |
| Item | Cost (3 years) |
|---|---|
| Cloud platform subscription (10 sites, 500 data points) | 18,000 – 36,000 € |
| Industrial gateways (1 per site × 10) | 8,000 – 15,000 € |
| Installation and commissioning (simpler) | 5,000 – 15,000 € |
| 4G/M2M SIM connectivity (if no fiber) | 3,600 – 7,200 € |
| Team training | 2,000 – 5,000 € |
| 3-Year Total | 36,600 – 78,200 € |
TCO Verdict: SaaS cloud solutions are 2 to 4 times cheaper over a 3-year period for multi-site deployments. The cost advantage increases as the number of sites grows. For a single site with an existing SCADA system that has already been amortized, an on-premises solution may still be a viable option.
\nThis is often the main argument put forward by advocates of on-premises solutions. Let's take a closer look at what's actually true.
\nSecurity Verdict: At the same level of maturity, an ISO 27001-certified cloud hosted in France is generally more secure than an unmanaged on-premises solution. For OIVs (Operators of Vital Importance) or highly sensitive sectors, the French sovereign cloud (ANSSI-certified SecNumCloud) is recommended.
\nThe round-trip latency between a field gateway and a cloud server hosted in Paris ranges from 50 to 200 ms, depending on the quality of the 4G or fiber connection.
\nIs this acceptable for your application?
\n| Application | Required Latency | Cloud OK? |
|---|---|---|
| PLC control loop (PID) | 1–10 ms | ❌ No — remains on the local PLC |
| Motion control | 1–5 ms | ❌ No — remains on the drive/servo |
| Safety alarms (SIL, PLe) | 10–100 ms | ❌ No — remains on the safety PLC |
| Machine status monitoring | 100 ms–1 s | ✅ Yes |
| Alerts and notifications | 1–30 s | ✅ Yes |
| Production dashboards | 1 – 60 s | ✅ Yes |
| Reports and history | No time constraints | ✅ Yes |
| Remote maintenance (VNC/SSH) | 50 – 500 ms | ✅ Yes (acceptable) |
Golden Rule: Real-time control ALWAYS remains on the local PLC. The cloud handles monitoring, alerts, historical data, and remote maintenance. This separation of responsibilities is the key to a proper IIoT architecture.
\nLatency Verdict: Cloud latency is perfectly acceptable for 95% of industrial monitoring scenarios. Only the real-time control loop must remain local.
\nScaling from 10 to 50 on-premises monitored sites requires:
\nTypical turnaround time: 4 to 12 weeks. High marginal cost.
\nAdd a new SaaS cloud site:
\nTypical lead time: 1 to 2 weeks (determined primarily by hardware availability). Low marginal cost.
\nScalability verdict: The cloud wins by a wide margin. This is particularly crucial for multi-site deployments or system integrators that manage portfolios ranging from several dozen to several hundred client sites.
\nFor essential and important entities subject to NIS2 (water, energy, critical industries), the cybersecurity requirements are the same regardless of the architecture. The difference lies in the ability to demonstrate compliance:
\nIf your SCADA system processes personal data (operator attendance records, biometric access), the location of the data is important:
\nFDA 21 CFR Part 11 (electronic traceability in the pharmaceutical industry) and EU GMP Annex 11 are compatible with the cloud, provided you choose a service provider that can supply the validation certificates (IQ/OQ/PQ) required by auditors.
\nCompliance Verdict: The cloud, hosted in France by an ISO 27001-certified provider, is compliant with NIS2, the GDPR, and major industry regulations. Check the provider’s certifications.
\nManufacturers often underestimate the maintenance burden of an on-premises SCADA system:
\nIn practice, an on-premises SCADA system requires 0.3 to 0.5 IT FTEs over the course of its lifecycle (shared with other systems).
\nOn a SaaS cloud platform, the provider manages:
\nYour team only maintains the field gateways (with automatable OTA firmware updates) and the application configuration.
\nMaintainability Assessment: The cloud reduces the operational burden by 70–80%. This is crucial for small and medium-sized businesses without a dedicated IT team.
\nKey Features:
\nWeaknesses:
\nReputable industrial cloud platforms guarantee 99.9% availability (contractual SLA = < 8.76 hours of downtime per year) or even 99.95%.
\nMulti-AZ (multi-datacenter) architecture: A failure in one datacenter does not affect service. Disaster recovery (DR) is automatic.
\nMain cloud risk: If the site’s Internet/4G connection is lost, the gateway loses its connection to the cloud. Data is buffered locally (store-and-forward) and retransmitted once the connection is restored. Remote monitoring is unavailable during the outage.
\nAnswer: For critical sites, deploy a backup connection (dual-operator 4G SIM with failover to fiber, or satellite VSAT as a last resort).
\nResilience verdict: The cloud offers better platform availability. On-premises solutions are more resilient for local monitoring without network dependencies. A hybrid approach (local control + cloud monitoring) offers the best of both worlds.
\nMost new industrial deployments adopt a hybrid architecture:
\n\nAdvantages of the hybrid solution:
\nThis is exactly the architecture that Eziwan deploys: an industrial gateway at each site (edge), and a cloud platform for centralized monitoring.
\n| Criterion | On-premises | SaaS Cloud | Hybrid |
|---|---|---|---|
| 3-Year TCO (10 sites) | 141–265 k€ | 37–78 k€ | 50–100 k€ |
| Security | Depends on your IT | ISO 27001 | ISO 27001 + OT isolation |
| Control latency | Excellent | Not applicable | Excellent (local) |
| Monitoring latency | Excellent | 50–200 ms | 50–200 ms |
| Scalability | Difficult | Easy | Easy |
| Maintainability | IT workload: 0.3–0.5 FTE | Minimal | Minimal |
| Platform availability | ~99% (if redundant) | 99.9%+ (SLA) | 99.9%+ |
| Resilience to Internet Outages | Full | Limited | Good (store-and-forward) |
| NIS2/GDPR Compliance | Possible | Possible | Possible |
| Deployment Time | 4–12 weeks | 1–2 weeks | 1–2 weeks |
There is no one-size-fits-all answer. The choice depends on the number of your sites, your IT maturity, your regulatory requirements, and your scalability goals.
\nOne thing is certain: for multi-site deployments, the TCO balance clearly favors the SaaS cloud. And the security argument only holds water if your on-premises infrastructure is properly maintained—which is rarely the case in small and medium-sized businesses without a dedicated cybersecurity team.
\nThe hybrid edge-and-cloud architecture, exemplified by solutions such as Eziwan, now makes it possible to combine local control (zero latency, offline operation) with the power of the cloud (centralized monitoring, remote access, unlimited history)—without having to choose between them.
\nCan a cloud-based SCADA system operate if the Internet is down?\nWith a hybrid architecture (edge gateway + cloud), the industrial process continues to operate (the PLC runs autonomously), and data is buffered locally by the gateway (store-and-forward). Real-time monitoring is interrupted during the outage, but the data is not lost—it is transmitted as soon as the connection is restored. For critical alarms, configure local alerts (relays, SMS messages from the edge gateway) that function without an Internet connection.
\nWhich on-premises SCADA systems are compatible with a cloud-based IoT gateway?\nWonderware AVEVA, Ignition (Inductive Automation), CODESYS, FactoryTalk (Rockwell), WinCC (Siemens), Citect—all integrate with cloud-based IoT gateways via OPC-UA, Modbus TCP, or REST APIs. The hybrid architecture involves letting the on-premises SCADA system handle local control and adding a cloud-based IoT gateway for remote monitoring and technician access.
\nIs SaaS cloud computing suitable for trade secrets (formulas, proprietary processes)?\nCritical process data (recipes, proprietary parameters) can be excluded from cloud transmission—you only send what you need for monitoring (temperatures, pressures, machine statuses). For the most sensitive data, cloud hosting in France (OVHCloud, Scaleway), which is subject to French law, offers an additional level of protection compared to U.S. hosting providers subject to the CLOUD Act.
\nHow long does it take to migrate from an on-premises SCADA system to the cloud?\nFor a site with an existing SCADA system, deploying a cloud layer (remote access, multi-site monitoring) takes 1 to 4 weeks without disrupting the on-premises SCADA system. The existing SCADA system remains in place; the cloud IoT gateway is added in parallel. A complete migration to a cloud-based SCADA system (without an on-premises SCADA system) takes 2 to 6 months, depending on the complexity of the installation.
\nAre you trying to decide between cloud and on-premises solutions for your monitoring project? Contact our team for personalized advice tailored to your industrial context.
\nIndustrial systems have become the primary target of cybercriminals. In 2025, 68% of cybersecurity incidents reported to ANSSI involved OT (Operational Technology) systems, compared to 41% in 2022. The growing interconnection between IT and OT networks, accelerated by Industry 4.0, has significantly expanded the attack surface of factories, power plants, and water systems.
\nThis guide outlines the main OT threats identified in 2025–2026, the sectors most at risk in France, and concrete steps you can take to reduce your exposure.
\nFor decades, industrial systems were protected by the air gap: their complete physical isolation from IT networks and the Internet. This natural protection has disappeared with the digitization of industry.
\nThe game-changing factors:
\nConsequence: OT systems are rife with unpatched vulnerabilities, insecure protocols, and increasing network exposure. For an attacker, this is an ideal target.
\nRansomware remains the number one threat. But in 2025–2026, cybercriminal groups developed variants specific to industrial systems, capable of:
\nActive Groups in Europe: LockBit 3.0, BlackCat/ALPHV, Play, and Cl0p all targeted French industries in 2024–2025. The manufacturing sector accounts for 28% of ransomware victims in Europe.
\nAverage impact of industrial ransomware:
\nMost Common Entry Points:
\nProgrammable logic controllers are now being targeted directly. The most sophisticated attacks modify the program logic (firmware or ladder logic) to:
\nRecurring vulnerabilities identified by ANSSI (2024–2025):
\n| Vendor | Vulnerability Type | CVE |
|---|---|---|
| Siemens S7-1500 | Buffer overflow in the Modbus TCP server | CVE-2023-46156 |
| Schneider Electric M340 | Lack of authentication on the FTP port | CVE-2024-8935 |
| Rockwell Automation ControlLogix | RCE via EtherNet/IP without authentication | CVE-2024-6077 |
| Mitsubishi MELSEC iQ-R | Denial of service via malformed packets | CVE-2024-7419 |
| Wago 750 Series | Default credentials not changed | CVE-2023-4156 |
Key preventive measure: Isolate PLCs in dedicated VLANs, prohibit direct connections from the IT network, and use industrial DMZs that comply with the Purdue architecture.
\nModbus, DNP3, BACnet, and Profinet were designed between the 1970s and 1990s with reliability and speed in mind. None of them include native authentication. Any device on the same network can:
\nTypical attack: An attacker who gains access to the OT network (via a compromised VPN, an infected maintenance workstation, or a physically connected cable) can directly send Modbus commands to the controller of a pump or compressor.
\nMitigation:
\nHuman-machine interfaces (HMIs) and SCADA servers are often the weak links because:
\nCommon Attack Scenario:
\nFact Check 2025: The Shodan platform lists more than 15,000 industrial HMIs accessible directly from the Internet in France, including approximately 3,400 that do not have authentication configured.
\nThe OT supply chain threat is growing rapidly. It involves compromising equipment, software, or a service provider before it reaches the end victim.
\nIdentified vectors:
\nDirectly Related NIS2 Requirements: Article 21 of the NIS2 Directive explicitly requires supply chain security management for essential and significant entities.
\nInternal threats are often underestimated in the industry. They include:
\n2024 Statistics (Verizon DBIR Report): 18% of OT incidents involve an insider or a compromised trusted third party.
\nKey Measure: Zero Trust Access — every access attempt must be authenticated (MFA), time-limited, and audited. A third-party vendor must never have permanent, unlimited access.
\nThe water sector is the number one target of OT attacks, according to ANSSI and Europol. The reasons:
\nReference Incident: In February 2021, an attacker altered the caustic soda level at a water treatment plant in Florida via an unsecured TeamViewer connection. An alert operator detected the anomaly in time. The same type of attack is possible on any water SCADA system without rigorous access controls.
\nIn France, NIS2 classifies water utilities serving more than 10,000 residents as critical entities, subject to enhanced cybersecurity requirements effective October 17, 2024.
\nAttacks on energy infrastructure (generation, transmission, and distribution) have tripled in Europe since 2022. Distribution system operators (DSOs), renewable energy producers, and industrial sites with electrical substations are at risk.
\nTargeted protocols: IEC 60870-5-101/104, IEC 61850 GOOSE, DNP3 — none of which include native authentication in their base versions.
\nThese sectors combine strict regulations (FDA 21 CFR Part 11, EU GMP Annex 11) with critical OT systems. Contamination of a manufacturing process resulting from the manipulation of PLCs can have serious health consequences.
\nAttacks aimed at halting production (competitive sabotage) are on the rise in these high-value-added sectors.
\nSmart cities are deploying IoT sensors, actuators, and gateways on a massive scale, often with insufficient security budgets. Street lighting, parking management, and urban transportation systems are now all connected—and potentially vulnerable.
\n1. Inventory of All OT Assets\nYou can’t protect what you don’t know about. Map all PLCs, SCADA systems, HMIs, gateways, and network devices, including their operating systems, firmware, protocols, and connections. Use passive discovery tools (Nozomi Networks, Claroty, Dragos) that do not disrupt the OT network.
\n2. IT/OT Network Segmentation\nIsolate your OT network from the IT network using an industrial firewall or a dedicated DMZ. The Purdue architecture (levels 0 through 5) remains the industry standard. At a minimum: prohibit any direct communication between desktop PCs and field controllers.
\n3. Eliminate unsecured remote access\nAudit all existing remote access methods (VPN, TeamViewer, AnyDesk, RDP). Disable those that are not strictly necessary. For legitimate access, implement MFA and limit access time windows.
\n4. Changing Default Credentials\nAll equipment (controllers, switches, HMIs, routers) shipped with default credentials (admin/admin, root/root) must have those credentials changed upon initial deployment. Document the credentials in a password vault (Bitwarden, HashiCorp Vault).
\n5. Backing Up PLC Configurations\nExport and back up TIA Portal, Unity Pro, and Studio 5000 projects offline to a location isolated from the OT network. In the event of a ransomware attack, restoration from a clean backup must be possible within hours, not weeks.
\n6. Strong Authentication for Remote Access\nDeploy an industrial VPN with MFA (TOTP or FIDO2) for all remote access—in-house technicians, contractors, and integrators. Each session must be recorded for auditing purposes.
\n7. OT Network Behavior Monitoring (NDR)\nDeploy a passive monitoring sensor on your OT network to detect communication anomalies: new devices, unusual Modbus function codes, communications to unknown IP addresses, and firmware changes. Nozomi Networks, Claroty, and Dragos are the market leaders.
\n8. OT Vulnerability Management\nSubscribe to your manufacturers’ security bulletins (Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation Security Advisories). Assess critical CVEs (CVSS ≥ 7.0) and schedule patches during upcoming maintenance windows.
\n9. OT Incident Response Plan\nDocument the specific OT response process: who to contact (ANSSI if the entity is NIS2-compliant), how to isolate a compromised segment without halting production, and procedures for restoring systems from backups. Test the plan once a year through a simulation.
\n10. Team Training (OT Security Awareness)\nAutomation engineers generally have not received cybersecurity training. Sessions lasting 2–4 hours on OT-specific threats, phishing, USB drive management, and secure remote access significantly reduce internal risk.
\nThe Eziwan gateway and platform were designed from the outset with OT security as a critical non-functional requirement.
\nZero Trust Architecture:
\nGranular remote access control:
\nIntegrated OT Monitoring:
\nSovereign Hosting:
\nUse this checklist to assess your OT cybersecurity maturity level:
\nGovernance
\nNetwork Architecture
\nAccess and Identities
\nMaintenance and Updates
\nDetection and Response
\nCan ransomware that infects the IT network also affect OT controllers?
\nYes, if the OT and IT networks are interconnected without strict segmentation. This is exactly how NotPetya (2017) and many industrial incidents since then spread. The ransomware encrypts IT servers, spreads via Active Directory and network shares, and if the OT network is on the same LAN or accessible via the same Windows domain, SCADA monitoring stations—and sometimes PLCs—are compromised.
\nCan Siemens or Schneider PLCs be directly infected by malware?
\nIndustrial control systems do not “become infected” in the traditional sense (they lack a standard file system, and arbitrary code cannot be executed via typical vectors). However, they can be reprogrammed remotely if access is gained (see Stuxnet). The real risk is more often the shutdown or manipulation of PLCs by a compromised operator or through poorly secured remote access, rather than a direct infection of the firmware.
\nWhat is the requirement to report to ANSSI in the event of an OT incident under NIS2?
\nFor entities subject to NIS2 (Essential Entities and Important Entities), the requirements are as follows: preliminary notification within 24 hours if the incident is likely to have a significant impact, an interim report within 72 hours, and a final report within one month. ANSSI can be notified using the dedicated form on its website. Failure to comply may result in fines of up to €10 million or 2% of global revenue.
\nAre OT network segmentation solutions very expensive for a small-to-medium-sized enterprise?
\nNo. Basic segmentation (OT/IT VLANs on a managed switch costing €200–400, with restrictive inter-VLAN rules) is within reach of any small and medium-sized business. For a higher level of protection, compact industrial firewalls (such as the Stormshield SNi40 or Fortinet FortiGate Rugged) start at 500–800€. Segmentation offers the best cost-effectiveness in OT cybersecurity—it contains incidents before they spread.
\nShould unsecured protocols such as Modbus TCP be disabled on the OT network?
\nOn the internal OT network, Modbus TCP can remain active—its lack of authentication is acceptable in a physically isolated and segmented network. The critical mistake is to expose the Modbus port (502) to the Internet or the IT network without any controls. The priority is to ensure that no OT ports are accessible from the outside, not necessarily to replace Modbus with a more secure protocol in the short term.
\nOT cybersecurity is no longer an option for French manufacturers. The NIS2 Directive, the requirements of the IEC 62443 standard, and the reality of incidents (ransomware, attacks on water networks, sabotage of energy infrastructure) make protecting OT systems essential.
\nThe good news: Contrary to what many business leaders believe, it’s not necessary to start from scratch to make significant progress. The five fundamental measures outlined in this guide—inventory, segmentation, removal of unsecured access, default credentials, and backups—reduce the risk of a major incident by 80%, at a reasonable cost and with manageable complexity.
\nYour next step: Conduct an OT audit of your infrastructure (Eziwan offers a free audit of your remote connections) and identify the three priority actions to implement within the next 30 days.
\nArticle written by the Eziwan team. Eziwan is a provider of IIoT gateways and industrial monitoring platforms for small and medium-sized industrial companies, local governments, and French automation integrators. Learn more about our approach to OT security →
\nThe IEC 62443 standard has become the international benchmark for cybersecurity in industrial control systems (ICS/SCADA/OT). With the entry into force of the NIS2 Directive in France, it is now explicitly cited as the technical standard applicable to critical and important entities.
\nHowever, the standard is considered complex and extensive. This practical guide distills the essentials for French manufacturers: what the standard actually requires, how to comply with it, and the priorities for 2026.
\nIEC 62443 (formerly ISA-99) is a family of standards developed by the ISA (International Society of Automation) and published by the IEC. It covers the cybersecurity of industrial automation and control systems (IACS).
\nThe standard is organized into four series:
\n| Series | Title | Target Audience |
|---|---|---|
| 62443-1.x | General (concepts, models, terminology) | All |
| 62443-2.x | Policies & Procedures | Industrial operators, CISOs |
| 62443-3.x | System (architecture, security levels) | Architects, integrators |
| 62443-4.x | Components (product security) | Equipment manufacturers |
For a French manufacturer seeking to comply with NIS2, the most relevant sections are:
\nThe central concept of IEC 62443 is the Security Level—the level of protection required based on the system's criticality.
\n| Security Level | Description | Against what threat? |
|---|---|---|
| SL 0 | No specific protection | — (offline systems) |
| SL 1 | Protection against accidental attacks | Human error, non-targeted malicious acts |
| SL 2 | Protection against deliberate attacks using limited resources | Hacktivists, opportunists |
| SL 3 | Protection against attacks using sophisticated methods | Organized criminal groups |
| SL 4 | Protection against state-sponsored attacks | State-sponsored APTs |
For the vast majority of French manufacturers: Level SL 2 is the appropriate target. SL 3 is reserved for operators of vital importance (OIV) with highly critical systems. SL 4 is almost exclusively for military and nuclear infrastructure.
\nThe process consists of three steps:
\n1. Identify Zones and Conduits (IEC 62443-3-2)
\nStart by mapping your OT systems into security zones:
\nNext, identify the pipes (Conduits)—the communication paths between zones (remote access VPNs, SCADA links, IT/OT gateways).
\n2. Assess the criticality of each zone (CASC)
\nFor each area, assess the consequences of a compromise based on the CASC criteria:
\n3. Define the target SL by zone
\nThe assessed criticality determines the target safety level (SL): an area with safety-related logic controllers (SIL) in a SEVESO facility will aim for SL 3, while a control room at a drinking water pumping station generally aims for SL 2.
\nThe IEC 62443-3-3 standard defines 7 fundamental requirements (FR) for systems. Each FR is broken down into detailed requirements based on the SL level.
\nWhat this means in practice:
\nEziwan App: Each technician has an individual OpenVPN/IPSec VPN key. MFA authentication is available on the cloud platform.
\nWhat this means:
\nApplication: Eziwan RBAC allows you to define access rights by site, by piece of equipment, and by time slot for each technician.
\nWhat this means:
\nApplication: All Eziwan communications are encrypted using OpenVPN (authentication + encryption). The configurations are digitally signed.
\nWhat this means:
\nImplementation: AES-256-GCM encryption of all communications; stored data is encrypted on the French cloud infrastructure.
\nWhat this means:
\nEziwan App: zero-inbound-port architecture—the OT network is never directly exposed. Traffic passes through the Eziwan cloud, which acts as a centralized control point.
\nWhat this means:
\nApplication: Comprehensive logging of all security events, configurable alerts for connection anomalies, and log export for SIEM.
\nWhat this means:
\nApplication: Dual SIM failover, multi-AZ cloud infrastructure, automatic backups of gateway configurations.
\nHere is a practical approach for French manufacturers who must comply with NIS2 by referencing IEC 62443.
\nList all your OT systems:
\nFor each asset: firmware/software version, network connectivity, date of the last security update, existing remote access capabilities.
\nDraw a diagram of the current OT network, including security zones and communication flows. Identify:
\nFor each area, assess:
\nPrioritize the areas to be addressed first: high criticality + high vulnerability = Priority 1.
\nBased on the risk analysis:
\nFor each area where the current level is below the target SL, define corrective actions:
\nSL 2 Priority Actions:
\nKey Actions for SL 2:\n7. Update the firmware on OT equipment (gateways, industrial switches)\n8. Document incident response procedures\n9. Train maintenance teams on OT cybersecurity risks
\nIEC 62443 compliance is not a one-time project but an ongoing process. Plan for:
\nThe NIS2 Directive (transposed into French law by the Act of October 8, 2024) does not explicitly cite IEC 62443, but the measures it requires are directly in line with it.
\nCritical infrastructure: energy (electricity, natural gas, oil), transportation (air, rail, maritime, road), banking, financial infrastructure, water (supply, wastewater), healthcare, digital infrastructure.
\nKey sectors: postal services, waste management, chemicals, food, industrial manufacturing (medical devices, electronic equipment, mechanical engineering), digital service providers.
\nMany manufacturers commission security policies before conducting an actual inventory. The result: theoretical documents that are out of touch with the reality on the ground. Always start with the inventory and mapping.
\nOT security has specific constraints: equipment cannot be taken offline for updates, the protocols are legacy (Modbus from 1979), and the teams are automation engineers—not IT professionals. Involve the production teams from the very beginning.
\nSL 3 and SL 4 have very strict requirements (strong authentication on PLCs, encryption of all industrial protocols, including Modbus) that often necessitate replacing OT equipment. For most manufacturers, SL 2 is a realistic and sufficient target.
\nThe most common OT incidents involve remote access by maintenance contractors. Prioritize third-party access security (named accounts, MFA, audit trails) before addressing the more technical aspects.
\nNIS2 mandates security measures but does not certify compliance with IEC 62443. IEC 62443 certification (by an accredited body) is distinct from NIS2 compliance. For most manufacturers, documented compliance with IEC 62443 without formal certification is sufficient to meet NIS2 requirements.
\nIs IEC 62443 certification required to comply with NIS2?\nNo. The NIS2 directive mandates technical and organizational security measures but does not require formal IEC 62443 certification (which is issued by accredited bodies such as TÜV, Bureau Veritas, etc.). However, documenting that your practices are aligned with IEC 62443 is an excellent way to demonstrate your NIS2 compliance to ANSSI.
\nWhich part of IEC 62443 should an industrial PMI start with?\nFor an industrial PMI, start with IEC 62443-2-1 (policies and procedures) and IEC 62443-3-3 (system requirements for Security Levels 1 and 2). These are the most directly applicable parts and the ones most frequently requested by clients. The 4.x parts (components) are of greater interest to equipment manufacturers.
\nWhat is a security zone in IEC 62443?\nA security zone is a group of systems with the same required security level, separated from other zones by conduits (controlled communication channels). Example: Zone 1 = production PLCs (SL2), Zone 2 = SCADA (SL2), Zone 3 = IT (SL1). Communications between zones must pass through a firewall or a controlled DMZ.
\nHow do I determine the target Security Level (SL) for my facility?\nThe target SL depends on the consequences of an incident: SL1 for a limited risk (temporary shutdown of a non-critical process), SL2 for a significant risk (impact on production or personal safety), and SL3 for critical systems (energy, water, healthcare). Most industrial SMEs aim for SL2 for their SCADA systems and SL1 for support systems.
\nDoes IEC 62443 cover VPN remote access security?\nYes. IEC 62443-3-3 explicitly addresses authentication (SR 1.1, SR 1.2), communication encryption (SR 4.1), session management (SR 1.3), and auditability (SR 2.8). An OpenVPN/IPSec VPN with certificate-based authentication and logging meets the requirements of Security Levels 1 and 2 in these areas.
\nOne of the main barriers to the adoption of industrial IoT is the difficulty in justifying the investment to decision-makers: What is the actual ROI? How can it be measured? How long will it take to achieve it?
\nThis guide provides a structured method for calculating the return on investment for an industrial IoT monitoring project, with numerical examples drawn from real-world deployments.
\nMost IoT ROI calculations focus on direct and obvious savings. But industrial IoT generates benefits in four categories that are often underestimated:
\nProjects that measure only Category 1 consistently attribute an overly low ROI to the IoT.
\nROI is calculated over a given period (usually 1, 2, or 3 years):
\nROI (%) = [(Total Profits - Total Costs) / Total Costs] × 100
Total Costs = Initial Investment + Recurring Costs
\nTotal benefits = the sum of savings and gains across the 4 categories
\nThis is often the most important item and the easiest to quantify.
\nActual cost of a technician's service call (France, 2026):
\n| Component | Estimated Cost |
|---|---|
| Travel time (2-hour round trip) | 60–120€ |
| Mileage allowance (50 km × 0.33€) | 33€ |
| On-site service time (1–2 hours) | 60–120€ |
| On-call duty (25–50% surcharge) | +30–80€ |
| Total on-call travel cost | 180–350€ |
| Total full-day travel cost | 150–250€ |
How IoT Monitoring Reduces Travel:
\nTypical savings observed:
\nAn unexpected breakdown costs, on average, 3 to 5 times more than an equivalent preventive maintenance service.
\nCost of an unplanned shutdown (example: industrial SME):
\nWith IoT monitoring and early warnings, signs of malfunction are detected before a failure occurs: vibration levels rise gradually, temperature exceeds its threshold, or motor current increases abnormally. Maintenance is scheduled during a planned shutdown.
\nROI of prevention: Avoiding just 1 to 2 unplanned shutdowns per site per year is often enough to recoup the total IoT investment.
\nWithout IoT monitoring, operators and technicians spend time:
\nEstimated time saved (for 20 monitored pieces of equipment):
\n| Task eliminated or reduced | Time/week before | Time/week after | Savings |
|---|---|---|---|
| Monitoring rounds | 8h | 2h | 6h |
| Manual data entry | 3h | 0h | 3h |
| Report compilation | 2h | 0h (automatic) | 2h |
| On-call management | 4 hours | 1 hour | 3 hours |
| Total | 17 hours | 3 hours | 14 hours/week |
14 hours/week × hourly rate (60€) = 840€/week in productivity savings, or 43,000€/year.
\nWith historical data available in the cloud, diagnosing a failure takes 10–15 minutes instead of 1–2 hours on-site. The technician reviews the trend graph, identifies the anomaly, and plans a targeted intervention.
\nFor sectors subject to NIS2 (water, energy, transportation, healthcare), fines for noncompliance can reach 2% of global annual revenue for a critical entity.
\nIoT monitoring—which includes access logging, traceability of interventions, and automatic audit reports—significantly reduces the risk of noncompliance.
\nFor companies covered by an SLA (maintenance providers, network operators), every hour of downtime can result in contractual penalties.
\nExample: A water network operator subject to a penalty of €2,000 per hour of non-compliance with pressure requirements. One outage detected 4 hours earlier thanks to IoT = €8,000 in penalties avoided.
\nReal-time electricity consumption data helps identify unnecessary consumption spikes, underutilized equipment, and load reduction opportunities.
\nTypical savings: A 5 to 15% reduction in the electricity bill for monitored equipment.
\nReal-world example: A pumping station with pumps running at full power 24 hours a day. IoT analysis reveals that demand at night is 40% lower. Reducing the pumps’ speed using a variable-speed drive (already in place) → 22% savings on electricity consumption.
\nBefore the IoT, maintenance decisions were based on experience and paper records. After the IoT, they are based on real data:
\nInitial investment:
\nAnnual recurring costs:
\nAnnual savings:
\nROI in Year 1: (103,600 - 24,000 - 19,200) / 43,200 = 140%\nPayback period: 4 to 5 months
\nInitial investment:
\nAnnual recurring costs:
\nAnnual savings:
\nROI in Year 1: (54,000 - 9,000 - 7,200) / 16,200 = 234%\nPayback period: 3 months
\nROI is highest for equipment with high downtime costs and at the most remote sites (high travel costs). Prioritize:
\nAn IoT system that isn't integrated into maintenance workflows generates little value. ROI is maximized when:
\nEstablish KPIs for monitoring at the outset:
\nCompare results on a quarterly basis to identify opportunities for improvement.
\nA sloppy installation leads to costly rework. Budget 30 to 50 percent of the hardware cost for installation, configuration, and training.
\nTo maximize ROI, teams must truly adopt the new practices. A technician who doesn't use remote access before traveling to a site doesn't save anything.
\nThe cost of migrating from one IoT platform to another is often higher than the initial cost. Check the provider's scalability, open API, and long-term viability before committing.
\nThe ROI of industrial IoT is rarely the problem people imagine: for the vast majority of industrial deployments, it is achieved in less than 12 months—often in 3 to 6 months.
\nThe real question isn't \"Is it cost-effective?\"—it's \"Where do I start?\" The answer: Start with 5 to 10 high-criticality sites or pieces of equipment, measure the actual ROI over 3 months, and then roll out the solution at scale based on concrete data.
\nHow to Calculate the ROI of an Industrial IoT Project Without Historical Downtime Data?\nUse industry estimates as a starting point: an unplanned outage costs the manufacturing industry an average of 5 to 15% of its annual production value. For water utilities, expect costs of €2,500 to €5,000 per unplanned emergency response. Refine these estimates with your actual data after a 3-month pilot deployment.
\nIs the ROI of industrial IoT the same for an SME as for a large corporation?\nNo. Large corporations benefit from economies of scale on gateways and subscriptions, and have more critical equipment—so the absolute ROI is higher. On the other hand, the relative ROI (percentage of savings vs. maintenance budget) is often better for SMEs, since they lack dedicated IT resources and save proportionally more by automating monitoring.
\nShould you calculate the ROI before or after launching a pilot?\nBoth. Before: An estimated ROI justifies the pilot’s budget to management. Afterward: the measured ROI (based on actual data) justifies full-scale deployment and validates the initial assumptions. Experience shows that the actual ROI is often higher than the estimated ROI, as unexpected benefits emerge during the pilot (greater visibility, faster decision-making, etc.).
\nWhat Costs Should Be Factored Into an Industrial IoT Project?\nCommon underestimated costs: RS-485 cabling installation (allow €200–500 per site), training for maintenance teams (at least 2 days), SCADA configuration (integrating new data into existing tools), and change management (getting field technicians to adopt the new tools).
\nRemote industrial monitoring has become a strategic issue for French manufacturers. Between the phase-out of the 2G GPRS network (Bouygues and SFR will discontinue service by the end of 2026), the NIS2 Directive, which mandates enhanced cybersecurity measures, and pressure to reduce maintenance costs, companies must modernize their approach to remote monitoring.
\nThis guide covers the entire subject: definitions, technical architectures, protocol selection, cybersecurity, and practical implementation for deployments ranging from 1 to 1,000 sites.
\nRemote industrial monitoring (or industrial telemetry) refers to the range of technologies that enable:
\nIt applies to all sectors: manufacturing, water and wastewater, energy, agriculture, and building services.
\nThese terms are often confused. Here are the differences:
\n| Term | Scope | Infrastructure |
|---|---|---|
| SCADA (Supervisory Control and Data Acquisition) | Single site or network of sites with centralized architecture | On-premises server + local HMIs |
| Remote Monitoring / Remote Supervision | Multi-site, access from anywhere | WAN (4G, fiber) + cloud or central server |
| IIoT (Industrial Internet of Things) | Networked sensors & equipment | Cloud, edge computing, APIs |
In 2026, the lines between them are blurring: modern IIoT platforms (including Eziwan) offer cloud-based SCADA capabilities while integrating legacy industrial protocols (Modbus, OPC-UA).
\nBenefits:
\nTypical use cases: water utilities, power distribution networks, solar farms, and geographically dispersed fleets of industrial equipment.
\nAdvantages:
\nTypical use cases: large industrial companies with existing SCADA systems, industries with data sovereignty requirements.
\nFor sites that generate large amounts of data (production lines, presses, CNC machines), edge computing allows critical data to be processed locally and only aggregated data to be sent to the cloud.
\n\nModbus is the most widely used protocol in the industry. It comes in two variants:
\nWhat Modbus allows you to monitor: all modern industrial PLCs (Siemens S7, Schneider Modicon, ABB, Allen Bradley), as well as the vast majority of energy meters, variable-speed drives, and industrial sensors.
\nLimitation: Master/slave architecture only. No event notifications—the master must poll the slaves regularly.
\nMQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol designed for low-bandwidth connections.
\nKey Features for Remote Monitoring:
\nusine/ligne1/pompe3/courant — logical data structureCloud integration: MQTT is natively supported by AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and HiveMQ.
\nOPC-UA (Unified Architecture) is the interoperability standard for Industry 4.0.
\nKey Features:
\nWhen to choose OPC-UA: Integrations with existing SCADA, MES, and SAP ERP systems. Environments where data semantics (not just raw values) are important.
\nRemote industrial monitoring is a major attack vector if it is not properly secured. In 2024–2025, several incidents involved unsecured remote access to OT equipment.
\n1. No open incoming ports on the industrial network
\nThe zero-inbound-port architecture is the fundamental principle: industrial devices themselves initiate the connection to the monitoring cloud. No RDP, VNC, or Modbus ports are directly exposed to the Internet.
\n2. VPN and Encryption Required
\nAll communications between industrial sites and the monitoring platform must be encrypted. OpenVPN with AES-256-GCM encryption is the 2026 recommendation for new deployments.
\n3. Strong Authentication for Remote Access
\nEvery technician accessing the system remotely must authenticate using a personal cryptographic key (not a shared password). Multi-factor authentication (MFA) is mandatory for entities subject to NIS2.
\n4. Principle of Least Privilege
\nA maintenance technician for a specific PLC has access only to that PLC—not to the entire OT network. Fine-grained access segmentation limits the spread of a breach.
\n5. Complete audit log
\nAll remote connections, configuration changes, and actions are logged with a timestamp, user ID, and source IP address. These logs are required by the NIS2 directive for critical and important entities.
\nThe NIS2 Directive (transposed into French law in October 2024) requires critical entities and important entities to implement specific measures for remote access:
\nSectors involved: water and sanitation, energy, transportation, health care, waste management, and critical industrial production.
\nRequired equipment:
\nDeployment time: 2 to 4 hours for a technician (hardware installation + cloud configuration + Modbus data validation).
\nEstimated cost: €300–600 for equipment + €30–80/month for platform subscription + M2M SIM card.
\nAt this scale, Zero-Touch Provisioning (ZTP) becomes essential for reducing deployment costs.
\nEziwan ZTP Process:
\nCost savings vs. manual configuration: For 50 sites, ZTP typically saves 2 to 3 person-days of network configuration time.
\nFor large fleets, centralized management features become critical:
\nPrevious situation: weekly supervisory rounds, 2–3 on-call shifts per week for emergency response.
\nSolution deployed: 80 4G LTE gateways with Modbus RTU, real-time alerts on pump levels and faults, and remote access for technicians via OpenVPN/IPSec.
\nResults:
\nPrevious situation: Each site had its own local SCADA system, with no consolidated visibility at the group level.
\nSolution deployed: 3 IoT gateways that consolidate Modbus data from each site into a single cloud-based dashboard. Remote access for the group's maintenance team.
\nResults:
\nPrevious situation: Proprietary data loggers that were incompatible across different inverter manufacturers.
\nDeployed solution: IoT gateways with a universal Modbus parser supporting the SunSpec, SMA, ABB, and Fronius protocols. Performance monitoring dashboard (kWh, performance ratio, availability).
\nResults:
\nBefore launching your remote monitoring project, check the following:
\nRemote industrial monitoring is no longer an option in 2026: the phase-out of 2G GPRS, the NIS2 Directive, and economic pressure to reduce maintenance costs make it a necessity for all industrial companies with remote sites.
\nThe good news: With 4G LTE solutions featuring Zero-Touch Provisioning, you can now connect an industrial site in less than an hour, for less than 50€/month, all-inclusive.
\nThe key to success is choosing a secure cloud-native architecture from the start—not adding security as an afterthought on top of an architecture that wasn't designed for it.
\nWhat is the difference between SCADA and cloud-based IoT monitoring?
\nA traditional SCADA system is a centralized (often on-premises) system with thick clients (dedicated PC software), local data archiving, and a star architecture. Cloud-based IoT monitoring is a distributed architecture: each site sends its data to the cloud via a gateway, without a central on-site server. The cloud offers multi-site access, mobile access, and a REST API for integration—whereas traditional SCADA requires a site-to-site VPN and a license per client. The two can coexist via OPC-UA or Modbus connectors to the existing SCADA system.
\nHow many variables can be monitored simultaneously across 100 sites?
\nThere is no fixed limit on the cloud side—modern IIoT platforms are designed to handle millions of measurement points. The practical limit lies with the gateway and network: a standard gateway collects up to 500 Modbus variables per site with a 5-second polling interval, or 6,000 values per minute per site. Across 100 sites, that’s 600,000 values per minute—manageable if the cloud is scaled accordingly (time series, site-based partitioning).
\nCan remote monitoring work if the PLC is in STOP mode (program stop)?
\nYes, for monitoring the PLC's status (CPU in STOP mode, time of last alarm, I/O status). No for Modbus collection of process variables—the PLC’s Modbus TCP server stops responding in STOP mode on certain models (the S7-1200 stops the MB_SERVER when in STOP mode). Check the specific behavior of the PLC in STOP mode before relying on Modbus data collection to detect CPU stops.
\nWhat is the minimum latency between a state change on the PLC and its appearance on the dashboard?
\nWith a 1-second Modbus polling interval and a properly sized cloud infrastructure, the total latency is typically 2 to 5 seconds (1 second of polling wait time + 1 to 2 seconds of 4G transit time + 1 to 2 seconds of cloud processing time). For critical alarms (threshold exceedances), Eziwan can send SMS/email notifications in less than 10 seconds after detecting the exceedance. For a real-time response (< 100 ms), local logic is required on the PLC or gateway—not the cloud.
\nCan non-Ethernet devices (RS-485 meters, 4-20 mA sensors) be monitored?
\nYes, via the gateway's RS-485 port for Modbus RTU, and via the analog inputs for 4–20 mA or 0–10 V signals. Sensors without a digital protocol (simple dry contacts, level switches) connect to the digital inputs of the gateway or an expansion module. The goal is to monitor the entire site from a single gateway, regardless of the heterogeneity of the equipment.
\nThe question “Which protocol should I use for my industrial IoT project?” comes up time and again in factory modernization projects. Modbus, MQTT, and OPC-UA are the three most commonly mentioned protocols—but they are not direct alternatives. They operate at different layers, address different needs, and often complement rather than compete with one another.
\nThis article explains their fundamental differences, strengths, and limitations, and provides a decision-making guide to help you choose the right protocol for your use case.
\nBefore making a comparison, it is important to understand that Modbus, MQTT, and OPC-UA do not operate at the same level:
\nModbus is a data read protocol: it allows you to query a device to read its registers (measurements, statuses). It is a field protocol—master/slave—designed for data acquisition from industrial equipment.
\nMQTT is a messaging protocol: it allows users to publish and subscribe to data streams through a centralized broker. It is a message transport protocol, not a protocol for direct data acquisition from a device.
\nOPC-UA is a service architecture: it combines data acquisition, data model access, security, alarms, and history into a single, unified industry standard. It is the most comprehensive—and the most complex—solution.
\nIn practice: Most modern industrial IoT architectures use all three: Modbus to read field devices, MQTT to transmit data to the cloud, and OPC-UA for interoperability between complex systems.
\nModbus was created in 1979 by Modicon (now Schneider Electric). It is the oldest industrial protocol still in active use—and by far the most widely used in the French industrial sector.
\nModbus RTU operates over an RS-485 (or RS-232) serial connection. It is asynchronous, master/slave, with a linear (multidrop) bus topology. Up to 247 slaves can be connected to a single RS-485 bus.
\nModbus TCP is Modbus encapsulated in TCP/IP packets. It operates over Ethernet on port 502. It retains the master/slave model but allows for arbitrary network topologies (star, tree). There is no strict limit on the number of slaves on the network.
\nModbus exposes 4 types of data:
\nTo read a temperature measurement from a sensor: the master sends a request to \"read registers 3x01 through 3x02,\" and the slave responds with the two registers containing the value (typically a 32-bit float spread across two contiguous registers).
\nAbsolute universality: If you have industrial equipment with an RS-485 port or an Ethernet port and don't know which protocol it uses, start by testing Modbus. It is highly likely that it supports Modbus.
\nSimplicity: The protocol is simple—numbered registers, standard read/write functions. Any developer can implement a Modbus client in a matter of hours.
\nResilience: No dependence on a broker or a central server. The master polls each slave directly. A failure of the master does not affect the slaves' communication with each other.
\nMaturity: 45 years of industrial deployment. Modbus libraries are available in all programming languages (Python, C, Java, JavaScript, etc.).
\nPull-only architecture: The master must proactively poll each slave. The devices do not send data on their own. On a bus with 50 slaves polled every second, the actual polling interval per slave can drop to 20 seconds.
\nNo built-in security: Modbus RTU and Modbus TCP have no authentication or encryption mechanisms. Any device on the network can read or write the registers of an exposed Modbus device. Security must be implemented at the network level (VPN, segmentation).
\nNo automatic discovery: There is no mechanism for discovering Modbus devices on a bus. You must know the slave address and register addresses for each device.
\nNo semantic naming: Registry entry 40001 does not indicate what it contains—you need the manufacturer's documentation to know that it is \"water inlet temperature.\" No self-description.
\nMQTT was created in 1999 by IBM for telemetry over low-bandwidth satellite links. It was standardized by OASIS in 2014 (MQTT 3.1.1) and 2019 (MQTT 5.0).
\nMQTT is a publish/subscribe protocol: publishers send messages to topics, and subscribers receive messages on the topics they are subscribed to. A central MQTT broker routes messages between publishers and subscribers.
\nThe broker is at the heart of the MQTT architecture. Clients (publishers and subscribers) connect to the broker—they never communicate directly with each other.
\nPush architecture: Publishers send data when they have something to say. No polling—the subscriber receives the data immediately upon publication. Typical latency: 10–50 ms end-to-end.
\nLightweight: The protocol was designed for resource-constrained devices (microcontrollers, 2G modems). An MQTT message can fit into 2 bytes (minimum header). Very bandwidth-efficient.
\nConfigurable QoS: Three levels of quality of service: QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once). For mission-critical applications, QoS 2 guarantees delivery exactly once.
\nCloud interoperability: All major cloud providers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) offer a native MQTT broker. MQTT is the de facto protocol for cloud-based IoT architectures.
\nNative TLS: MQTT natively supports TLS 1.3. Security is built into the protocol; it is not an add-on.
\nCannot read devices directly: A Modbus RTU device does not natively support MQTT. A gateway is required to read the Modbus data and publish it via MQTT. This is why Modbus and MQTT are often used together in industrial IoT architectures.
\nDependence on the broker: If the MQTT broker goes down, the entire messaging architecture fails. The broker's resilience is critical. Managed brokers (AWS IoT, HiveMQ Cloud) are very reliable, but create a dependency on an external service.
\nNo standardized data model: MQTT does not define the message format or the structure of topics. Each implementation is free to choose its own approach—which hinders interoperability. Two MQTT systems from different vendors may not be able to communicate without some adaptation.
\nNo native request/response: MQTT is designed for unidirectional events. To implement a request/response pattern (e.g., requesting a parameter from a device), you must use MQTT 5.0 with correlated response topics—this is possible but more complex.
\nOPC-UA (IEC 62541) was developed by the OPC Foundation beginning in 2006 as the successor to OPC Classic (based on Windows COM/DCOM). It is the most comprehensive industry standard: it combines data acquisition, a semantic model, security, history, alarms, and method access into a single protocol.
\nOPC-UA is now the preferred protocol among PLC manufacturers for Industry 4.0 architectures: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, and B&R Automation—all of which have supported OPC-UA natively for the past 5 to 10 years.
\nSemantic data model: Unlike Modbus (which uses anonymous, numbered registers), OPC-UA exposes a tree of named and typed objects. The node \"ns=2;i=1001\" can be named \"Machine1/MainMotor/BearingTemperature\" and include metadata (unit, range, description). Self-description is built-in.
\nBuilt-in security: Authentication, authorization, encryption, message integrity—it's all built into the protocol. OPC-UA supports several security profiles (None, Sign, SignAndEncrypt) using modern algorithms (AES-256, RSA-2048+).
\nPublish/Subscribe via OPC-UA PubSub (2017): OPC-UA can now operate in asynchronous (push) publication mode, not just in request/response (pull) mode. It can publish to MQTT brokers, making OPC-UA and MQTT complementary rather than competing technologies.
\nAccess to Methods: OPC-UA allows you to call methods on devices—not just read values. Whether it's actuating a valve or issuing a motor start command, everything is modeled as an OPC-UA object.
\nSemantics and Interoperability: The OPC-UA \"Companion Specifications\" define industry-standardized models: OPC-UA for Plastics, for Robotics, for PackML (packaging), for Mining... SCADA software that supports OPC-UA for PackML can connect to any compliant packaging line without requiring any specific configuration.
\nComplexity: OPC-UA is the most complex protocol to implement and configure. The specifications are over 1,000 pages long. The learning curve is significant for teams with no prior OPC-UA experience.
\nRequired resources: A full-featured OPC-UA server requires more resources than a Modbus slave. Older PLCs or resource-constrained microcontrollers cannot run a full OPC-UA stack (although there are lightweight \"nano\" profiles available).
\nNot universally used in the field: Older equipment (manufactured before 2010–2015) does not support OPC-UA. In a heterogeneous industrial environment, you will encounter Modbus much more frequently than OPC-UA on existing field equipment.
\nNetwork overhead: OPC-UA messages are larger than Modbus messages (XML or binary, depending on the transport). On low-bandwidth 4G connections, this can be a factor.
\nUsage: Process monitoring, alerts, historical data. 80% of French industrial IoT projects follow this model.
\nUsage: Projects with multiple data consumers (SCADA + ERP + BI). MQTT as an integration bus.
\nApplications: Factories with modern PLCs, Industry 4.0 projects, MES integration.
\n| Requirement | Modbus RTU | Modbus TCP | MQTT | OPC-UA |
|---|---|---|---|---|
| Read RS-485 field sensors | ✓✓ | — | — | — |
| Read PLCs on the network | ✓ | ✓✓ | — | ✓ |
| Send data to the cloud | — | — | ✓✓ | ✓ |
| SCADA/MES Interoperability | ✗ | ✗ | Partial | ✓✓ |
| Built-in Security | ✗ | ✗ | TLS | ✓✓ |
| Legacy equipment | ✓✓ | ✓ | — | ✗ |
| Recent PLCs (>2015) | ✓ | ✓ | — | ✓✓ |
| Cloud-native architectures | ✗ | ✗ | ✓✓ | ✓ |
| SMEs without protocol expertise | ✓✓ | ✓✓ | ✓ | ✗ |
The Eziwan gateway is agnostic to field-side protocols:
\nOn the cloud side, data is standardized internally and exposed via:
\nYou can combine Modbus RTU on field devices with MQTT to your AWS/Azure cloud without changing anything—the gateway handles the translation.
\nIn 2026, the answer to \"Modbus, MQTT, or OPC-UA?\" is generally \"all three\":
\nThis isn't a competition—it's a layered architecture. The choice isn't \"which protocol,\" but \"which protocol at which layer for which device.\"
\nCan Modbus and MQTT be used simultaneously on the same gateway?
\nYes, and that’s the most common architecture in IIoT. The gateway collects data from PLCs via Modbus TCP or RTU (field layer) and publishes it via MQTT to the cloud (transport layer). Modbus stops at the gateway—it is never exposed to the Internet. MQTT takes over for transport to the cloud, using TLS 1.3 and authentication.
\nCan OPC-UA replace Modbus on existing PLCs (S7-1200, M340)?
\nOn Siemens S7-1200 controllers, the OPC-UA server is only available starting with firmware version 4.4 and requires explicit configuration in TIA Portal. On S7-1500 controllers, it has been supported natively since firmware version 2.0. On Schneider M340 controllers, OPC-UA is not built-in—an additional module is required. In practice, for existing installations, Modbus TCP remains the universal solution; OPC-UA is primarily relevant for new projects using recent PLCs.
\nMQTT with QoS 0 vs. QoS 1 vs. QoS 2 — Which Should You Choose for Industrial Monitoring?
\nFor monitoring process data (temperatures, pressures), QoS 1 (At Least Once) strikes the right balance: delivery is guaranteed even after reconnection, at the risk of a few duplicates (which are acceptable for monitoring data). QoS 2 (Exactly Once) is more resource-intensive due to the round-trip confirmation and is rarely necessary for measurements. QoS 0 (At Most Once) is suitable for very frequent data (> 1/s) where occasional loss is acceptable.
\nIs a public MQTT broker (HiveMQ, EMQX Cloud) sufficient for industrial applications?
\nFor pilot projects or non-critical applications, yes. But for a production environment with confidentiality requirements (process data, equipment identifiers), a private broker hosted in France is preferable. MQTT data passing through U.S. public brokers is potentially subject to the CLOUD Act—this should be evaluated based on the sensitivity of the data and the industry.
\nDoes OPC-UA affect the PLC's performance compared to Modbus?
\nOPC-UA places significantly greater demands on CPU and memory than Modbus TCP. On an S7-1500 CPU 1511 with an active OPC-UA server and 50 client connections, the cycle time can increase by 5 to 15 percent. On an S7-1200, resources are more limited—always test the impact using the complete production program before deploying OPC-UA in production.
\nThe market for industrial IoT gateways has expanded significantly in recent years. With such a vast array of options—from Taiwanese brands priced at €80 to integrated solutions costing €2,000, and from simple Modbus devices to gateways with VPN and edge computing—how can you make sense of it all?
\nThis guide describes the nine criteria that help distinguish a gateway truly suited for industrial environments from a poorly repurposed consumer-grade product. It is intended for maintenance managers, automation engineers, and industrial IT directors who are planning a connectivity or monitoring project.
\nThis is the number one criterion. If your gateway doesn't \"speak\" the same protocol as your devices, all other criteria become secondary.
\nModbus RTU (RS-485) — The gold standard in French industry. Energy meters, HVAC controllers, sensors, variable-frequency drives: if your equipment has an RS-485 serial port, it likely uses Modbus RTU. Any industrial gateway worth its salt must support it natively.
\nModbus TCP (Ethernet) — The network version of Modbus. Newer PLCs, Modbus-Ethernet gateways, and devices with RJ45 interfaces. Check whether the gateway supports the role of Modbus master (active polling) or only that of a server (passive).
\nMQTT — The quintessential IoT messaging protocol. Used to publish data to cloud brokers (AWS IoT, Azure IoT Hub, local Mosquitto MQTT). Essential for cloud-native architectures.
\nOPC-UA — IEC 62541 industrial standard, adopted by Siemens, Rockwell, and Beckhoff for recent PLCs. If your IT system includes Siemens S7-1500/1200 PLCs or a recent version of TIA Portal, check for OPC-UA compatibility.
\nSpecific Protocols:
\nProtocol Checklist:
\nAn industrial gateway in 2026 must include at least a 4G LTE Cat-M1/Cat-4 module. 4G covers 97% of France’s population and is sufficient for 95% of industrial IoT applications (real-time monitoring, alerts, remote access).
\nPoints to Consider:
\nOne SIM card = one carrier = one point of failure. In certain industrial areas (partial dead zones, tunnels, areas with poor coverage), one carrier may lose signal while the other maintains it.
\nDual SIM, which supports two SIM cards from different carriers and automatic switching, is the solution for mission-critical applications. Eziwan supports Dual SIM natively.
\nQuestions to Ask:
\nFor sites with fiber or Ethernet available, a gateway with an Ethernet WAN port allows you to use fiber as the primary connection and 4G as a backup. Both connections must be managed simultaneously with automatic and transparent failover.
\nCybersecurity for industrial IoT gateways has become a non-negotiable requirement, driven by NIS2, which now covers a wide range of industrial companies.
\nOutbound-only architecture: The gateway must establish outbound connections only. No inbound ports should be open on your OT network. This eliminates the attack surface accessible from the Internet. This is the Zero Trust architecture: \"Never trust, always verify.\"
\nVPN Protocol: OpenVPN is currently the industry standard: robust, extensively audited, it traverses firewalls via TCP port 443 and authenticates using X.509 certificates (AES-256-GCM encryption). IPSec (IKEv2) remains relevant for FIPS 140-2-regulated environments.
\nData encryption in transit: TLS 1.3 or higher for cloud communications. Verify that the gateway does not communicate in plain text with an unencrypted MQTT broker.
\nAuthentication: Cryptographic keys per device, individually revocable. Avoid gateways that use a single administrator password shared across all devices.
\nSecure firmware updates (OTA): Gateways that have not been updated become attack vectors. Verify that the gateway supports cryptographically signed OTA updates.
\nSince October 2024, NIS2 has required essential and significant entities to manage the security of their digital supply chains, including IoT gateways. A gateway that opens incoming ports on the OT network or communicates in plain text is considered a NIS2 non-compliance.
\nAn \"industrial\" gateway must be able to withstand real-world industrial environments. Here are the certifications and specifications to check:
\n| Application | Min. temperature | Max. temperature |
|---|---|---|
| Air-conditioned equipment room | -10°C | +40°C |
| Non-air-conditioned cabinet | -20°C | +60°C |
| Outdoor / cold environment | -40°C | +70°C |
A standard IT gateway operates between 0°C and +40°C. A true industrial gateway typically operates between -20°C and +70°C.
\nIP20: Minimum protection; for use only in a closed cabinet in a clean room.
\nIP40: Protection against solid objects larger than 1 mm. Standard equipment cabinet.
\nIP65: Dust-tight and protected against water jets. For dusty environments (food processing, construction, outdoor use under cover).
\nIP67: Temporary submersion up to 1 meter. For very humid environments.
\nIP68: Prolonged submersion. Rarely necessary but useful for underground equipment.
For applications in industrial vehicles, overhead cranes, compressors, or vibrating environments: verify compliance with EN 61131-2 or IEC 60068 for mechanical testing.
\nFor installation in an electrical cabinet, mounting on a 35mm DIN rail is the industry standard. Avoid gateways that require wall screws or non-standard 19\" rack mounting for industrial installations.
\nCE (EU requirement): CE marking is required for all electronic equipment sold in Europe.
\nATEX (explosive atmospheres): For chemical and oil facilities with potentially explosive atmospheres. ATEX Zone 1/2 or Zone 21/22, depending on the application.
\nEN 61131-2: Specific standard for equipment used with programmable logic controllers (PLCs).
ZTP is a criterion that is often underestimated, especially when deploying dozens or hundreds of gateways.
\nWithout ZTP: Each gateway must be configured manually before deployment. A technician must log in to the local interface, enter the cloud server's IP address, credentials, network settings, etc. For 50 sites, that’s 50 visits of at least 30 minutes each = 25 hours of technical work, plus travel time.
\nWith ZTP: The gateway automatically connects to the management cloud the first time it is powered on (via a preconfigured M2M SIM). It downloads its configuration from the server and is operational in less than 5 minutes without any local intervention.
\nQuestions to Ask the Provider:
\nThe most advanced gateways have enough computing power to execute logic locally, without relying on the cloud:
\nLocal aggregation: Calculate averages, min/max values, and totals over a period (e.g., energy consumed in kWh per hour) before sending the data to the cloud. This reduces the required bandwidth.
\nLocal Alerts: Trigger a local alarm (relay, buzzer, direct SMS) without going through the cloud. Useful in the event of a network outage—the gateway continues to monitor and send alerts locally.
\nData Filtering: Send only data that has changed by more than a defined threshold. This drastically reduces mobile data costs at sites with high traffic.
\nLogic Scripts: On advanced gateways (Eziwan, certain Teltonika models), you can run Python or JavaScript scripts locally to handle complex business logic.
\nFor multi-site projects (3–4 sites or more), the centralized management console is a key differentiator:
\nFleet Dashboard: Real-time view of the status of all gateways (connected/disconnected, signal strength, active alerts).
\nRemote firmware updates: Deploy a security update to 50 gateways with just a few clicks, without having to travel to the site.
\nRemote Configuration: Change an alarm threshold, add a new sensor, or modify a network setting—all from the web console.
\nFleet Alerts: Receive a notification when a gateway loses its connection or when a device exceeds a threshold.
\nThis criterion has become strategic for French companies in light of NIS2 and digital sovereignty requirements.
\nKey Questions:
\nFor NIS2 essential entities and operators of critical infrastructure, hosting data in France with a service provider not subject to foreign extraterritorial laws is a de facto requirement.
\nEven the best gateway in the world is worthless without support that can answer your technical questions in real time:
\nSupport SLA: What is the guaranteed response time? 4 hours, 8 hours, or 24 hours? For mission-critical industrial applications, an SLA of less than 4 business hours is recommended.
\nIndustrial expertise: Is the support team familiar with the Modbus, PROFIBUS, and Siemens S7 industrial protocols? Or is it a general IT support team?
\nDocumentation: Is the API documented (OpenAPI 3.0)? Are there code examples? Are there Python/Node libraries?
\nProject Support: Does the vendor offer support during the initial deployment?
\n□ Protocoles
□ Modbus RTU (RS-485) master
□ Modbus TCP Master
□ MQTT TLS
□ Industry-specific protocols
□ Connectivité
□ Built-in 4G LTE
□ Dual SIM with two carriers
□ Port Ethernet WAN (optionnel)
□ Délai failover < 30 secondes
□ Sécurité
□ Architecture outbound-only (zero inbound port)
□ OpenVPN/IPSec VPN or a modern equivalent
□ TLS 1.3 for cloud communications
□ Authentication using a cryptographic key
□ Signed OTA update
□ Robustesse
□ Temperature: -20°C / +70°C minimum
□ IP40 minimum (IP65 if the environment is dusty)
□ Montage rail DIN 35mm
□ CE Certifications (+ ATEX if necessary)
□ ZTP
□ Deployment without local intervention
□ Preconfigured M2M SIM
□ Edge computing
□ Local aggregation
□ Alertes locales sans cloud
□ Logique locale configurable
□ Centralized console
□ Real-time Fleet Dashboard
□ OTA firmware updates
□ Remote configuration
□ Data hosting
□ Hosting in France or the EU
□ Non soumis au CLOUD Act
□ ISO 27001 minimum
□ Support
□ Documented SLA
□ Expertise protocoles industriels
□ OpenAPI-documented API
What is the difference between an industrial IoT gateway and an industrial 4G router?\nAn industrial 4G router provides IP network connectivity (routing, NAT, VPN). An industrial IoT gateway adds field capabilities: an RS-485 port for Modbus RTU, edge computing, and cloud-native integration (MQTT, REST API). Some products, such as the Eziwan Gateway, combine both functions in a single device.
\nCan an industrial IoT gateway be used without an Eziwan cloud subscription?\nThe Eziwan Gateway hardware can operate in standalone mode with your own MQTT broker or API. The Eziwan cloud platform (dashboard, ZTP, fleet management, alerts) is optional. That said, it is included in the subscription and eliminates the need to manage server infrastructure.
\nHow many Modbus registers can be collected simultaneously?\nThe Eziwan Gateway can handle up to 500 Modbus registers (RTU or TCP) per polling interval. For deployments with higher requirements (multi-circuit energy meters, lines with numerous sensors), polling can be distributed across multiple configurable time slots.
\nWhat is edge computing on an industrial gateway, and do I need it?\nEdge computing allows logic to be executed directly on the gateway (aggregation, filtering, local anomaly detection, cloud-free alerts). Useful when: connectivity is intermittent (data is processed and buffered locally), the volume of raw data is too large to send to the cloud, or a rapid response is required (<1 s) without going through the cloud.
\nHow can you verify that a gateway complies with NIS2 regulations?\nNIS2 compliance for gateways includes: communication encryption (TLS 1.3 minimum), strong authentication (X.509 certificates, no default passwords), access traceability (audit log), security updates (signed OTA updates), and data hosting within the EU (GDPR). Ask your provider for their compliance attestation or ISO 27001 certifications.
\nThe terminology surrounding industrial maintenance is often a source of confusion: predictive maintenance, condition-based maintenance, preventive maintenance, corrective maintenance—these terms are frequently used interchangeably, but they refer to fundamentally different approaches with very different ROIs.
\nThis article clarifies the definitions, compares approaches based on concrete criteria, and helps you choose the strategy best suited to your situation in 2026—whether it’s a small factory with 20 pieces of equipment or a large industrial site with 500+ assets.
\nDefinition: We step in after a breakdown. When the equipment breaks down, we fix it.
\nVariants:
\nTypical cost: 4 to 5 times higher than the equivalent preventive maintenance (express parts, overtime, lost production).
\nWhen it is acceptable: Non-critical equipment that is easily replaceable, where the cost of monitoring exceeds the cost of failure.
\nDefinition: Items are replaced or overhauled according to a fixed schedule (based on time or production intervals), regardless of their actual condition.
\nExample: Change the oil in a gearbox every 2,000 hours, even if it is still in good condition.
\nMain problem: 30 to 40% of the parts replaced during preventive maintenance visits are still usable. This results in a waste of both resources AND components.
\nTypical cost: 2 to 3 times higher than well-calibrated condition-based maintenance.
\nWhen applicable: Equipment with well-known and predictable degradation patterns over time, in a regulatory context that requires periodic inspections.
\nDefinition: Action is taken when the actual condition of the equipment warrants it, based on continuous physical measurements (vibration, temperature, current, acoustic levels, etc.).
\nPrinciple: Every piece of equipment \"speaks\" through its data. We listen to it.
\nExample: The bearing is replaced when the vibration exceeds a critical threshold established during commissioning, not on a fixed schedule.
\nDocumented ROI: A 25–55% reduction in unplanned downtime; 10–30% savings on total maintenance costs.
\nWhat's needed: Sensors installed on equipment, real-time data collection, configured alert thresholds.
\nDefinition: The date of a future failure is predicted using a mathematical model (statistical or machine learning) fed with historical and real-time data.
\nDifference from the conditional: The CBM says, \"The equipment is in poor condition; take action soon.\" The PdM says, \"The equipment will break down in 3 to 5 days with an 87% probability.\"
\nWhat's needed: At least 12–18 months of historical data per piece of equipment, expertise in modeling, and teams capable of acting on the predictions.
\nThe Reality on the Ground in 2026: True predictive maintenance (machine learning + physical models) is now accessible to large companies and mid-sized enterprises with dedicated data teams. For small and medium-sized businesses, condition-based maintenance offers 80% of the benefits with only 20% of the complexity.
\n| Criterion | Corrective | Preventive | Conditional | Predictive |
|---|---|---|---|---|
| Implementation cost | Very low | Low | Medium | High |
| Operating cost | Very high | Medium | Low | Medium |
| Technical complexity | None | Low | Medium | High |
| Data required | None | Scheduled | Real-time | Historical + RT |
| ROI timeframe | Immediate | 12–18 months | 8–14 months | 18–36 months |
| Predictability | None | Good | Good | Excellent |
| Suitable for SMEs | Yes | Yes | Yes | Sometimes |
Condition-based maintenance relies on physical measurements. Here are the most commonly used sensors, ranked by ROI:
\nWhat we detect: Rotational imbalance, shaft misalignment, bearing damage, pump cavitation, gear wear.
\nApplications: Electric motors, centrifugal pumps, compressors, fans, conveyors.
\nEarly warning signs: Increase in the overall vibration level (RMS), appearance of characteristic harmonic frequencies, increase in kurtosis (impulsivity).
\nSensor cost: €50 (basic industrial model) to €500 (broadband + ICP).
\nTime to Failure: Detection 2 to 12 weeks before bearing failure.
\nWhat is detected: Abnormal overheating of motors, transformers, electrical connections, bearings, and brakes.
\nApplications: Electrical panels, motors, bearings, cooling systems.
\nWarning signs: Operating temperature rises above the established reference value.
\nSensor cost: €20 (PT100 contact probe) to €2,000 (fixed thermal imaging camera).
\nWhat we detect: Load imbalance, insulation degradation, abnormal harmonics, difficult startup.
\nApplications: Induction motors, servo motors, drive systems.
\nAdvantage: No mechanical installation required—the measurement is non-intrusive. Ideal for equipment that is difficult to access.
\nWhat we detect: Compressed gas leaks, electric arcs, bearing degradation under low load, lubrication issues.
\nApplications: Compressed air systems, high-voltage electrical cabinets, low-speed bearings.
\nTypical ROI: An ultrasonic compressed air audit typically identifies 15 to 30% of leaks—resulting in immediate savings on compressor electricity consumption.
\nWhat is detected: Particle contamination, viscosity degradation, presence of water, wear particles.
\nApplications: Gear reducers, gearboxes, turbines, compressors.
\nIn-line sensors: Enable continuous monitoring without sampling, with automatic alerts for particles or dielectric substances.
\nList your equipment and evaluate each item based on:
\nFocus CBM sensors on equipment with high criticality and progressive failures.
\nFor each piece of critical equipment, define which parameters to measure. Example for a centrifugal pump:
\nThe sensors connect to the Eziwan gateway via RS-485/Modbus RTU for standard industrial sensors, or via 4–20 mA outputs for process transmitters. The gateway transmits all measurements to the cloud platform in real time.
\nDuring commissioning, record the reference values for each parameter on new equipment or equipment in good condition. These reference values are used to:
\nToo sensitive = false alarms that discourage teams. Not sensitive enough = missed failures. Calibrating the thresholds requires 2 to 4 weeks of observation under normal conditions to fine-tune them.
\nEziwan allows you to adjust thresholds from the cloud platform without on-site intervention.
\nA CBM alarm is only useful if it triggers a planned action in the CMMS. The Eziwan REST API allows you to automatically create a work order in your CMMS (SAP PM, Infor EAM, Hive Maintenix) as soon as an alarm is triggered.
\nBackground: 800-kW gearbox, replacement cost €180,000, delivery time 6 weeks.
\nBefore CBM: 2 catastrophic failures in 4 years. Each failure = 6 weeks of partial downtime = €420,000 in lost production.
\nAfter CBM (vibration + temperature + oil analysis): Detection of gradual deterioration 8 weeks before failure. Repair scheduled during a planned shutdown. Cost of preventive repair: €28,000 vs. €180,000 for catastrophic replacement.
\nROI: 9 months.
\nBackground: 12 gearmotors on a critical production line. Preventive maintenance at 3,000 hours (routine oil change + inspection).
\nAfter CBM (current + vibration): Of the 12 gearmotors monitored, CBM made it possible to:
\nROI: 11 months.
\nFor an industrial SME (fewer than 50 pieces of equipment):\nStart with condition-based maintenance on your 5 to 10 most critical pieces of equipment. The investment is affordable, the ROI is quick, and the complexity is manageable even without a dedicated data team.
\nFor a mid-sized or large company:\nCondition-based maintenance remains the foundation. For the most critical equipment with sufficient historical data, supplement this with predictive models (starting with 2 to 3 priority pieces of equipment).
\nWhat we see in 2026: The majority of French manufacturers that have truly improved their maintenance performance have done so using IoT-based condition-based maintenance—not through complex ML projects. The ROI is measurable in less than a year.
\nWhat is the difference between predictive maintenance and condition-based maintenance (CBM)?\nCondition-based maintenance triggers an action when a threshold is exceeded (e.g., temperature > 85°C → immediate alert). Predictive maintenance analyzes trends over time to anticipate deterioration before the critical threshold is reached (e.g., temperature has been rising by 2°C per week for the past 3 weeks → schedule an intervention in 2 weeks). Condition-based maintenance is easier to implement, while predictive maintenance offers a longer lead time for intervention.
\nWhat type of sensor is most useful for implementing condition-based maintenance?\nFor motors and pumps: the current sensor (current transformer on the power cable) is the most versatile—it detects overloads, hard starts, and mechanical degradation without requiring any modifications to the equipment. For mechanical transmissions (gearboxes, bearings): the accelerometer vibration sensor. These two types of sensors cover 80% of preventable failures in industry.
\nThe issue of the location of industrial data evolved from a technical debate into a major regulatory challenge in 2025–2026. With the gradual implementation of NIS2, new GDPR sanctions on transfers outside the EU, and growing awareness of the risks associated with the U.S. CLOUD Act, French industrial companies must know where their OT/IoT monitoring data is hosted.
\nThis article explores why hosting in France has become a non-negotiable selection criterion for many manufacturers, and what that means in practical terms for your choice of IIoT solution.
\nThe industrial data generated by your IoT gateways, PLCs, sensors, and SCADA systems covers a wide range:
\nTaken together, these data points form a detailed map of your industrial infrastructure: its production capacity, vulnerabilities, and failure modes. If they fall into the wrong hands—competitors, hostile state actors, cybercriminals—the consequences could be severe.
\nSo the question is not \"Is my data sensitive?\" but \"Who has access to it, and under which jurisdiction?\"
\nSince 2018, the Clarifying Lawful Overseas Use of Data Act (CLOUD Act) has required U.S. companies to provide U.S. federal authorities with the data they host—even if that data is physically stored in Europe.
\nIn practical terms, this means that if you use AWS, Microsoft Azure, or Google Cloud, your business data can be accessed by the FBI or the NSA, even if your servers are located in Paris or Frankfurt, without you necessarily being notified, and without any effective legal recourse under European law.
\nWhen it comes to industrial data, this risk is particularly concerning:
\nBoth the European Commission and ANSSI have recommended avoiding service providers subject to the CLOUD Act when handling sensitive data. NIS2 reinforces this recommendation by making it a de facto requirement for critical entities.
\nNIS2 does not explicitly require that all data be hosted in France or the EU. However, several of its requirements indirectly lead to this:
\nArticle 21 of NIS2 requires supply chain risk management, including cloud service providers. This involves a formal assessment of each cloud provider: Where is it domiciled? Under which jurisdiction can its data be seized? What security certifications do they hold?
\nFor critical entities (CE)—which include many companies in the energy, water, transportation, healthcare, and digital infrastructure sectors—this assessment must be documented and defensible in the event of an ANSSI audit.
\nNIS2 imposes very short notification deadlines: 24 hours for the initial alert, 72 hours for the incident report. To meet these deadlines, you must have immediate access to audit logs, connection logs, and monitoring data. If this data is hosted by a U.S. service provider subject to legal procedures, you may not be able to access it in a timely manner.
\nNIS2 requires a business continuity plan that includes the resilience of information systems. A cloud service provider whose operations could be compromised by a U.S. court order (such as an injunction or asset freeze) poses an unacceptable continuity risk for critical entities.
\nFor critical entities, NIS2 penalties can reach 10 million euros or 2% of global revenue. Senior executives are also held personally liable. In this context, choosing “cheap but risky” hosting is no longer economically rational.
\nThe GDPR applies to personal data—which may include business data if it can be used to identify a natural person. Typical examples include:
\nFor this data, the GDPR prohibits any transfer outside the European Economic Area without an adequate protection mechanism (Standard Contractual Clauses, Binding Corporate Rules, etc.). Since the Privacy Shield was invalidated in 2020 (Schrems II ruling), transfers to the United States have been particularly vulnerable from a legal standpoint.
\nHosting in France eliminates any ambiguity: the data remains within the EEA, under GDPR jurisdiction, without the need to justify any data transfer mechanisms.
\nNot all French hosting providers are created equal. For a mission-critical industrial IoT infrastructure, look for these certifications:
\nThe gold standard for information security certification. Essential. Requires a documented Information Security Management System (ISMS) that is audited annually.
\nMandatory for health data (pharmaceuticals, hospitals, medical devices). ANSSI/MiPih standards.
\nThe ANSSI certification for trusted cloud services. The highest security level available for the French cloud. Recommended for OIVs and NIS2-essential entities. Current providers: OVHcloud, Outscale (Dassault Systèmes), Oodrive.
\nList of service providers certified for sensitive information systems.
\nWarning: Some service providers advertise \"hosting in France\" even though they are subsidiaries of U.S. companies subject to the CLOUD Act. Insist on a written confirmation that the service provider is not subject to any extraterritorial law that would allow access to your data without notification.
\nThe 12 OIV sectors in France (energy, water, transportation, food, finance, healthcare, etc.) have had specific cybersecurity obligations since the 2013 Military Programming Act (LPM). For these sectors, hosting monitoring data in certified French data centers is not an option—it is a contractual requirement of ANSSI.
\nWith NIS2, the scope expands significantly:
\nAn SME that is a subcontractor for Airbus, Dassault Aviation, or a pharmaceutical company may be contractually required to host its data in a manner that complies with the client’s requirements. Major industrial groups are increasingly including these clauses in their supplier requests for proposals.
\nHere are 5 questions to ask your current or future IIoT provider:
\n1. Where is my data physically hosted?\nAsk for a specific data center address, not just “in Europe.” “Europe” hosting could mean Ireland (Amazon), the Netherlands (Microsoft), or Finland (Google)—all of which are subject to the CLOUD Act.
\n2. Is the parent company subject to the CLOUD Act?\nIf your service provider is a subsidiary of a U.S. company, it is subject to the CLOUD Act regardless of where its servers are located.
\n3. What security certifications do you have?\nISO 27001 at a minimum. SecNumCloud if you are an OIV or a NIS2-designated critical entity.
\n4. Have you signed a GDPR Data Processing Agreement (DPA)?\nThis is required whenever personal data is processed (which is often the case with access logs).
\n5. Can you provide me with a recent penetration test report?\nReputable service providers publish summaries of their penetration tests or share them under an NDA.
\nThe Eziwan platform is hosted exclusively in France by ISO 27001-certified service providers. We are a French company (an SAS under French law) and are not subject to any extraterritorial laws that would allow access to your data without your consent and without a French court order.
\nOur concrete commitments:
\nFor NIS2 critical entities and OIVs, we can provide a comprehensive package that includes the security policy, certifications, and contractual SLAs tailored to regulatory requirements.
\nBy 2026, the question “Where is my industrial data stored?” had become just as important as “Is my equipment redundant?” or “Do I have a backup of my PLC configurations?”
\nThe risks are real and well-documented:
\nThe good news is that high-performance, affordable sovereign hosting solutions are available in France. It’s no longer a matter of choosing between security and convenience—modern IIoT platforms hosted in France offer the same features as their U.S. counterparts, with the added assurance of digital sovereignty.
\nThe location of the data center is not enough: industrial data travels through an entire chain that must be evaluated link by link.
\n| Component | Question to Ask | Point of Concern |
|---|---|---|
| SIM Card / Carrier | Where does mobile data pass through (APN)? | A public APN routes data through the open Internet; a private APN keeps the data within the carrier’s network |
| Gateway / router | Does the firmware and its telemetry data get sent to a third-party cloud? | Some Asian manufacturers require the use of their own management cloud |
| Transport | Is encryption end-to-end (VPN, TLS)? | A tunnel terminating at an intermediary creates a point of interception |
| Cloud platform | Who is the ultimate host, and which jurisdiction’s laws apply? | A French interface on AWS remains subject to the CLOUD Act |
| Backups | Where is the data replicated? | Backups are sometimes stored in another jurisdiction |
| Support | From where do support teams access the data? | Offshore support = de facto access from outside Europe |
This end-to-end audit takes half a day and helps you avoid unpleasant surprises during a customer security questionnaire or a NIS2 audit.
\nIs all industrial IoT data subject to the GDPR?
\nThe GDPR applies to personal data—typically location data linked to identifiable vehicles, access logs containing personal identifiers, or production data linked to identifiable operators. Purely process-related data (such as temperatures, pressures, and flow rates from an anonymized line) is not personal data. However, VPN access logs (including technicians’ identities) and geolocation data for mobile assets are indeed personal data subject to the GDPR.
\nDoes the U.S. CLOUD Act apply to a cloud service provider based in Europe?
\nYes, if that service provider is a subsidiary or a company subject to U.S. law (headquartered in the United States, listed on the NYSE or Nasdaq, or part of a U.S. corporate group). AWS Europe (Frankfurt), Azure Europe, and Google Cloud EU are all entities subject to the CLOUD Act through their U.S. parent companies. Only hosting providers governed exclusively by French or European law (OVHcloud, Scaleway, 3DS Outscale, Outscale) fall outside the scope of the CLOUD Act.
\nDoes NIS2 explicitly require hosting in France or the EU?
\nNIS2 does not explicitly require a specific country of hosting, but mandates “appropriate technical and organizational measures,” including supply chain security and data protection. For OIVs (Operators of Vital Importance) governed by the LPM, the SGDSN often requires hosting on SecNumCloud-certified infrastructure—which effectively excludes non-European clouds for the most sensitive data.
\nWhat is the SecNumCloud certification, and who can obtain it?
\nSecNumCloud is ANSSI’s certification framework for “trusted” cloud service providers. Qualified providers must, among other things, guarantee immunity from non-European laws (no CLOUD Act), ensure that data is stored in France, and maintain audited security standards. As of the end of 2025, SecNumCloud-certified providers include OVHcloud, Outscale (3DS), and a few others.
\nCan a manufacturer require its end customer to host its data in France?
\nYes, through contractual provisions (SLA, DPA—Data Processing Agreement). In industrial B2B contracts, particularly in regulated sectors (defense, energy, water), it is common to contractually require that data be hosted in France or the EU. Compliance with these clauses can be verified through annual audits.
\n