How IoT Devices Get Hacked and What Developers Do to Stop It

Anna Ivakhnik

The Internet of Things has blurred the boundary between the digital and physical world. From smart thermostats and industrial controllers to telehealth sensors and connected vehicles, billions of embedded devices collect data and actuate processes in real‑time. Yet their physical presence, long service life and constrained hardware make them attractive targets for attackers. A vulnerability in a medical infusion pump or a smart meter can endanger safety and privacy; a compromised industrial controller can cause physical damage. Understanding how attackers compromise IoT devices and what developers and IoT software development companies can do to mitigate these threats is essential for product teams, CTOs, cybersecurity engineers and customers across industries.

This article outlines the most prevalent attack vectors targeting IoT devices, drawing insights from real-world incidents such as the Mirai botnet. It provides a developer-oriented security playbook based on standards like the OWASP IoT Top 10 and NIST SP 800-213. The article focuses on practical measures that cybersecurity companies and product teams can apply to build resilient connected devices, such as secure boot, signed over-the-air (OTA) updates, public-key infrastructure (PKI), threat modelling, supply-chain hygiene, monitoring and testing.

How attackers actually compromise IoT devices

Weak or default credentials & open services

Many consumer and industrial devices are shipped with default usernames and passwords. If owners forget to change these, the device becomes an easy target for automated scanning. The Mirai botnet exploited this vulnerability by scanning the internet for Internet of Things (IoT) devices using a fixed set of 64 well-known default login/password combinations. It compromised more than 600,000 devices and launched massive distributed denial-of-service (DDoS) attacks. The US Cybersecurity and Infrastructure Security Agency (CISA) revealed that the Mirai malware used 62 common default usernames and passwords to gain access.

Unprotected firmware & update mechanisms

Attackers often replace or tamper with a device’s firmware in order to gain persistent control. Firmware updates that are not signed or replayable allow malicious code to be installed. Threats to firmware include tampering, attacks during over-the-air (OTA) updates and insecure development practices. Without secure boot and cryptographic signing, an attacker who gains access through a physical port or the network can flash modified firmware and bypass software controls.

Insecure communication protocols

Many IoT devices use plain TCP/UDP protocols (e.g. MQTT without TLS) or outdated cryptographic libraries. Industrial networks often rely on legacy protocols such as Modbus and DNP3, which lack authentication or encryption. Unencrypted communication leaves data vulnerable to eavesdropping and man-in-the-middle attacks. This allows attackers to intercept commands, extract credentials, or inject malicious messages to manipulate actuators.

Supply‑chain & component vulnerabilities

IoT devices rely heavily on third-party operating systems, software libraries, and hardware components. Unpatched vulnerabilities in these components create an attack surface. Outdated hardware and software in legacy industrial devices hinder network visibility and create security gaps. Many industrial environments still use default credentials and have insufficient access controls. The OWASP IoT Top 10 highlights the use of “insecure or outdated components” (I5) and “insecure ecosystem interfaces” (I3).

Physical attacks & side channels

Physical access to a device can yield debug ports, unprotected flash memory or side channels like electromagnetic emanations. Attackers may connect via JTAG or UART pins and dump firmware or credentials. The OWASP IoT Top 10 lists “lack of physical hardening” (I10) as a critical vulnerability. IoT devices are often deployed in public or remote locations, making them susceptible to tampering or theft.

Case study: Mirai botnet and default credentials

The Mirai botnet is one of the most well-known IoT security incidents. It infected hundreds of thousands of internet-connected cameras, routers, and DVRs by scanning for devices with factory-default credentials. Once infected, the devices became part of a botnet that was used to launch DDoS attacks against major web services. According to Cloudflare, Mirai’s list of default credentials included common combinations such as 'admin/admin' and 'root/12345'. This case illustrates how simple password vulnerabilities can have far-reaching consequences.

Developer‑oriented security measures

Designing secure IoT devices requires a layered approach from secure development practices and hardware roots of trust to lifecycle management and monitoring. The following measures form a comprehensive defense strategy.

A. Security‑by‑design and threat modeling

Security must be incorporated into the design from the outset, rather than being added at the end. The US National Institute of Standards and Technology (NIST) urges manufacturers to conduct risk assessments and threat modelling at an early stage of product development. NIST IR 8259 Revision 1 emphasises the importance of integrating the NIST Cybersecurity Framework into the development of IoT products and of distinguishing between pre-market and post-market activities. NIST SP 800-213 reminds organisations to extend their risk management processes to IoT devices, identifying device cybersecurity requirements based on the system's use case and potential impact. This involves creating attack trees or using frameworks such as STRIDE to anticipate the goals of potential adversaries and design appropriate controls.

