IoT Security: Protect Smart Homes & Medical Devices

IoT security covers the practices, technologies, and policies that protect connected devices — and the networks they run on — from attack. Smart thermostats, insulin pumps, industrial sensors, and assembly-line controllers all share one uncomfortable trait: most shipped with weak or no defenses. By 2026, 21.1 billion IoT devices are active globally, and attackers hit them roughly 820,000 times a day. This article covers what makes IoT security different from traditional IT security, what good protection looks like across smart homes, industrial systems, and medical devices, and what the new regulatory wave is demanding from manufacturers.

Why IoT Security Has Become a Crisis, Not a Concern

The numbers are not a warning. They’re a report. IoT devices face approximately 820,000 attacks per day worldwide. Connected homes average 29 daily attack attempts — triple the rate from 2024. Industrial IoT attacks rose 75% over two years. Healthcare cybersecurity incidents involving connected medical devices now average more than $10 million per breach.

The scale problem explains part of this. There are more entry points than any security team can manually track. But the deeper problem is design. Most IoT devices were built for connectivity and cost, not defense. They ship with default credentials, receive infrequent firmware updates, and run proprietary or end-of-life operating systems. That combination makes them attractive targets that are easy to reach, easy to access, and hard to monitor.

The Scale Problem: 21.1 Billion Devices and Counting

According to IoT Analytics, active connected devices reached 21.1 billion globally in 2025, growing 14% year over year. That figure is on track to hit 40.6 billion by 2034. The IoT security market reflects the urgency: estimates put it between $8 billion and $45 billion in 2026, depending on definition. That spread reveals another problem — nobody agrees on what IoT security even covers, which means spending is fragmented and many gaps go unfilled.

For security teams, the math is unforgiving. A manufacturing facility running 10,000 sensors cannot patch each one manually. A hospital with 50,000 connected devices cannot audit each endpoint weekly. Security has to be built in, monitored automatically, and governed by policy — not handled device by device.

Why IoT Devices Are Easier to Attack Than Laptops or Servers

Five characteristics make IoT endpoints structurally weaker than traditional IT assets:

• Resource constraints prevent running full security stacks. A microcontroller with 256KB of RAM cannot support an endpoint detection agent, a full TLS stack, and application logic simultaneously.
• Long operational lifespans expose devices to threats that didn’t exist when they were built. Medical equipment runs for 10 to 20 years. Industrial controllers last even longer. Security assumptions made in 2010 don’t hold in 2026.
• Infrequent or absent patch cycles mean known vulnerabilities persist. One in five medical devices runs an unsupported operating system. 53% of hospital-connected devices have known critical vulnerabilities.
• Physical access is often unrestricted. A smart meter on the outside of a building, a sensor on a factory floor, or a camera in a hallway can be physically tampered with in ways a server rack in a locked data center cannot.
• Vendor fragmentation means no consistent security baseline. A single hospital may use devices from 200 different manufacturers. Each has its own firmware, update schedule, and security model — or lack of one.

The Three Attack Surfaces You Must Understand

IoT security operates across three distinct layers. Weaknesses in any one layer can compromise the entire system. Understanding where each threat lives determines where controls need to go.

Device Layer Vulnerabilities

The device layer includes the hardware, firmware, and operating system of each endpoint. Default credentials are the most documented problem here — the Mirai botnet, which launched some of the largest DDoS attacks in history, compromised hundreds of thousands of devices using nothing more than default username/password combinations published in device manuals.

Beyond credentials, device layer risks include unsigned firmware (allowing attackers to flash malicious updates), insecure boot sequences, hardcoded API keys in device code, and physical debug ports (JTAG, UART) left enabled in production hardware. Many consumer devices also lack storage encryption, so anyone with physical access to the chip can read stored credentials and configuration.

Network Layer Vulnerabilities

The network layer carries outsized importance in IoT security because it’s the only layer that gives defenders visibility into devices that can’t run their own security software. Without network monitoring, a compromised sensor can silently exfiltrate data or relay commands for months.

Common network-layer failures include unencrypted traffic (many older IoT protocols transmit in plaintext), flat network architectures where IoT devices share segments with business systems, weak Wi-Fi configurations (WEP or WPA2-TKIP instead of WPA3), and insecure APIs that accept unauthenticated requests from any source. Shadow IoT — employees connecting personal devices to corporate networks — creates additional unmanaged entry points that security teams don’t know exist.

