A LinkedIn announcement rarely warrants a deep technical response. But when Teltonika Networks confirmed a strategic partnership with Schneider Electric, it was worth pausing to ask what “partnership” actually means in an industrial context – and what it means for the engineers, panel builders, and system integrators who will be expected to deliver on it.

This is not a merger, a product bundle, or an OEM arrangement. It is something more nuanced and arguably more useful: an intentional ecosystem alignment between two companies that have always been complementary but have rarely been marketed together. Schneider Electric designs and manufactures world-class programmable logic controllers, energy metering equipment, and building automation hardware. Teltonika Networks designs and manufactures rugged cellular routers and gateways that speak the same industrial protocols those devices use. The gap between them has always been closed by clever integrators – this partnership simply makes that relationship official, and starts to build a channel around it.

To understand why this matters, it helps to look at both product families in detail, understand the protocol chain that connects them, and think carefully about how the channel is expected to absorb and commercialise the combination.

The Schneider side of the stack

Schneider Electric’s relevant portfolio for this kind of industrial IoT integration spans three main product families: controllers, energy metering, and the EcoStruxure platform that sits above them.

Modicon PLCs

The Modicon range is where most industrial telemetry deployments begin. At the entry level, the Modicon M221 is a compact nano PLC designed for basic machine control – packaging lines, pumping stations, small conveyor systems. It ships with an embedded Ethernet port, a Modbus serial link, and USB programming access. It is cost-effective and widely deployed, which means there is a huge installed base in the field that needs to be brought online without full replacement. Connectivity retrofits here almost always go through the RS-485 port via Modbus RTU.

The Modicon M241 steps up to five embedded communication ports including Ethernet, CANopen, two serial interfaces, and USB. It handles more complex modular machines and is better suited to structured Modbus TCP polling over Ethernet from an upstream gateway. The Modicon M262 represents the current IIoT-ready tier – it ships with native MQTT, HTTP, OPC UA, and TLS support, meaning it can address a cloud broker directly without a translation gateway in between. That said, the M262 still benefits from a cellular router providing the WAN path, failover capability, and VPN termination that the PLC itself cannot manage.

iEM energy meters

Equally relevant for connectivity integrators is Schneider’s iEM energy meter family. The iEM3255 is a CT-connected three-phase meter with a Modbus RS-485 interface, multi-tariff capability, digital I/O, and MID certification. It is extremely common in industrial sub-metering, landlord-tenant billing, and renewable energy monitoring applications. The Modbus register map is well-documented and the meter behaves predictably as a Modbus RTU slave device on an RS-485 bus – which is exactly the kind of device a Teltonika TRB-series gateway is designed to poll and forward upstream.

EcoStruxure and PowerTag

At the platform level, EcoStruxure Machine and EcoStruxure Building are Schneider’s architecture frameworks for connecting edge hardware to apps, analytics, and cloud services. The PowerTag energy sensor range extends this to individual circuit breakers, providing wireless Modbus-to-cloud bridging for panel-level monitoring. Understanding EcoStruxure matters because it defines the data model that downstream connectivity hardware needs to serve – and any properly integrated Teltonika deployment should be able to feed data that maps coherently to EcoStruxure’s expected structure.

The Teltonika side of the stack

Teltonika Networks produces a large range of cellular devices, but for integration with Schneider industrial hardware three families are directly relevant: the TRB series gateways, the RUT series routers, and the TSW managed switches.

TRB245 – the reference gateway for serial integration

The TRB245 is arguably the workhorse device for this kind of integration. It is a compact 4G LTE gateway with a single Ethernet port, dual SIM slots, and a native RS-485 serial interface. It runs RutOS – Teltonika’s OpenWrt-based firmware – and ships with Modbus TCP/RTU client functionality and a built-in MQTT gateway as installable packages from the RutOS Package Manager. In plain terms: you can connect a TRB245 directly to the RS-485 bus of a Schneider iEM3255 meter, configure it to poll specific Modbus registers on a timed schedule, and publish the resulting data as MQTT payloads to a broker of your choice. This is precisely the integration demonstrated in real deployments – a TRB245 bridging a Schneider meter onto a cloud monitoring platform via MQTT over 4G.

RUT956 – multi-interface industrial router