Adopting a Secure Software Development Lifecycle (SSDLC) and the NIST Secure Software Development Framework (SSDF) ensures that security is considered at every stage: requirements, design, coding, testing, deployment, and maintenance. This includes secure coding practices, code review, static analysis, dynamic analysis, and fuzzing (discussed below). In regulated industries such as healthcare and critical infrastructure, compliance frameworks such as IEC 62443 (for industrial control systems) require organisations to treat IoT devices as system elements and manage the associated risks.

B. Hardware root of trust and secure boot

A hardware root of trust provides a minimal, immutable foundation for verifying firmware and bootloader integrity. This can be implemented using a Trusted Platform Module (TPM), secure element or microcontroller with built‑in secure boot. Secure boot ensures only verified firmware runs, preventing rogue firmware installation, and should be paired with encryption. Secure boot should include rollback protection to prevent attackers from downgrading to older, vulnerable firmware; this can be implemented via monotonic counters or version numbers stored in hardware fuses.

Implementers should minimise the bootloader’s attack surface by disabling debug interfaces (e.g., JTAG) and ensuring that the chain of trust extends from the root key to the application. Hardware root of trust is foundational; once compromised, no software measure can fully regain security.

C. Signed, atomic and rollback‑protected OTA updates

Over-the-air updates are essential for addressing vulnerabilities and introducing new features. However, insecure OTA mechanisms can be exploited by attackers. Memfault’s OTA update checklist emphasises the importance of signing firmware images with cryptographic algorithms (such as RSA or ECDSA) and verifying signatures on the device prior to applying an update. Hash checks should be used to validate the integrity of the downloaded image. Version numbers should be encoded in the firmware header to prevent downgrades, and the device should reject older versions to avoid rollback attacks.

OTA updates should be atomic (either fully applied or not at all) and use A/B partitioning or double-banking. Staged rollouts allow updates to be tested on a small subset of devices before full deployment. Memfault also recommends protecting signing keys and checking the validity of TLS certificates used for update servers, including automated certificate rotation. Logging and telemetry during OTA updates enable troubleshooting and help to detect abnormal update patterns.

D. Device identity and certificate lifecycle (PKI)

Each device in a fleet should have a unique identity linked to a cryptographic key. Public key infrastructure (PKI) allows devices to authenticate with servers and other devices via X.509 certificates. According to Keyfactor, digital certificates provide secure device identity, enable encrypted communications, and protect code updates through code signing. The industrial cybersecurity standard IEC 62443 requires identification, access control, code signing and TLS connectivity, and a robust PKI is mandatory from Security Level 2 onwards.

During manufacturing or provisioning, devices should be assigned a unique key pair and a certificate issued by the manufacturer. Certificate lifecycle management (CLM) must automate the issuance, renewal, rotation and revocation of certificates. Using self-signed certificates or long-lived keys can lead to outages and vulnerabilities. Keyfactor warns that failing to properly manage certificates can cause trust issues and increase risk. Cloud platforms often offer device provisioning services that integrate with managed PKI.

E. Secure communications and least privilege

Both data in transit and data at rest must be protected. Devices should use the latest versions of TLS (1.2 or 1.3) for all network connections and, where feasible, mutual TLS (mTLS) for client authentication. Legacy protocols such as Modbus should either be encapsulated in secure tunnels (e.g. via VPNs or TLS proxies) or replaced with secure alternatives. Digi International highlights that unencrypted data transmission and poor password management enable attackers to intercept sensitive data or issue malicious commands. Furthermore, communication with cloud platforms or backend APIs should implement role-based access control (RBAC) or attribute-based access control (ABAC) to ensure that devices and users operate with the least necessary privilege.

Encryption should also be used for data stored locally on the device, with hardware cryptographic acceleration being used where available. Keys and certificates must be stored in tamper-resistant hardware. Network segmentation and firewalls can limit lateral movement, and micro-segmentation within the network can ensure that, even if one device is compromised, it cannot communicate freely with all the others.

F. Hardened component choices & supply‑chain hygiene

Developers rely on open‑source libraries, operating systems and third‑party components that may contain vulnerabilities. The OWASP IoT Top 10 lists “use of insecure or outdated components” as a key risk. To mitigate this:

• Maintain a software bill of materials (SBOM): Keep an inventory of components and versions used. Tools like CycloneDX or SPDX help track dependencies.
• Monitor and patch vulnerabilities: Subscribe to security advisories and apply updates promptly. However, many IoT devices cannot be patched easily; NIST SP 800‑213 notes that manufacturers must identify device cybersecurity capabilities and support actions to address them.
• Minimise attack surface: Remove unused services, close ports and disable unnecessary features. DeviceAuthority emphasises that legacy industrial devices often use default credentials and lack access controls.
• Validate third‑party code: Conduct static and dynamic analysis, penetration testing and supply‑chain audits. Avoid including heavy frameworks or untrusted binaries when not needed.

G. Device management, monitoring & incident response

