In a Nutshell: What to Take Away from This Comparison​

Before getting into the details, here are the key takeaways for decision-makers who are pressed for time:

• Coverage: The four carriers (Orange, SFR, Bouygues, Free) now cover 99% of the population with 4G thanks to the 2018 New Deal Mobile. The difference lies in rural areas and the size of the territory, where Orange maintains a slight lead.
• Pricing: Bouygues and SFR are generally the most aggressive on volume plans; Orange charges a coverage premium.
• Resilience: No single-carrier SIM card covers 100% of a multi-site network. The multi-carrier SIM (multi-IMSI / eUICC) automatically switches to the best network and eliminates single-carrier dead zones.
• 2026–2028 Deadline: 2G will be shut down (Orange will shut down its network between September 22 and October 20, 2026), and 3G will follow around 2028. Any new deployment must be LTE-M / NB-IoT / 4G at a minimum, or it will quickly become obsolete.
• Security: For critical infrastructure (NIS2), a private APN + VPN is no longer an option but a prerequisite.

What is an M2M SIM card, and how does it differ from a consumer SIM card?​

An 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:

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.

Key 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.

Mobile Coverage in France in 2026: What the ARCEP Data Shows​

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.

4G: Everyone Covers More Than 99% of the Population​

Thanks 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:

• Area coverage (rural areas, mountainous regions, secondary roads), where Orange maintains a lead.
• Indoor coverage / signal quality, now rated by ARCEP on a three-tier scale: very good, good, limited.
• Remaining dead zones, addressed by the targeted coverage program (several thousand shared cell towers).

Resource Sharing: The SFR/Bouygues “Crozon” Agreement​

An 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.

Key Frequency Bands for the IoT​

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.

⚠️ End of 2G and 3G: The Deadline That Makes Networks Obsolete​

This is the most underestimated aspect of an IoT deployment in 2026, and it deserves its own section.

• 2G: Orange will shut down its 2G network between September 22 and October 20, 2026. Other carriers are following a similar schedule. ARCEP even plans to eliminate the requirement to map 2G coverage, a sign that the technology is reaching the end of its life cycle.
• 3G: scheduled shutdown around 2028.

Direct 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.

What should I do?

• For any new deployment: require 4G (LTE Cat-1 / Cat-1 bis) or low-power IoT LTE-M / NB-IoT modules, which will continue to be supported well beyond 2030.
• For existing 2G/3G infrastructure: plan for hardware replacement before the deadline. An LTE-M/NB-IoT-compatible SIM card is not sufficient if the modem is not compatible.
• Prioritize SIM cards for which the carrier explicitly guarantees long-term support for LTE-M and NB-IoT.

Eziwan Tip: Eziwan gateways and SIM cards support 4G/LTE-M with fallback, designed to withstand these outages without requiring on-site intervention.

M2M Operators in France: An Overview for 2026​

Orange Business (M2M Data / Orange IoT)​

Orange is the incumbent carrier with the most extensive coverage, particularly in rural areas and overseas territories.

M2M Plans:

• Flux M2M Lite: data only, plans ranging from 1 MB to 2 GB/month
• Flux M2M Pro: data + SMS + voice, private APN available
• Orange IoT Suite: SIM fleet management + connectivity + API

Key Strengths:

• Most extensive 4G coverage, with a lead in rural and outlying areas
• Nationwide LTE-M network deployed for low-power IoT
• DOM/COM coverage (Réunion, Martinique, Guadeloupe, the Antilles, etc.)
• Enterprise SLA with up to 99.9% availability
• GSMA member for industrial eSIM profiles
• Independent network (not shared): suitable as a “second carrier” in a failover scenario

Weaknesses:

• Premium rates: often 20–40% higher than SFR and Bouygues
• M2M contracts typically last 24–36 months
• Minimum order quantities can be high (≈100 SIM cards)

Estimated rates (data only, excluding add-ons):

SFR Business (SFR IoT)​

SFR offers competitive M2M plans, providing good value for money on large-scale deployments and a popular pooling system.

M2M Plans:

• SFR IoT Connect: M2M data connectivity
• SFR IoT Platform: fleet management + APIs + alerts
• Pooled Plans: a shared total data allowance across all SIM cards under the contract

Key strengths:

• Competitive rates (often 15% to 25% lower than Orange for average volumes)
• Pooling: ideal when usage varies from one SIM to another
• 4G network comparable to Orange’s, with high-performance 5G in urban areas
• Well-documented fleet management API

Weaknesses:

• Coverage slightly behind Orange in very rural areas
• Network shared with Bouygues (“Crozon”) in sparsely populated areas: SFR↔Bouygues failover is not very effective in these areas
• M2M support is sometimes less responsive than in the Enterprise segment

Estimated rates:

Bouygues Telecom for Business (IoT)​

Bouygues has significantly improved its coverage and often offers the lowest rates on the market for large data plans.

M2M Offerings:

• Bouygues Telecom IoT: Data SIM, SMS, voice
• FleetMap: SIM fleet management tool
• Partnerships with integrators for major IoT platforms

Strengths:

• Very competitive prices, often the lowest for large volumes
• Full 4G coverage, “Crozon” network sharing with SFR in sparsely populated areas
• Volume-based pricing starting at ~50 SIM cards
• Good level of service for small and medium-sized businesses

Weaknesses:

• More limited presence in the French overseas departments and communities
• Network shared with SFR in sparsely populated areas (same concern regarding failover)

Estimated rates:

Objenious / LoRaWAN (Bouygues)​

For low-power, low-data-rate applications (remote water/gas meter reading, asset tracking, environmental sensors), LoRaWAN is an alternative to cellular networks:

• National LoRaWAN network covering most of the population
• Extremely low power consumption: several years on a single battery
• Limitation: not suitable for video, high data rates, or frequent OTA updates

Note: 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.

MVNOs and Specialized IoT Operators​

1NCE — the “lifetime” SIM card with a one-time fee​

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.”

For:

• Very low-power deployments (sensors, remote meter reading, asset tracking)
• Virtually zero OPEX after purchase; predictable costs over 10 years
• OpenVPN tunnel included, along with a management portal and API
• Industrial (ruggedized) and eSIM/eUICC versions available (for a small additional fee)

Cons:

• 500 MB lifetime limit: insufficient for video or frequent OTA updates (top-up: ~€12 for 500 MB)
• Limited data speed (up to 1 Mbit/s)
• No dedicated private APN, unlike with enterprise carriers
• Support is primarily text-based, except for the premium plan

1NCE 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.

Tele2 IoT / Telenor Connexion​

European operators specializing in IoT, with attractive multi-country offerings for international deployments and mature fleet management.

Arkessa / ZARIOT / Transatel / Onomondo​

eUICC / 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.

Multi-carrier SIMs: The Solution for Critical Industries​

A 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.

How It Works​

Benefits of a Multi-Carrier SIM Card​

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.

“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.

The Eziwan SIM Card​

The Eziwan SIM is a multi-carrier M2M SIM included in our plans:

• Automatic switching between Orange / SFR / Bouygues based on the best coverage
• Secure private APN (encrypted traffic between the gateway and the Eziwan cloud, data center in France)
• Monitoring dashboard: RSRP, RSRQ, data usage in real time
• Unified billing: a single contract for the entire fleet
• No minimum volume commitment: order from 1 to 1,000 SIM cards
• LTE-M and 4G compatible: designed to transition through the phase-out of 2G/3G without disruption

Private APN: Why It's Essential in Industry​

The private APN (Access Point Name) creates a dedicated virtual network between your SIM cards and your cloud infrastructure, without going through the public internet.

Advantages of a private VPN:

• Traffic is never exposed to the public Internet (reduced attack surface)
• Fixed IP addressing possible (same IP per SIM, simplifies remote access)
• Complete network isolation from the operator’s other customers
• A key component for NIS2 compliance for critical and important entities

Public APN vs. Private APN:

Availability: Orange, SFR, and Bouygues all offer private APNs; the Eziwan SIM includes one by default.

Typical Data Usage by Use Case​

Choosing a plan that’s just the right size helps you avoid overpaying (or running out of data). Observed ranges:

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.

International Roaming: Things to Watch Out For​

For equipment deployed outside of France:

European 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”).

Outside 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.

Permanent 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.

Summary Comparison Table​

★ = Eziwan's estimated rating; adjust based on your geographic location and volume.

How to Choose: A Quick Decision Tree​

• Simple sensors, very low power consumption, fixed budget over 10 years → 1NCE or an operator’s LTE-M offering.
• Multi-site national park, rural areas, high criticality → Multi-carrier SIM (Eziwan) with private APN.
• Large urban volumes, cost optimization → Bouygues or SFR (pooling).
• Overseas territories, maximum coverage required → Orange.
• International/multi-country deployment → Global multi-IMSI SIM (Eziwan, Tele2 IoT, Onomondo).
• Video / frequent remote access → Generous data plan from a single operator or multi-operator provider; definitely not a capped “lifetime” SIM.

In any case: at least 4G/LTE-M modules (never 2G/3G alone) and a private APN whenever the data is sensitive.

FAQ — Industrial IoT M2M SIM​

Can I use a consumer SIM card in an IoT gateway? Technically, 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.

Will my 2G or 3G devices continue to work? No, 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.

What is the minimum data usage of an M2M SIM in standby mode? Without 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.

Can you switch carriers without having to reconfigure everything? With 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.

What is the difference between LTE-M and NB-IoT? LTE-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.

Do M2M SIM cards comply with French regulations? Yes. 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.

How do you manage 500 SIM cards spread across 500 locations? Through 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.

Is a multi-carrier SIM much more expensive? Generally 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.

For 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.

Further Reading​

• Blog: Dual-SIM LTE Failover — Securing Critical Connectivity
• Blog: Industrial 4G RSRP/RSRQ Monitoring — Interpreting LTE Metrics
• Blog: Industrial 4G LTE Router — Migrating from ADSL Before the End of Copper
• Blog: 5G private network — use cases and ROI for the factory
• Blog: Industrial dual-SIM operator comparison

Additional Resources​

• Industrial Connectivity — 4G LTE and M2M connectivity solutions for industry
• Eziwan Connectivity — M2M SIM plans and managed connectivity for industrial IoT
• Internet Connection for Remote Industrial Sites — Connect a site without fixed infrastructure via 4G/LTE
• Eziwan Industrial Solutions — comprehensive range of industrial monitoring and connectivity solutions
• Industrial IoT Gateways — multi-carrier IoT gateways with integrated SIM management

Why Use Grafana for Industrial Monitoring?​

Grafana has established itself in the industry for several reasons:

• Universal connectors: InfluxDB, TimescaleDB, PostgreSQL, Prometheus, MQTT, REST API — a data source for every stack
• Rich dashboards: time series, gauge, stat, table, heatmap, flow chart (with plugins)
• Built-in alerts: SMS, email, Slack, PagerDuty, and webhook notifications
• Access management: teams, folders, and permissions per dashboard
• Industry-specific plugins: P&ID (flowcharting), piping diagrams, and schematic diagrams

Compared to a traditional SCADA system:

Architecture: From Modbus to Grafana​

The complete stack for monitoring Modbus PLCs in Grafana:

Alternative for large volumes:

Eziwan Solution (all-in-one):

Eziwan 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.

Install Grafana + InfluxDB with Docker​

# 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:

Configuring Telegraf for MQTT​

# 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"

Create Your First Industrial Dashboard​

Panel 1: Trend Chart (Time Series)​

To view the pressure trends for a station over time:

InfluxDB (Flux) Query:

from(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:

• Type: Time series
• Y-axis unit: bar (Pressure)
• Line width: 2
• Fill opacity: 10
• Thresholds: green < 8 bar, orange 8–10 bar, red > 10 bar

Panel 2: Gauge (Instantaneous Value)​

To display the current value of a variable:

InfluxDB Query:

from(bucket: "industrie")
  |> range(start: -1m)
  |> filter(fn: (r) => r["station"] == "station1" and r["_field"] == "pression")
  |> last()

Panel settings:

• Type: Gauge
• Min: 0, Max: 16
• Unit: bar
• Thresholds: 0=green, 10=orange, 12=red

Panel 3: Metrics (KPIs)​

To view the OEE or a production counter:

InfluxDB Query:

from(bucket: "industrie")
  |> range(start: -24h)
  |> filter(fn: (r) => r["_field"] == "pieces_produites")
  |> sum()

Panel settings:

• Type: Stat
• Unit: pcs (custom)
• Color mode: Background (red if < target)

Panel 4: Multi-site Table​

To view the status of all your sites in real time:

from(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.

Configure Grafana Alerts​

Threshold Exceeded Alert​

In Grafana 10+ (Unified Alerting):

1. Open the panel → Edit → Alert
2. Create a rule:

   Condition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
   

3. Configure the notification:
   • Contact Point: Email → maintenance@usine.fr
   • Contact Point: Webhook → SMS via Twilio/OVH SMS
4. Auto-mute: 15 minutes after acknowledgment

Alert Grouping for Multi-Site Environments​

To avoid "alert storms" when multiple sites go down at the same time:

# 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'

Event Annotation​

Add automatic annotations to graphs when alarms occur:

// 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}"}))

Grafana Templates and Variables for Multi-Site Setups​

Template Variables let you create a generic dashboard that can be reused across all your sites.

Create a "site" variable​

Dashboard Settings → Variables → New Variable:

• Name: site
• Type: Query
• Data Source: InfluxDB
• Query:

  import "influxdata/influxdb/schema"
  schema.tagValues(bucket: "industrie", tag: "station")
  

Using the variable in panels​

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.

Preconfigured Grafana Dashboards for Industry​

Pumping Station Monitoring Dashboard​

┌─────────────────────────────────────────────────────────────────┐
│  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]                       │
└─────────────────────────────────────────────────────────────────┘

Multi-Site Production Dashboard​

┌────────────────────────────────────────────────────────────────────┐
│  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 → Grafana Integration​

Eziwan offers two ways to integrate with Grafana:

Mode 1: Grafana hosted on Eziwan (recommended)​

The 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:

• Preconfigured dashboards for common use cases (water, energy, production)
• Managed SMS/email alerts
• 5 years of data archiving with no configuration required
• Multi-site, multi-user, and access rights management

Mode 2: Export to Your Existing Grafana Instance​

If you already have an internal Grafana instance:

• Eziwan REST API: Query your data via GET /api/v1/variables/{id}/history
• MQTT Webhook: Eziwan publishes your data to your existing MQTT broker
• Eziwan Grafana Plugin (available upon request): plugin data source for direct connection

FAQ — Grafana for Industrial Monitoring​

Can Grafana replace a SCADA system in production? For 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.

Which database should you use to store industrial data in Grafana? InfluxDB 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.

How do I secure access to Grafana from the Internet? Place 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.

Can Grafana handle 1,000 sites and 100,000 variables? Yes, 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).