Where a TRB245 is a gateway, the RUT956 is a full industrial router. It combines cellular 4G LTE, WiFi, and wired Ethernet with GNSS/GPS positioning, dual SIM auto-switching, and both RS-485 and RS-232 serial ports. The dual serial interfaces allow it to sit between multiple RS-485 device buses simultaneously. Its Modbus TCP-to-RTU gateway function means it can serve as a transparent serial-to-IP bridge, allowing a SCADA system upstream to poll Schneider devices on the serial bus as if they were Modbus TCP nodes on an IP network. For larger panel builds with multiple Schneider meters or PLCs on a shared RS-485 ring, the RUT956 is the natural step up from the TRB245.

RUT241 – the cost-effective 4G option

The RUT241 occupies an important position for panel builders who need LTE connectivity but are working to a tighter per-site budget. It is an LTE Cat 4 router with two Ethernet ports, single SIM, and the same RutOS base. Critically, it supports Modbus TCP server functionality and an onboard MQTT broker, which means it can act as a local data concentrator for multiple Ethernet-connected Schneider devices on the same panel network – including M241 or M262 PLCs communicating via Modbus TCP over Ethernet rather than serial. Many industrial HMI and PLC combinations from third-party vendors also integrate directly with the RUT241 over Modbus TCP, making it a widely compatible choice.

TSW212 – managed switch for larger panel networks

For panel builds where multiple Schneider PLCs, meters, and HMIs share an Ethernet backplane, Teltonika’s TSW212 managed L2/L3 switch is worth noting. It supports PROFINET, EtherNet/IP, and MRP – protocols common in Schneider-adjacent automation environments – alongside eight Gigabit Ethernet ports and two SFP ports for fibre uplinks. Pairing a TSW212 with a RUT956 or RUTM-series router gives panel builders a clean, DIN-rail-mountable network architecture entirely within the Teltonika ecosystem, which simplifies procurement and reduces the number of support relationships an integrator needs to maintain.

The protocol chain explained

The practical value of this technology combination only becomes clear when you map the full data path from a field device to a cloud dashboard. It is worth doing this explicitly, because it is often glossed over in partnership announcements.

At the left end, the Schneider device speaks Modbus RTU over a two-wire RS-485 serial bus. Modbus is worth understanding properly here: it was originally published by Modicon – the company that became Schneider Electric’s PLC division – in 1979, and it has endured because it is simple, deterministic, and universally supported. A Modbus RTU transaction is a straightforward request-response cycle: the master device (the Teltonika gateway) sends a function code and register address; the slave device (the Schneider meter) responds with the requested data. Common function codes for reading analog data are FC03 (read holding registers) and FC04 (read input registers). The iEM3255’s Modbus register map is publicly documented by Schneider and maps directly onto voltage, current, power factor, active energy, and multi-tariff consumption data.

The Teltonika device acts as the protocol translation layer. In TRB245 terms this means operating as a Modbus RTU master on the RS-485 side and an MQTT publisher on the WAN side. RutOS allows you to configure polling intervals per register group, define the JSON structure of the published payload, and set the MQTT broker address, topic hierarchy, and TLS credentials. The result is structured telemetry data flowing upstream at configurable intervals – typically anywhere from 15-second real-time monitoring to 15-minute interval logging for billing applications.

The WAN path is the 4G LTE cellular connection. The TRB245 and RUT956 both support dual SIM slots with automatic failover based on configurable conditions: signal quality thresholds, data limit proximity, roaming detection, or network denial. This multi-SIM capability is essential for any deployment where connectivity continuity is a commercial commitment rather than a best-effort consideration.

The upstream broker and analytics layer varies by deployment. In simpler setups, MQTT data flows into Grafana via an InfluxDB time-series backend – Grafana is free, flexible, and handles the kind of energy monitoring dashboards these deployments require very well. More structured enterprise deployments typically route through AWS IoT Core or Azure IoT Hub, where the MQTT protocol is natively supported and the platform handles device authentication via X.509 certificates. The Teltonika devices support TLS on MQTT, OpenVPN, and WireGuard – so the security layer of the WAN transport can be properly hardened regardless of which cloud platform is used upstream.

What the reference stack actually looks like in a panel

