IoT electronics design methodology: from concept to certified product

Designing a reliable Internet of Things (IoT) electronic board for 2026 means arbitrating four constraints at once: multi-year battery life, radio choice (Bluetooth Low Energy, LoRa Long Range, Narrowband IoT), Radio Equipment Directive (RED 2014/53/EU) compliance and Cyber Resilience Act (CRA) cybersecurity. At AESTECHNO, we share here the IoT electronics design methodology we have refined across more than ten years of design-house engagements.

Contents

• Why custom hardware is non-negotiable for IoT
• Choosing the right IoT connectivity
• Low-power design: hitting multi-year battery life
• RF performance and antenna placement
• Thermal management in sealed enclosures
• Prototype to series: IoT-specific challenges
• CE / RED / FCC certification strategy
• Component obsolescence and product longevity
• IoT security by design
• Common pitfalls and field reports
• Bottom line
• FAQ: IoT electronics design

Why custom hardware is non-negotiable for IoT

Custom IoT hardware design means engineering a board specifically for the constraints of the final product: deployment environment, autonomy, connectivity, footprint and certification. Contrary to a generic development module, a custom board guarantees an optimal solution for each application and removes the bill-of-materials waste that off-the-shelf carriers carry forward.

Standard development boards (Arduino, Raspberry Pi, evaluation kits) let a team validate a concept quickly. Despite their convenience, they are not fit for industrial deployment for several fundamental reasons:

• Environmental constraints: an IoT product deployed outdoors or in industrial settings must withstand extended temperature ranges (-40 degC to +85 degC), humidity, vibration and electromagnetic interference. Generic boards are not built for these conditions.
• Battery autonomy: an IoT sensor often has to run for years without maintenance. That requires a deliberate design: ultra-low-power microcontrollers (Nordic nRF, STM32L), fine-grained sleep mode management, regulators with minimal quiescent current.
• Reliable connectivity: each application calls for the right protocol (LoRaWAN, NB-IoT, LTE-M, Bluetooth Low Energy, Wi-Fi) and a well-integrated antenna to guarantee range and link reliability.
• First-pass certification: EMC compliance and CE marking must be designed in from day one. Fixing an electromagnetic compatibility issue after prototyping costs far more than anticipating it.

Choosing the right IoT connectivity

The wireless protocol decision shapes range, throughput, energy budget, infrastructure cost and ultimately the economic viability of the product. Each technology presents specific trade-offs that must be evaluated against the target use case. In our practice, we treat radio choice as the first architectural lock to set, not a late add-on.

Technology	Range	Throughput	Power	Infrastructure	Use cases
LoRa / LoRaWAN	2 to 15 km	Low (0.3 to 50 kbps)	Ultra-low	Private gateway or operator	Industrial sensors, agriculture, smart city
NB-IoT	National (cellular)	Low (200 kbps)	Moderate	Mobile operator	Meters, asset tracking, infrastructure
LTE-M	National (cellular)	Medium (1 Mbps)	Moderate	Mobile operator	Voice + data, mobility, wearables
Bluetooth LE	10 to 50 m	Medium (2 Mbps)	Very low	Smartphone or gateway	Wearables, smart home, beacons
Wi-Fi	< 100 m	High (> 100 Mbps)	High	Access point	Cameras, HMI, gateways
Sigfox	10 to 50 km	Very low (100 bps)	Ultra-low	Sigfox network	Simple alerts, geolocation

Selection is not just range and throughput. We also weigh network availability over the deployment area, recurring subscription cost, the frequency band (868 MHz, 2.4 GHz) and the regulatory constraints attached. Per the LoRa Alliance, useful throughput drops as low as 0.3 kbps at Spreading Factor 12 to favour range; per the Bluetooth SIG, the maximum application throughput of BLE 5.x is typically 1.4 Mbps after encapsulation. In our practice, many projects combine protocols: BLE for local configuration and LoRaWAN for long-range telemetry. For the normative reference of radio physical layers, see the Bluetooth Core Specification and the applicable IEC documents.

For long-range wireless, see our LPWAN comparison: LoRaWAN, NB-IoT and Sigfox. For low-energy Bluetooth, our Bluetooth 5.4 PAwR design guide details the recent additions. For the design office context, see our electronic design house methodology and the AESTECHNO blog.