Can I display a P&ID diagram in Grafana? Yes, 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.

Further Reading​

• Blog: IIoT Predictive Maintenance — From Sensor Data to Field Alerts
• Blog: Remote Industrial Monitoring — The Complete Guide 2026
• Blog: Modbus TCP vs. RTU — Which Protocol Should You Choose?
• Blog: Solar Farm — IoT Supervision and Monitoring
• Docs: Modbus RTU Configuration on the Eziwan Gateway

Want 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.

Additional Resources​

• Modbus RTU to the Cloud — Connect your RS-485 Modbus RTU devices to the cloud
• Industrial Cloud Data Logger — Archive your Modbus data in the cloud
• Cloud SCADA — cloud-based SCADA platform with built-in dashboards
• Industrial Protocols — understanding Modbus, MQTT, OPC UA, and other protocols
• Industrial Monitoring and Remote Support — multi-site monitoring of your Modbus devices

What Is OPC-UA and Why Does It Matter?​

OPC-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).

Why OPC-UA Dominates Industry 4.0​

• Interoperability: A Siemens S7-1500 OPC-UA server can be read by any compliant client without a proprietary driver
• Information model: Data has meaning (unit, description, history), not just a value
• Native security: encryption, authentication, certificates—built into the protocol
• Compliance profiles: a lightweight subset for small embedded devices
• Pubsub & MQTT: OPC-UA Pub/Sub extension for cloud architectures (IEC 62541-14)

OPC-UA Architecture: Fundamental Concepts​

Client-Server​

The basic OPC-UA model is client-server:

• OPC-UA Server: exposed by the device (PLC, HMI, data server)
• OPC-UA Client: consumes the data (SCADA, gateway, cloud application)

A 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).

Address Space and NodeId​

The Address Space is the information tree exposed by an OPC-UA server. Each node has a unique NodeId:

NodeId Format:

• ns=2;i=1234 — namespace 2, integer identifier 1234
• ns=2;s=Station_1.Pression — namespace 2, string identifier
• ns=0;i=2258 — namespace 0 (standard), ServerStatus

Namespaces:

• ns=0: standard OPC-UA namespace (types, methods)
• ns=1: often the manufacturer's namespace
• ns=2+: application namespaces (your data)

Communication Methods​

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).

OPC-UA Security: The Complete Guide​

Security is one of OPC-UA's strengths—and also one of the sources of its complexity. Here are the key concepts.

Security Modes​

X.509 Certificates​

OPC-UA uses X.509 certificates for mutual client-server authentication:

Creating a self-signed certificate for testing:

# 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.

User Authentication​

In addition to machine certificates, OPC-UA supports user authentication:

• Anonymous: no authentication (if allowed by the server)
• Username/Password: application login
• Certificate: X.509 user certificate
• IssuedToken: JWT or Kerberos token

Implementing OPC-UA in Python​

The python-opcua library (or its fork, asyncua) is the go-to choice in Python.

Installation​

pip install asyncua

Python OPC-UA Client — Reading Data​

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())

OPC-UA Python Client — Subscription​

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())

Secure connection with a certificate​

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()

Implementing OPC-UA in Node.js​

The node-opcua library is the go-to choice for JavaScript/TypeScript.

npm install node-opcua

Reading Data​

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);

OPC-UA on Major Industrial Controllers​

Siemens S7-1500 / S7-1200​

The S7-1500 supports native OPC-UA server functionality starting with firmware version 2.0:

• Port: 4840 (TCP)
• Configuration in TIA Portal: Device Configuration → OPC UA → Server
• Enable the desired nodes in the Access configuration
• Authentication: Certificates or Username/Password

The S7-1200 has supported OPC-UA since firmware version 4.1.

Schneider Electric M580 / M340​

M580: OPC-UA via the BMENOC0311 module (firmware ≥ V2.0) M340: No native OPC-UA support → Modbus TCP recommended, or an OPC-UA to Modbus gateway (e.g., Kepware KEPServerEX)

Allen-Bradley / Rockwell (EtherNet/IP)​

Rockwell PLCs do not natively support OPC-UA. Options:

• KEPServerEX (Kepware): EtherNet/IP → OPC-UA bridge
• FactoryTalk Linx Gateway: OPC-UA server for the Rockwell ecosystem
• Eziwan Gateway: direct EtherNet/IP/Modbus connection, REST API exposure

Beckhoff TwinCAT 3​

TwinCAT 3 includes a native OPC-UA server via TF6100 (OPC-UA module). Configuration is performed via TwinCAT System Manager.

Wago / Phoenix Contact / Pilz​

Most modern PLCs from these manufacturers support OPC-UA. Check the firmware and enable the server in the network configuration.

OPC-UA PubSub: The Extension for the Cloud​

OPC-UA PubSub (IEC 62541-14) is the extension that makes OPC-UA compatible with cloud-based IoT architectures:

• Publisher: The device publishes its data to a Message-Oriented Middleware
• Subscriber: The cloud or SCADA system subscribes to the data stream

Supported transport protocols:

• AMQP (port 5672)
• MQTT (port 1883 or 8883) — the most widely used in IoT
• UDP Multicast (local network)

Encodings:

• JSON (human-readable, easy to debug)
• UADP (binary, compact, embedded)

Example of an OPC-UA PubSub JSON message:

{
  "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"}
  }
}

Migration from OPC-DA to OPC-UA​

If you have systems running OPC-DA (OPC Classic, Windows DCOM), migrating to OPC-UA offers:

• Elimination of the Windows/DCOM dependency
• Compatibility with Linux, Raspberry Pi, and Linux-based PLCs
• Encryption (not available in OPC-DA)
• Direct internet access (not possible with DCOM without a complex VPN)

Migration 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.

OPC-UA with the Eziwan Gateway​

The Eziwan Gateway includes an OPC-UA client capable of connecting to the OPC-UA servers on your devices:

• Siemens S7-1500 OPC-UA connection (port 4840)
• Connection to any IEC 62541-compliant OPC-UA server
• Support for None, Sign, and SignAndEncrypt security modes
• Configuration of NodeIDs in the cloud interface (automatic browsing of the address space)
• Data transmission to the Eziwan cloud platform via MQTT/TLS

Key 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.

FAQ — OPC-UA​

Is OPC-UA more complex than Modbus? Yes, 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.

Does port 4840 need to be open on my firewall? In 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.

Can OPC-UA replace MQTT in an IoT architecture? OPC-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).

What performance can you expect from an embedded OPC-UA server? A 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.

Are there any free OPC-UA servers available for testing? Yes: 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.

Further Reading​

• Blog: OPC-UA and MQTT — How to Combine the Two on an Industrial Gateway
• Blog: Secure Remote Access to PLCs and SCADA — VPN, Zero-Trust, and NIS2
• Blog: Connecting a Siemens S7 PLC to the Cloud — Technical Guide
• Blog: IEC 62443 — A Practical Guide to Industrial Cybersecurity
• Blog: Modbus TCP vs. RTU — A Comprehensive Comparison for Industrial IoT

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.

Additional Resources​

• OPC UA to MQTT — publish OPC UA data to a cloud-based MQTT broker
• Industrial Protocols — comparison of OPC UA, Modbus, MQTT, and other protocols
• Industrial IoT Gateway — choosing an OPC UA-compatible gateway
• Modbus TCP to the Cloud — monitoring Modbus TCP PLCs from the cloud
• Cloud SCADA — modern SCADA architecture with OPC UA and cloud connectivity

Why connect your M340/M221 to the cloud?​

Schneider 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.

But their native communication capabilities are limited:

• No native cloud connectivity
• Remote access often restricted to a costly MPLS VPN
• No long-term data logging without an on-premises SCADA server
• Alerts are either nonexistent or only local (indicator lights, horns)

The 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.

Modbus Compatibility of Schneider Electric PLCs​

Modicon M221​

The 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.

Accessible registers:

• %MW0 to %MW255 — memory words
• %QW — analog outputs
• %IW — analog inputs
• %M — memory bits (coils 0–255)

Modbus Slave Configuration on the M221:

In EcoStruxure Machine Expert - Basic:

1. Configuration → Modbus Serial or Modbus TCP
2. Slave address: 1 (default)
3. Enable "Slave function" → OK

Modicon M340​

The 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.

Registers accessible via Modbus:

Modbus Address → Unity Pro Address:

• Register 400001 = %MW0
• Register 400100 = %MW99
• Register 400501 = %MW500

Modicon M580 (ePAC)​

The M580 features native Modbus TCP on its CPU Ethernet port and supports the same register tables as the M340, plus:

• Access to I/O modules via BMENOC0311 (Ethernet module)
• EtherNet/IP support
• Data Exchange capability with EcoStruxure Plant

Connection Architecture​

Option 1: Via Modbus TCP (Ethernet) — recommended​

Prerequisites:

• ETH module installed on the rack (BMX NOE 0100 for M340)
• PLC IP address configured (e.g., 192.168.1.10)
• Internal firewall allowing port 502 from the gateway's IP address

Advantages:

• No additional RS-485 wiring
• Higher throughput (up to 30 requests per second)
• Compatibility with Traffic Unity Pro (non-intrusive readings)

Option 2: Via Modbus RTU (RS-485)​

For the M221: Use the TCSMCNAM3M002P cable (RJ45 to RS-485) or the VW3A8306 adapter, depending on the model.

For the M340: 9-pin SUB-D connector on the PLC side; pins 3 (+) and 8 (-) for RS-485.

M221/M340 Serial Settings (Default):

• Speed: 19,200 bps
• Parity: none (8N1)
• Slave address: 1

Configuring the Eziwan Gateway for Schneider​

Once the gateway is connected, you can configure it from the Eziwan cloud interface with just a few clicks.

Add a Modbus Device​

1. Access Flotte → Site → + Équipement
2. Select Modbus TCP or Modbus RTU
3. Enter:
   • IP: 192.168.1.10 (or your M340’s address)
   • Port: 502
   • Slave ID: 1

Configure the variables to be read​

Conversion engineering: Apply a multiplier if the PLC returns a raw value (e.g., ×0.01 to convert from 1500 to 15.00 bar).

Recommended polling interval​

What You Get in the Cloud​

Real-Time Dashboard​

As soon as the gateway connects for the first time, data is transmitted in real time to the Eziwan dashboard:

• Trend graphs for 1 hour, 24 hours, 7 days, and 30 days
• Configurable gauges and indicators
• Multi-site tables to compare your installations
• CSV/Excel export for reporting

Alert System​

Set up specific alerts for each variable:

Alert: 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

Long-Term Historical Analysis​

All data is archived for 5 years as standard, at no additional cost. You can:

• View production history for years N-1 and N-2
• Identify gradual deterioration (e.g., a pump drawing more current)
• Generate compliance reports (water, energy, pharmaceuticals)

Case Study: M340 Pumping Station​

Background: A local government agency manages 12 pumping stations equipped with 2020 M340 BMX P34 units. Current maintenance: 3 field rounds per week, 2 technicians.

Deployed Configuration:

• 12 × Eziwan Gateway (Modbus TCP, SFR Business SIM)
• Variables read per station: well level, flow rate, discharge pressure, motor current, operating hours, faults (12 variables)
• Polling interval: 5 seconds for flow rate/pressure/failures, 1 minute for level/meters

Results after 6 months:

• On-site inspections: 3/week → 1/week (-67%)
• Incidents detected before a shutdown: 4 (overheated pump, stuck valve, seized float)
• Estimated savings: €41,000/year (travel costs + avoided corrective maintenance)
• ROI on equipment + subscription: 5 months

Migration from SoMachine / Unity Pro​

If 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.

If you also want to write commands (setpoints, commands) from the cloud:

• Use Function Codes FC05 (Write Single Coil) and FC06 (Write Single Register)
• Configure access rights in the Eziwan gateway (multi-factor authentication)
• Create register ranges specifically dedicated to remote commands (e.g., %MW200-MW220)

EcoStruxure Compatibility​

The Eziwan gateway is compatible with EcoStruxure in several ways:

Alongside EcoStruxure Plant​

The gateway reads the same registers as your EcoStruxure SCADA system, without any interference. Ideal for adding:

• Centralized multi-site monitoring
• Mobile access for field technicians
• SMS/email alerts (often missing in the base EcoStruxure system)

Phased Replacement​

If your EcoStruxure Plant license is nearing the end of its lifecycle, you can migrate in phases:

1. Deploy the Eziwan gateway in parallel
2. Validate the data for 4–8 weeks
3. Switch the primary monitoring to Eziwan
4. Reduce the EcoStruxure license to the scope that is actually needed

Cloud Connection Comparison: M221 vs. M340 vs. M580​

FAQ — Connecting the M340/M221 to the Cloud​

Do I need to modify the SoMachine/Unity Pro program? No. 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.

My M340 already has a Unity Pro SCADA system—is it compatible? Yes. 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).

Can I monitor analog input modules (BMX AMI 0410)? Yes. 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? Yes. 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.

Is it compatible with the Zelio Logic product line? The 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.

Getting Started with Your POC​

Do you have an M340, M221, or M580 on-site and want to verify the cloud connection?

Eziwan offers a free 30-day POC that includes:

• 1 pre-configured gateway shipped within 48 hours
• Onboarding guided by our technical team
• Dashboards configured according to your specifications
• No commitment, no credit card required

Start the free POC → | Calculate your ROI →

Further Reading​

• Blog: Connecting a Siemens S7 PLC to the Cloud — Technical Guide
• Blog: Secure Remote Access to PLCs and SCADA Systems — VPN and NIS2
• Blog: Modbus TCP vs. RTU — Which Protocol Should You Choose?
• Docs: Siemens S7-1200/S7-1500 compatibility
• Blog: IIoT predictive maintenance — from sensor data to alerts

Do you use other Schneider Electric product lines (Altivar, Easergy, PowerLogic)? Contact us to verify compatibility with your specific equipment.

Additional Resources​

• Schneider PLC Remote Access — secure remote access to Schneider M340, M221, and M580 PLCs
• Connect a PLC to the cloud — connect any industrial PLC to the cloud
• Modbus TCP to the cloud — monitoring via Modbus TCP from the cloud
• Industrial Remote Access — VPN and zero-trust architecture for industrial sites
• Industrial Monitoring and Remote Support — centralized monitoring of your Schneider PLCs

This guide compares the four main wireless technologies used in industrial IoT in France, with practical recommendations for each use case.

Overview: 4 Technologies for 4 Different Needs​

Before getting into the details, here’s the gist in one sentence for each technology:

• LoRaWAN: for low-power, battery-powered sensors in open environments over long distances (1 to 15 km)
• Zigbee: for dense indoor sensor networks with mesh topologies over short distances (10 to 100 m)
• 4G LTE: for remote locations, critical equipment, long-distance WAN connections, and high-speed internet
• Wi-Fi: for locations with existing network infrastructure, mobile devices in covered areas, and local high-speed internet