Panel builders need practical answers, not protocol diagrams. The combination of a Schneider Modicon PLC or iEM meter with a Teltonika cellular gateway resolves to something very manageable in a standard DIN-rail enclosure.

A typical sub-metering or remote monitoring panel in a utility cabinet or kiosk might contain a Schneider iEM3255 wired to a CT clamp assembly for non-invasive current measurement, connected via a two-wire RS-485 cable to the serial port of a TRB245. The TRB245 takes a 12V DC or 9-30V wide-input supply from the same DIN rail, meaning no additional PSU is required if a suitably rated Schneider or Phoenix Contact power supply is already fitted. The cellular antenna – typically an external MIMO antenna – routes through an SMA bulkhead fitting on the enclosure wall. Data flows over 4G, the configuration lives on the gateway, and there is nothing in the cabinet that requires a laptop to maintain in normal operation.

Where a Modicon M241 or M262 PLC is also present, the topology shifts slightly. The PLC may communicate via Modbus TCP over Ethernet, in which case the Teltonika router sits on the same Ethernet segment and polls the PLC as a Modbus TCP slave rather than using the RS-485 serial port. The RUT956 handles this well because it can simultaneously manage serial RS-485 polling from one device class and Ethernet Modbus TCP polling from another, aggregating both data streams for upstream publication.

The channel impact: distributors, panel builders, and system integrators

An open-ecosystem alignment like this shifts the responsibility for integration down the channel. Because there is no single proprietary bundle to buy, every stakeholder in the supply chain absorbs a different portion of the technical translation work.

The recurring revenue model for integrators is worth examining more closely. A site-level cellular data subscription – typically a multi-network IoT SIM provisioned for resilience across multiple operator networks – generates monthly recurring revenue that scales with the number of monitored assets. Bundled with remote monitoring support, firmware management via Teltonika RMS, and alert-based incident response, the model transitions from installation income to a predictable service relationship. That is a significant commercial shift for integrators who have traditionally worked on project-by-project margin.

The antenna problem nobody talks about

The part of these deployments that is most frequently underspecified is the antenna. Industrial enclosures – powder-coated steel cabinets, GRP kiosks, reinforced concrete substations – present meaningful RF attenuation challenges. A Teltonika router performing well in a lab environment on a stub antenna will behave very differently when that same antenna is inside a sealed metal enclosure with a 4G signal that needs to reach a macro cell 2km away.

The correct solution in almost all industrial installations is an external antenna routed through a bulkhead – either SMA or N-type depending on cable run length – to a MIMO panel or omnidirectional antenna mounted on the outside of the enclosure or on a nearby mast. The TRB245 has two SMA antenna ports supporting 2×2 MIMO, as does the RUT956. For high-RSRQ environments or sites with long cable runs to the antenna, active or high-gain directional antennas become necessary rather than optional. Specifying the antenna correctly at the design stage – including cable loss calculations for the coaxial run between router and external mount point – is the difference between a stable, performing cellular link and an intermittent one that generates support calls.

Remote management: RMS and the case for lifecycle thinking

Teltonika’s Remote Management System (RMS) provides a cloud-based management plane for deployed Teltonika devices. From RMS, integrators can access device configuration remotely, push firmware updates, establish on-demand VPN tunnels to devices behind NAT for troubleshooting, and monitor cellular signal quality and WAN uptime metrics across a fleet. For integrators maintaining tens or hundreds of deployed sites – each with a Schneider automation stack behind a Teltonika gateway – RMS is not an optional add-on. It is the tool that makes fleet-scale support operationally viable.

This matters particularly in the context of the Schneider partnership because many of the assets being monitored – energy meters, PLCs on pump stations, variable speed drives on HVAC plant – are in locations where physical access is costly and infrequent. The ability to reconfigure a Modbus polling schedule, update MQTT broker credentials, or diagnose a connectivity issue from a browser rather than a site visit is a direct operational saving. Over a three-to-five-year asset lifecycle, that saving compounds into a meaningful cost advantage for managed service providers.

What comes next: SGP.32 and the active antenna horizon

The current deployment model – router in enclosure, coaxial cable to external antenna – has a fundamental weakness. High-frequency RF coaxial cable introduces insertion loss that worsens with cable length and frequency. At the LTE Band 3 frequencies (1800 MHz) used by many UK cellular networks, a 5-metre run of RG58 coaxial introduces approximately 1-1.5 dB of signal loss before the signal even reaches the modem. In marginal signal environments, that loss matters.

