• • • IOT • • •


HOW TO KEEP IOT DEVICES SECURE THROUGHOUT THEIR LIFETIME


Solutions such as SEGGER’s emBoot-Secure


implement this approach by combining Secure Boot with authenticated firmware updates.


BY BIANCA SCHMIDT, TECHNICAL WRITER,


SEGGER MICROCONTROLLER T


he European Cyber Resilience Act (CRA) is often seen as the driving force behind improving IoT security. In reality, it reflects a


much broader shift. The percentage of embedded devices that are


connected has increased dramatically and devices remain in service for many years. The need for security has increased even more dramatically. Security, once a simple compliance requirement, has become a fundamental engineering discipline. After all, it’s now the law! Unlike traditional embedded products, modern


IoT devices continue to evolve long after deployment. Software is updated, vulnerabilities are discovered and advances in computing power and cryptanalysis can render previously secure cryptographic algorithms obsolete. Maintaining security throughout the entire product lifecycle has, therefore, become just as important as implementing it during development.


Establishing trust from


the first instruction Every security architecture begins with one simple question: Why should a device trust the software it is about to execute? Without a trusted starting point, higher-level security mechanisms such as encrypted communication or application-level access control provide little value if an attacker can replace the firmware itself. Secure Boot establishes this initial trust by


verifying that the firmware originates from an authorised source and has not been modified. Instead of relying solely on checksums, which only detect accidental corruption, it uses digital signatures to authenticate the firmware before execution. Secure Boot establishes the initial chain of trust, while authenticated firmware updates preserve it throughout the device lifetime.


Keeping trust throughout


the product lifetime Once deployed, connected devices often continue to evolve. New functionality is added, bugs are corrected, vulnerabilities are fixed and cryptographic recommendations change over time. This creates a critical security challenge. If


firmware can be updated, the update mechanism itself becomes a potential attack vector. A malicious firmware image can compromise an otherwise well-designed product if it is accepted without verification. Secure firmware updates, therefore, extend the


same trust model established during boot. Every update should be authenticated before installation, ensuring that only authorised firmware is accepted. Many systems also implement rollback protection to prevent installation of older software versions that contain known vulnerabilities. Separating firmware creation, signing and


deployment further strengthens security. Private signing keys should remain protected within the development infrastructure and never become part of the device itself. The embedded device only requires the corresponding public key for verification. This significantly reduces the consequences of compromised distribution channels.


Security is more than encryption Encrypting communication without first establishing trust in the software running on the device is much like protecting the communication channel while leaving the software itself unverified. Secure firmware updates protect the software


running on the device. Equally important is protecting the data the device exchanges with other systems. Modern communication protocols such as TLS combine encryption, authentication and integrity protection to establish secure communication channels, while cryptographic libraries such as SEGGER’s emSSL provide the


12 ELECTRICAL ENGINEERING • JULY/AUGUST 2026


underlying building blocks for secure embedded communication. For resource-constrained embedded systems, these mechanisms must deliver strong security without exceeding tight memory and performance constraints.


Designing for long-term security Perhaps the biggest change introduced by connected products is the shift from software delivery to software maintenance. Achieving this requires more than technical mechanisms. Manufacturers need processes to monitor vulnerabilities, develop and validate security updates, digitally sign firmware, distribute software securely and respond quickly to newly discovered threats. A well-designed architecture makes these tasks manageable by clearly separating responsibilities and allowing individual components to evolve without affecting the complete system. Security by Design, therefore, extends beyond


cryptographic algorithms or Secure Boot. It influences software architecture, development workflows, release processes and long-term maintenance strategies. Products designed with these principles can adapt to changing threats while remaining reliable throughout many years of operation. Longer product lifetimes, increasing


connectivity and evolving cybersecurity requirements demand a different engineering mindset. Security must be established before software execution, maintained through authenticated firmware updates and supported by secure communication and robust cryptographic services. These mechanisms are most effective when they work together as part of a unified security architecture. Only then can embedded systems provide the level of protection required for connected products operating over many years in increasingly demanding environments. By treating security as a continuous engineering


process rather than a final development step, manufacturers can build IoT products that remain resilient, maintainable and better prepared for future cybersecurity challenges and evolving regulatory requirements.


www.segger.com electricalengineeringmagazine.co.uk


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48