IOT and Embedded Systems Relation

IoT Is Growing, But Are We Building Secure Enough Embedded Systems?

Why security must become an engineering requirement from the first stage of IoT development, rather than an update added after deployment.

Introduction

A smart home can control its lighting through a mobile application. An industrial sensor can monitor equipment remotely. A wearable device can continuously collect personal information.

These applications demonstrate how embedded systems and the Internet of Things (IoT) are becoming part of everyday life.

But there is an important question that deserves more attention:

Are we building these connected devices with security as a priority, or are we focusing mainly on functionality?

In my view, one of the biggest engineering challenges in IoT is not simply connecting more devices to the internet. It is ensuring that those devices remain secure throughout their lifecycle.

A device that works perfectly but cannot protect its data, restrict unauthorized access, or receive secure updates is not a complete engineering solution.

1. The problem starts at the design stage

When developers begin building an embedded product, the initial focus is often on functionality.

Can the sensor collect accurate readings? Can the microcontroller process the information? Can the device communicate with a mobile application?

These are important questions, but security should be considered alongside them.

Consider a simple smart door-lock system.

Its primary function is to control access to a door. However, what happens if an unauthorized person gains access to its communication interface?

The problem is no longer limited to software. It can affect a physical environment.

This is why embedded security requires a broader engineering perspective. Hardware, firmware, communication protocols, authentication, and software updates must work together.

1. Five security considerations every IoT developer should understand

A. Device identity and authentication

Every connected device should have a reliable identity.

Without appropriate authentication, an attacker may attempt to impersonate a legitimate device or access services that should be restricted.

Developers should consider unique device credentials, secure provisioning, and authentication between devices and backend services.

B. Protecting transmitted and stored data

IoT devices can process sensitive information, including location, operational data, and personal information.

Developers should identify which information needs protection and implement appropriate encryption and access controls.

Security should cover both data stored on the device and information transmitted across networks.

C. Secure firmware updates

One of the most important considerations is how a device receives software updates.

Imagine deploying thousands of connected devices. A security vulnerability is discovered after deployment.

How will manufacturers distribute a fix?

A secure update mechanism should authenticate updates, restrict unauthorized installation, and provide a controlled update process.

Without this capability, devices may remain exposed even after a vulnerability has been identified.

D. Restricting access to interfaces

Embedded devices may expose communication interfaces through USB, serial connections, wireless protocols, or network services.

Developers should identify which interfaces are necessary and restrict access to authorized entities.

Leaving unnecessary services or interfaces accessible increases the potential attack surface.

E. Monitoring device security

Security does not end when a device is manufactured or deployed.

Manufacturers and operators need ways to understand the device's security status, identify problems, and respond to incidents.

This requires considering logging, diagnostics, vulnerability reporting, and maintenance throughout the product lifecycle.

1. What established security guidance tells us

This is not just an individual engineering concern.

The National Institute of Standards and Technology (NIST) published NISTIR 8259A, which defines a core baseline of IoT device cybersecurity capabilities.

Its guidance identifies seven technical capability areas:

1. Device identification.
2. Device configuration.
3. Data protection.
4. Logical access to interfaces.
5. Software update.
6. Cybersecurity state awareness.
7. Device security.

These capabilities provide a useful starting point for thinking about security during product design.

Reference: "NISTIR 8259A – IoT Device Cybersecurity Capability Core Baseline" (https://csrc.nist.gov/pubs/ir/8259/a/final).

The OWASP Operational Technology Top 10 also highlights concerns such as unmanaged external access, known vulnerabilities, inadequate access control, and missing hardening.

Reference: "OWASP Operational Technology Top 10" (https://ot.owasp.org/v/2025/the-top-10/).

The important takeaway is that IoT security is not a single feature. It is a combination of technical capabilities, development decisions, and ongoing manufacturer responsibilities.

1. Is security always too expensive for low-cost IoT devices?

One argument often raised is that stronger security increases development costs.

This concern is understandable.

Low-cost embedded devices operate with limitations in processing power, memory, battery capacity, and manufacturing budgets.

However, I don't think the correct response is to treat security as optional.

Instead, developers should make risk-based decisions.

For example:

• Avoid enabling unnecessary communication interfaces.
• Use established cryptographic libraries rather than inventing cryptographic algorithms.
• Protect credentials during provisioning.
• Design firmware updates into the architecture.
• Apply access restrictions according to the device's actual use case.

Not every device requires the same security architecture. A battery-powered temperature sensor and an industrial controller have different risk profiles.

But every device should have an appropriate security strategy.

The goal is not to add the most expensive security technology. It is to avoid preventable weaknesses through better engineering decisions.

1. Why embedded engineers need to think beyond hardware and firmware

Traditionally, embedded development has involved working with microcontrollers, peripheral interfaces, sensors, communication protocols, and firmware.

Today, connected devices require engineers to understand a wider set of technologies.

An embedded engineer working on IoT products may need knowledge of:

• C and C++ programming.
• Microcontroller architecture.
• UART, SPI, and I2C communication.
• TCP/IP and wireless communication.
• Secure boot and firmware updates.
• Cryptographic fundamentals.
• Authentication and access control.
• Hardware and firmware security testing.

This does not mean every embedded engineer must become a cybersecurity specialist.

It means that understanding security fundamentals is becoming an important part of building reliable connected systems.

1. My perspective: Security should be part of the first prototype

I believe the industry should change how it evaluates successful IoT products.

A prototype should not be considered successful simply because the sensor works, the data reaches a dashboard, or the mobile application displays the correct values.

Engineers should also ask:

• Who can access the device?
• How are its credentials protected?
• Can its firmware be updated securely?
• What happens if communication is interrupted?
• How does the system respond to unauthorized access?

These questions should be included in the development process rather than postponed until a security review.

The earlier these considerations are addressed, the easier it is to make informed architectural decisions.

Conclusion

The future of IoT will not be determined only by how many devices we connect or how many features we add.

It will also depend on whether those devices can operate reliably and securely throughout their lifecycle.

For aspiring embedded engineers and developers, this creates an important opportunity to develop skills that combine hardware, firmware, networking, and cybersecurity.

My position is simple: a connected device should not be considered complete merely because it works. It should also be designed to operate securely.