The emerging response to this problem is the active antenna unit – an antenna housing that integrates the cellular modem directly within the antenna enclosure at the point of best signal, outputting a simple digital interface (USB or Ethernet) rather than a raw RF coaxial feed back to an indoor router. This eliminates the coaxial cable loss entirely. Powering the modem inside the antenna via Power over Ethernet or USB power delivery means the only cable running between the enclosure and the antenna is a standard Cat5e or Cat6 data cable.

Two developments are making this architecture practical. The first is the availability of MFF2-format embedded eSIM chips – soldered directly onto the modem PCB during manufacture, resistant to vibration and thermal cycling, with no physical SIM tray to ingest moisture or corrode. The second is the GSMA SGP.32 standard for remote SIM provisioning on constrained IoT devices. SGP.32 replaces the legacy SMS-based carrier switching model with an IP-native, push-based architecture that allows network profile updates to be delivered over the air without physical access to the device. An active antenna with an MFF2 eSIM and SGP.32 support becomes truly field-maintainable – carrier changes, network profile updates, and roaming policies can all be managed remotely, from the same RMS-type platform used to manage the broader device fleet.

For panel builders, this represents an eventual simplification of the bill of materials: no SMA bulkhead, no coaxial run, no separate router chassis, just an active antenna on the outside of the enclosure and a data cable to an edge compute unit or next-generation controller inside. For the Schneider integration specifically, it means the cellular transport layer may eventually disappear inside the antenna and become invisible to the automation engineer entirely – a connectivity utility, not a device to be configured and managed separately.

Practical considerations for your next project

For engineers and project managers evaluating this combination for an upcoming deployment, a few practical points are worth carrying into the specification stage.

Modbus register mapping takes time. Schneider publishes register maps for the iEM series and Modicon PLCs, but the mapping exercise – identifying which registers correspond to which data points, understanding register data types (16-bit integer, 32-bit float, byte order), and configuring the TRB245 or RUT956 to poll them correctly – is skilled work that needs to be costed into the integration budget. RutOS provides a graphical Modbus client configuration interface that reduces this to a table of register definitions, but the definitions still need to come from the Schneider documentation or direct device interrogation.

MQTT topic design is an architectural decision. Topics should be structured to support both current monitoring needs and future expansion – a flat topic like /data is unusable at scale. A structure such as /site/{site-id}/device/{device-id}/telemetry allows a subscriber to filter by site, device type, or individual asset without consuming the full stream. This decision should be made before the first gateway is configured, not retrofitted when you have 50 deployed devices publishing to an unstructured topic namespace.

IoT SIM selection deserves proper attention. A standard consumer SIM provisioned on a single network is not appropriate for unmanned industrial deployments with multi-year operational expectations. Multi-network IoT SIM contracts – where the SIM can register on the best available network at any given site – provide meaningful resilience. Pairing this with the TRB245’s dual SIM capability gives a second layer of failover at the hardware level.

Finally, the enclosure thermal environment matters for both Schneider and Teltonika hardware. A steel cabinet in direct sunlight in summer can reach internal temperatures well above the stated operating ranges of some DIN-rail equipment. Both product families publish operating temperature ranges that need to be checked against the expected thermal environment, and ventilation or active cooling specified if necessary.

The SIM card reality: dynamic IP, CGNAT, and secure remote access

There is a dimension to industrial cellular deployments that partnership announcements never mention, but that every integrator encounters within minutes of commissioning their first site: the SIM card almost certainly does not have a publicly routable IP address, and inbound connections to the deployed device are not possible without additional architecture. Understanding this – and the layered solutions built around it – is as important as understanding the Modbus protocol chain itself.

Why most IoT SIMs carry dynamic private IPs

The default behaviour of a cellular IoT SIM on a shared APN is to receive a private IP address from the carrier’s Carrier-Grade NAT (CGNAT) pool. CGNAT address ranges fall within the RFC 6598 block (100.64.0.0/10) or the standard RFC 1918 private ranges (10.x.x.x, 192.168.x.x). In either case, the address is not routable on the public internet – nothing outside the carrier’s network can initiate an inbound TCP connection to the deployed router. This is deliberate and generally sensible: dynamic private IPs are substantially cheaper than static public addresses, available in unlimited quantity, and present a meaningfully smaller attack surface.