Cloud and Data Layer Vulnerabilities

Most IoT devices send data to cloud backends for storage, analysis, or remote control. If those backends have weak authentication, overly permissive APIs, or insecure data storage, attackers who can’t crack the device itself can go around it entirely — accessing data at rest or issuing commands through the cloud interface.

The cloud layer also introduces third-party risk. When a vendor’s cloud platform is compromised, every device connected to it becomes vulnerable regardless of the security of the individual device. This is why supply chain security and vendor assessment are now part of any serious IoT risk program.

Securing the Smart Home: What Homeowners Actually Need to Do

Smart home IoT security gets simplified into “change your passwords” by most consumer guides. The actual threat picture is more specific, and so are the fixes.

The 29-Attacks-Per-Day Reality

Bitdefender and Netgear’s 2025 research found that connected homes faced an average of 29 daily attack attempts — three times the 2024 rate. The most targeted devices were routers, smart cameras, and network-attached storage systems. These aren’t random scans. Botnets run automated scripts that probe known vulnerability signatures across IP ranges, testing for specific device types by their response patterns.

The practical implication: a smart home device connected to the open internet without proper segmentation is being probed continuously. “Set it and forget it” is a vulnerability, not a feature.

Default Credentials: The #1 Entry Point

Default credentials remain the single most exploited IoT vulnerability in consumer environments. Many routers still ship with admin/admin or printed passwords on a label that’s visible to anyone who enters the home. The fix is straightforward but frequently skipped: change the username and password on every device during setup, use a password manager to generate unique 20+ character credentials, and disable remote administration on devices that don’t need it.

The EU Cyber Resilience Act and the UK’s PSTI Act already prohibit universal default passwords on consumer devices sold in those markets. US devices are moving the same direction through FCC’s Cyber Trust Mark labeling program.

Network Segmentation for Home Users

Most consumer routers support a guest network or IoT VLAN. Putting smart home devices on a separate network segment from computers and phones limits the blast radius if any device is compromised. A compromised smart thermostat on a segmented network cannot reach your laptop or access stored credentials.

The setup takes about 20 minutes on any modern router. Create a separate SSID, assign IoT devices to it, and configure the router to block traffic between the IoT segment and the primary network. Devices that only need internet access (cameras, speakers, environmental sensors) go on the IoT segment. Devices you actively use for computing stay on the primary network.

The Matter Protocol and What It Changes for Home Security

Matter is an open application-level protocol for smart home devices, backed by Apple, Google, Amazon, and Samsung. It standardizes device commissioning and local communication, which has meaningful security implications: Matter devices use certificate-based authentication, require secure commissioning over Bluetooth before joining a network, and operate locally — meaning they don’t depend on a manufacturer’s cloud service that could go offline or be compromised.

Matter doesn’t solve every problem. It doesn’t address firmware update enforcement, physical security, or the security of devices that pre-date the standard. But for new purchases in 2026, buying Matter-certified devices gives a meaningful baseline guarantee that other consumer IoT products don’t.

Industrial IoT Security: Higher Stakes, Harder Targets

Industrial IoT (IIoT) security operates in environments where a successful attack doesn’t just expose data — it can halt production lines, rupture pipelines, damage equipment worth millions, or create physical safety hazards. The convergence of IT and OT (operational technology) networks over the past decade has expanded the attack surface dramatically while OT security capabilities lagged behind.

What Makes IIoT Attacks Different from IT Attacks

In enterprise IT, a breach typically means data theft or ransomware. In IIoT environments, a compromised sensor feeding false data can cascade through automated decision systems — triggering shutdowns, damaging equipment, or producing defective products that reach consumers. A 2021 attack on a Florida water treatment plant demonstrated this directly: an attacker accessed the system and increased sodium hydroxide levels to 111 times the normal concentration before an operator noticed the mouse moving on-screen and reversed the change.

IIoT devices also have update constraints that enterprise IT doesn’t. You can’t push a firmware update to an active industrial controller without a maintenance window. Many facilities run 24/7 operations, meaning patches queue for weeks or months. Legacy PLCs (programmable logic controllers) may run software from the 1990s on hardware that physically cannot support modern encryption or secure protocols.

The 75% Attack Increase and Real Breach Consequences

Industrial IoT attacks increased 75% over the two years leading into 2026. The primary drivers are the expansion of IT/OT convergence (connecting previously air-gapped OT networks to business networks and the internet), the rise of ransomware groups specifically targeting critical infrastructure, and the proliferation of exposed industrial control system interfaces discoverable via tools like Shodan.