Detailed Technical Comparison​

LoRaWAN in Detail​

When to Use It​

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).

Ideal industrial use cases for LoRa:

• Water, gas, and electricity meter reading in urban and suburban areas
• Monitoring environmental conditions over large areas (temperature, humidity, CO₂ in multiple buildings)
• Asset tracking using long-life GPS/motion sensors (pallets, mobile tanks)
• Monitoring of sensors in hard-to-reach areas (sewers, underground infrastructure, rural areas)
• Opening/closing detection (hatches, silo doors) over large areas

LoRaWAN Advantages:

• Exceptional battery life (5 to 10 years on an AA battery)
• Very simple infrastructure: a LoRa hub covers a radius of 5 to 15 km in rural areas
• Public networks available in France (Bouygues Telecom LoRa, Objenious, Sewan, CityMesh)
• Very low cost per node (€10 to €50 for a single sensor)

LoRaWAN Limitations:

• Very low data rate: cannot send images, video streams, or more than a few bytes per message
• High latency: the downlink (cloud → sensor) can take 5 to 10 seconds — not suitable for real-time control
• Regulatory limitations: the 868 MHz band is limited to a 1% duty cycle (approximately 36 seconds of transmission per hour) — this restricts the frequency of transmissions
• In dense indoor environments (thick concrete, basements), the range drops to a few dozen meters

Typical Industrial LoRa Architecture:

Zigbee in Detail​

When to Use It​

Zigbee 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.

Ideal Industrial Use Cases for Zigbee:

• Building Automation Systems (BAS): lighting, blinds, HVAC
• Monitoring of environmental conditions in high-density environments (warehouses, cleanrooms)
• Networks of occupancy sensors, door sensors, and zone-based energy meters
• Light industrial automation as a replacement for wired systems in commercial buildings

Zigbee Advantages:

• Mesh architecture: Zigbee nodes relay data from distant nodes, eliminating dead zones
• Low battery consumption (1 to 5 years)
• Large ecosystem of standardized and interoperable sensors (Matter standard since 2022)
• Sufficient data rate for real-time measurements (alarms, status updates)
• Very high node density (thousands on a single network)

Zigbee Limitations:

• Limited range: 10 to 100 m per hop (mesh networks compensate for this, but require a sufficient number of intermediate nodes)
• Coordination required: every Zigbee network requires a coordinator (Zigbee hub or gateway)
• 2.4 GHz = interference with Wi-Fi, Bluetooth, and microwave ovens in dense industrial environments
• Not suitable for long-distance connections between distant buildings

4G LTE in Detail​

When to Use It​

4G 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.

Ideal industrial use cases for 4G:

• Remote sites (pumping stations, cabins, antennas, weather sensors) without a wired connection
• Backup connection for critical industrial sites (fiber-to-4G failover)
• IoT gateways that transmit field data to the cloud (Modbus monitoring, OPC-UA)
• Remote VPN access for remote maintenance of industrial equipment
• Vehicles and mobile equipment (refrigerated trucks, construction machinery)
• Rapid deployments where installing a network cable is impossible or too costly

Benefits of Industrial 4G LTE:

• Nationwide coverage: 99.2% of French municipalities (including remote rural and industrial areas)
• Sufficient bandwidth: 5 to 50 Mbps is more than enough for monitoring and remote maintenance
• No local infrastructure: no cabling, no switches, no access points to maintain
• Dual SIM: automatic switching between carriers to maximize availability
• Plug-and-play: an industrial 4G gateway is up and running in less than an hour

4G LTE Limitations:

• Higher cost per node: a 4G industrial gateway costs €300 to €600; a SIM subscription costs €10 to €20 per month
• Power consumption: requires a mains power supply (not suitable for battery-powered sensors)
• Latency: 30 to 100 ms (acceptable for monitoring, but not for demanding real-time control)
• Dead zones: some very remote rural areas with no coverage (can be mitigated with an external antenna or satellite)
• Dependence on the carrier: availability depends on the mobile network (acceptable with dual-SIM)

Wi-Fi in Detail​

When to Use It​

Wi-Fi is suitable for sites with existing network infrastructure, devices requiring high-speed connectivity, and areas with full coverage from access points.

Ideal Industrial Use Cases for Wi-Fi:

• Connecting sensors or industrial equipment in a factory with existing Wi-Fi coverage
• On-site vehicles or mobile equipment (forklifts, AGVs) in areas with Wi-Fi coverage
• IP surveillance cameras (requires high-speed Wi-Fi)
• Local SCADA in real-time monitoring mode (latency < 10 ms)

Benefits of Industrial Wi-Fi:

• Very high data rates (supports video streaming and fast firmware updates)
• Infrastructure often already in place in modern factories
• Very low latency (1 to 10 ms) — suitable for moderate real-time applications
• Many industrial devices with built-in Wi-Fi (HMIs, collaborative robots)

Limitations of Industrial Wi-Fi:

• Limited range: 30 to 150 m per access point (AP); requires a mesh network to cover large areas
• Interference: The 2.4 GHz band is congested in dense industrial environments (motors, radio frequencies, CNC machines)
• High power consumption: not suitable for battery-powered sensors
• Expensive infrastructure: industrial access points (Cisco, Aruba, Extreme Networks) = €500 to €3,000 per AP
• Complex network management: roaming for mobile devices requires Wi-Fi expertise

Decision Guide: How to Choose?​

Decision Tree​

Recommendation Table by Sector​

Hybrid Architecture: The Best of Both Worlds​

In practice, mature industrial IoT deployments use a combination of technologies, selected based on the nature of each piece of equipment.

Example of a hybrid architecture: a 10-hectare industrial site

The 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.

5-Year Cost Comparison (Deployment of 100 Sensors)​

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.

Conclusion​

There is no single "best" universal IoT technology. The choice depends on three fundamental criteria:

1. Range: short (Zigbee), medium-to-long (LoRaWAN), very long or WAN (4G LTE)
2. Power consumption: long-lasting battery life (LoRaWAN > Zigbee > Wi-Fi), AC power (all)
3. Data rate: sensor data (LoRaWAN and Zigbee are sufficient), monitoring and remote access (4G LTE and Wi-Fi required)

The 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.

Need help choosing the right architecture for your project? Contact our team of engineers for a free assessment of your situation.

FAQ​

Can LoRaWAN and 4G LTE be combined at the same site? Yes—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.

Is LoRaWAN reliable for critical industrial monitoring? LoRaWAN 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.

What is the difference between LoRa and LoRaWAN? LoRa 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.

Can Zigbee be used in an industrial environment with electromagnetic interference? Zigbee (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.

Is industrial Wi-Fi suitable for moving machinery (AGVs, conveyors)? Wi-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.

Further Reading​

• Blog: OPC-UA, MQTT, Modbus — Choosing an Industrial Gateway
• Blog: Modbus, MQTT, OPC-UA — A Comprehensive Comparison of Industrial Protocols
• Blog: M2M IoT SIMs — 2026 Comparison of French Operators
• Blog: Choosing an Industrial IoT Gateway — 9 Criteria
• Blog: Remote Industrial Monitoring — Complete Guide 2026

Eziwan 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 →

Additional Resources​

• Industrial Connectivity — multi-protocol connectivity solutions for industrial IoT
• Industrial Protocols — guide to industrial communication protocols (Modbus, OPC-UA, MQTT, etc.)
• Industrial IoT Gateways — multi-protocol wireless and wired gateways for IIoT
• Internet Connectivity for Remote Industrial Sites — choosing the right radio protocol for sites without wired coverage
• Eziwan Industrial Solutions — comprehensive range of industrial connectivity and monitoring solutions

This 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.

Agriculture: A Fertile Ground for the Industrial IoT​

Modern 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.

What the IoT Brings to Agriculture:

• 24/7 monitoring without the need for the farmer to be present at all times
• Immediate alerts in the event of an anomaly (equipment failure, threshold exceeded)
• Historical data for optimizing practices and ensuring traceability
• Reduced losses (non-compliant milk, poor crop growth, animal mortality)
• Easier regulatory compliance (animal welfare, water regulations)

Use Case 1: Monitoring of Livestock Facilities​

Pig barns, chicken coops, dairy cattle​

Off-the-ground livestock facilities (pig barns, chicken coops, dairy barns) are particularly well-suited for IoT monitoring. The critical parameters to monitor are:

Building Climate Conditions:

• Temperature (°C) and relative humidity (%): Significant fluctuations directly impact the animals’ growth and health
• CO₂ concentration (ppm): an indicator of air quality and ventilation efficiency
• NH₃ concentration (ammonia, ppm): a hazardous gas produced by manure, regulated for animal welfare

Ventilation Equipment:

• On/off status of each fan (digital input)
• Rotational speed or damper position (0-10V or 4-20mA output)
• Power consumption per circuit (current transformer)

Feed and Water:

• Feed silo levels (ultrasonic level sensor)
• Water consumption (pulse flow meter)
• Status of automatic feeders (ON/OFF)

Compatible sensors and interfaces:

Typical alert thresholds for livestock buildings:

Use Case 2: Monitoring Milk Tanks​

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.

Failure to comply with these temperatures results in:

• Irreversible microbiological spoilage of the milk
• Refusal by the dairy to collect the milk (direct financial loss)
• Contractual penalties (quality penalties)

IoT Monitoring of the Milk Tank:

Most modern milk tanks (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) have an RS-232 or RS-485 Modbus port for monitoring. Accessible parameters include:

• Milk temperature (°C) with a resolution of 0.1°C
• Cooling compressor status
• Milk volume (if the tank has a gauge)
• Temperature history (complete curve since the last milking)

The 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.

Customer 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.

Use Case 3: Monitoring Horticultural and Vegetable Greenhouses​

Horticultural 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.

Parameters to monitor in a greenhouse:

Greenhouse equipment that can be monitored:

• Boilers and heat pumps (heating): Bosch, Vaillant, Viessmann — via Modbus or digital relays
• Fans and vents: 0-10V control or relay
• Irrigation pumps: Modbus variable-frequency drive
• Water treatment unit (UVA, reverse osmosis system): digital on/off inputs

ROI for vegetable greenhouse monitoring: For 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.

Use Case 4: Irrigation Management​

Irrigation 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.

IoT-Based Irrigation Monitoring:

• Field-specific flow meters: measurement of the volume of water applied per field or per crop (Modbus or pulse)
• Soil moisture sensors (tensiometers, TDR sensors): measure volumetric moisture and soil suction—data used to trigger irrigation
• Integrated weather stations: Potential Evapotranspiration (PET) calculated in real time, integrated with Météo France for forecast PET
• Well water meters: tracking of water volumes withdrawn for DDT reporting (regulatory requirements > 1,000 m³/year)
• Well pumps and irrigation units: monitoring of status and electricity consumption

Regulatory Compliance: Facilities 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.

Use Case 5: Storage Silos​

Grain 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.

Parameters to monitor:

• Temperature: silo temperature chains (Rolfes, GSI) with 4 to 8 probes per silo at different heights
• Moisture: grain moisture sensors, either continuous or at the silo inlet (receiving silo)
• Level: ultrasonic or pressure-based level sensors to determine stored volume
• Ventilation: status of exhaust and cooling fans, airflow (m³/h)
• Electricity consumption: automatic fan control based on temperature

Interface: Most modern silo control systems (Superchief, GSI Fan Controller, Brock NECO) have a Modbus RS-485 output or an RS-232 port.

4G Connectivity for Farms​

The 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.

Solutions for areas with poor coverage:

1. External 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.

2. Eziwan Multi-Carrier SIM: Tests all three French carriers (Orange, SFR, Bouygues) and connects to the best available signal. Significantly improves coverage in rural areas.

3. LoRa + 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.

4. Satellite 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.

Agricultural Regulations and the IoT​

Animal Welfare​

European 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:

• Continuously document compliance with regulatory thresholds
• Provide evidence during inspections by the DDPP (Departmental Directorate for Population Protection)
• Issue immediate alerts if a regulatory threshold is exceeded

Nitrates Directive​

Farms 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.

Supply Chain Traceability​

Many 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).

Costs and ROI for a Farm​

Typical Investment​

ROI for a Dairy Farm​

• Cost of a collection refusal: €600 to €2,000 (depending on volume + penalties)
• Annual risk without supervision: 1 to 2 tank incidents per year over 5 years of operation
• Annualized cost of an incident: €600 to €800 per year
• Supervision cost: €250 to €400 per year
• Net ROI: €200 to €550 per year = paid off in less than 1 year

Available Assistance​

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.

Conclusion​

Industrial 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.

For 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.

Next step: Contact the Eziwan team for a free feasibility study tailored to your farm and your type of production.

FAQ​

Is 4G available in rural agricultural areas of France? 4G 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.

Can an existing grain silo or cooperative warehouse be connected without replacing the equipment? In 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.

What regulatory requirements can IoT monitoring help document? In 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.

Further Reading​

• Blog: 4G Water and Wastewater Monitoring — Water Management for Municipalities
• Blog: ROI of Industrial IoT — Calculation and Optimization
• Blog: 4G signal monitoring — RSRP, RSRQ, and rural coverage
• Blog: M2M IoT SIM cards — comparison of French carriers in 2026

Eziwan 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 →

Additional Resources​

• Remote Irrigation Monitoring — control and monitoring of irrigation systems via IoT
• Internet Connection for Remote Industrial Sites — 4G connectivity for farms in rural areas
• Industrial Equipment Monitoring — monitoring of agricultural and storage equipment
• Industrial Connectivity — robust connectivity solutions for rural areas
• Eziwan Industrial Solutions — a range of IoT solutions tailored to primary sectors

This 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.

Current Status: The Water Remote Management Infrastructure in France​

An Aging Fleet​

Remote management of drinking water networks in France currently relies heavily on equipment installed between 2000 and 2015. The dominant technologies are:

• SOFREL S4W/S500 Modems: Deployed on a large scale by concession operators (Veolia, Suez, Saur) across water networks, these GSM/GPRS modems use the 2G/EDGE network, which is currently being phased out
• Servelec RTUs (formerly Sontay) and Lacroix Sofrel: a range of RTUs designed specifically for water systems, used at pumping and treatment plants
• Concessionaires’ proprietary systems: Each concession operator has deployed its own infrastructure (Veolia Hub Eau, Suez IntelliO) using proprietary protocols that limit the ability to take over operations directly

The 2G Shutdown: A Catalyst for Modernization​

Orange 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.

SOFREL S4W modems and other 2G/GPRS RTUs used at water towers, pumping stations, and lift stations will no longer work after these shutdowns.

This is a major opportunity to modernize by transitioning to 4G LTE solutions with a centralized cloud-based monitoring platform.

Modern Monitoring Architecture for a Drinking Water Network​