The consequence is that tens of thousands of Schneider automation sites – energy meters, pump station PLCs, HVAC plant – sitting behind Teltonika routers on standard IoT SIMs are genuinely unreachable from the outside world without additional architecture. An engineer who wants to remotely access the EcoMachine programming environment on a Modicon M241, or pull a diagnostic log from a TRB245 running Modbus polling, cannot simply open a browser and connect to the device’s IP. A secure intermediary layer is required.

The outbound VPN tunnel: the de facto architecture

The standard engineering response to the CGNAT problem is an outbound-initiated encrypted tunnel. Rather than waiting for inbound connections the carrier NAT will never allow through, the router establishes an encrypted connection outward to a fixed server endpoint. This tunnel remains persistent – or automatically re-establishes when the SIM IP changes or the cellular session reconnects – and all remote access flows through it in either direction. The result is a stable, privately addressed channel to the device, regardless of what the underlying SIM IP happens to be at any given moment.

RutOS supports OpenVPN, WireGuard, IPsec, ZeroTier, and L2TP natively. OpenVPN is the most widely deployed in this sector – mature, reliable through CGNAT, and capable of certificate-based X.509 authentication. Teltonika’s own RMS VPN Hub service runs on OpenVPN with AES-256 encryption, provisioned entirely from within the RMS web interface with no VPN server infrastructure to maintain on the integrator’s side. WireGuard is increasingly preferred for new builds: its smaller codebase, faster handshake, and lower CPU overhead on the router are meaningful when the device is simultaneously running Modbus polling, MQTT publishing, and signal-quality monitoring. For integrators managing 50 or more sites, a self-hosted WireGuard or OpenVPN server on a VPS with a static IP is often the more cost-effective path once the fleet exceeds the point where per-device credit models become inefficient.

Specialist secure remote access platforms for OT environments

Beyond the general-purpose VPN infrastructure described above, a separate and significant market has developed around purpose-built secure remote access platforms for operational technology environments. These are not generic VPN tools adapted for industrial use – they are products designed from the ground up around the specific constraints of OT remote access: non-IT personnel commissioning equipment, strict machine LAN isolation from corporate networks, audit trail requirements, and the need for an engineer to work inside a PLC programming environment exactly as if sitting on site. Three platforms in particular are widely deployed in the same industrial environments where Schneider Modicon and Teltonika hardware operates.

Tosibox: hardware key, hardware lock

The Finnish company Tosibox has built a distinctive and genuinely differentiated approach to industrial remote access around the concept of a physical cryptographic key device. The Tosibox Lock is a DIN-rail-mountable industrial gateway that sits on the machine LAN and establishes the remote access endpoint. The Tosibox Key is a USB dongle – an intelligent cryptoprocessing device – that the engineer physically plugs into their laptop. When the Key is plugged in and the Tosibox client software is running, it automatically establishes an encrypted VPN tunnel to any paired Lock, providing full access to the devices on that machine network as if the engineer were patching directly into the local switch.

The security model is hardware-rooted in a way that software-only VPN clients cannot replicate: the cryptographic material that authenticates the session lives on the Key device itself, not on the engineer’s laptop. If the laptop is compromised, the Key is not. Permissions can be granted, revoked, and scoped at the Lock level – allowing an OEM machine builder to access their own equipment on a customer site without the customer’s IT team needing to open firewall ports or maintain VPN infrastructure. The Tosibox Plug and Go connection method pairs Lock and Key physically during commissioning (plug the Key into a computer on the same network as the Lock), after which all subsequent remote access is automatic over the internet via the encrypted tunnel. The Lock range covers the Lock 150, Lock 200, and Lock 500 models, with Lock 200 specifically designed for DIN-rail installation in industrial panels. A SoftKey option is available for users who want software-only access without the USB hardware token.

eWON Cosy+ and Talk2M: the machine builder’s standard