The Colonial Pipeline attack in 2021 cost the company $4.4 million in ransom and triggered fuel shortages across the US East Coast. That incident involved the IT side of the network, not OT directly — but it illustrated how operational disruption comes not just from physical compromise but from shutdowns organizations choose to make out of caution when they lose confidence in their network integrity.

IEC 62443: The Standard Industrial Operators Should Know

IEC 62443 is the international standard for industrial automation and control system (IACS) security. It’s structured into four series covering policies and procedures, program management, system requirements, and component requirements. The component-level standard, IEC 62443-4-2, defines security requirements for industrial IoT devices themselves — authentication, authorization, data integrity, and communication security.

The EU’s NIS2 Directive, which mandates implementation by 2026, aligns substantially with IEC 62443-4-2 for industrial operators. Organizations in energy, water, transport, and manufacturing that fall under NIS2’s scope of “operators of essential services” need IEC 62443 familiarity to structure their compliance programs. The standard is not a checklist — it’s a risk-based framework, and its Security Level definitions (SL 1 through SL 4) let organizations match controls to the realistic threat level they face.

Zero-Trust Architecture in Operational Technology Environments

Zero-trust in OT means no device is trusted by default, regardless of network location. Every IIoT device must authenticate before communicating, and access is restricted to the minimum required for function. In practice, this means device identity verification at the network edge, microsegmentation of OT networks so that a compromised sensor on one line cannot reach controllers on another, and strict east-west traffic controls that prevent lateral movement.

OT and ICS networks should operate independently from IT networks. Where integration is necessary — and it often is for operational efficiency — the connection should go through a demilitarized zone (DMZ) with unidirectional data diodes or application-layer firewalls that prevent commands from flowing from IT to OT automatically.

Medical IoT Security: When a Breach Becomes a Patient Safety Event

Medical IoT security sits at the intersection of cybersecurity and clinical care. A compromised insulin pump, infusion system, or ventilator isn’t a data breach — it’s a potential clinical emergency. Healthcare cybersecurity incidents involving connected medical devices now average over $10 million per event. And the vulnerability picture is stark: 53% of connected medical devices in hospitals have known critical vulnerabilities.

The Compliance Baseline: FDA QMSR Effective February 2026

Effective February 2, 2026, the FDA’s updated Quality Management System Regulation (QMSR) replaced the older Quality System Regulation under 21 CFR Part 820. The QMSR incorporates ISO 13485:2016 and formally embeds cybersecurity into risk management, design controls, validation activities, and post-market surveillance — making it a mandatory element of device quality systems, not an optional technical consideration.

Under Section 524B of the FD&C Act, manufacturers of cyber devices must now submit cybersecurity management plans, continuously monitor for vulnerabilities, establish coordinated vulnerability disclosure processes, and release timely security patches — with critical uncontrolled risks addressed within 60 days. A “cyber device” under this definition covers any medical device that contains software, has network connectivity (including USB or Bluetooth), or relies on external systems like update servers.

Software Bill of Materials (SBOM): What It Is and Why It Matters

An SBOM is a complete inventory of all software components in a device — open-source libraries, third-party modules, and manufacturer-written code. The FDA now requires SBOMs as part of premarket submissions for cyber devices. The purpose is direct: when a new vulnerability is discovered in an open-source component, manufacturers and health delivery organizations need to know within hours which devices contain it, not weeks.

In practice, generating an accurate SBOM requires manufacturers to have complete visibility into their own software supply chain — something that many historically lacked. The transition is driving significant investment in software composition analysis (SCA) tooling across the medical device industry. SBOMs should be updated with every firmware release and made available to healthcare organizations that operate the devices.

The 53% Vulnerability Rate in Hospital-Connected Devices

A 2025-2026 cybersecurity analysis found that 53% of connected medical devices and IoT equipment in hospitals had known critical vulnerabilities. Roughly one-third had identified critical risks potentially affecting device operation. 77% of hospital systems contained known exploited vulnerabilities.

These numbers reflect a structural problem: medical device approval cycles measured in years, combined with device lifespans measured in decades, mean that devices approved before modern cybersecurity expectations were set are still in clinical use. Healthcare organizations cannot simply swap out non-compliant devices — procurement timelines, budget cycles, and clinical workflow dependencies make rapid replacement impossible.