Typical Sites to Monitor​

Recommended Architecture​

Migration from Existing Systems​

Replacing a SOFREL S4W Modem​

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.

Migration Steps:

1. Preliminary Audit (1 hour remotely): identification of the Modbus registers configured on the S4W, mapping of the I/O used (digital inputs, analog inputs, relay outputs), list of current SMS recipients
2. Delivery of the pre-configured Gateway: The Eziwan Gateway is delivered with your configuration template (Modbus registers identical to those on the S4W, same alarm thresholds, same SMS recipients)
3. Physical Replacement (30–45 minutes per site): The Gateway connects to the same RS-485 wiring. The 4G SIM card is inserted and activated. The cloud connection is established automatically
4. Verification: An Eziwan technician takes remote control to validate data transmission and alerts
5. Commissioning: The site appears in the cloud dashboard with all its historical data (starting from the migration—S4W historical data is not transferred)

Compatibility: 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.

Migration 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.

Migration from a delegated system (end of DSP)​

When 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.

Eziwan's Approach to DSP Transitions:

1. Early deployment: Install the Eziwan gateways 3–6 months before the end of the DSP contract, running in parallel with the existing system
2. Parallel validation: Compare Eziwan data with data from the outgoing operator to verify consistency
3. Smooth transition: By the end of the DSP contract, the Eziwan monitoring system is already operational and validated
4. Historical data continuity: 3–6 months of historical data are already available on the Eziwan platform

Regulatory Compliance​

Self-Monitoring and ARS Requirements​

The 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):

Parameters to Monitor and Log (UPEP):

• Treated water flow rate (m³/h and m³/day)
• Turbidity of treated water (NTU) — alert threshold: > 1 NTU
• Residual chlorine content (mg/L) — alert threshold: < 0.1 mg/L
• pH (6.5 to 9.0)
• Conductivity (μS/cm)
• Temperature (°C)

Archiving Requirements:

• Minimum retention period of 5 years
• Certified UTC timestamp
• SANDRE-compatible export format for transmission to government agencies
• Access available to DDETSPP (formerly DDASS) upon request

How Eziwan Meets These Requirements:

• Minimum 10-year data retention (beyond the regulatory 5-year requirement)
• UTC timestamps on each measurement, digitally signed
• CSV and JSON exports in SANDRE format
• API access for regulatory agencies
• Configurable automatic daily and weekly reports

NIS2 Directive: Applicability to Drinking Water​

The transposition of the NIS2 Directive into French law (Law of April 16, 2024) classifies water operators into categories based on their size:

Key Entities:

• Drinking water operators serving > 50,000 people OR
• Revenue > 50 M€ OR
• Designated as OIV (Operators of Vital Importance)

Significant Entities:

• Drinking water utilities serving more than 10,000 people OR
• Revenue greater than 10 M€

NIS2 requirements relevant to remote water management:

Case Study: Water District with 80 Stations​

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.

Issues:

• 40% of stations lack automatic alarms (outages are detected through calls from residents)
• The 2G network is being phased out in the region
• NIS2 requirement (municipal district serving > 15,000 residents)
• Performance contract requiring a service availability rate of > 99.5%

Eziwan Deployment:

• 80 Eziwan gateways (1 per station) delivered pre-configured within 3 weeks
• Migration from S4W systems in 6 weeks (13 stations per week, 2 technicians)
• Configuration: 8 to 24 Modbus registers per station, SMS/email alerts
• Centralized dashboard: real-time view of all 80 stations, GIS mapping

6-Month Results:

• Unplanned service calls reduced by 68% (from 240 to 77 calls per year)
• Detection of a major leak in a discharge line (abnormal nighttime flow automatically detected at 2 a.m., repair completed at 6 a.m.)
• Documented NIS2 compliance (external audit passed)
• Estimated savings: €95,000 per year (avoided service calls + avoided damage)

Compatible Protocols and Equipment​

Water Meters​

Water Sensors​

Water Field Controllers​

Calculating ROI for a Local Government​

Costs Avoided Through IoT Monitoring​

Technician Service Calls:

• Average cost of an unscheduled service call: €180 to €350 (1.5 hours round trip + diagnosis)
• Typical reduction with Eziwan: 60 to 75% of unscheduled service calls avoided
• Example: 80 stations, 3 technicians: 240 service calls/year → 77 service calls/year = 163 service calls avoided × €250 = €40,750/year

Damage Avoided (Leaks, Failures, Overflows):

• Undetected discharge line leak: 5,000 to 50,000 m³ lost before manual detection
• Cost per m³ of treated water: €0.80 to €1.20
• Example: 1 leak of 15,000 m³ prevented = €12,000 to €18,000 per year

On-Call Duty:

• Reduction in nighttime emergency calls: -40 to 60%
• Savings on on-call premiums and overtime: €10,000 to €25,000 per year, depending on the fleet

Regulatory Compliance:

• Avoid receiving a formal notice from the ARS due to an undetected threshold violation
• Estimated cost of a documented non-compliance: €15,000 to €50,000 (urgent repairs + external audit)

Example of an ROI calculation for 80 stations​

ROI in Year 1: 80,750 − 72,000 = +8,750 € in the first year ROI starting in Year 2: 80,750 − (14,400 + 9,600) = +56,750 €/year

Funding and Available Assistance​

ERDF and Regional Allocations​

Projects 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.

Water Agencies​

The 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.

Contact your local water agency to find out about current programs and the subsidy rates applicable to your project.

Local Investment Support Grant (DSIL) and DETR​

The 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.

FAQ​

Is IoT monitoring eligible for the France Relance Plan or regional grants? Yes, 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.

Is migrating from an existing SOFREL system disruptive? No. 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.

How does the solution meet the ARS self-monitoring reporting requirements? The 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.

Conclusion and Next Steps​

Modernizing 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.

The 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.

Your next steps:

1. Audit of your current infrastructure: equipment inventory, identification of 2G modems, mapping of field controllers
2. ROI simulation: our team can prepare a customized calculation based on your infrastructure
3. Pilot project: Start with 5 to 10 pilot stations to validate the solution before a full-scale deployment

Contact the Eziwan team for a free audit of your remote water management infrastructure.

Further Reading​

• Blog: 4G Water and Wastewater Monitoring — Feedback from the Field
• Blog: GPRS to 4G Remote Meter Reading — A Practical Migration
• Blog: Modbus TCP vs. RTU — A Comprehensive Guide for Water Networks
• Blog: NIS2 Checklist — 30 Checkpoints for Local Governments
• Blog: M2M IoT SIM Cards — Operator Comparison for Rural Networks

Eziwan 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 →

Additional Resources​

• Water & Wastewater Solutions — IoT monitoring of drinking water networks for municipalities
• Water Tower Monitoring — remote management of municipal water towers and reservoirs
• Wireless M-Bus Meter Reading — automatic water meter reading via radio
• Water Tank Monitoring — real-time monitoring of levels and pressures
• Pumping Station Solution — remote monitoring and control of pumping stations

This 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.

What We're Comparing​

On-premises (traditional) SCADA: Physical 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.

Cloud-based SCADA / IIoT SaaS: A 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.

Criterion 1: Total Cost of Ownership (TCO over 3 years)​

On-Premises SCADA — Typical TCO for 10 Industrial Sites​

Cloud-Based SCADA SaaS — Typical TCO for 10 Industrial Sites​

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.

Criterion 2: Safety​

This is often the main argument put forward by advocates of on-premises solutions. Let's take a closer look at what's actually true.

What's true for on-premises solutions:​

• Data is physically located on your premises — no data is transmitted outside your premises
• No reliance on a third party for data access
• Possible isolation from the Internet (air gap)

Common misconceptions about on-premises systems:​

• "On-premises = more secure" — false in most cases. SMEs generally do not have a dedicated cybersecurity team. Their on-premises servers often run on unpatched Windows Server 2012/2016, without access monitoring or intrusion detection. An ISO 27001-certified cloud provider with a dedicated security team is generally more secure than an unmonitored server in a machine room.
• "My data never leaves the facility" — true only if you have actually isolated the SCADA server. If you access the SCADA system from the Internet (RDP, VPN), the data is still transmitted.

What the cloud offers:​

• ISO 27001-certified hosting with a 24/7 security team
• Encryption in transit and at rest (TLS 1.3, AES-256)
• Automatic security updates — no unpatched CVEs for 3 years
• Native MFA authentication for all access
• Comprehensive, centralized audit logs

The following are real cloud risks:​

• Internet availability — if the Internet connection goes down, you lose access to the remote SCADA system (but not local control, which remains on the PLCs)
• Sovereign data compliance — if you process sensitive data (OIV, personal data), the choice of cloud provider is critical (France vs. the U.S.)

Security 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.

Criterion 3: Latency and Real Time​

The Truth About Cloud Latency​

The 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.

Is this acceptable for your application?

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.

Latency Verdict: Cloud latency is perfectly acceptable for 95% of industrial monitoring scenarios. Only the real-time control loop must remain local.

Criterion 4: Scalability​

On-premises: Scalability Is Difficult and Costly​

Scaling from 10 to 50 on-premises monitored sites requires:

• Additional servers (or memory/storage upgrades)
• Additional licenses (often prorated based on the number of tags or connections)
• Assistance from an integrator for configuration
• Migration of historical data
• Testing and validation before going live

Typical turnaround time: 4 to 12 weeks. High marginal cost.

Cloud: Nearly Instant Scalability​

Add a new SaaS cloud site:

1. Order a gateway (delivered in 5–7 days)
2. Install it and connect it to the site’s OT network (30–60 minutes)
3. Configure the data points from the web dashboard
4. The site appears in the centralized dashboard—immediately

Typical lead time: 1 to 2 weeks (determined primarily by hardware availability). Low marginal cost.

Scalability 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.

Criterion 5: Compliance and Regulation​

NIS2 (European Cybersecurity Directive)​

For 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:

• On-premises: You are responsible for the entire chain (OS, application, network, access). The NIS2 audit will review your logs, update procedures, and network segmentation.
• Certified cloud: The ISO 27001-certified cloud provider covers part of the requirements (infrastructure, hosting). You remain responsible for application configuration and user access.

GDPR and Personal Data​

If your SCADA system processes personal data (operator attendance records, biometric access), the location of the data is important:

• EU Cloud (AWS Paris, OVHCloud): GDPR-compliant if the contract includes the appropriate DPA clauses
• US Cloud (without SCCs): non-compliant for personal data of European citizens
• On-premises in France: compliant by nature if access is properly controlled

Regulated Industries (Pharmaceuticals, Agri-Food)​

FDA 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.

Compliance 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.

Criterion 6: Maintainability​

On-premises: The Hidden IT Burden​

Manufacturers often underestimate the maintenance burden of an on-premises SCADA system:

• OS updates (monthly Windows Server patches)
• Antivirus updates (daily)
• Backup management and restore testing
• SQL database updates (PostgreSQL, MS SQL)
• SSL certificate renewal
• License management (renewal, Microsoft audit)
• Internal user support

In practice, an on-premises SCADA system requires 0.3 to 0.5 IT FTEs over the course of its lifecycle (shared with other systems).

Cloud: Outsourced Maintenance​

On a SaaS cloud platform, the provider manages:

• The entire infrastructure (servers, network, storage)
• Security updates (without service interruption)
• Backups (contractually guaranteed RTO/RPO)
• Infrastructure scalability based on workload

Your team only maintains the field gateways (with automatable OTA firmware updates) and the application configuration.

Maintainability Assessment: The cloud reduces the operational burden by 70–80%. This is crucial for small and medium-sized businesses without a dedicated IT team.

Criterion 7: Resilience and Availability​

On-premises: A Double-Edged Sword in Terms of Resilience​

Key Features:

• Works even when the Internet is down (continuous local monitoring)
• No reliance on a third party for local access

Weaknesses:

• Server failure = complete shutdown of monitoring
• Requires hardware redundancy for high availability (doubles the cost)
• Complex disaster recovery (server reconstruction)
• Actual SLA is often poor (99% = 3.65 days of downtime per year)

Cloud: High Availability by Design​

Reputable industrial cloud platforms guarantee 99.9% availability (contractual SLA = < 8.76 hours of downtime per year) or even 99.95%.

Multi-AZ (multi-datacenter) architecture: A failure in one datacenter does not affect service. Disaster recovery (DR) is automatic.

Main 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.

Answer: For critical sites, deploy a backup connection (dual-operator 4G SIM with failover to fiber, or satellite VSAT as a last resort).

Resilience 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.

Hybrid Architecture: The Best of Both Worlds​

Most new industrial deployments adopt a hybrid architecture:

Advantages of the hybrid solution:

• Critical controls and alarms remain local (zero latency)
• Monitoring, history, and remote access are in the cloud
• In the event of an Internet outage, the process continues (PLC) and data is buffered (gateway)
• Edge intelligence (local automation rules) reduces dependence on the cloud

This is exactly the architecture that Eziwan deploys: an industrial gateway at each site (edge), and a cloud platform for centralized monitoring.

Summary Table​

When to Choose What?​

Choose the SaaS cloud if:​

• You manage multiple sites (3+) and want centralized monitoring
• You don’t have a dedicated IT team to maintain servers
• You’re deploying a new solution (greenfield) without legacy SCADA
• Your budget is limited and you’re looking to minimize capital expenditures
• You need high-quality remote access for your technicians or contractors

Choose the on-premises option if:​

• You have a recent, existing SCADA system that has already been fully depreciated (Wonderware, Ignition)
• You are an OIV and have strict network isolation requirements
• You have an in-house IT team capable of maintaining the infrastructure
• Your site is a single location with no need for multi-site monitoring
• Your latency requirements are extremely strict (real-time critical < 10 ms)

Choose the hybrid option if:​

• You have an existing SCADA system that you want to supplement with remote access
• You want the best ROI without overhauling your on-premises SCADA architecture
• Your process requires local control but you want cloud-based monitoring
• This is the most common scenario for new IIoT projects

Conclusion​

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.

One 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.

The 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.

FAQ​

Can a cloud-based SCADA system operate if the Internet is down? With 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.

Which on-premises SCADA systems are compatible with a cloud-based IoT gateway? Wonderware 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.

Is SaaS cloud computing suitable for trade secrets (formulas, proprietary processes)? Critical 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.

How long does it take to migrate from an on-premises SCADA system to the cloud? For 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.

Further Reading​

• Blog: Remote Industrial Monitoring — Complete Guide 2026
• Blog: Edge Computing vs. Industrial Cloud — When to Use Which?
• Blog: Secure Remote Access to PLCs and SCADA — VPN and NIS2
• Blog: ROI of Industrial IoT — Calculation and Optimization
• Docs: Eziwan Platform Architecture

Are 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.

Additional Resources​