HMS Networks’ eWON product family has accumulated over 600,000 registered devices in industrial deployments worldwide and is widely considered the benchmark for machine-builder remote access. The Cosy+ is a compact DIN-rail gateway that connects to the machine LAN via Ethernet or serial interfaces, and to the internet via wired Ethernet, WiFi, or cellular. It establishes an outbound OpenVPN connection to Talk2M – HMS’s dedicated industrial cloud service – and the engineer connects to that same Talk2M account using the eCatcher desktop client, which is provided free of charge.

The Cosy+ has been explicitly tested and documented for compatibility with Schneider Electric PLCs alongside Rockwell Automation, Siemens, Mitsubishi, Omron, and others. It includes a hardware Secure Element chip certified to Common Criteria EAL, providing a hardware root of trust for the device identity – meaning the cryptographic credentials stored on the Cosy+ cannot be extracted or spoofed by software attack. A physical key switch input allows the end user to physically enable or disable the remote connection at the machine panel, which satisfies safety-critical requirements in environments where an unexpected remote engineer action could cause harm. Talk2M itself is ISO 27001 certified and audited by the independent cybersecurity firm NVISO. The Cosy+ also carries an RS-485 interface, making it capable of reading Modbus RTU data from Schneider meters or PLCs simultaneously with its remote access function.

Secomea: browser-based OT access without a local client

The Danish company Secomea takes a three-component approach: the SiteManager hardware gateway installed at the machine, the GateManager cloud server that brokers connections and manages permissions, and the LinkManager software that runs on the engineer’s computer. The distinctive characteristic of the Secomea approach is that access can be initiated directly from a browser via Secomea Prime, without installing a local VPN client – the engineer logs into the GateManager portal and is presented with a list of the machines and devices they are authorised to access. Clicking through creates a secure connection to the target equipment with the engineer operating it exactly as if on site.

The SiteManager 15xx and 35xx series gateways support up to 100 connected industrial devices per unit, accessible via Ethernet, serial, and USB. They support RDP, VNC, SSH, Telnet, HTTPS, Modbus TCP, PROFINET, and OPC UA natively, with no additional configuration required for most PLC and HMI brands. Secomea is certified to IEC 62443, NIST, and BSI security standards – the same framework increasingly being cited in UK government critical national infrastructure guidance. The GateManager supports SSO via Azure AD and Okta, making it compatible with enterprise identity management infrastructure. The absence of conflicting IP subnet issues (a common VPN headache) and the drag-and-drop access management interface are often cited by integrators as reasons for choosing Secomea over generic VPN infrastructure for large managed estates.

IXON Cloud: machine builder remote access with integrated IIoT

IXON is a Dutch platform that combines secure remote access with machine data logging in a single product. The IXrouter3 and SecureEdge gateways are DIN-rail devices that connect to the machine LAN and establish a secure VPN connection to IXON Cloud, a distributed VPN service running across more than 50 servers globally. Engineers access machines via browser through the IXON Cloud portal – no local VPN client is required for most access modes. The platform explicitly supports Schneider Electric PLC remote access alongside Siemens, Allen-Bradley, Beckhoff, and others, with native protocol support for OPC-UA, Modbus TCP, EtherNet/IP, and Siemens S7.

The SecureEdge Pro variant adds a TPM chip for secure cryptographic key storage, secure boot, and IEC 62443-4-2 certification at the hardware level. IXON operates a no-user-licence model, meaning an unlimited number of engineers and customers can be granted access to machines without per-seat cost – an important commercial consideration for machine builders who need to provide remote support to dozens of customer sites. The platform’s integrated data logging capability means the same gateway that provides engineer access also collects Modbus register data for cloud dashboards and alarm notification, effectively combining the telemetry function of a Teltonika TRB245 and the remote access function of an eWON Cosy+ into a single unit.

Choosing between approaches

The choice between a general-purpose VPN architecture (RMS VPN Hub, self-hosted WireGuard) and a specialist OT remote access platform (Tosibox, eWON, Secomea, IXON) is largely a question of who bears the integration responsibility and what the primary use case is. General VPN infrastructure gives the integrator full control and is lower cost per site at scale – it is well-suited to telemetry-first deployments where the primary flow is outbound Modbus data via MQTT and remote engineer access is an occasional maintenance requirement. Specialist OT platforms shift the security architecture responsibility to a dedicated provider, are faster to commission for non-IT personnel, and are better suited to deployments where remote access to PLC programming environments is a frequent, primary workflow – machine commissioning, predictive maintenance, remote software updates.