Legacy Medical Devices: The Problem No One Wants to Fund

Legacy medical devices — those running unsupported operating systems or hardware that cannot receive security patches — are the most difficult problem in healthcare IoT security. Compensating controls exist: network segmentation isolates them, application-layer firewalls filter their traffic, and continuous monitoring detects anomalies. But none of these fully substitute for a device that can receive and apply security updates.

In ransomware scenarios, even temporary loss of access to medical devices disrupts diagnostic and treatment processes, forcing hospitals to divert patients or delay procedures. That operational reality has elevated device cybersecurity from a compliance checkbox to a clinical continuity requirement. Budget owners who treat medical device security as an IT cost center rather than a patient safety investment are making the wrong trade-off.

What Good IoT Security Actually Looks Like: A Layered Defense Model

IoT security rests on three pillars: device security, network security, and cloud/data security. No single control is sufficient. The goal is layered defense where an attacker who bypasses one control hits another before reaching anything critical.

Hardware Root of Trust and Secure Boot

A hardware root of trust is a cryptographic anchor built into device silicon that verifies the integrity of firmware before execution. Secure boot uses that anchor to ensure only cryptographically signed firmware can run — preventing attackers from persisting through firmware replacement. Physical unclonable function (PUF)-based identity ties a device’s cryptographic identity to unique physical characteristics of its silicon that can’t be cloned.

Regulatory frameworks including the EU Cyber Resilience Act and NIST’s post-quantum roadmap now treat hardware root of trust, secure boot, and tamper-resistant identity as prerequisites for device certification in industrial, healthcare, and smart home sectors. By 2026, IoT Analytics expects these features to become standard entry conditions for critical and premium IoT device categories.

Encrypted Communications: TLS and WPA3

All IoT communications should be encrypted end-to-end. TLS 1.2 at minimum, TLS 1.3 preferred for devices with sufficient processing resources. WPA3 for wireless traffic. VPN tunneling for devices that communicate over the public internet. These controls prevent man-in-the-middle attacks — where an attacker intercepts traffic between a device and its backend — and protect the integrity of commands sent to devices.

The resource constraint problem is real: many older microcontrollers lack the processing power for full TLS handshakes at acceptable speed. For these devices, DTLS (Datagram Transport Layer Security) provides encrypted UDP communication with lower overhead. Hardware security modules (HSMs) or secure elements can offload cryptographic operations from the main processor, enabling encryption on resource-constrained hardware.

Firmware Update Management

Firmware updates need to be installed as soon as they become available. That sentence is easy to write and organizationally difficult to execute. A practical firmware management program requires: automated inventory of all device firmware versions, alerting when a new update is released for any device in the fleet, a tested rollback mechanism in case an update causes operational problems, and cryptographic signature verification before applying any update.

Legacy devices for which the manufacturer no longer provides patches should be flagged for replacement, isolated from sensitive network segments, and monitored more aggressively in the interim. Keeping a patched device versus an unpatched device isn’t a minor difference — unpatched devices have known exploitation paths that are actively used.

Device Identity and Least-Privilege Access

Every IoT device should have a unique cryptographic identity — typically an X.509 certificate provisioned at manufacture. This identity is used to authenticate the device to the network and to sign any data it transmits. Zero-trust network access (ZTNA) frameworks treat every device as untrusted by default and require it to prove its identity and posture before gaining network access.

Least privilege means a device can only communicate with the systems it needs to function. A temperature sensor has no legitimate reason to make DNS queries or initiate outbound connections to arbitrary IP addresses. Enforcing least-privilege access at the network level — through micro-segmentation, application-aware firewalls, and egress filtering — contains the damage from any compromise.

SIEM and Continuous Monitoring

IoT devices often lack robust native logging, but security information and event management (SIEM) and extended detection and response (XDR) systems can centralize network-level event data across the entire fleet. Behavioral baselines — what normal traffic volume, connection patterns, and data payloads look like for each device type — enable anomaly detection that catches compromises the devices themselves can’t report.

SIEM integration also satisfies compliance audit requirements under ISO/IEC 27001, HIPAA, and NIS2, providing the event logs and forensic trail that regulators require after an incident. Organizations without centralized logging face dual jeopardy: they can’t detect incidents in progress, and they can’t reconstruct what happened afterward.

The Gap Other Articles Miss: Protocol-Level Attacks on MQTT and CoAP