• Cloud SCADA — cloud-based SCADA platform for centralized industrial monitoring
• Industrial Monitoring and Remote Support — remote monitoring solutions for industry
• Industrial edge computing — local data processing to reduce reliance on the cloud
• Guide: 4G SCADA Architecture — designing a SCADA architecture with 4G connectivity

This 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.

Why OT Systems Have Become the Number One Target​

For 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.

The game-changing factors:

• IT/OT Convergence: PLCs, SCADA systems, and sensors are now connected to ERP and MES systems and the cloud for remote monitoring
• Equipment Lifespan: A programmable logic controller (PLC) has a lifespan of 15 to 25 years. PLCs installed between 2005 and 2010 often run on obsolete operating systems (Windows XP, CE) that are no longer supported
• Protocols without native security: Modbus, DNP3, Profibus, and BACnet were designed for reliability, not security. They support neither authentication nor encryption
• Limited resources: A PLC or RTU lacks the processing power to run antivirus software or modern cryptographic algorithms
• Slow update cycle: Applying a patch to a controller may require a planned production shutdown—many companies delay updates for years

Consequence: OT systems are rife with unpatched vulnerabilities, insecure protocols, and increasing network exposure. For an attacker, this is an ideal target.

The Top 6 OT Threats in 2026​

1. Industrial Ransomware (ICS Ransomware)​

Ransomware remains the number one threat. But in 2025–2026, cybercriminal groups developed variants specific to industrial systems, capable of:

• Encrypt SCADA configuration files (Wonderware, Ignition, and Siemens TIA Portal projects)
• Modify PLC parameters to cause a physical failure in addition to encryption
• Exploit OPC-UA and Modbus TCP interfaces to move laterally within the OT network

Active 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.

Average impact of industrial ransomware:

• Production downtime: 12 to 21 days
• Total cost (ransom + recovery + lost revenue): €2.5 to 8 million for an SME
• Ransom payment rate: 42% of industrial companies pay (vs. 30% across all sectors)

Most Common Entry Points:

1. VPNs without MFA compromised via credential stuffing
2. Remote access by maintenance contractors (TeamViewer, AnyDesk) using shared credentials
3. Phishing attacks targeting engineers with access to OT systems
4. Exploitation of vulnerabilities in HMI (Human-Machine Interface) systems exposed to the Internet

2. Attacks on Programmable Logic Controllers (PLCs) and Remote Terminal Units (RTUs)​

Programmable logic controllers are now being targeted directly. The most sophisticated attacks modify the program logic (firmware or ladder logic) to:

• Cause unintended emergency shutdowns
• Force equipment to operate outside its normal operating ranges
• Hide actual values from operators (manipulation of monitoring data)

Recurring vulnerabilities identified by ANSSI (2024–2025):

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.

3. Attacks on Unsecured Industrial Protocols​

Modbus, 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:

• Read all registers on a Modbus controller without restriction
• Write values to coils and registers without authentication
• Send DNP3 commands to electrical or water distribution equipment

Typical 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.

Mitigation:

• Deploy industrial gateways with application firewalls that block unauthorized Modbus write commands (whitelist source IPs and function codes)
• Implement mutual TLS authentication for OPC-UA communications
• Monitor Modbus communications to detect abnormal function codes (FC05/FC06/FC15/FC16 outside of maintenance windows)

4. Attacks on HMI and SCADA Interfaces​

Human-machine interfaces (HMIs) and SCADA servers are often the weak links because:

• They run on Windows Server (2012, 2016, or even 2008) that is rarely updated
• They are accessible from IT networks for production monitoring
• They include web servers for remote access (often without MFA)

Common Attack Scenario:

1. An attacker compromises an IT workstation via phishing
2. Network scan → detects a Wonderware SCADA server on port 80
3. Exploitation of a web vulnerability or default credentials
4. Access to production monitoring → modification of alarm thresholds to mask an anomaly
5. Deployment of ransomware from the SCADA system to the rest of the OT network

Fact 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.

5. Attacks on the Supply Chain (OT Supply Chain)​

The OT supply chain threat is growing rapidly. It involves compromising equipment, software, or a service provider before it reaches the end victim.

Identified vectors:

• Malicious firmware in imported industrial routers or IoT gateways (mostly from Asia) that contain backdoors
• Compromised software updates for SCADA software or industrial protocol libraries
• Maintenance contractors who access the OT network using their own devices (USB drives, laptops) from other infected client sites
• Integration of third-party components into PLCs (communication cards, industrial modules) with unverified firmware

Directly Related NIS2 Requirements: Article 21 of the NIS2 Directive explicitly requires supply chain security management for essential and significant entities.

6. Internal Threats (Insiders)​

Internal threats are often underestimated in the industry. They include:

• Dissatisfied employees with access to control systems
• Contractors with permanent remote access that is not revoked after their assignment ends
• Intentional sabotage of critical systems (documented cases in the water and energy sectors)

2024 Statistics (Verizon DBIR Report): 18% of OT incidents involve an insider or a compromised trusted third party.

Key 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.

Sectors Most Vulnerable in France​

1. Water and Sanitation​

The water sector is the number one target of OT attacks, according to ANSSI and Europol. The reasons:

• Critical infrastructure with a direct impact on public health
• Aging systems (many Sofrel RTUs from the 2000s–2010s)
• Staff often lack cybersecurity training
• Limited IT/OT budgets in local governments

Reference 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.

In France, NIS2 classifies water utilities serving more than 10,000 residents as critical entities, subject to enhanced cybersecurity requirements effective October 17, 2024.

2. Energy and Electric Grids​

Attacks 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.

Targeted protocols: IEC 60870-5-101/104, IEC 61850 GOOSE, DNP3 — none of which include native authentication in their base versions.

3. Pharmaceutical and Food Industries​

These 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.

Attacks aimed at halting production (competitive sabotage) are on the rise in these high-value-added sectors.

4. Local Governments and Smart Cities​

Smart 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.

The 10 Priority Steps to Secure Your OT in 2026​

Level 1: Fundamentals (to be completed immediately)​

1. Inventory of All OT Assets You 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.

2. IT/OT Network Segmentation Isolate 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.

3. Eliminate unsecured remote access Audit 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.

4. Changing Default Credentials All 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).

5. Backing Up PLC Configurations Export 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.

Level 2: Strengthening (to be planned over 6–12 months)​

6. Strong Authentication for Remote Access Deploy 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.

7. OT Network Behavior Monitoring (NDR) Deploy 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.

8. OT Vulnerability Management Subscribe 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.

9. OT Incident Response Plan Document 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.

10. Team Training (OT Security Awareness) Automation 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.

How Eziwan Meets OT Security Requirements​

The Eziwan gateway and platform were designed from the outset with OT security as a critical non-functional requirement.

Zero Trust Architecture:

• All gateway → cloud communications are encrypted using TLS 1.3 with mutual authentication via X.509 certificates
• Each gateway has a unique, non-modifiable identifier pre-programmed at the factory (Device Identity)
• No incoming ports are open on the gateway: connections are initiated exclusively from the OT to the cloud (push model)

Granular remote access control:

• OpenVPN/IPSec VPN with mandatory MFA for all remote access
• Time-limited sessions (configurable automatic expiration: 1 hour, 4 hours, 24 hours)
• Comprehensive audit log: who logged in, from which IP address, for how long, and what actions were performed
• Vendor access: restricted by source IP address, target device, and time window

Integrated OT Monitoring:

• Anomaly detection for Modbus values (out-of-range variations, static values, communication interruptions)
• Real-time alerts via SMS/email for any detected anomalies
• Complete history of values for post-incident investigation

Sovereign Hosting:

• Infrastructure hosted in France (AWS Paris eu-west-3), ISO 27001
• Data not transferred outside the EU
• Compliance with GDPR, NIS2, and ANSSI requirements

OT Security Checklist 2026​

Use this checklist to assess your OT cybersecurity maturity level:

Governance

• Up-to-date OT asset mapping (complete inventory)
• Formalized OT security policy approved by management
• Designated OT cybersecurity manager (or specialized MSSP)
• Classification of systems by criticality (IEC 62443 Security Levels)

Network Architecture

• IT/OT segmentation with industrial firewall/DMZ
• Dedicated VLANs by Purdue zone (levels 0, 1, 2, 3)
• No OT equipment directly accessible from the Internet
• No direct connections between IT workstations and field controllers

Access and Identities

• Default credentials removed from all devices
• MFA deployed for all remote access methods (VPN, RDP, web-based SCADA)
• Limited access for contractors (duration, scope, time window)
• Audit log of remote access archived for ≥ 1 year

Maintenance and Updates

• Documented OT vulnerability management process
• PLC configuration backups tested and stored off-network
• Scheduled firmware update procedure during maintenance windows

Detection and Response

• Monitoring of OT network behavior (OT NDR or OT SIEM)
• Documented and tested OT incident response plan
• ANSSI notification procedure (mandatory for NIS2 entities)
• Identified cybersecurity emergency contacts (internal or external CERT)

FAQ — OT Cybersecurity and Industrial Threats in 2026​

Can ransomware that infects the IT network also affect OT controllers?

Yes, 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.

Can Siemens or Schneider PLCs be directly infected by malware?

Industrial 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.

What is the requirement to report to ANSSI in the event of an OT incident under NIS2?

For 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.

Are OT network segmentation solutions very expensive for a small-to-medium-sized enterprise?

No. 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.

Should unsecured protocols such as Modbus TCP be disabled on the OT network?

On 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.

Conclusion​

OT 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.

The 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.

Your 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.

Article 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 →

Additional Resources​

• Industrial Cybersecurity — Overview of protection solutions for OT networks
• OT Remote Access Cybersecurity — Securing remote connections to ICS
• NIS2 for Industry — Regulatory Requirements and Penalties for Manufacturers
• Industrial VPN — Protecting Remote Access with Strong Encryption

However, 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.

What is IEC 62443?​

IEC 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).

The Structure of the Standard​

The standard is organized into four series:

For a French manufacturer seeking to comply with NIS2, the most relevant sections are:

• IEC 62443-2-1: security policies and procedures
• IEC 62443-3-3: system security requirements
• IEC 62443-4-2: component requirements (for evaluating your equipment)

Security Levels (SL): Understanding Security Levels​

The central concept of IEC 62443 is the Security Level—the level of protection required based on the system's criticality.

The 4 Levels​

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.

How do you determine the required SL for your system?​

The process consists of three steps:

1. Identify Zones and Conduits (IEC 62443-3-2)

Start by mapping your OT systems into security zones:

• Production zone (PLCs, sensors, local HMIs)
• Monitoring zone (SCADA, historian servers)
• OT DMZ (IT/OT interface)
• Remote access zone

Next, identify the pipes (Conduits)—the communication paths between zones (remote access VPNs, SCADA links, IT/OT gateways).

2. Assess the criticality of each zone (CASC)

For each area, assess the consequences of a compromise based on the CASC criteria:

• Confidentiality: Does the data need to remain confidential?
• Integrity: Could a change to the data or commands cause damage?
• Davailability: Would a system outage cause significant harm?
• Safety: Could a malfunction endanger lives?

3. Define the target SL by zone

The 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.

The 7 Foundational Requirements of IEC 62443-3-3​

The 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.

FR 1 — Identification and Authentication Checks​

What this means in practice:

• Each user and device must be uniquely identified (no shared accounts)
• Default passwords on OT devices must be changed
• For SL 2: two-factor authentication (MFA) for remote access

Eziwan App: Each technician has an individual OpenVPN/IPSec VPN key. MFA authentication is available on the cloud platform.

FR 2 — Usage Monitoring​

What this means:

• Each user has access only to the resources necessary for their role (principle of least privilege)
• Actions on critical equipment require explicit authorization

Application: Eziwan RBAC allows you to define access rights by site, by piece of equipment, and by time slot for each technician.

FR 3 — Data Integrity​

What this means:

• Data transmitted between devices must not be alterable in transit
• The integrity of the PLC configurations must be verifiable

Application: All Eziwan communications are encrypted using OpenVPN (authentication + encryption). The configurations are digitally signed.

FR 4 — Data Confidentiality​

What this means:

• Sensitive data (recipes, production parameters, personal data) must be encrypted in transit and at rest

Implementation: AES-256-GCM encryption of all communications; stored data is encrypted on the French cloud infrastructure.

FR 5 — Limited Data Flow​

What this means:

• Communications between security zones must be controlled and limited to the minimum necessary
• No direct communication between the office IT zone and OT controllers without a DMZ

Eziwan 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.

FR 6 — Response to Events​

What this means:

• Security incidents must be detected, recorded, and addressed
• For NIS2: mandatory notification within 24 hours for critical entities

Application: Comprehensive logging of all security events, configurable alerts for connection anomalies, and log export for SIEM.

FR 7 — Availability of Resources​

What this means:

• The system must remain available even in the event of an attempted attack (DoS protection)
• Backup and recovery mechanisms must be in place

Application: Dual SIM failover, multi-AZ cloud infrastructure, automatic backups of gateway configurations.

The 6-Step IEC 62443 Compliance Process​

Here is a practical approach for French manufacturers who must comply with NIS2 by referencing IEC 62443.

Step 1: Inventory of OT Assets (3–5 days)​

List all your OT systems:

• Controllers (PLCs, DCSs, RTUs)
• HMIs and operator stations
• SCADA servers and historians
• OT network equipment (switches, routers, firewalls)
• Gateways and connectivity equipment

For each asset: firmware/software version, network connectivity, date of the last security update, existing remote access capabilities.

Step 2: Mapping Areas and Ducts (2–3 days)​

Draw a diagram of the current OT network, including security zones and communication flows. Identify:

• Existing IT/OT interfaces
• Remote access methods (VPN, RDP, TeamViewer)
• Devices with ports exposed to the Internet (search for your IP addresses on Shodan)

Step 3: Simplified Risk Analysis (1 week)​

For each area, assess:

• Criticality (impact of a breach: production, security, environment)
• Threat (who might want to attack your sector?)
• Vulnerability (current security status of the area)

Prioritize the areas to be addressed first: high criticality + high vulnerability = Priority 1.

Step 4: Defining the Target SL Level by Zone​

Based on the risk analysis:

• Standard production areas → SL 2
• Areas with SIL safety controllers → SL 3
• OT office areas (engineering workstations) → SL 1 to SL 2

Step 5: Remediation Plan (spanning 6–18 months)​

For each area where the current level is below the target SL, define corrective actions:

SL 2 Priority Actions:

1. Remove all default passwords from OT devices
2. Replace unsecured remote access methods (exposed RDP, TeamViewer) with a zero-trust VPN
3. Implement MFA authentication for all remote access
4. Create named accounts (no shared generic accounts)
5. Enable access logging on all devices that support it
6. Segment the OT network from the office IT network (DMZ or VLAN with ACL)

Key Actions for SL 2: 7. Update the firmware on OT equipment (gateways, industrial switches) 8. Document incident response procedures 9. Train maintenance teams on OT cybersecurity risks