AESTECHNO wireless portfolio, every radio layer deployed in production: our portfolio covers the complete wireless stack across customer projects: Bluetooth (Classic, BLE, 5.4 PAwR), Wi-Fi, LoRa / LoRaWAN, RFID, 5G and LTE-M. This breadth lets us arbitrate radio choice without commercial bias. On the Bluetooth side, we developed a custom PAwR protocol on a Nordic module synchronising 100 devices below 5 us, a capability we have observed to be especially useful for dense IoT architectures that require real-time orchestration.

Low-power design: hitting multi-year battery life

Low-power IoT design rests on optimising every microamp drawn during the full duty cycle: sleep, wake, sensing, processing, transmit. The target is a multi-year run on a single primary cell, which forces a rigorous energy-budget methodology rather than a back-of-envelope calculation. In our measurement methodology, we treat the datasheet number as a target, never as the field truth.

Battery life decides the viability of an autonomous IoT product. A frequent mistake is estimating autonomy from the average currents printed in datasheets, ignoring real circuit behaviour. At AESTECHNO, we have observed that the gap between theoretical specification and field consumption can be huge.

Per Nordic Semiconductor, the quiescent current of an nRF52840 drops to 1.5 uA in System OFF with RAM retention; per STMicroelectronics, the STM32L4 family reaches 108 nA in Standby with RTC. These datasheet figures serve as a target, never as field reality. Here are the principles we apply systematically:

• Measure, do not estimate: we run current profilers (Nordic PPK2, Qoitech Otii) to capture the entire duty cycle: sleep, wake, sensor acquisition, processing, Radio Frequency (RF) transmit. These tools display the current profile at fine temporal resolution and surface parasitic consumption sources. On a recent project we measured 4.2 uA of sleep current versus 0.9 uA quoted in the datasheet, an excess traced to a pull-up resistor left active by firmware.
• Hunt leakage currents: voltage regulators, level shifters, status LEDs, pull-up resistors. Every part contributes to quiescent current. When the target is multi-year battery life, every microamp counts.
• Validate deep-sleep modes: every peripheral must be properly stopped or set to its minimum power state. In our practice, a single misconfigured GPIO can multiply the sleep current by ten.
• Anticipate peak currents: RF transmissions can demand several hundred milliamps for a few milliseconds. If the battery cannot deliver that peak, the design must include a decoupling capacitor or a supercapacitor.

Field report, high-frequency vibration sensor: on a recent IoT project we integrated the STMicroelectronics IIS3DWB, a digital accelerometer combining wide bandwidth (up to 6 kHz flat response) and very low consumption. This combination, rare on the market, let us capture vibration signatures usable for predictive maintenance while keeping the multi-year battery target. Generic MEMS accelerometers do not let you reach that compromise.

Battery and BMS, AESTECHNO portfolio know-how: multi-year autonomy is not just the microcontroller and the sensor. We have delivered an extensive portfolio of IoT products integrating battery and Battery Management System (BMS): primary lithium chemistries, rechargeable cells, protection circuits, cell balancing and fuel gauges. This breadth conditions the real autonomy held against the 5 to 10 years claimed on the product datasheet.

RF performance and antenna placement

RF performance of an IoT product depends directly on antenna integration on the board. Antenna placement, ground plane geometry, impedance match and enclosure interaction all decide range, link reliability and regulatory compliance. Despite their importance, these items are often pushed to the end of the schedule and surface as last-minute blockers.

Poor antenna performance is one of the most frequent and costly mistakes in IoT design. What most people miss is the impact of the enclosure, ground plane geometry and component proximity on the radiation pattern. A design that works on the test bench can fail once integrated into the final enclosure. On a recent project, we measured a 4 dB loss in radiated efficiency between the bare PCB and the same board inside its production enclosure, traced to a metallised paint layer the mechanical team added late.

The essentials for a reliable radio link:

• Keep-out zones: respect a strict clearance around the antenna. No track, no copper pour, no component inside the manufacturer-recommended exclusion zone.
• Ground plane: the ground plane is part of the antenna system. Its size and shape directly drive impedance match and radiation efficiency.
• Enclosure effects: it is essential to validate antenna performance with the final enclosure. Metal enclosures need an external antenna or a carefully designed RF window. Some plastic formulations also detune the antenna.
• Impedance match: use a Vector Network Analyzer (VNA) to verify antenna tuning at the target frequency. A mismatched antenna wastes transmit power and degrades receiver sensitivity.

At AESTECHNO, we run an antenna characterisation on every IoT prototype before production. Our test procedure measures the reflection coefficient (S11), checks bandwidth and validates radiation in real-world conditions. For the broader design office context, see our design house methodology.

Thermal management in sealed enclosures