Most IoT security coverage focuses on devices and networks. Very few articles address the specific application-layer protocols IoT devices use — and the protocol-level vulnerabilities those introduce. Two protocols deserve specific attention: MQTT and CoAP.

MQTT: The Messaging Protocol Running Most Smart Home and IIoT Devices

MQTT (Message Queuing Telemetry Transport) is the dominant messaging protocol for IoT — it’s lightweight, designed for constrained devices and unreliable networks, and runs over TCP. The problem is that MQTT brokers (the servers that route messages between devices) frequently run with authentication disabled by default or use plaintext username/password credentials without TLS.

A 2023 Shodan scan found over 40,000 publicly accessible MQTT brokers with no authentication required. Anyone who discovers an exposed broker can subscribe to all message topics — receiving every sensor reading, status update, and command that flows through it — and publish messages to any topic, including commands that control connected devices. This isn’t a theoretical attack: researchers have used exposed MQTT brokers to read power consumption data from smart meters, unlock doors, and send spoofed sensor readings to industrial systems.

Secure MQTT deployment requires TLS on all broker connections (port 8883, not the unencrypted 1883), unique client ID authentication with strong credentials for every connecting device, topic-level access control lists (ACLs) that limit which devices can publish or subscribe to which topics, and broker configuration that disables anonymous connections. For high-security environments, mutual TLS (mTLS) — where both client and broker present certificates — provides the strongest authentication.

CoAP: The HTTP Alternative for Constrained Devices

CoAP (Constrained Application Protocol) is a lightweight HTTP alternative designed for devices with minimal RAM and processing. It runs over UDP rather than TCP and is common in industrial sensor networks and smart energy systems. CoAP’s UDP foundation creates specific security problems that TCP-based protocols don’t face.

Because UDP is connectionless, CoAP is vulnerable to IP spoofing and amplification attacks. An attacker who spoofs a victim’s IP address in CoAP requests causes the server’s responses to flood the victim — and because CoAP responses can be several times larger than requests, the amplification factor makes this an efficient DDoS vector. Researchers have demonstrated amplification ratios of up to 34x using CoAP servers, comparable to DNS and NTP amplification.

DTLS (Datagram Transport Layer Security) is CoAP’s security mechanism — it’s TLS adapted for UDP. DTLS provides encryption and authentication while tolerating packet loss and reordering. However, DTLS adoption remains low because it adds handshake overhead that smaller CoAP deployments often avoid for performance reasons. For any IoT deployment that uses CoAP at the network perimeter, DTLS is non-negotiable. Internal CoAP traffic on fully isolated OT networks may accept the lower-overhead profile, but boundary-crossing CoAP must be encrypted.

2026 Regulatory Landscape: What Laws Are Forcing Change

IoT security regulation moved from voluntary guidance to enforceable law between 2023 and 2026. Three frameworks define what manufacturers and operators must do.

EU Cyber Resilience Act

The EU Cyber Resilience Act holds manufacturers liable for security flaws in connected products and requires security throughout the device lifecycle — from design through decommissioning. Key requirements include: no universal default passwords, a documented vulnerability disclosure process, security updates for the full expected product lifetime (or at least 5 years), an SBOM for all software components, and CE marking that attests to security compliance.

Products that don’t meet CRA requirements cannot be sold in the EU. For global manufacturers, the CRA is effectively setting a worldwide baseline because it’s not economically viable to build separate product lines for EU and non-EU markets. The cultural shift the CRA forces is significant: security stops being a post-launch patch and becomes a design criterion with legal consequences.

US IoT Cybersecurity Improvement Act and FCC Cyber Trust Mark

The US IoT Cybersecurity Improvement Act requires federal agencies to only purchase IoT devices that meet NIST-defined security standards. For consumer products, the FCC’s Cyber Trust Mark program launched a voluntary labeling system in 2024 that shows consumers whether a product meets defined security benchmarks — covering password security, software update capability, data encryption, and vulnerability disclosure processes.

The Trust Mark is currently voluntary, but FCC statements suggest mandatory requirements could follow. For manufacturers aiming at government contracts or security-conscious consumer segments, certification is a competitive requirement now regardless of its legal status.

NIS2 Directive and IEC 62443-4-2

The EU’s NIS2 Directive significantly expands the scope of the original NIS Directive, bringing manufacturing, healthcare, energy, water, transport, and digital infrastructure operators under stricter cybersecurity obligations. Affected organizations — designated as “operators of essential services” or “operators of important services” — face requirements for risk management programs, supply chain security, incident reporting within 24 hours, and cybersecurity governance at board level.