In practice, many large industrial estates use both. A Teltonika RUT956 running MQTT telemetry via dynamic IP SIM handles the data channel. An eWON Cosy+ on the same panel LAN handles the OT engineer access channel. The two functions are independent, use different network paths, and are managed by different teams – which is exactly the right security architecture for environments where telemetry data and engineering access have different trust requirements.

The SIM: multi-network IoT, not consumer data

Regardless of which remote access architecture is chosen, the SIM selection matters. A standard consumer SIM provisioned on a single network is inappropriate for any unattended industrial deployment with multi-year operational expectations. The practical requirements are: a multi-network roaming profile that can register on whichever operator provides the strongest signal at a given site, low data plans structured for M2M traffic profiles (not video streaming), and a provider who will not suspend accounts for non-standard usage patterns. Specialist IoT SIM and roaming SIM providers supply SIMs specifically configured for M2M deployments – with multi-network steering, data plans that suit low-volume telemetry, and support teams who understand industrial use cases rather than treating an always-on cellular router as a fair-usage violation. The dual SIM capability of the TRB245 and RUT956 provides a second hardware failover layer independent of the network – if the primary carrier’s service degrades at a site, the router switches to the secondary SIM and re-establishes both the MQTT telemetry session and the VPN tunnel automatically.

For deployments in remote or infrastructure-critical locations – particularly rural energy assets or utility substations where mainstream 4G coverage is marginal – it is also worth evaluating LTE Band 450 (LTE450). This sub-GHz spectrum, used by specialist operators across parts of Europe and increasingly under evaluation in the UK, offers significantly better building and ground penetration than mainstream LTE bands and has been specifically adopted for utility and energy sector IoT in several markets. A TRB245 or RUT956 supporting Band 450 on the relevant regional variant can maintain connectivity in locations where Band 3 or Band 20 LTE simply cannot reach. The antenna considerations for 450 MHz are also different – wavelength at 450 MHz is approximately 66 cm, meaning antenna gain and physical size requirements differ from a standard 700/800 MHz deployment.

The longer-term horizon for SIM management in large estates points toward eUICC and the SGP.32 standard for constrained IoT devices. Rather than physically visiting sites to swap SIM cards when a carrier contract changes or coverage priorities shift, eUICC-capable deployments allow network profiles to be updated over the air. The SGP.32 standard specifically addresses the remote SIM provisioning model for IoT devices that cannot run a full browser-based provisioning flow – which describes precisely the kind of headless Teltonika gateway installed in a sealed industrial enclosure on a remote energy site. For estates being specified today with a five-to-ten-year operational horizon, including eUICC-capable hardware in the specification is worth serious consideration even if SGP.32-based provisioning infrastructure is not yet in use by your SIM provider.

Conclusion

The Schneider Electric and Teltonika partnership formalises something that experienced industrial integrators have been building quietly for years: a full-stack architecture from automation-native field device to cloud analytics platform, using open protocols and commercially available components at every layer. The Modbus-to-MQTT translation that a TRB245 or RUT956 provides over a 4G cellular link is not a proprietary black box – it is a well-documented, configurable data path that puts system integrators firmly in control of the specification.

What the partnership changes is the channel around that architecture. It creates a commercial signal that specialist connectivity suppliers, industrial distributors, and panel builders can align their procurement and support models to. It also creates an expectation among Schneider Electric customers that their automation hardware can be connected remotely without specialised integration work – which is an opportunity for integrators who can deliver that outcome as a productised service rather than a bespoke project.

The forward trajectory – active antennas, SGP.32 remote profile management, embedded eSIM – will eventually simplify the connectivity layer further. 5G RedCap (Reduced Capability) is also worth monitoring in this context: positioned between LTE Cat 4 and full 5G in terms of capability and cost, RedCap modules will enable a new tier of cellular IoT devices that offer lower latency and higher throughput than current 4G gateways without the cost and power overhead of full 5G, which is relevant for the next generation of Schneider-adjacent edge compute hardware. But the integration model, the protocol chain, and the commercial dynamics of the channel will remain recognisable. Understanding them now, and building the technical competence to deliver on them reliably, is the foundation for a recurring-revenue service model in industrial IoT.