Race to the Edge: Smart Modules, SGP.32 and IoT Hardware

It started with a Raspberry Pi question

The question was narrow enough. If you were designing a commercial IoT product today, something built in the thousands or tens of thousands rather than as a one-off, would you still reach automatically for a Raspberry Pi 5? Not for a hobby build. For a real product: a vending machine, a kiosk, a smart locker, an EV charger, a payment terminal, a piece of industrial equipment.

That led into the usual territory of Compute Modules, industrial single-board computers, system-on-modules and embedded x86. Then it ran into cellular smart modules, and the question changed shape. Some of these parts are no longer really modems. They are small computers with 4G or 5G built in. And once you see them that way, a second question follows almost immediately: if the cellular module can run the application as well as provide the connection, do you still need the separate computer next to it? And if that product was only using a small 4G router to get the computer online, do you still need the router either?

The more you pull that thread, the bigger it gets. Because at the same time as cellular modules are turning into computers, industrial routers are turning into computers too, and embedded computing platforms are becoming more industrial and more connected. Three different industries, approaching the same ground from three different directions. The edge.

Start with a vending machine

A vending machine is a useful example because it makes the architecture easy to see. A modern one already carries some form of application computer, quite possibly running Linux, handling the display, stock levels, payment terminal, sensors, machine control and the link back to the operator's platform. Then it needs connectivity, and a perfectly normal way to provide it looks like this:

Application computer → Ethernet → 4G router → SIM → mobile network

You might reach for something like a compact industrial router. There is nothing wrong with that. The router arrives as a finished, certified product with its own modem, SIM interface, networking stack, firewall, VPN support and remote management. For a retrofit or a modest deployment, it is an excellent answer.

But there is a different question if you are not retrofitting fifty machines. What if you are designing the next vending platform and expect to build fifty thousand of them? That is where it gets interesting.

What is the router actually doing?

This is the first question worth asking. If the router is connecting several Ethernet devices, terminating VPNs, running firewall rules and VLANs, handling dual-WAN and failover, then it is doing a proper router's job. Keep it. A factory installation with PLCs, cameras, an HMI and a SCADA link genuinely needs that.

Sometimes, though, the architecture is really just computer, router, internet. The router may be capable of twenty clever things while the product only wants the twenty-first: give me a mobile data connection. In that situation you have one computer talking to another computer that happens to contain a modem. At ten units, nobody cares. At fifty thousand, you probably should.

The modem became a computer

This is the part that changes the thinking. Companies such as Quectel, Fibocom and Telit Cinterion have sold cellular modules for years, and the mental model was simple: your processor runs the application, the module provides the connection. Their current smart modules break that model. Inside a modern smart module you can find multi-core 64-bit processors, memory, storage, Linux or Android, graphics, camera and display interfaces, Wi-Fi, Bluetooth, GNSS and, at the top of the range, dedicated neural processing for on-device AI.

At that point, calling it a modem is misleading. It is closer to a small embedded computer with a cellular modem already inside it. And it gives the module maker a very different pitch. Instead of "use our modem with your computer", they can increasingly say "run the application on our module". The full spec-by-spec picture, from an entry-tier Cat 4 part to a 48 TOPS edge-AI flagship, is in our reference guide to IoT smart modules. What matters here is the direction of travel.

It is not one-sided marketing, either. In late 2025 Quectel launched finished smart single-board computers of its own, describing them as fully finished hardware that can be integrated straight into a customer's larger system. When a cellular module company starts shipping SBCs, the boundary between the two industries has already gone.

Put that together and the traditional vending-machine stack starts to collapse.

So why haven't we always done this?

Because integration brings its own problems. A separate industrial router is an abstraction layer. The product maker builds the machine while someone else worries about cellular networking. Need another operator? Change the SIM. Need to diagnose the link? Log into the router. It is a clean boundary between the machine and the network, and embedding the connectivity deep in the product removes that comfort.

There has also always been an awkward question hiding underneath: what happens when you want to change mobile operator? With a removable SIM the answer is obvious, if inconvenient. Open fifty thousand machines and swap the card. At least the mechanism exists. Embed the connectivity and manufacturers understandably become nervous about locking themselves into today's operator for the entire life of the product. That is exactly where SGP.32 enters the story.

SGP.32 changes more than the SIM

Most explanations of SGP.32 focus on connectivity, and reasonably so. It is the GSMA specification for remotely provisioning and managing eUICCs in IoT devices, especially devices constrained by their user interface or their network connection. It introduces the eSIM IoT Remote Manager, or eIM, so that profile operations can be initiated remotely rather than by someone standing beside the device with a QR code.

A word on version, because it matters for anyone specifying hardware now. The GSMA published SGP.32 v1.3 on 28 May 2026, but v1.2 remains the version formal certification is issued against, so the two coexist while the certification programme catches up. The current UK and European state of play is covered in our SGP.32 mid-2026 briefing. The important point for hardware design is not the version number, though. It is what the architecture makes possible.

One device, one eUICC, personalise it later

Here is the idea that is easy to underappreciate. The value is not simply remote SIM switching. It is that you can build the device once, embed the eUICC, seal the product, and decide the connectivity later. That changes the manufacturing process itself.

For a manufacturer that can mean no SIM tray, no SIM door, no production worker fitting the wrong SIM, no card working loose, no need to open a sealed product just to change provider, and fewer connectivity-specific hardware variants. For a smart meter, an EV charger or an outdoor kiosk that has to stay sealed against water and tampering, that is a far cleaner mechanical proposition.

