Embedded systems engineering for secure connected products

Why embedded systems engineering now starts with lifecycle design

For connected products, embedded systems engineering can no longer stop at microcontroller selection, firmware implementation and functional testing. The work now has to account for device identity, secure boot, update mechanisms, vulnerability handling, support periods and evidence for regulatory or customer review. These requirements need attention before the hardware design is frozen. Late changes to flash size, secure elements, bootloaders, cryptographic acceleration or production provisioning can be costly and risky once boards, tooling and manufacturing flows are already committed. Industry guidance from NIST, ETSI, ISA/IEC and recent connected-product regulations points in the same general direction: embedded products need a lifecycle security model, not a one-time release checklist. (csrc.nist.gov)

This is a practical product engineering issue. Many embedded devices are expected to operate for years in homes, factories, vehicles, medical environments, energy systems or edge infrastructure. A device that cannot be patched, authenticated or recovered after a firmware compromise may still meet its first launch milestone, but it can become a maintenance, liability or market-access problem later.

From board bring-up to secure product architecture

Traditional embedded development often starts with hardware constraints: processor family, memory, sensors, radios, power budget, thermal limits and bill of materials. Those constraints still matter. Connected products, however, add a second architecture layer that is just as important. Teams need to define what the device trusts, how it joins a network, how it receives commands, how it stores secrets, how it updates software and how it proves that its software has not been tampered with.

A practical architecture review should separate four concerns. First, the device needs a reliable identity, such as a unique credential provisioned during manufacturing. Second, firmware needs a controlled execution path, typically involving secure boot or measured boot. Third, updates must be authenticated and resilient to power loss or partial installation. Fourth, diagnostic data should support troubleshooting without exposing private data, keys or unnecessary attack surface.

The Eclipse Foundation’s 2024 IoT and Embedded Developer Survey shows why these topics have become mainstream engineering concerns. In the survey announcement, developers identified communication security at 40%, over-the-air updates at 32% and secure boot at 19% as foundational security layers for IoT and embedded development. Those figures do not define a universal product roadmap, but they do show that the industry conversation has moved from isolated device firmware toward maintainable connected systems. (newsroom.eclipse.org)

Security requirements are becoming engineering inputs

For many teams, security used to enter the project after the main product requirements were already set. That approach is increasingly difficult to defend. NISTIR 8259A defines an IoT device cybersecurity capability core baseline as device capabilities generally needed to support common cybersecurity controls for devices, device data, systems and ecosystems. In engineering terms, security is not only a policy topic. It becomes a set of product capabilities that must be implemented through hardware and software choices. (csrc.nist.gov)

ETSI EN 303 645 V3.1.3, released in September 2024, provides high-level security and data protection provisions for consumer IoT devices. ETSI describes the document as an outcome-focused baseline that supports manufacturers while allowing flexibility in implementation. That matters for embedded teams because it avoids prescribing a single technical design, while still pushing teams to make security requirements explicit and testable. (etsi.org)

Regulation is also changing the planning horizon. The UK consumer connectable product security regime came into effect on 29 April 2024 and includes baseline requirements such as banning universal default and easily guessable passwords, providing a vulnerability disclosure route and publishing information on minimum security update periods. The EU Cyber Resilience Act entered into force in December 2024, with main obligations applying from 11 December 2027, and introduces mandatory cybersecurity requirements for products with digital elements placed on the EU market. The U.S. Cyber Trust Mark is voluntary, but the FCC’s 2024 final rule describes a binary label with a scannable code for consumer IoT products that meet approved baseline cybersecurity standards. (gov.uk)

Firmware resilience and updateability shape hardware choices

A common mistake is to treat firmware update support as a software-only feature. In real products, updateability depends on memory layout, bootloader design, rollback strategy, cryptographic verification, power-loss handling, manufacturing tools and field diagnostics. If the device has too little nonvolatile memory for dual-bank updates, no safe recovery partition or no protected location for verification keys, the update strategy may be constrained before application firmware is mature.

NIST SP 800-193, published in May 2018, remains relevant because it frames platform firmware resiliency around three mechanisms: protecting firmware from unauthorized change, detecting unauthorized change and recovering rapidly and securely after an attack. Although the publication focuses on platform firmware, the protect-detect-recover model is useful for embedded product teams designing boot chains, root-of-trust components and recovery procedures. (csrc.nist.gov)

For low-cost embedded devices, the trade-off is rarely simple. A larger flash device, external secure element or more capable microcontroller can raise unit cost, but it may also reduce field failure risk and make compliance evidence easier to produce. Conversely, a minimal hardware design can be attractive during prototyping but may leave no path to secure updates, key rotation or long-term maintenance. Good engineering decisions make these trade-offs visible early, with cost, risk and support obligations reviewed together.