IEC 62443-4-2 aligns closely with NIS2’s technical requirements for industrial IoT. Organizations subject to NIS2 that structure their IIoT security programs around IEC 62443 will find significant overlap with compliance requirements — reducing the documentation burden of demonstrating compliance while also producing genuinely better security outcomes.

People Also Ask

Q: What is the most common IoT security vulnerability?

Default credentials are the most exploited IoT vulnerability. Most devices ship with manufacturer-set usernames and passwords that are publicly documented or trivially guessable. The Mirai botnet, which launched record-breaking DDoS attacks, compromised hundreds of thousands of devices this way. Changing credentials on every device during setup, combined with disabling unnecessary services, addresses the most common attack path.

Q: How is IoT security different from regular cybersecurity?

IoT security differs from enterprise IT security primarily in resource constraints and physical consequences. IoT devices often lack the computing resources to run endpoint security agents, operate for years between updates, and exist in physically exposed environments. Compromise can produce physical outcomes — disrupted industrial processes, manipulated medical devices, unlocked access controls — not just data theft. Standard IT security tools don’t transfer directly to IoT without adaptation for constrained hardware and operational safety requirements.

Q: What regulations govern medical device IoT security?

In the US, the FDA’s updated QMSR (effective February 2026) and Section 524B of the FD&C Act require manufacturers of connected medical devices to submit cybersecurity management plans, maintain SBOMs, and patch critical vulnerabilities within 60 days. In the EU, the Medical Device Regulation (EU MDR) and the Cyber Resilience Act jointly govern cybersecurity requirements. HIPAA applies to the data these devices handle. IEC 81001-5-1 provides the technical standard for health software cybersecurity.

Frequently Asked Questions

Q: Should I put IoT devices on a separate network?

A: Yes — network segmentation is the single highest-value control available in both home and enterprise IoT environments. Placing IoT devices on a dedicated VLAN or guest network prevents a compromised device from reaching other systems on the primary network. Most consumer routers support this through a guest network feature. Enterprise environments should use managed switches with VLAN tagging and firewall rules that control traffic between segments. OT and ICS networks should operate independently from IT networks entirely, with controlled data flows through a DMZ when integration is necessary.

Q: What is a Software Bill of Materials (SBOM) and do I need one?

A: An SBOM is a complete inventory of all software components in a device or application — including open-source libraries, third-party modules, and in-house code. If you’re a medical device manufacturer, the FDA now requires SBOMs for premarket submissions under Section 524B of the FD&C Act. If you’re a device operator — a hospital, utility, or manufacturer running IoT fleets — requesting SBOMs from your vendors lets you respond faster when new vulnerabilities are discovered in components your devices use. The EU Cyber Resilience Act makes SBOMs mandatory for CE-marked connected products.

Q: How often should IoT firmware be updated?

A: Security patches should be applied as soon as they’re released for any device with a known exploited vulnerability. For routine updates, a monthly review cycle is appropriate for most IoT fleets. The practical barrier is operational: industrial and medical devices often require maintenance windows or clinical downtime for updates. The solution isn’t to skip updates — it’s to build update cycles into operational planning, automate firmware inventory tracking, and prioritize patches based on the severity and exploitability of the addressed vulnerability rather than treating all updates equally.

Q: What is the difference between IoT security and OT security?

A: IoT and OT security overlap substantially but differ in priorities and device characteristics. OT (operational technology) security specifically addresses systems that monitor or control physical processes — PLCs, SCADA systems, industrial sensors. IoT is broader and includes consumer, commercial, and industrial connected devices. OT security prioritizes availability and safety above confidentiality — a process controller that goes offline is a worse outcome than one that leaks data. IoT security frameworks need to account for both priorities, which is why industrial IoT security requires different controls than consumer IoT despite sharing underlying technology.

Q: Can existing IoT devices be made secure after purchase?

A: Partially. Compensating controls can significantly reduce the risk from devices that shipped with weak security: change default credentials, disable unused features and open ports, place the device on a segmented network, monitor its traffic for anomalies, and keep firmware current. These measures don’t fix underlying hardware or firmware vulnerabilities that require vendor patches, but they reduce the attack surface and detect compromises faster. Devices that can’t receive firmware updates and run end-of-life operating systems should be treated as permanently risky and isolated or replaced based on the sensitivity of what they access.