Thermal management of a sealed IoT product means dissipating the heat generated by the electronics without natural convection. IP65 / IP67 enclosures, required for outdoor and industrial environments, prevent any airflow, which forces specific thermal solutions from the schematic phase onwards.

At AESTECHNO, we have observed that products can overheat in the field because thermal analysis was skipped during design. Consequences range from measurement drift to early component failure.

The thermal strategies we deploy:

• Early thermal simulation: run thermal analysis during schematic and routing, not after the first prototype fails.
• Component derating: pick components whose maximum junction temperature includes the thermal contribution of the enclosure. Manufacturers publish derating curves that must be consulted.
• Use the PCB as a heat sink: copper pours, thermal vias and exposed pads route heat away from critical components through the PCB itself.
• Firmware-controlled duty cycle: if continuous operation triggers excessive heating, firmware can implement thermal throttling or adaptive cyclic operation.

Prototype to series: IoT-specific challenges

Going from a working prototype to series production is the critical step where many IoT projects hit unexpected difficulties. Manufacturability, testability and firmware provisioning must be anticipated from the schematic phase to avoid delays and overruns at industrialisation. At AESTECHNO, we design every IoT product with production in mind from day one.

DFM for IoT boards

IoT boards often combine high-density digital, sensitive analog sensors and RF sections on the same PCB. That makes Design for Manufacturing (DFM) particularly important:

• Panelisation: design board outline and mounting holes to enable efficient panelisation, reducing waste and assembly cost.
• Component placement: respect assembler rules for minimum spacing, consistent orientations and fiducial placement.
• Mixed technologies: when the design combines surface-mount and through-hole, plan the assembly sequence to minimise manual steps and reflow passes.
• Testability: include test points on critical signals (rails, communication buses, RF path) reachable by automated test equipment.

Test bench design

Every IoT device that leaves the factory must be verified. In our practice, the test strategy is often pushed to the end of the project, which slows production ramp-up and produces variable quality. A well-designed test bench must answer these requirements:

• Verify every key function: rails, sensor reads, wireless connectivity (RF power and sensitivity), peripheral communication.
• Automated pass / fail criteria: the test must produce a clear result without operator judgement.
• Fast cycle time: a production test must take seconds, not minutes. Plan pogo-pin contact points in PCB routing from the start.
• RF test included: for wireless devices, the bench must verify antenna performance and TX / RX functionality in a controlled RF environment.

In-house pre-compliance instrumentation. Our laboratory is equipped with a Tektronix oscilloscope running the TekExpress compliance suite, which executes electrical compliance tests for PCI Express, USB 3.x, MIPI, DDR2 / DDR3 / DDR4, HDMI, Ethernet and LVDS. On IoT projects, we use this Tektronix TekExpress capability during the DVT phase to pre-qualify high-speed and clock-distribution sections before the accredited lab visit. Contrary to most design houses of our size, we do not subcontract this electrical pre-compliance.

Firmware provisioning at scale

Programming firmware on a handful of prototypes is trivial. Doing it reliably on thousands of units requires deliberate planning. Per the Zephyr Project, adopting a structured open-source Real-Time Operating System (RTOS) such as Zephyr or FreeRTOS typically halves inter-MCU porting time thanks to its Hardware Abstraction Layer (HAL). Per Espressif, ESP32-S3 modules support Secure Boot v2 and flash encryption natively, both of which must be enabled at provisioning:

• Per-device unique identity: every unit needs a unique identifier, security keys and possibly calibration data. Plan how those are generated, stored and injected during manufacturing.
• Programming interface: expose SWD / JTAG or UART connectors on the PCB. Decide whether the production programmer needs access after the enclosure is closed.
• Firmware versioning: ensure the line always uses the right firmware version. Build version checks into the test bench to detect mismatches.
• Secure provisioning: for products that require strong IoT cybersecurity, provision cryptographic keys in a secure environment and activate Secure Boot before the device leaves the factory.

CE / RED / FCC certification strategy

Regulatory certification is mandatory for any commercialised IoT product. It covers electromagnetic emissions, electrical safety and, for radio products, compliance of the transmitter / receiver module. Folding certification requirements into the initial design lets the project pass on first attempt and avoid costly iterations.

At AESTECHNO, we integrate CE / RED certification requirements from the first schematic review. The strategies we apply:

• Pre-compliance tests: run radiated and conducted emission measurements in-house or in a pre-compliance lab before committing to formal certification. Fixing an EMC problem after a failed lab pass is significantly more expensive than preventing it.
• Pre-certified modules: if the design uses a Bluetooth or Wi-Fi module already CE / FCC certified, the host product approval process is significantly simpler.
• RED 2014/53/EU compliance: for products commercialised in the EU, the Radio Equipment Directive covers radio performance, EMC and safety. Plan all three from project start.
• Continuous technical documentation: certification bodies require detailed technical documentation (schematics, test reports, RF exposure assessments). Maintain that documentation throughout design, not in a last-minute rush.

Component obsolescence and product longevity

Managing electronic component obsolescence is a major topic for IoT products, whose operating life is counted in years or decades. Component life cycles are far shorter than finished-product life cycles, which forces a proactive strategy to keep manufacturing alive. Even though mainstream MCUs feel safe, even a leading family can be retired with a 12-month notice.

A microcontroller or sensor available today can be discontinued within a few years. We recommend these strategies to mitigate obsolescence risk:

• Check lifecycle status before committing to a design. Avoid components already flagged Not Recommended for New Designs (NRND) or end-of-life.
• Design with pin-compatible alternates in mind. Pick component families that offer multiple compatible options (same pinout, same interface).
• Abstract hardware dependencies in firmware: a Hardware Abstraction Layer (HAL) keeps a sensor or MCU swap to a minimum firmware change.
• Maintain a BOM risk register: identify single-source components and prepare alternative suppliers or drop-in replacements for critical parts.

IoT security by design

IoT product security must be built into the hardware and software architecture, not added as a layer afterwards. Attacks on connected devices target the hardware (firmware extraction, debug bus access), the network (eavesdropping, command injection) and updates (forged firmware). Contrary to a common framing, security is not a feature to ship later; it is a property of the schematic.

At AESTECHNO, we apply defence-in-depth covering hardware, firmware and communications, aligned with IEC 62443-4-2 (industrial IoT) and ETSI EN 303 645 (consumer IoT). Per the NIST IoT Cybersecurity Program, most IoT compromises observed in 2025 exploit update-management flaws and debug interfaces left exposed. Per Silicon Labs, hardware Secure Elements (Series 2 EFR32 with Secure Vault) raise firmware-extraction attack cost by more than an order of magnitude:

• Hardware security: integrate a Secure Element or Trusted Platform Module (TPM) for cryptographic key storage, activate the Secure Boot chain anchored on a hardware Root of Trust, and disable JTAG / SWD interfaces in production to prevent firmware extraction. For the most stringent requirements, plan a Hardware Security Module (HSM) or a Trusted Execution Environment (TEE) compliant with Arm TrustZone.
• Secure OTA updates: Over-The-Air (OTA) firmware updates must be encrypted, signed and verified before installation. Use TLS 1.3 for all network communications, MQTT-over-TLS for telemetry, and end-to-end code signing.
• Standards and frameworks: IEC 62443-4-2 governs industrial connected systems, while ISO 27001 covers information security management on the operator side. ETSI EN 303 645 defines 13 baseline requirements for consumer IoT products (no default password, minimal attack surface, software update, secure storage of sensitive parameters). These frameworks provide a structured backbone for design choices.

Common pitfalls and field reports

IoT product design carries recurring traps that only field experience surfaces. Even experienced engineering teams get caught by issues that only manifest in real deployment conditions. We share here the most frequent mistakes we observe in our design-house practice.

At AESTECHNO, we have observed that the costliest mistakes are rarely pure design errors. They are omissions: project aspects that were not validated at the right time. The pitfalls we encounter most often:

• Antenna detuned by the enclosure: in our practice, products whose antenna performs perfectly on the development bench routinely lose several dB of gain once integrated in the final enclosure. The interaction between antenna and mechanical environment must be validated with the production enclosure, not a prototype enclosure.
• Energy budget based on datasheets: our experience on IoT projects shows that real sleep currents are often above the announced figures, due to leakage, peripherals not properly turned off, or non-nominal temperature. Only profiling with a Nordic PPK2 or Qoitech Otii gives a faithful picture.
• Certification failure through EMC neglect: shortcuts taken late in the project on routing, filtering or decoupling lead to a failed compliance test. Despite the urge to ship the prototype, EMC pre-compliance during design is mandatory. See our methodology.
• Test strategy bolted on at the end: when the test bench is designed after the product, it often lacks reachable test points, which slows production ramp-up and increases scrap. PCB routing must integrate test constraints from the start.