Ongoing monitoring is crucial for detecting compromised devices and abnormal behavior. NIST IR 8349 recommends characterising IoT devices’ expected network behavior so that network administrators can implement appropriate access controls and detect deviations. Devices should send telemetry about health, performance and security events to a central system. Anomalies such as unexpected port scans or spikes in outbound traffic may indicate compromise.

A device management platform should allow operators to roll back firmware, isolate or quarantine compromised devices, and revoke certificates. Logging must be tamper‑resistant and securely transmitted. Incident response plans should include a vulnerability disclosure process, emergency kill‑switch and communication templates for notifying customers. Without monitoring, attacks can persist unnoticed for years.

Check out a related article:
IoT Solutions: What Language Does Your Wristband Speak?

H. Testing: fuzzing, firmware analysis & red‑team exercises

Security testing should cover both software and hardware. Static analysis tools and linters catch coding errors, but dynamic testing is essential to expose runtime vulnerabilities. Fuzzing tools generate malformed inputs to trigger crashes and memory corruption. Firmware emulation tools and IoT‑specific testbeds (e.g., OWASP’s IoTGoat) allow researchers to test for vulnerabilities. Red‑team exercises and penetration tests simulate adversaries; insights from Mirai show how simple scanning can reveal default credentials. NIST SSDF encourages regular testing and updates as part of the secure development lifecycle.

Standards, checklists & compliance

Regulatory and industry standards provide a framework for IoT security. Key ones include:

• OWASP IoT Top 10: Highlights common vulnerabilities such as weak passwords, insecure network services, insecure ecosystem interfaces, lack of secure update mechanism and physical hardening. Developers should use it as a checklist during design and testing.
• NIST SP 800‑213 & NIST IR 8259: Provide guidance for integrating IoT devices into information systems. They stress extending risk management processes, understanding device use cases, analyzing impact on system risk and determining device cybersecurity requirements. The revised 8259 emphasises aligning product cybersecurity capabilities with customer needs and the NIST Cybersecurity Framework.
• IEC 62443: The industrial automation security standard; at Security Level 2 it mandates identification, access control, secure communications and code signing.
• Manufacturer Usage Description (MUD): NIST IR 8349 encourages using MUD files to specify expected network behavior of devices, enabling network-based access control policies.
• Privacy regulations: For healthcare and consumer devices, compliance with HIPAA, GDPR or other data protection laws is mandatory. Developers should implement data minimisation, consent management and data‑at‑rest encryption.

Developer checklist

1. Perform threat modeling: Identify attackers, assets and abuse cases (e.g., STRIDE, attack trees).
2. Adopt SSDLC/SSDF: Integrate security at every development phase.
3. Use secure boot and hardware roots of trust: Validate firmware; disable debug interfaces.
4. Implement signed OTA updates: Sign firmware, verify before installation, enable atomic rollbacks.
5. Provision unique device identities: Use PKI; automate certificate lifecycle management.
6. Encrypt communications & data: Use TLS 1.2/1.3; implement mutual authentication; protect data at rest.
7. Maintain SBOM & patch management: Track components; apply patches promptly; remove unused services.
8. Monitor device behavior: Use telemetry, logs and MUD for anomaly detection.
9. Develop incident response procedures: Define processes for vulnerabilities, emergency updates, customer communication and device quarantine.
10. Conduct regular security testing: Use static analysis, fuzzing, penetration testing and red‑team assessments.

Quick operational playbook

To translate these best practices into day‑to‑day operations, teams can adopt the following tactical steps:

• Pre‑provision cryptographic keys and certificates during manufacturing to ensure each device has a unique identity.
• Require multi‑factor authentication (MFA) for access to development and management portals.
• Use staged OTA rollouts: Test updates with a small group of devices, monitor telemetry and gradually expand.
• Establish baseline telemetry by recording normal performance metrics and network patterns; set alerts for deviations.
• Enable an emergency kill‑switch: In case of a critical vulnerability, remotely disable affected features or disconnect the device.
• Create a vulnerability disclosure program: Encourage researchers to report issues responsibly.
• Prepare communication templates: Quickly notify customers about issues and updates; transparency builds trust.
• Regularly review and update policies: Align with new standards, threat landscapes and company growth.

IoT security is not a one‑time project but a lifecycle investment. Attackers exploit weak credentials, insecure firmware, outdated components and unencrypted protocols to compromise devices, as seen in the Mirai botnet case. Developers must integrate security from concept to decommission: model threats, choose secure hardware, sign updates, manage certificates, encrypt data, monitor behavior and test continuously. Standards like the OWASP IoT Top 10 and NIST SP 800‑213 provide frameworks and checklists to guide this journey.

For product teams and organisations, partnering with an experienced IoT software development can accelerate time‑to‑market while embedding security. Similarly, engaging a cybersecurity consultancy can help implement PKI, threat modeling and incident response programs. By investing in security‑by‑design, regular updates and monitoring, companies can deliver trustworthy connected products that protect users and create long‑term value. The cost of ignoring security is far greater than the investment required to build it in from the start.