The bigger point is procurement. With a physical SIM, connectivity often becomes part of production: which SIM, which operator, which country, which batch. SGP.32 offers a route to separating the hardware decision from the final connectivity decision. Build the hardware, then personalise the connectivity, potentially after the product has reached its destination country, and potentially again years into its life. None of this abolishes commercial lock-in or interoperability work, and an eSIM on a datasheet is not the same as a working SGP.32 implementation. But the physical SIM no longer has to be the reason you keep a replaceable connectivity layer, and that makes deeply integrated hardware far more attractive.

Meanwhile, routers are becoming computers

While cellular module makers turn modems into computers, router makers are doing almost the opposite: turning routers into application computers. Robustel's platform now ships a Debian application environment with container support, and its edge boxes pair that with a small NPU. Teltonika's RUTC41 runs Docker containers alongside a full router stack, which we covered in Teltonika's move into edge computing. Milesight's UR75 runs Node-RED natively. The argument writes itself: why put a separate SBC next to the router when the router can run the application?

So there are now two attacks on the old two-box architecture. The module maker wants to absorb the computer. The router maker wants to absorb the computer. And the embedded-compute vendor is trying to make its computer more industrial and better connected. Which architecture actually fits which deployment is worked through in detail in our guide to SBC vs industrial router for edge computing.

Raspberry Pi is moving too

The third direction is embedded compute, and Raspberry Pi is the clearest illustration. It started as an educational board, but Compute Module 5 is a very different proposition, designed to be integrated into finished products on a carrier board that carries exactly the interfaces a product needs. Raspberry Pi has committed to keeping CM5 in production until at least January 2036, and says that between roughly seventy and eighty per cent of its units now go into industrial and embedded applications. The delay to the next-generation Pi and what it means for industrial designs is covered in our Raspberry Pi 6 analysis.

So the module maker has gone modem to smart module to embedded compute platform. The router maker has gone router to gateway to edge compute platform. And Raspberry Pi has gone SBC to compute module to embedded industrial platform. Three journeys, one destination.

And then there is AI

Artificial intelligence adds another reason for processing to move into the device. Machine vision, people counting, product recognition, acoustic monitoring, anomaly detection: sending every frame to the cloud is rarely ideal once latency, bandwidth, cost and privacy are in play. That pushes more compute on-device, and it is exactly why smart modules have grown dedicated neural processing, from around 12 TOPS on a mid-range 5G part to tens of TOPS on a flagship. The module companies do not just want to connect the edge device. They increasingly want to supply the silicon doing the edge processing.

This is not the death of the router

It is worth being clear, because the convergence story is easy to overstate. Smart modules are not about to wipe out industrial routers. Where an installation genuinely needs routing, VLANs, firewalling, multiple Ethernet ports, dual-WAN, dual-SIM or mature remote network management, a router is the right tool and remains so. That is a networking problem, and networking is what routers are for.

The pressure is narrower than it looks. It falls on the case where a manufacturer fits a small router inside a product mainly because the product's computer needs 4G. There, a smart module does not have to recreate every feature of a mature router operating system. It only has to provide the features that particular product actually uses.

Retrofitting and designing are different problems, too. Connecting five hundred existing machines with compact routers can be entirely rational: no redesign, no carrier board, no RF project. Designing a new platform for a hundred thousand units is a product-architecture decision, and it deserves far more scrutiny. And SGP.32 does not remove every layer of complexity either. It involves the eUICC, the IoT Profile Assistant and the eIM working together with modem firmware and a provisioning platform. Nobody should read "eSIM" on a datasheet in 2026 and assume SGP.32 support. Ask which firmware, which eUICC, where the profile assistant runs, and which platforms have actually been tested.

What would we build?

There is no single correct architecture, only a set of sensible answers to different problems.

The full decision framework, worked through deployment by deployment, is in our SBC vs industrial router guide.

The antenna does not disappear

One final catch. Remove the router and you have not removed the radio. A finished industrial router hands you defined antenna connectors and an approved RF platform. Put the cellular module directly onto your product board and the RF problem becomes yours. Depending on the technology you may need a main cellular antenna, a diversity antenna, 2×2 or 4×4 MIMO, GNSS, Wi-Fi and Bluetooth, and all of them have to coexist inside the real product. Placement, ground planes, isolation, cable loss and enclosure material all matter. A plastic kiosk is one thing; a steel vending machine is another. Removing the router does not remove the connectivity engineering. It moves it into the product-development stage, where it is arguably harder.

So who wins the race?

Probably nobody outright. Different architectures will keep suiting different jobs. Retrofitting existing machinery still favours the industrial router. Connecting a whole site still needs one. A low-power sensor is still best served by a microcontroller and a small modem. But for a high-volume connected product, smart modules are becoming hard to ignore, and once SGP.32 makes it practical to embed connectivity without tying the hardware permanently to one operator, they become harder to ignore again.

That is why the opening question has changed. It is no longer "Raspberry Pi or industrial router?" It is "what actually needs to exist inside this product?" Compute, cellular, routing, local networking, AI inference, industrial interfaces, remote management. Then: how many separate devices do we really need to provide them? Sometimes the answer is still an SBC and a router. Increasingly, sometimes it is one part where there used to be three.

I went looking for Raspberry Pi 5 alternatives. I found a race to the edge. The practical follow-up, building the same product two ways and counting what each really costs, is coming next in Raspberry Pi 5 alternatives for commercial IoT.

Frequently asked questions

Related reading