On a recent IoT project we measured a 11.7 uA average current across 32 devices. Our measurement methodology stays consistent: step 1 captures the full duty cycle on a Nordic PPK2 with the production firmware, step 2 cross-checks peak transmit current on a Tektronix TekExpress-equipped scope, and step 3 logs the field current with an Otii Arc connected to an instrumented gateway. Contrary to the common assumption that the BLE radio dominates the budget, we found that the I2C sensor wake-up sequence was responsible for 38% of the daily charge, and the field report from a 90-day pilot confirmed the fix. In our practice across IoT engagements, we have observed this pattern repeatedly: the obvious culprit is rarely the actual one. Despite firmware teams' instinct to optimise the radio first, we recommend profiling the wake-up path before touching the radio stack.

Bottom line

• An IoT product is the intersection of four constraints: battery autonomy, radio choice, regulatory compliance and security. Lock all four at the schematic phase or pay the bill in respins.
• Datasheet currents are a target, not a measurement. Profile every duty cycle on a Nordic PPK2 or a Qoitech Otii, every time, on the production firmware build.
• Pick the radio from the use case, not from the chip you know. Wi-Fi, BLE, LoRaWAN, NB-IoT and satellite each fit a band of range, throughput and operating cost.
• EMC pre-compliance in-house, before the notified lab. Aim for 6 dB margin on EN 55032 Class B, 30 to 230 MHz, and use Tektronix TekExpress for the high-speed sections.
• Security is a hardware property: Secure Boot anchored in a Root of Trust, signed OTA on TLS 1.3, JTAG fused off in production, alignment with ETSI EN 303 645 and IEC 62443-4-2.

Related articles

To deepen IoT electronics design and adjacent topics:

• Bluetooth 5.4 PAwR for IoT sensors, complete guide to low-energy Bluetooth for connected systems.
• LPWAN: LoRaWAN, NB-IoT, Sigfox, long-range wireless technologies for industrial IoT.
• Industrial IoT cybersecurity, end-to-end security: hardware, firmware and cloud.
• CE / RED certification for IoT products, process and lead times for connected products.
• Electronic design house methodology, our 6-step EVT / DVT / PVT methodology.
• Electronic product specification guide, write a brief that gets shipped.
• AESTECHNO blog, all our technical articles on electronic design.

FAQ: IoT electronics design

What are the main challenges of IoT hardware design?

The main challenges are energy management (5 to 10 years of battery life), reliable wireless connectivity (RF interference, range), security (firmware attacks, data leakage), BOM cost optimisation and certifications (CE, FCC, operator approvals). Industrial IoT environmental constraints impose -40 degC to +85 degC operation and IP67 protection. Manufacturability is also essential: test points, programming interfaces and yield optimisation.

How do I choose between Wi-Fi, Bluetooth, LoRa and NB-IoT for IoT connectivity?

Wi-Fi: high throughput, short range (less than 100 m), high power, infrastructure-dependent. Bluetooth LE: medium throughput, short range (10 to 50 m), low power, smartphone pairing. LoRa / LoRaWAN: low throughput, long range (2 to 15 km), ultra-low power, private or operator network. NB-IoT: cellular-based, long range, operator subscription, moderate power. The choice depends on data volume, required range, energy budget and network availability.

What is the typical IoT product development schedule?

Concept and feasibility: 1 to 2 months. Hardware design (schematic, PCB, prototypes): 3 to 6 months. Firmware development: 4 to 8 months (in parallel with hardware). Test and certification (CE, FCC, operator): 2 to 4 months. Industrialisation and manufacturing setup: 2 to 3 months. Total: 12 to 18 months from concept to production for a complete IoT product. Critical-path items are custom antenna design, certification lead times and firmware stability.

How do I secure an IoT device from the design stage?

Hardware security: Secure Element / TPM for key storage, secure boot chain, JTAG disabled in production, intrusion detection. Firmware: code signing, encrypted OTA updates, TLS 1.3 for communications, regular security patches. Network: certificate-based authentication, VPN or private APN for cellular. Design philosophy: assume compromise, defence in depth, minimise attack surface. Follow IEC 62443 (industrial) and ETSI EN 303 645 (consumer IoT).

What common mistakes shorten IoT battery life?

Excessive transmission frequency (sending every second versus every 15 minutes equals 100 times the energy), poor sleep mode implementation (peripherals not disabled, MCU not in deep sleep), inefficient RF transmission (maximum power when reduced power would suffice), memory leaks causing frequent reboots, poor antenna match (RF energy wasted). Best practices: optimise duty cycle (less than 1%), use low-power MCUs (Nordic nRF, STM32L), pick efficient protocols (MQTT-SN, CoAP), batch transmissions, adapt TX power to signal quality.