Embedded vs. Bolt‑On Security in the Internet of Things: Risks, Attacks, and Protective Strategies
The article examines how built‑in security components differ from bolt‑on solutions in IoT, highlighting real‑world vulnerabilities, physical attack scenarios, and the need for proactive, physically grounded security models to protect connected devices and users.
On the Internet, the security industry protects us by promoting and implementing security practices such as mutual authentication, encryption, secure protocols, and trust. In the real world, however, the Internet of Things (IoT) rarely incorporates such built‑in security architectures; this gap was only formally defined in 2014 by Symantec, distinguishing between built‑in and bolt‑on security components.
Built‑in components embed security as an integral part of the device, whereas bolt‑on components add security functions after deployment. Because IoT devices interact with the physical world via human‑machine interfaces, attacks on internet‑connected IoT devices are not only easier but also potentially more hazardous.
Image source: Shutterstock
In buildings we rely on smart sensors to handle critical daily tasks such as lighting control, detecting air and water quality threats, and managing heating and ventilation. From a bolt‑on perspective, adding internet‑enabled networking appears harmless and useful for increased connectivity.
Unfortunately, these sensors and controllers were not designed to face the threats that arise when building control systems are exposed to the internet. Without a proper foundational security architecture, exposing them online expands the attack surface and diversifies potential threats.
Traditional Internet security remains important for IoT but is insufficient on its own. Proper authentication, authorization, billing, encryption, intrusion detection, software signing, and trust models enable safe interaction among online devices. However, mirroring and extending these mechanisms in smart ovens, smart locks, connected shoes, and fitness wear requires extreme caution, as vulnerabilities can pose imminent physical threats to users.
For example, in 2017 researchers used network‑connected low‑resolution cameras in a shopping mall to capture swipe‑pattern data used to unlock Android phones, discovering a set of patterns that could unlock phones in more than half of test cases.
Crucially, the attack does not rely on specialized high‑end cameras; it leverages data from many common low‑resolution consumer cameras. If an attacker can access a user’s phone protected only by a swipe pattern, they can obtain personal data across IoT domains such as home automation, vehicle security, and health monitoring.
In IoT, attacks are not merely metaphorical—they are tangible physical attacks. They can be launched without the attacker being online, for instance by physically entering a building and triggering an IoT motion detector while sniffing the wireless network to capture the encrypted communication generated by the motion event.
The attacker can store the captured packets on a mobile device, amassing enough data to build a repository of the encrypted communication, then derive smaller cryptographic keys from the vast key space, analogous to how Alan Turing exploited predictable patterns in WWII to break encrypted messages.
Inferring that a particular packet originates from a motion event at a specific time is key to reducing well‑encrypted data structures into exploitable code. Access to packet headers and structures also enables malicious attacks on other building systems such as power and heating, all stemming from a simple app download and brief proximity to the sensor.
A recent incident at an Austrian hotel highlighted another IoT‑enabled hack: attackers demanded ransom by exploiting smart locks that lacked physical key overrides, taking advantage of over‑reliance on network‑based credentials and poorly designed fallback mechanisms to gain costly access to vulnerable systems.
In this scenario, the security fix is straightforward: program electronic locks to disable default mechanical fail‑open modes. This low‑cost, low‑effort mitigation requires engineers to adopt a proactive security mindset rather than relying on legacy assumptions about connectivity and built‑in network models.
IBM recently demonstrated the importance of physical factors by conducting an anonymous “ethical hack” of a smart office building. Using conventional hacking techniques the team could not fully access the building’s control and automation systems, but by driving past the building and connecting to its local network they succeeded, underscoring the role of physical proximity.
Rather than suppressing expansion, a built‑in IoT security model shows that physical security forms the foundation for higher‑level network protection, enabling safer and broader interaction among internet‑connected devices.
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.