How standards change the product engineering workflow

Standards do not remove the need for product-specific judgment. They create a common language for requirements, tests and evidence. ISA/IEC 62443 is a good example in industrial automation and control systems. ISA describes the series as defining requirements and processes for implementing and maintaining electronically secure industrial automation and control systems, with a holistic approach that bridges operations technology, information technology, process safety and cybersecurity. The series also includes secure product development lifecycle requirements and technical security requirements for components. (isa.org)

In a product engineering workflow, this changes the order of work. Instead of writing firmware first and asking a security reviewer to approve it later, teams can map requirements during concept development. A typical flow is to define the product environment, identify assets and misuse cases, choose a security baseline, allocate requirements to hardware and firmware, build manufacturing provisioning steps, create verification tests and maintain a post-release vulnerability process.

This workflow is especially important when embedded products combine local control with cloud services or mobile applications. A device may be technically secure in isolation, but the product can still fail if the companion app exposes credentials, the cloud API lacks access control or the device cannot revoke a compromised token. The FCC’s IoT labeling rule explicitly recognizes that an IoT product can include device components, mobile apps, networking equipment and cloud platforms rather than a single standalone device. (govinfo.gov)

Common trade-offs teams should resolve early

The hardest embedded systems engineering decisions are often cross-functional. A hardware engineer may want the lowest-cost memory configuration. A firmware engineer may need space for rollback images. A security lead may require protected key storage. A product manager may need a five-year update story for a regulated market. None of these views is automatically wrong; the risk comes from resolving them too late.

• Memory versus update safety: Single-image updates are cheaper but can increase recovery risk. Dual-image or A/B strategies require more space but can improve resilience.
• Power budget versus cryptography: Stronger authentication and encrypted communication consume compute cycles and energy, so protocol and silicon choices should be evaluated together.
• Convenience versus credential security: Shared defaults simplify manufacturing and support but conflict with modern IoT security expectations and some regulatory requirements.
• Fast launch versus support evidence: A product can ship sooner without detailed security documentation, but later audits, customer questionnaires or labeling programs may require evidence that is difficult to reconstruct.
• Closed firmware versus coordinated disclosure: Keeping firmware opaque does not eliminate vulnerability management. A clear reporting channel and triage process are now part of credible product support.

A useful design review should therefore include a security bill of materials, update and rollback plan, key provisioning flow, vulnerability disclosure owner, minimum support period, dependency tracking method and end-of-life communication plan. The exact artifacts vary by product category, but the principle is consistent: connected devices need operational plans as well as embedded code.

What this means for product teams

For product leaders, the main point is to treat embedded security and lifecycle support as product features with cost, schedule and user-experience impact. A secure boot chain is not only a technical control; it affects factory programming, service procedures and field recovery. An update mechanism is not only a firmware module; it affects cloud infrastructure, user communication and long-term support budgets. A vulnerability disclosure process is not only a legal page; it affects engineering triage and release management.

For engineering teams, the opportunity is to reduce uncertainty. When requirements are mapped early, teams can select silicon, memory, RTOS components, connectivity modules and manufacturing tools with fewer late surprises. When standards are used as checklists for evidence rather than as after-the-fact paperwork, security becomes easier to test and maintain. When product managers understand the hardware consequences of update and support promises, market commitments are more realistic.

The direction is clear: embedded systems engineering for connected products is becoming a lifecycle discipline. Teams are better positioned when they connect hardware decisions, firmware architecture, security baselines and post-release operations into one coherent product engineering process. For more product engineering perspectives, visit Yingguoguo.

Frequently asked questions

What is embedded systems engineering?

Embedded systems engineering is the design and development of computing systems built into physical products. It combines hardware selection, firmware development, real-time behavior, interfaces, power management, testing, manufacturing support and lifecycle maintenance.

Why is security now central to embedded product design?

Many embedded devices are connected to networks, cloud services or mobile apps. That makes identity, authentication, secure updates, vulnerability handling and recovery mechanisms part of the product’s core reliability and safety story, not optional extras.

When should update strategy be defined?

The update strategy should be defined before hardware is finalized. Memory size, bootloader architecture, protected storage, power-loss recovery and cryptographic verification all affect whether updates can be delivered safely after launch.

Do standards replace product-specific risk assessment?

No. Standards such as NISTIR 8259A, ETSI EN 303 645 and ISA/IEC 62443 provide baselines and common language. Teams still need to assess the product’s environment, users, threats, safety impact, cost constraints and support model.