Step 6: Evaluation and Continuous Improvement​

IEC 62443 compliance is not a one-time project but an ongoing process. Plan for:

• Annual review of the inventory and mapping
• Annual (or semi-annual) penetration testing of remote access points
• Update the remediation plan after each incident or infrastructure change

IEC 62443 and NIS2: What French Entities Need to Do​

The 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.

The Entities Involved​

Critical infrastructure: energy (electricity, natural gas, oil), transportation (air, rail, maritime, road), banking, financial infrastructure, water (supply, wastewater), healthcare, digital infrastructure.

Key sectors: postal services, waste management, chemicals, food, industrial manufacturing (medical devices, electronic equipment, mechanical engineering), digital service providers.

Required Cybersecurity Measures (Art. 21 NIS2)​

1. Information Systems Security Policy (IEC 62443-2-1)
2. Incident Management: detection, response, notification within 24 hours (IEC 62443-2-1, FR 6)
3. Business Continuity: Backups, recovery plans (IEC 62443-3-3 FR 7)
4. Supply Chain Security: Security of subcontractors with OT access (IEC 62443-2-4)
5. Procurement Security: security assessment prior to deployment of OT equipment (IEC 62443-4-2)
6. Training and Awareness: all personnel with access to OT systems
7. Cryptography and Encryption: encrypted communications, protected sensitive data
8. Access Control: strong authentication, RBAC, logging (IEC 62443-3-3 FR 1, FR 2)
9. Human Resources Security: background checks, exit procedures
10. Risk Assessment: formal, documented process (IEC 62443-3-2)

5 Mistakes to Avoid in an IEC 62443 Project​

Mistake 1: Starting with the documentation before the site survey​

Many 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.

Mistake 2: Treating IEC 62443 as an IT project​

OT 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.

Mistake 3: Aiming for SL 3 or SL 4 without a valid reason​

SL 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.

Mistake 4: Neglecting Third-Party Access Security​

The 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.

Mistake 5: Thinking that NIS2 compliance equals IEC 62443 compliance​

NIS2 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.

FAQ​

Is IEC 62443 certification required to comply with NIS2? No. 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.

Which part of IEC 62443 should an industrial PMI start with? For 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.

What is a security zone in IEC 62443? A 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.

How do I determine the target Security Level (SL) for my facility? The 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.

Does IEC 62443 cover VPN remote access security? Yes. 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.

Additional Resources​

• Guide: NIS2 for Industry — Requirements, Penalties, Action Plan
• Blog: NIS2 Compliance Checklist — 30 Checkpoints
• Blog: OT Cybersecurity — Threats and Incidents in 2026
• Blog: Zero Inbound Ports — Secure OT Architecture
• Docs: Eziwan Remote Access Security

Additional Resources​

• Industrial Cybersecurity — protection solutions for OT and ICS networks
• NIS2 for Industry — regulatory requirements and compliance plan
• OT Remote Access Cybersecurity — Securing remote access to PLCs
• Industrial Remote Access — IEC 62443-compliant zero-trust architectures
• Guide to Securing OT Networks — Segmentation, VPN, and NIS2 Compliance

This 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.

Why IoT ROI Is Often Underestimated​

Most IoT ROI calculations focus on direct and obvious savings. But industrial IoT generates benefits in four categories that are often underestimated:

1. Direct savings: costs avoided (travel, emergency service calls, unplanned outages)
2. Productivity gains: time saved through automated monitoring
3. Risk reduction: avoided incident costs (contractual penalties, regulatory fines, reputational damage)
4. Value of data: optimizations made possible by newly available data

Projects that measure only Category 1 consistently attribute an overly low ROI to the IoT.

The Industrial IoT ROI Formula​

ROI is calculated over a given period (usually 1, 2, or 3 years):

ROI (%) = [(Total Profits - Total Costs) / Total Costs] × 100

Total Costs = Initial Investment + Recurring Costs

• Initial investment: hardware (gateways, sensors), installation, configuration, training
• Recurring costs: platform subscriptions, M2M SIM cards, hardware maintenance

Total benefits = the sum of savings and gains across the 4 categories

Category 1: Direct Savings​

Reducing Technician Travel​

This is often the most important item and the easiest to quantify.

Actual cost of a technician's service call (France, 2026):

How IoT Monitoring Reduces Travel:

• Remote diagnostics: The technician determines the cause of the problem before leaving → he brings the right part instead of making two trips
• False alarms avoided: Without supervision, every operator alert results in a service call. With IoT, the dashboard distinguishes between real failures and false alarms
• Scheduled service calls: Predictive alerts allow service calls at a single site to be grouped together during a single scheduled visit

Typical savings observed:

• Water utilities: 1.5 to 3 trips avoided per pumping station per year
• Multi-site industries: 2 to 4 emergency calls converted to scheduled maintenance per site per year
• Solar farms: 60–70% reduction in reactive maintenance visits

Reducing Unplanned Downtime​

An unexpected breakdown costs, on average, 3 to 5 times more than an equivalent preventive maintenance service.

Cost of an unplanned shutdown (example: industrial SME):

• Production losses: 500 to 5,000€/hour (depending on the sector)
• Emergency labor (+50% on-call rate): 500–1,500€
• Express parts (cost × 2 vs. normal stock): +€200–500
• Total cost of a 4-hour shutdown for an SME: €2,500 to €22,000

With 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.

ROI of prevention: Avoiding just 1 to 2 unplanned shutdowns per site per year is often enough to recoup the total IoT investment.

Category 2: Productivity Gains​

Operator time saved through the automation of monitoring​

Without IoT monitoring, operators and technicians spend time:

• Conducting regular monitoring rounds
• Manually entering readings into spreadsheets
• Compiling performance reports
• Responding to phone calls reporting outages

Estimated time saved (for 20 monitored pieces of equipment):

14 hours/week × hourly rate (60€) = 840€/week in productivity savings, or 43,000€/year.

Reducing Diagnostic Time​

With 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.

Category 3: Risk Reduction​

Avoided Regulatory Compliance Issues​

For sectors subject to NIS2 (water, energy, transportation, healthcare), fines for noncompliance can reach 2% of global annual revenue for a critical entity.

IoT monitoring—which includes access logging, traceability of interventions, and automatic audit reports—significantly reduces the risk of noncompliance.

Avoided service penalties​

For companies covered by an SLA (maintenance providers, network operators), every hour of downtime can result in contractual penalties.

Example: 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.

Category 4: Data Value​

Energy Consumption Optimization​

Real-time electricity consumption data helps identify unnecessary consumption spikes, underutilized equipment, and load reduction opportunities.

Typical savings: A 5 to 15% reduction in the electricity bill for monitored equipment.

Real-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.

Data-Driven Decisions vs. Intuition​

Before the IoT, maintenance decisions were based on experience and paper records. After the IoT, they are based on real data:

• Maintenance frequency adjusted to actual usage (vs. a fixed schedule)
• Prioritization of investments based on actual performance data
• Quantified demonstration of the impact of the improvements made

Examples of ROI Calculations by Industry​

Water utility — network of 40 pumping stations​

Initial investment:

• 40 IoT gateways: 40 × €400 = €16,000
• Installation (0.5 days per technician per site): 40 × €200 = €8,000
• Total: €24,000

Annual recurring costs:

• Platform subscriptions + SIM cards: 40 × 480€/year = 19,200€/year

Annual savings:

• Trips avoided (2 per station per year × €200): 40 × €400 = €16,000
• Avoided on-call duty (1 per station per year × €300): 40 × €300 = €12,000
• Avoided unplanned downtime (0.5/year × €3,000): 20 × €3,000 = €60,000
• Operator productivity gains (5 hours/week freed up × 60€): 15,600€
• Total savings: 103,600€/year

ROI in Year 1: (103,600 - 24,000 - 19,200) / 43,200 = 140% Payback period: 4 to 5 months

Industrial SME — 3 production sites​

Initial investment:

• 15 gateways (5 per site): 15 × €400 = €6,000
• Installation and configuration: €3,000
• Total: €9,000

Annual recurring costs:

• Subscriptions + SIM cards: 15 × 480€ = 7,200€/year

Annual savings:

• Travel between sites avoided: 24 trips × €250 = €6,000
• Downtime avoided (1.5 per site per year × €8,000): €36,000
• Reduction in preventive maintenance (20% of service calls): €12,000
• Total savings: €54,000/year

ROI in Year 1: (54,000 - 9,000 - 7,200) / 16,200 = 234% Payback period: 3 months

Factors That Maximize ROI​

1. Start with the most critical sites and equipment​

ROI is highest for equipment with high downtime costs and at the most remote sites (high travel costs). Prioritize:

• Critical pumps in the drinking water supply
• Equipment in continuous production (high cost per hour of downtime)
• Sites more than 1 hour’s travel time from the on-call technician

2. Integrating Monitoring into Maintenance Processes​

An IoT system that isn't integrated into maintenance workflows generates little value. ROI is maximized when:

• IoT alerts automatically trigger work orders in the CMMS
• IoT reports replace manual reports
• Technicians use remote access before each site visit (for preliminary diagnostics)

3. Continuously Measure and Optimize​

Establish KPIs for monitoring at the outset:

• Number of service calls avoided (compared to pre-IoT data)
• MTTR (Mean Time To Repair): average time to resolve incidents
• OEE (Overall Equipment Effectiveness) for production lines
• Number of unplanned shutdowns

Compare results on a quarterly basis to identify opportunities for improvement.

Mistakes That Reduce ROI​

Underestimating Initial Deployment Costs​

A sloppy installation leads to costly rework. Budget 30 to 50 percent of the hardware cost for installation, configuration, and training.

Neglecting Change Management​

To 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.

Choosing a Non-Scalable Platform​

The 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.

Conclusion​

The 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.

The 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.

FAQ​

How to Calculate the ROI of an Industrial IoT Project Without Historical Downtime Data? Use 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.

Is the ROI of industrial IoT the same for an SME as for a large corporation? No. 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.

Should you calculate the ROI before or after launching a pilot? Both. 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.).

What Costs Should Be Factored Into an Industrial IoT Project? Common 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).

Resources for Further Study​

• Blog: IIoT Predictive Maintenance — From Sensor Data to Alerts
• Blog: Water and Wastewater Monitoring — 300 4G Stations
• Blog: Remote Industrial Monitoring — Complete Guide 2026
• Blog: Cloud SCADA vs. On-Premises SCADA — Decision Guide
• Blog: Zero-Touch Provisioning — Deploy 50 Routers in 2 Hours

Additional Resources​

• Eziwan ROI Calculator — estimate the return on investment for your industrial IoT project
• Industrial IoT ROI Guide — methodology and real-world examples of IIoT ROI calculations
• IIoT Predictive Maintenance — reduce maintenance costs with predictive IoT
• Eziwan Industrial Solutions — a comprehensive range of solutions to maximize industrial ROI
• Industrial Equipment Monitoring — monitoring of industrial assets to optimize performance

This guide covers the entire subject: definitions, technical architectures, protocol selection, cybersecurity, and practical implementation for deployments ranging from 1 to 1,000 sites.

What is remote industrial monitoring?​

Remote industrial monitoring (or industrial telemetry) refers to the range of technologies that enable:

• View the status of industrial equipment (machines, PLCs, sensors) from a remote location
• Receive alerts in real time in the event of an anomaly, threshold exceedance, or failure
• Remotely operate equipment (adjust setpoints, restart, reconfigure)
• Analyze historical data to optimize performance and plan maintenance

It applies to all sectors: manufacturing, water and wastewater, energy, agriculture, and building services.

Monitoring vs. SCADA vs. IIoT: What Are the Differences?​

These terms are often confused. Here are the differences:

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).

Remote Monitoring Architectures​

Architecture 1: Centralized Cloud Monitoring (Recommended)​

Benefits:

• Rapid deployment, with no on-site server infrastructure required
• Access from any browser, tablet, or smartphone
• Scalability from 1 to thousands of sites without requiring an architectural overhaul
• Centralized updates with no on-site intervention required

Typical use cases: water utilities, power distribution networks, solar farms, and geographically dispersed fleets of industrial equipment.

Architecture 2: On-premises SCADA with VPN remote access​

Advantages:

• Data remains within the company's IT infrastructure
• Compatible with existing SCADA systems (Wonderware, WinCC, Vijeo Citect)
• Full control over hosting and security

Typical use cases: large industrial companies with existing SCADA systems, industries with data sovereignty requirements.

Architecture 3: Edge Computing + Hybrid Cloud​

For 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.

Industrial Protocols for Remote Monitoring​

Modbus RTU/TCP — the universal standard​

Modbus is the most widely used protocol in the industry. It comes in two variants:

• Modbus RTU: over an RS-485 serial connection. Up to 32 devices over 1,200 m of cable. Data rate: 9,600 to 115,200 bps.
• Modbus TCP: Modbus encapsulation over Ethernet/IP. Port 502. Data rate limited only by the network.

What 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.

Limitation: Master/slave architecture only. No event notifications—the master must poll the slaves regularly.

MQTT — The IIoT Protocol​

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol designed for low-bandwidth connections.

Key Features for Remote Monitoring:

• Persistent Connection: The MQTT client (gateway) connects to the broker once and maintains the session
• Configurable QoS: Guaranteed delivery of critical messages (QoS 1 or 2)
• Hierarchical topics: usine/ligne1/pompe3/courant — logical data structure
• Last Will & Testament: automatic notification if a device disconnects

Cloud integration: MQTT is natively supported by AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and HiveMQ.

OPC-UA — for demanding SCADA environments​

OPC-UA (Unified Architecture) is the interoperability standard for Industry 4.0.

Key Features:

• Object-oriented information model (not just digital registers)
• Built-in security: authentication, encryption, message signing
• Compatible with major SCADA systems (WinCC, FactoryTalk, Ignition)
• Standard for MES and ERP applications

When to choose OPC-UA: Integrations with existing SCADA, MES, and SAP ERP systems. Environments where data semantics (not just raw values) are important.

Cybersecurity in Remote Monitoring​

Remote 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.

The 5 Golden Rules of OT Cybersecurity​

1. No open incoming ports on the industrial network

The 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.

2. VPN and Encryption Required

All communications between industrial sites and the monitoring platform must be encrypted. OpenVPN with AES-256-GCM encryption is the 2026 recommendation for new deployments.

3. Strong Authentication for Remote Access

Every 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.

4. Principle of Least Privilege

A 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.

5. Complete audit log

All 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.

NIS2 and Remote Monitoring​

The NIS2 Directive (transposed into French law in October 2024) requires critical entities and important entities to implement specific measures for remote access:

• Identity-based access control (no shared accounts)
• Encryption of communications
• Access logging and monitoring
• Incident management with notification within 24 hours (critical entities)

