Choosing the right gateway for an IoT system starts with the work the gateway must do, not with a catalogue. An IoT gateway sits between the field devices and the cloud, translating protocols, filtering data, running local decisions and holding the security boundary, so off-the-shelf versus custom is an architecture decision for the whole edge computing project.
If you are choosing a gateway now: list the protocols it must speak (Modbus, CAN, BLE, MQTT or others), the decisions it must make when the network is down, the security boundary it must hold and how long the product must stay in production. Those four answers decide between off-the-shelf and custom before any datasheet does. Each of the four is worked through in turn.
In modern edge computing architectures, the IoT gateway is more than a connectivity device. It acts as the operational brain of distributed systems, orchestrating communication between sensors, embedded devices, and cloud infrastructure. Selecting the right gateway architecture can determine whether an IoT deployment scales smoothly or becomes a long-term engineering bottleneck.
Through real-world implementations across industrial automation, healthcare, and connected infrastructure, one lesson becomes clear: the gateway is mission-critical. It is the control layer, the data filter, and often the first line of security in any connected system.
For organisations investing in IoT product development services, understanding how to evaluate gateway options is essential to building reliable, future-ready edge computing systems.
What does an IoT gateway do in an edge computing architecture?
An IoT gateway in an edge computing architecture translates between field protocols and the cloud, aggregates and filters data locally, runs real-time decision logic, authenticates devices, coordinates over-the-air updates and increasingly hosts AI inference. It is the point where you decide what leaves the site, at what rate and in what format.
An IoT gateway sits between edge devices and centralised systems, managing communication, computation, and security. While sensors generate raw data and cloud platforms provide analytics and storage, the gateway determines how data moves between these layers.
In edge computing environments, gateways typically handle:
- Protocol translation (Modbus, CAN, BLE, MQTT, etc.)
- Local data aggregation and filtering
- Real-time processing and decision logic
- Device authentication and encryption
- Over-the-air (OTA) update coordination
- Edge AI inference pipelines
Without a properly designed gateway layer, IoT systems become overly dependent on cloud connectivity, leading to increased latency, higher bandwidth costs, and greater operational risk.
This is where strong hardware firmware development becomes essential. The gateway must be engineered as both a hardware platform and a software-defined system that can evolve.
The four protocols in that list, what each one carries on a gateway and where its specification lives
| Protocol | What it carries on a gateway | Specification source |
|---|---|---|
| Modbus | Register reads and writes to PLCs and drives, serial or TCP | Modbus Organization |
| CAN | Frames from vehicle and machine controllers | ISO 11898-1:2024 |
| BLE | Low-power sensor and wearable links | Bluetooth Core 6.1 |
| MQTT | Publish and subscribe messaging to the cloud broker | OASIS standard, mqtt.org |
The translation job is rarely one protocol in and one protocol out. A factory gateway often speaks Modbus to a drive on one port and a legacy serial protocol on another before anything reaches MQTT, which is why our post on bridging legacy and modern industrial protocols treats the protocol list as the first design input for a gateway, not a checkbox.
When is an off-the-shelf IoT gateway the right choice?
An off-the-shelf IoT gateway is the right choice when the deployment is early, the protocols are standard, the workload is predictable and the customisation needed is small. It brings certified wireless modules, industrial I/O and a standard operating system on day one, so a team moves from prototype to pilot without designing hardware.
Off-the-shelf (OTS) gateways are often the fastest way to get an IoT deployment started. These pre-built platforms typically include certified wireless modules, industrial I/O interfaces, and standardised operating systems.
Their biggest advantages include:
Faster deployment cycles: OTS gateways allow teams to move from prototype to pilot quickly without designing custom hardware.
Industrial certifications: Many OTS platforms already meet safety and compliance requirements, reducing validation effort.
Lower upfront engineering investment: Hardware design, board validation, and manufacturing setup are already handled.
For early-stage deployments or standard telemetry applications, OTS gateways can be an excellent starting point.
However, they come with limitations. OTS platforms often include fixed hardware interfaces, limited expansion options, and firmware stacks that restrict customisation. In some cases, they may be either underpowered for edge AI workloads or unnecessarily complex for simple deployments. Over time, these constraints can slow innovation.
Before committing to a unit, check it against every protocol the gateway must speak. An off-the-shelf gateway that speaks Modbus TCP but has no CAN interface turns into a translator project the day a machine controller joins the network, and on a fixed-hardware platform the expansion header is usually the first thing you run out of.
When is a custom IoT gateway worth the extra engineering?
A custom IoT gateway is worth the extra engineering when the system must carry several protocols at once, run edge AI, hold a strict security boundary, survive a harsh environment or stay in production for years. It is built around those constraints instead of bending the system to a generic platform: more engineering upfront, fewer limits over the product’s life.
Custom gateways are designed around the specific needs of a system rather than forcing the system to adapt to a generic platform. This approach requires more engineering effort upfront but offers significant long-term advantages.
Custom gateways enable:
- Tailored I/O interfaces
- Protocol-specific optimisation
- Hardware acceleration for edge workloads
- Controlled firmware architecture
- Scalable OTA infrastructure
In complex IoT deployments, customisation allows engineering teams to optimise both performance and power efficiency.
For example, industrial gateways may need to support CAN, Modbus, Ethernet/IP, and BLE simultaneously. Healthcare gateways may require secure data handling and deterministic behaviour. Smart infrastructure systems may require ultra-low-power operation. Generic hardware rarely fits all these requirements.
Custom gateway design ensures the architecture aligns with system goals from the beginning.
What should gateway firmware architecture handle?
Gateway firmware architecture has to schedule communication across several channels at once, buffer and prioritise data streams, encrypt and authenticate, run the OTA pipeline, detect and recover from faults and execute real-time control logic. Unlike sensor firmware it manages many concurrent tasks, so the RTOS or Linux decision, the software structure and the update mechanism are made first.
Gateway performance is determined as much by firmware as by hardware. Strong firmware development services ensure the gateway operates reliably under real-world conditions.
Gateway firmware typically handles:
- Device communication scheduling
- Buffering and prioritisation of data streams
- Encryption and authentication
- OTA update pipelines
- Fault detection and recovery
- Real-time control logic
Unlike sensor firmware, gateway firmware must manage multiple concurrent tasks and communication channels.
This requires careful architecture decisions, such as:
- RTOS vs Linux-based environments
- Containerised edge applications
- Modular communication stacks
- Secure update mechanisms
A poorly designed firmware layer can create latency issues, memory bottlenecks, and security vulnerabilities. A well-designed firmware stack turns the gateway into a scalable edge platform.
The RTOS or Linux decision is also a boot-time decision. A gateway that recovers from a power loss must be back on the network before the plant notices, and a Linux gateway boots as fast as its bootloader, kernel and service order allow, which our post on reducing boot time on an embedded Linux device sets out stage by stage. The layer that sits on top of the firmware is a separate discipline: the operating system platform, the protocol stacks and the cloud link, and it is scoped with the firmware rather than after it.
What does edge AI change about the gateway?
Edge AI changes the gateway from a data forwarder into a local decision point: inference runs on the gateway and only actionable results travel to the cloud, which cuts bandwidth, shortens response time and keeps the system useful when connectivity is poor. The hardware changes too: an AI-capable processor, acceleration, an optimised memory architecture and a model update pipeline.
Edge computing increasingly involves AI inference running directly on gateways. Instead of transmitting all sensor data to the cloud, gateways can process information locally and send only actionable insights.
This reduces bandwidth consumption, improves response times, and enhances reliability in low-connectivity environments.
Custom gateways often integrate:
- AI-capable processors
- Hardware acceleration modules
- Optimised memory architectures
- Firmware pipelines for model updates
When paired with robust hardware firmware development, gateways can support predictive maintenance, anomaly detection, and automated workflows without relying on the cloud. This local intelligence is becoming a defining characteristic of modern IoT systems.
What a gateway can infer locally is set by the class of processor on the board. A microcontroller-class gateway runs small quantised models only, while an applications processor with a dedicated neural processing unit, such as the i.MX 8M Plus used on our own system on module, runs vision and anomaly models on the gateway itself. Settle the inference workload before the silicon, because retrofitting an accelerator means a new board.
How do you secure an IoT gateway?
An IoT gateway is secured by treating it as the boundary it is: secure boot so only signed firmware runs, encrypted channels, certificate-based device authentication, a managed device identity and intrusion detection, all designed into the hardware and firmware from the start. A gateway aggregates every device behind it, which makes it a high-value target on any network it touches.
In distributed IoT systems, gateways often serve as the primary security boundary between field devices and enterprise networks.
Security considerations include:
- Secure boot mechanisms
- Encrypted communication channels
- Certificate-based authentication
- Device identity management
- Intrusion detection
Because gateways aggregate data from multiple devices, they become high-value targets for attackers.
Security must therefore be embedded into both hardware and firmware design, not added later. This is another reason custom gateways often outperform generic solutions in mission-critical environments.
Two public standards anchor that list. For industrial deployments the IEC 62443 series “was developed to secure industrial automation and control systems (IACS) throughout their lifecycle”, and it is the framework an industrial customer’s security team may ask a gateway to be assessed against. For the secure boot and recovery items, NIST’s Platform Firmware Resiliency Guidelines, SP 800-193 describe mechanisms “for protecting the platform against unauthorized changes, detecting unauthorized changes that occur, and recovering from attacks rapidly and securely”, which is the three-part test a gateway’s boot chain and update path should meet: protect, detect, recover.
What environmental and reliability constraints must a gateway design meet?
A gateway design must meet the environment it is installed in: thermal management for a sealed cabinet, vibration tolerance on a machine, power redundancy where a brown-out cannot stop the plant, EMI/EMC resilience next to drives and contactors, plus components that stay available for the product’s life. Each of those is a hardware and firmware decision together.
IoT gateways frequently operate in industrial or remote environments where reliability is essential.
Design considerations include:
- Thermal management
- Vibration tolerance
- Power redundancy
- EMI/EMC resilience
- Long-term component availability
Gateway reliability depends heavily on integrated engineering decisions across hardware and firmware layers.
This integration is a key focus area for teams delivering IoT product development services, where scalability and lifecycle management are critical.
EMI/EMC resilience is the one item on that list you cannot settle by inspection, because it is measured on the finished unit and not on a datasheet. On Pinetics’ own compute module, the i.MX 8M Plus system on module, an EMI/EMC test cycle is budgeted for every hardware revision rather than assumed from the one before, so a re-spin of the module or its carrier board is planned with its own test slot. A module with that history behind it gives a gateway a better starting point and pre-compliance evidence to work from, but the finished gateway is still the unit that has to pass.
How do you decide between an off-the-shelf and a custom gateway?
You decide between an off-the-shelf and a custom gateway by matching the deployment against nine criteria: rapid prototyping, standard protocols such as Modbus TCP, predictable workloads and minimal customisation point to off-the-shelf; complex protocols, edge AI, unique hardware integration, long-term scalability and strict security point to custom. The question is where the product is going, not how fast it starts.
Both approaches have valid use cases.
OTS gateways are ideal when:
- Rapid prototyping is required
- Applications use standard protocols
- Workloads are predictable
- Customisation needs are minimal
Custom gateways are better when:
- Deployments involve complex protocols
- Edge AI processing is required
- Hardware integration is unique
- Long-term scalability is a priority
- Security requirements are strict
The right decision depends on system architecture, not just immediate development speed. Choosing a gateway should always reflect the product’s future direction.
Off-the-shelf versus custom on nine deployment questions, read across each row
| Question about the deployment | Points to off-the-shelf | Points to custom |
|---|---|---|
| How soon must the first units run? | Rapid prototyping is required | Schedule allows a board design |
| Which protocols must the gateway speak? | Standard protocols only | Complex or several protocols at once |
| What runs on the gateway? | Workloads are predictable | Edge AI processing is required |
| How much must change from a stock platform? | Customisation needs are minimal | Hardware integration is unique |
| How long must the product stay in production? | A short or fixed deployment life | Long-term scalability is a priority |
| What does the security team require? | Standard platform security | Security requirements are strict |
How does a custom gateway programme run from schematic to first board?
A custom gateway programme runs as design steps each paired with its own review and rework: schematic design, schematic review, schematic rework, component placement, layout, layout review, layout rework, output files, then the board order. Firmware starts on a vendor evaluation kit before the first board exists, so schedule risk sits on the kit, not on the first custom board.
On an industrial IoT gateway programme Pinetics ran, every one of those stages was a tracked task in the project record, and every design change notice was prepared and reviewed as tracked work in its own right. The paired review and rework steps are what turn “we review our designs” into something a buyer can inspect: a review that raises findings and a rework task that closes them, before the board is ordered.
The firmware side follows the same rule. Proving the firmware on the processor vendor’s evaluation kit before custom hardware exists means the first custom board arrives with the software already running on the same silicon. Bring-up is then a board-level job rather than new hardware and untested firmware at the same time. How that gated plan runs across a whole product, from architecture to design transfer, is set out in how we run a gated product development programme.
What will IoT gateways need to do next?
IoT gateways will next need to make autonomous decisions at the edge, manage the lifecycle of AI models running on them, hold their place in secure distributed architectures, run predictive maintenance frameworks and integrate with real-time industrial control. Each of those adds load to both the hardware and the firmware, which is why the two have to be engineered together.
Edge computing continues to evolve as IoT deployments grow in scale and intelligence. Gateways are becoming distributed with computing nodes rather than simple communication bridges.
Future gateways will increasingly support:
- Autonomous edge decision-making
- AI model lifecycle management
- Secure distributed architectures
- Predictive maintenance frameworks
- Real-time industrial control integration
As this evolution continues, the importance of coordinated hardware and firmware engineering will only increase.
Gateways must be designed not just for current workloads, but for future system complexity.
One thing on that list does not change. A model update is a firmware update by another name, so the protect, detect and recover test in NIST SP 800-193 should be applied to the model pipeline as well: signed artefacts, a way to detect an unauthorised change and a way back to a known-good version.
Why is the gateway an architectural decision and not a hardware purchase?
The gateway is an architectural decision because it fixes the performance, scalability and security of the whole system for the product’s lifetime: which protocols it can ever speak, what it can decide when the cloud is unreachable, how it boots and updates, how it is defended. A hardware purchase answers today’s telemetry; the architecture answers every year after that.
Selecting the right IoT gateway is not simply a hardware decision; it is an architectural decision that affects performance, scalability, and security across the entire system’s lifecycle.
Whether choosing an off-the-shelf platform for rapid deployment or building a custom gateway for long-term innovation, success depends on aligning hardware capabilities with firmware intelligence and system requirements.
Pinetics helps organisations design scalable edge architectures, and builds the IoT gateways inside them as whole products: the board, the firmware and the embedded Linux or RTOS platform above it, with the paired review and rework gates described earlier. Our IoT product development services, firmware development services and hardware firmware development run on both off-the-shelf modules and custom boards, and every deliverable is engineered for reliability, security and adaptability so that connected systems perform where they matter most, at the edge. We work inside our customers’ quality systems rather than holding a certification of our own. That work rests on 100,000+ engineering hours and a leadership team with 20+ years of experience. If you are deciding between an off-the-shelf and a custom gateway, Pinetics will work through the protocols, the decisions it must make when the network is down, the security boundary and the production life before anything is bought.
In edge computing, the gateway is not just a bridge. It is the foundation of intelligent, distributed systems.
Sanjay Barewar, Director, Co-Founder and Global Chief Delivery Officer, Pinetics. 22+ years in electronic product development. BE Electrical, Pune University. LinkedIn