Sectors involved: water and sanitation, energy, transportation, health care, waste management, and critical industrial production.

Practical Deployment: From 1 to 1,000 Sites​

For a single site (POC or pilot)​

Required equipment:

• 1 IoT gateway with 4G connectivity and RS-485 interfaces
• M2M SIM subscription (or use your carrier's SIM)
• Access to the cloud-based monitoring platform

Deployment time: 2 to 4 hours for a technician (hardware installation + cloud configuration + Modbus data validation).

Estimated cost: €300–600 for equipment + €30–80/month for platform subscription + M2M SIM card.

For 10 to 50 sites​

At this scale, Zero-Touch Provisioning (ZTP) becomes essential for reducing deployment costs.

Eziwan ZTP Process:

1. You set up a standard configuration in the cloud (protocols, alerts, VPN)
2. Each gateway is shipped preconfigured from the factory (or configured remotely)
3. On-site: connect power, SIM, and RS-485—the gateway configures itself
4. Less than 30 minutes of technician time per site

Cost savings vs. manual configuration: For 50 sites, ZTP typically saves 2 to 3 person-days of network configuration time.

For 100+ sites (fleet management)​

For large fleets, centralized management features become critical:

• Fleet Dashboard: Overview of connectivity and status for each site
• Aggregated Alerts: Filtering of false alarms, automatic escalation
• OTA firmware updates: Deploy updates across the entire fleet without on-site visits
• SIM management: Data usage by site, one-click SIM replacement
• Automated Reports: network availability, incidents, service calls—for CSR or contractual reporting

Real-World Use Cases​

Water utility — network of 80 pumping stations​

Previous situation: weekly supervisory rounds, 2–3 on-call shifts per week for emergency response.

Solution deployed: 80 4G LTE gateways with Modbus RTU, real-time alerts on pump levels and faults, and remote access for technicians via OpenVPN/IPSec.

Results:

• Inspection rounds reduced by 70% (from weekly to monthly for routine checks)
• Fault detection in less than 30 seconds (vs. 4–48 hours previously)
• ROI achieved in 4 months

Food Processing Industry — 3 Production Sites​

Previous situation: Each site had its own local SCADA system, with no consolidated visibility at the group level.

Solution 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.

Results:

• A single dashboard for all three sites (vs. three separate SCADA interfaces)
• Incident response time reduced by 65%
• Secure and traceable access for maintenance contractors

Solar Farm — 15 Power Plants​

Previous situation: Proprietary data loggers that were incompatible across different inverter manufacturers.

Deployed solution: IoT gateways with a universal Modbus parser supporting the SunSpec, SMA, ABB, and Fronius protocols. Performance monitoring dashboard (kWh, performance ratio, availability).

Results:

• Consolidation of monitoring into a single dashboard
• Detection of performance drops of +3% → planned preventive action
• Automatic reports for investors and the network operator

Remote Monitoring Deployment Checklist​

Before launching your remote monitoring project, check the following:

Connectivity​

• 4G LTE coverage verified at each site (carrier tests)
• Dual SIM option evaluated for critical sites
• Estimated data usage per site (Modbus polling frequency × register size)

Field Equipment​

• Protocol inventory: Modbus RTU (RS-485), Modbus TCP, or proprietary?
• List of variables to monitor per device (Modbus registers)
• Power supply available in the cabinet (24V DC or 230V AC)

Cybersecurity​

• Zero-inbound-port architecture selected
• OpenVPN/IPSec or IPSec VPN planned
• Technician access policy defined (permissions, time slots)
• Is NIS2 applicable to your organization? (critical/important entities)

Cloud Platform​

• Data hosted in France or the EU (GDPR)
• API available for integration with existing SCADA/MES systems
• Platform availability SLA (minimum 99.5%)

Conclusion​

Remote 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.

The 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.

The 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.

FAQ — Remote Industrial Monitoring​

What is the difference between SCADA and cloud-based IoT monitoring?

A 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.

How many variables can be monitored simultaneously across 100 sites?

There 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).

Can remote monitoring work if the PLC is in STOP mode (program stop)?

Yes, 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.

What is the minimum latency between a state change on the PLC and its appearance on the dashboard?

With 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.

Can non-Ethernet devices (RS-485 meters, 4-20 mA sensors) be monitored?

Yes, 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.

Additional Resources​

• Guide: Secure Remote Access for PLCs and SCADA — VPN Architecture
• Guide: Industrial 4G LTE Router — Migrating from ADSL
• Guide: Connecting a Siemens S7 PLC to the Cloud
• NIS2: Specific Requirements for Manufacturers
• Docs: Eziwan Multi-Site Monitoring
• Blog: ROI of Industrial IoT — Calculation and Optimization

Additional Resources​

• Industrial Monitoring and Remote Support — monitoring and remote support solutions for industry
• Industrial Equipment Monitoring — monitor your industrial equipment in real time
• Cloud SCADA — cloud-based SCADA platform for multi-site monitoring
• Industrial Remote Diagnostics — remote diagnostics for your industrial facilities
• Guide: Monitoring Remote Sites — monitor sites without a wired connection
• Cloud-Based Industrial Data Logger — recording and archiving your process data

This 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.

First, let's understand: protocols of different types​

Before making a comparison, it is important to understand that Modbus, MQTT, and OPC-UA do not operate at the same level:

Modbus 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.

MQTT 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.

OPC-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.

In 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.

Modbus RTU and Modbus TCP​

What is Modbus?​

Modbus 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.

Modbus 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.

Modbus 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.

What Modbus Allows You to Read​

Modbus exposes 4 types of data:

• Coils (0x): read/write digital outputs (Booleans)
• Discrete Inputs (1x): read-only digital inputs (Booleans)
• Input Registers (3x): 16-bit read-only registers (sensor measurements)
• Holding Registers (4x): 16-bit read/write registers (setpoints, parameters)

To 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).

Strengths of Modbus​

Absolute 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.

Simplicity: The protocol is simple—numbered registers, standard read/write functions. Any developer can implement a Modbus client in a matter of hours.

Resilience: 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.

Maturity: 45 years of industrial deployment. Modbus libraries are available in all programming languages (Python, C, Java, JavaScript, etc.).

Limitations of Modbus​

Pull-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.

No 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).

No 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.

No 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.

When to Use Modbus​

• Reading data from field devices (energy meters, pressure sensors, variable-speed drives, PLCs)
• Existing field networks with RS-485 cabling already in place
• Projects involving heterogeneous equipment from different manufacturers (Modbus is the most widely used)
• Limited budgets or teams without specialized expertise

MQTT (Message Queuing Telemetry Transport)​

What is MQTT?​

MQTT 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).

MQTT 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.

MQTT Architecture​

The broker is at the heart of the MQTT architecture. Clients (publishers and subscribers) connect to the broker—they never communicate directly with each other.

Strengths of MQTT​

Push 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.

Lightweight: The protocol was designed for resource-constrained devices (microcontrollers, 2G modems). An MQTT message can fit into 2 bytes (minimum header). Very bandwidth-efficient.

Configurable 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.

Cloud 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.

Native TLS: MQTT natively supports TLS 1.3. Security is built into the protocol; it is not an add-on.

Limitations of MQTT​

Cannot 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.

Dependence 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.

No 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.

No 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.

When to Use MQTT​

• Data transmission from the field to the cloud (Modbus → Gateway → MQTT → Cloud)
• Event-driven architectures where data changes irregularly
• Embedded IoT deployments on microcontrollers or resource-constrained devices
• Integration with cloud-native brokers (AWS IoT, Azure IoT Hub)

OPC-UA (OPC Unified Architecture)​

What is OPC-UA?​

OPC-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.

OPC-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.

OPC-UA Capabilities​

Semantic 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.

Built-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+).

Publish/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.

Access 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.

Semantics 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.

Limitations of OPC-UA​

Complexity: 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.

Required 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).

Not 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.

Network 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.

When to Use OPC-UA​

• Recent Siemens S7-1200/1500 PLCs with TIA Portal (native OPC-UA)
• Industry 4.0 architectures with SCADA/MES/ERP interoperability
• Projects requiring strong security and traceability for access
• Multi-vendor environments requiring semantic interoperability

Decision Guide: Which Combination Is Right for Your Project?​

A Simple, Typical Industrial IoT Architecture​

Usage: Process monitoring, alerts, historical data. 80% of French industrial IoT projects follow this model.

Architecture with a Cloud Integration Bus​

Usage: Projects with multiple data consumers (SCADA + ERP + BI). MQTT as an integration bus.

Industry 4.0 Architecture with OPC-UA​

Applications: Factories with modern PLCs, Industry 4.0 projects, MES integration.

Decision Matrix​

How Eziwan Handles the Three Protocols​

The Eziwan gateway is agnostic to field-side protocols:

• Modbus RTU: native RS-485 port, master mode, up to 247 slaves per bus, configurable polling interval from 1 second to 15 minutes
• Modbus TCP: Modbus TCP client, simultaneous connections to multiple Modbus servers
• MQTT: MQTT publisher (publishes collected data), subscriber support available for commands
• OPC-UA: OPC-UA client (reads nodes, subscribes to value changes) — available upon request for OPC-UA deployments

On the cloud side, data is standardized internally and exposed via:

• REST API (JSON) for cloud applications
• Webhooks for real-time events
• Outbound MQTT for message bus integrations

You can combine Modbus RTU on field devices with MQTT to your AWS/Azure cloud without changing anything—the gateway handles the translation.

Conclusion​

In 2026, the answer to "Modbus, MQTT, or OPC-UA?" is generally "all three":

• Modbus to read your field devices (that's the language they use)
• MQTT to transmit data to your cloud and distribute it to multiple applications
• OPC-UA if you have recent Siemens/Rockwell/Beckhoff PLCs and need SCADA/MES interoperability

This isn't a competition—it's a layered architecture. The choice isn't "which protocol," but "which protocol at which layer for which device."

FAQ — Modbus, MQTT, and OPC-UA​

Can Modbus and MQTT be used simultaneously on the same gateway?

Yes, 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.

Can OPC-UA replace Modbus on existing PLCs (S7-1200, M340)?

On 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.

MQTT with QoS 0 vs. QoS 1 vs. QoS 2 — Which Should You Choose for Industrial Monitoring?

For 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.

Is a public MQTT broker (HiveMQ, EMQX Cloud) sufficient for industrial applications?

For 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.

Does OPC-UA affect the PLC's performance compared to Modbus?

OPC-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.

Further Reading​

• Blog: Modbus TCP vs. RTU — Which Protocol Should You Choose?
• Blog: OPC-UA, MQTT, Modbus — Choosing Your Industrial Gateway
• Blog: Complete OPC-UA Guide for Industry
• Blog: MQTT, RS485, Modbus — Industrial IoT Protocols Explained
• Docs: Modbus configuration on the Eziwan Gateway

Additional Resources​

• Industrial Protocols — A Comprehensive Comparison of Modbus, MQTT, OPC UA, and DNP3
• Modbus RTU to the Cloud — Connect Your RS-485 Modbus RTU Devices to the Cloud
• OPC UA to MQTT — Publish OPC UA Data to an MQTT Broker
• RS-485 Modbus 4G — RS-485 Modbus data transmission via 4G network
• IIoT Gateway — IIoT gateway solutions for industry
• Guide: Modbus to the Cloud — comprehensive guide to transmitting your Modbus data

This 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.

Criterion 1: Industrially supported protocols​

This is the number one criterion. If your gateway doesn't "speak" the same protocol as your devices, all other criteria become secondary.

Essential Protocols in France in 2026​

Modbus 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.

Modbus 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).

MQTT — 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.

OPC-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.

Specific Protocols:

• DNP3: power grids, drinking water, gas (France, North America)
• IEC 61850: high-voltage substations
• M-Bus: heat, water, and gas meters (buildings, district heating networks)
• BACnet: HVAC and building automation systems (BAS)

Protocol Checklist:

• Modbus RTU (RS-485) in master mode
• Modbus TCP in master mode
• MQTT with TLS 1.2/1.3
• Industry-specific protocols

Criterion 2: Network Connectivity and Redundancy​

4G LTE: The Current Standard​

An 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).

Points to Consider:

• Is the 4G module built-in (internal M2M SIM) or external (USB dongle)?
• An external module is an additional source of failure and poor thermal management
• Some gateways are labeled “4G compatible” but require an external modem—proceed with caution

Dual SIM: True Network Redundancy​

One 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.

Dual SIM, which supports two SIM cards from different carriers and automatic switching, is the solution for mission-critical applications. Eziwan supports Dual SIM natively.

Questions to Ask:

• Does the gateway support two SIM cards simultaneously?
• Is the failover automatic (without human intervention)?
• Is the failover time acceptable for your application (target: less than 30 seconds)?

Wired Backup Connection​

For 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.

Criterion 3: Security and Zero Trust Architecture​

Cybersecurity for industrial IoT gateways has become a non-negotiable requirement, driven by NIS2, which now covers a wide range of industrial companies.

What to Check​

Outbound-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."

VPN 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.

Data 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.

Authentication: Cryptographic keys per device, individually revocable. Avoid gateways that use a single administrator password shared across all devices.

Secure firmware updates (OTA): Gateways that have not been updated become attack vectors. Verify that the gateway supports cryptographically signed OTA updates.

NIS2 and Liability​

Since 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.

Criterion 4: Robustness in Industrial Environments​

An "industrial" gateway must be able to withstand real-world industrial environments. Here are the certifications and specifications to check:

Operating Temperature​

A standard IT gateway operates between 0°C and +40°C. A true industrial gateway typically operates between -20°C and +70°C.

IP Rating​

IP20: Minimum protection; for use only in a closed cabinet in a clean room.
IP40: Protection against solid objects larger than 1 mm. Standard equipment cabinet.
IP65: Dust-tight and protected against water jets. For dusty environments (food processing, construction, outdoor use under cover).
IP67: Temporary submersion up to 1 meter. For very humid environments.
IP68: Prolonged submersion. Rarely necessary but useful for underground equipment.

Vibrations and Shocks​

For applications in industrial vehicles, overhead cranes, compressors, or vibrating environments: verify compliance with EN 61131-2 or IEC 60068 for mechanical testing.

DIN Rail Mounting​

For 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.

Regulatory Certifications​

CE (EU requirement): CE marking is required for all electronic equipment sold in Europe.
ATEX (explosive atmospheres): For chemical and oil facilities with potentially explosive atmospheres. ATEX Zone 1/2 or Zone 21/22, depending on the application.
EN 61131-2: Specific standard for equipment used with programmable logic controllers (PLCs).

Criterion 5: Zero-Touch Provisioning (ZTP)​

ZTP is a criterion that is often underestimated, especially when deploying dozens or hundreds of gateways.

Without 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.

With 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.

Questions to Ask the Provider:

• Is ZTP truly "zero-touch," or does it still require initial configuration?
• Is the M2M SIM preconfigured with the cloud server settings?
• If there is a provisioning issue, how is remote diagnostics performed?

Criterion 6: Edge Computing and Local Logic​

The most advanced gateways have enough computing power to execute logic locally, without relying on the cloud:

Local 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.

Local 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.

Data Filtering: Send only data that has changed by more than a defined threshold. This drastically reduces mobile data costs at sites with high traffic.

Logic Scripts: On advanced gateways (Eziwan, certain Teltonika models), you can run Python or JavaScript scripts locally to handle complex business logic.

Criterion 7: Management and monitoring from a centralized console​

For multi-site projects (3–4 sites or more), the centralized management console is a key differentiator:

Fleet Dashboard: Real-time view of the status of all gateways (connected/disconnected, signal strength, active alerts).

Remote firmware updates: Deploy a security update to 50 gateways with just a few clicks, without having to travel to the site.

Remote Configuration: Change an alarm threshold, add a new sensor, or modify a network setting—all from the web console.

Fleet Alerts: Receive a notification when a gateway loses its connection or when a device exceeds a threshold.

Criterion 8: Data Hosting and Digital Sovereignty​

This criterion has become strategic for French companies in light of NIS2 and digital sovereignty requirements.

Key Questions:

• Where is the data collected by the gateway hosted?
• Is the software provider subject to the U.S. CLOUD Act (as a subsidiary of a U.S. company)?
• Can the data be seized by foreign authorities without notification?
• Is the service provider ISO 27001 certified? Is it SecNumCloud (ANSSI) certified for OIVs?

For 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.

Criterion 9: Technical Support and Assistance​

Even the best gateway in the world is worthless without support that can answer your technical questions in real time:

Support 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.

Industrial expertise: Is the support team familiar with the Modbus, PROFIBUS, and Siemens S7 industrial protocols? Or is it a general IT support team?

Documentation: Is the API documented (OpenAPI 3.0)? Are there code examples? Are there Python/Node libraries?

Project Support: Does the vendor offer support during the initial deployment?

Summary Checklist: 9 Criteria​

□ 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

FAQ​

What is the difference between an industrial IoT gateway and an industrial 4G router? An 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.

Can an industrial IoT gateway be used without an Eziwan cloud subscription? The 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.

How many Modbus registers can be collected simultaneously? The 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.

What is edge computing on an industrial gateway, and do I need it? Edge 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.

How can you verify that a gateway complies with NIS2 regulations? NIS2 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.

Further Reading​

• Blog: Industrial 4G Router vs. Consumer Router — 10 Differences
• Blog: Zero-Touch Provisioning — Deploy 50 Routers in 2 Hours
• Blog: NIS2 and Industrial Cybersecurity — Requirements and Action Plan
• Guide: Remote Industrial Monitoring — Architecture and Security
• Docs: Modbus RTU integration on the Eziwan Gateway

Resources​

• Eziwan Gateway — Technical Specifications
• Comparison: Industrial Router vs. Internet Router
• Guide: Modbus RTU vs. Modbus TCP
• Industrial VPN vs. Zero Trust
• Industrial IoT ROI Calculator
• Ewon Alternatives — IIoT Solutions Comparison

Additional Resources​

• Industrial IoT Gateway — Selection Criteria and Comparison of Industrial IoT Gateways
• Eziwan Gateway — Specifications and Features of the Eziwan Gateway
• IIoT Gateway — IIoT gateway solutions for industry
• IoT Gateway — complete range of Eziwan IoT gateways
• Industrial Routers — Industrial 4G LTE routers for your remote sites
• Industrial Connectivity — Connectivity solutions for Industry 4.0

This 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.

The 4 Maintenance Strategies: Precise Definitions​

1. Corrective Maintenance​

Definition: We step in after a breakdown. When the equipment breaks down, we fix it.

Variants:

• Deferred corrective action: The failure is detected, but the repair is scheduled (non-critical equipment)
• Emergency corrective action: Critical failure; immediate action required

Typical cost: 4 to 5 times higher than the equivalent preventive maintenance (express parts, overtime, lost production).

When it is acceptable: Non-critical equipment that is easily replaceable, where the cost of monitoring exceeds the cost of failure.

2. Systematic Preventive Maintenance​

Definition: Items are replaced or overhauled according to a fixed schedule (based on time or production intervals), regardless of their actual condition.

Example: Change the oil in a gearbox every 2,000 hours, even if it is still in good condition.

Main 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.

Typical cost: 2 to 3 times higher than well-calibrated condition-based maintenance.

When applicable: Equipment with well-known and predictable degradation patterns over time, in a regulatory context that requires periodic inspections.

3. Condition-Based Maintenance (CBM)​

Definition: Action is taken when the actual condition of the equipment warrants it, based on continuous physical measurements (vibration, temperature, current, acoustic levels, etc.).

Principle: Every piece of equipment "speaks" through its data. We listen to it.

Example: The bearing is replaced when the vibration exceeds a critical threshold established during commissioning, not on a fixed schedule.

Documented ROI: A 25–55% reduction in unplanned downtime; 10–30% savings on total maintenance costs.

What's needed: Sensors installed on equipment, real-time data collection, configured alert thresholds.

4. Predictive Maintenance (PdM)​

Definition: The date of a future failure is predicted using a mathematical model (statistical or machine learning) fed with historical and real-time data.

Difference 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."

What'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.

The 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.

Comparison Based on 7 Criteria​

Which Sensors Are Best for Condition-Based Maintenance?​

Condition-based maintenance relies on physical measurements. Here are the most commonly used sensors, ranked by ROI:

1. Vibration (accelerometer)​

What we detect: Rotational imbalance, shaft misalignment, bearing damage, pump cavitation, gear wear.

Applications: Electric motors, centrifugal pumps, compressors, fans, conveyors.

Early warning signs: Increase in the overall vibration level (RMS), appearance of characteristic harmonic frequencies, increase in kurtosis (impulsivity).

Sensor cost: €50 (basic industrial model) to €500 (broadband + ICP).

Time to Failure: Detection 2 to 12 weeks before bearing failure.

2. Infrared/Thermal Temperature​

What is detected: Abnormal overheating of motors, transformers, electrical connections, bearings, and brakes.

Applications: Electrical panels, motors, bearings, cooling systems.

Warning signs: Operating temperature rises above the established reference value.

Sensor cost: €20 (PT100 contact probe) to €2,000 (fixed thermal imaging camera).

3. Electric Current (Current Clamp)​

What we detect: Load imbalance, insulation degradation, abnormal harmonics, difficult startup.

Applications: Induction motors, servo motors, drive systems.

Advantage: No mechanical installation required—the measurement is non-intrusive. Ideal for equipment that is difficult to access.

4. Acoustics / Ultrasound​

What we detect: Compressed gas leaks, electric arcs, bearing degradation under low load, lubrication issues.

Applications: Compressed air systems, high-voltage electrical cabinets, low-speed bearings.

Typical ROI: An ultrasonic compressed air audit typically identifies 15 to 30% of leaks—resulting in immediate savings on compressor electricity consumption.

5. Oil Analysis (In-Line)​

What is detected: Particle contamination, viscosity degradation, presence of water, wear particles.

Applications: Gear reducers, gearboxes, turbines, compressors.

In-line sensors: Enable continuous monitoring without sampling, with automatic alerts for particles or dielectric substances.

Practical Implementation: How to Get Started?​

Step 1: Identify Critical Equipment (Simplified FMEA)​

List your equipment and evaluate each item based on:

• Criticality (impact of a failure: production shutdown, safety, environment)
• Failure Frequency (CMMS history, if available)
• Detectability (Does the failure give advance warning, or is it sudden?)

Focus CBM sensors on equipment with high criticality and progressive failures.

Step 2: Define Key Metrics by Equipment​

For each piece of critical equipment, define which parameters to measure. Example for a centrifugal pump:

• Vibration (accelerometer on the motor-side and pump-side bearings)
• Bearing temperature (PT100 or infrared)
• Motor current (current clamp)
• Differential pressure (if pressure is critical)

Step 3: Install and Connect the Sensors​

The 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.

Step 4: Establish Baseline Values​

During commissioning, record the reference values for each parameter on new equipment or equipment in good condition. These reference values are used to:

• Set alarm thresholds (alarm at +20%, emergency at +50% of the reference)
• Detect a gradual drift from the baseline

Step 5: Calibrate the alarm thresholds​

Too 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.

Eziwan allows you to adjust thresholds from the cloud platform without on-site intervention.

Step 6: Integrate with the CMMS​

A 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.

Feedback from the Field​

Cement Plant — Main Grinder Gearbox​

Background: 800-kW gearbox, replacement cost €180,000, delivery time 6 weeks.

Before CBM: 2 catastrophic failures in 4 years. Each failure = 6 weeks of partial downtime = €420,000 in lost production.

After 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.

ROI: 9 months.

Food processing plant — packaging line​

Background: 12 gearmotors on a critical production line. Preventive maintenance at 3,000 hours (routine oil change + inspection).

After CBM (current + vibration): Of the 12 gearmotors monitored, CBM made it possible to:

• Prevent 3 unplanned shutdowns
• Reduce unnecessary preventive maintenance by 40% (oil was still clean according to analysis)
• Detect 2 alignment issues that were imperceptible to the naked eye

ROI: 11 months.

Conclusion: What Strategy Should We Adopt?​

For an industrial SME (fewer than 50 pieces of equipment): Start 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.

For a mid-sized or large company: Condition-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).

What 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.

FAQ​

What is the difference between predictive maintenance and condition-based maintenance (CBM)? Condition-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.

What type of sensor is most useful for implementing condition-based maintenance? For 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.

Further Reading​

• Blog: IIoT Predictive Maintenance — From Sensor Data to Real-Time Alerts
• Blog: ROI of Industrial IoT — Calculation and Optimization
• Blog: Modbus TCP vs. RTU — Which Protocol for Sensor Data Collection?
• Blog: Grafana for Modbus Industrial Monitoring
• Docs: OEM Machine Manufacturer Use Case

Additional Resources​

• IIoT Predictive Maintenance — predictive maintenance solutions based on industrial IoT
• Industrial Remote Diagnostics — remote diagnostics to anticipate breakdowns
• Industrial Equipment Monitoring — continuous monitoring of your industrial machinery
• Industrial Monitoring and Remote Assistance — centralized monitoring to manage maintenance remotely
• Guide: Reducing Field Visits — optimizing service calls through condition-based maintenance

This 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.

What is "industrial data," and why does its location matter?​

The industrial data generated by your IoT gateways, PLCs, sensors, and SCADA systems covers a wide range:

• Process data: temperatures, pressures, flow rates, levels—the physical measurements of your production
• Operational data: alarm statuses, machine events, maintenance logs
• Network topology data: IP addresses, installation diagrams, equipment firmware versions
• Access data: who logged in to which device, when, and from where

Taken 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.

So the question is not "Is my data sensitive?" but "Who has access to it, and under which jurisdiction?"

The Problem with the U.S. CLOUD Act​

Since 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.

In 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.

When it comes to industrial data, this risk is particularly concerning:

• Industrial espionage: Your production parameters, production rates, and formulations could be exploited by U.S. competitors
• Critical infrastructure: For OIVs (Operators of Vital Importance), the disclosure of monitoring data could pose a national security risk
• Economic intelligence: a plant’s actual production capacity, its suppliers, and its logistics flows—all of these may be of interest to state actors

Both 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.

What NIS2 Says About Data Localization​

NIS2 does not explicitly require that all data be hosted in France or the EU. However, several of its requirements indirectly lead to this:

1. Digital Supply Chain Management​

Article 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?

For 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.

2. Incident Reporting and Availability of Evidence Data​

NIS2 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.

3. Business Continuity and Resilience​

NIS2 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.

4. Penalties​

For 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.

The GDPR and Industrial Data​

The GDPR applies to personal data—which may include business data if it can be used to identify a natural person. Typical examples include:

• Remote access data: who logged in to which PLC (user ID)
• Production logs: productivity data by operator/machine (if linked to an individual)
• Maintenance data: who performed which maintenance task (named technician)
• Alarms with assignment: which person acknowledged which alarm

For 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.

Hosting in France eliminates any ambiguity: the data remains within the EEA, under GDPR jurisdiction, without the need to justify any data transfer mechanisms.

Certifications That Matter to French Industry​

Not all French hosting providers are created equal. For a mission-critical industrial IoT infrastructure, look for these certifications:

ISO 27001​

The gold standard for information security certification. Essential. Requires a documented Information Security Management System (ISMS) that is audited annually.

HDS (Health Data Host)​

Mandatory for health data (pharmaceuticals, hospitals, medical devices). ANSSI/MiPih standards.

SecNumCloud​

The 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.

ANSSI-Certified CSP (Cloud Service Provider)​

List of service providers certified for sensitive information systems.

Warning: 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.

Real-world examples: Which manufacturers are affected?​

Operators of Vital Importance (OVI)​

The 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.

Essential and Important Entities Under NIS2​

With NIS2, the scope expands significantly:

• All companies with 250 or more employees in the covered sectors
• Critical defense contractors
• Local water and energy network operators (even medium-sized ones)
• Pharmaceutical and medical device companies

Industrial SMEs that export to sensitive customers​

An 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.

How to Evaluate Your Current IoT Solution​

Here are 5 questions to ask your current or future IIoT provider:

1. Where is my data physically hosted? Ask 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.

2. Is the parent company subject to the CLOUD Act? If 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.

3. What security certifications do you have? ISO 27001 at a minimum. SecNumCloud if you are an OIV or a NIS2-designated critical entity.

4. Have you signed a GDPR Data Processing Agreement (DPA)? This is required whenever personal data is processed (which is often the case with access logs).

5. Can you provide me with a recent penetration test report? Reputable service providers publish summaries of their penetration tests or share them under an NDA.

Eziwan's Position​

The 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.

Our concrete commitments:

• Data hosted in France: ISO 27001-certified data center located in France
• Company incorporated under French law: no disclosure obligations under foreign law
• GDPR DPA: GDPR-compliant data processing agreement available upon request
• NIS2 audit log: All access to data and equipment is logged and available for ANSSI audits
• End-to-end encryption: Data encrypted in transit (TLS 1.3) and at rest (AES-256)

For NIS2 critical entities and OIVs, we can provide a comprehensive package that includes the security policy, certifications, and contractual SLAs tailored to regulatory requirements.

Conclusion: Industrial Digital Sovereignty Is No Longer Optional​

By 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?”

The risks are real and well-documented:

• Regulatory: NIS2 penalties of up to €10 million for critical entities
• Legal: unlawful GDPR data transfers that could result in fines from the CNIL
• Operational: data unavailability in the event of a dispute with a foreign service provider
• Competitive: potential disclosure of production data to foreign entities