IoT Security: The Complete Guide to Protecting Connected Devices
Last updated: April 2026
As of 2026, somewhere between 21 and 24 billion IoT devices are connected to networks worldwide, according to IoT Analytics. Most of them cannot run antivirus software. Many shipped with the password “admin.” And 57% of them carry medium- or high-severity vulnerabilities, based on data from multiple industry reports. This guide covers what IoT security actually requires in practice, why connected devices demand a different security model than laptops and servers, and what organizations across healthcare, manufacturing, and critical infrastructure are doing to close the gap.
On this page:
- What Is IoT Security?
- IoT Security Threats and Challenges
- IoT Device Security Fundamentals
- IoT Network Security and Segmentation
- IoT Security Best Practices
- IoT Security Standards, Frameworks, and Compliance
- Choosing an IoT Security Solution
- IoT Security by Industry
- Where IoT Security Is Headed
What Is IoT Security?
IoT security is the set of technologies, processes, and policies that protect connected devices, their network traffic, and the data they generate from unauthorized access, compromise, and misuse.
That definition is simple, but the practice is not. Traditional cybersecurity assumes you can install an agent on the endpoint, push regular patches, and enforce authentication policies directly on the device. IoT breaks every one of those assumptions. A network-connected infusion pump, a building HVAC controller, and a factory floor PLC all lack the compute resources, memory, and operating system flexibility to support the security tools that protect a laptop or server. They run proprietary firmware. They receive patches infrequently, if ever. And many of them communicate using protocols that predate modern encryption standards.
This is why IoT security operates across three layers simultaneously:
Device security addresses the device itself: firmware integrity, credential management, configuration hardening, and vulnerability assessment for the specific hardware and software each device runs.
Network security protects the traffic between devices and the systems they communicate with. For IoT, this layer carries outsized importance because it is often the only place where security teams can apply controls to devices they cannot touch directly. Network segmentation, behavioral monitoring, and traffic analysis all live here.
Cloud and data security covers the platforms that collect, store, and process IoT data, along with the APIs that connect them. A misconfigured cloud backend can expose device data at scale, as the Mars Hydro incident demonstrated in 2025, when 2.7 billion IoT device records were left accessible due to a cloud storage misconfiguration.
The IoT security market reflects the urgency. Industry estimates put spending somewhere between $18 billion and $52 billion in 2026, depending on how broadly you define the category. What is not in dispute: spending is accelerating because the attack surface is growing faster than most security teams can inventory it.
Related: 10 IoT Healthcare Examples and Their Security Implications
IoT Security Threats and Challenges
What Attackers Are Doing in 2026
IoT threats have matured well beyond opportunistic scanning for default passwords. The attacks making headlines in 2025 and 2026 are coordinated, well-resourced, and increasingly automated.
Botnets are operating at an unprecedented scale. The Aisuru botnet (also tracked as TurboMirai) achieved DDoS capability exceeding 20 Tbps in the 2025-2026 timeframe, a 700% year-over-year jump in attack potential. Microsoft Azure blocked a single 15.72 Tbps DDoS attack linked to IoT botnets in early 2026. These botnets recruit consumer and enterprise IoT devices alike, from IP cameras to network video recorders.
Supply chain compromise baked into hardware. BadBox 2.0 compromised more than 10 million smart TVs, projectors, and infotainment systems with pre-installed malware in 2025, making it the largest known TV botnet. The malware was present before the devices ever reached the buyer. Supply chain attacks at this scale make post-deployment security controls essential, not optional.
Ransomware using IoT as a beachhead. Nozomi Networks reported a 46% surge in ransomware attacks targeting OT systems in 2025. The common pattern: attackers exploit a vulnerable IoT device to gain initial network access, then pivot laterally into higher-value IT or OT systems. The IoT device is the entry point, not the final target.
Cloud-side failures with device-scale consequences. The Mars Hydro data exposure (2.7 billion records) showed that even when devices themselves are functioning normally, a single cloud misconfiguration can compromise an entire fleet’s data. IoT security has to extend beyond the device.
AI-powered reconnaissance is expanding the attack surface. The World Economic Forum’s 2026 Global Cybersecurity Outlook found that 87% of surveyed executives identified AI-driven vulnerabilities as an increasing cybercrime risk. Generative AI lowers the cost and complexity of crafting targeted attacks against IoT infrastructure, from automated vulnerability scanning to social engineering of device operators.
Why IoT Devices Are Uniquely Difficult to Secure
The challenge with IoT is structural, not just a matter of better patch management:
Resource constraints are real. Most IoT devices lack the CPU, memory, and storage to run the security agents that protect traditional endpoints. You cannot install CrowdStrike on an infusion pump.
Patching cycles are measured in weeks, not hours. Research shows an average of 48 days for manufacturers to release a critical security patch for an IoT device. For medical devices and industrial controllers, the actual deployment timeline is often far longer because patches require vendor validation and scheduled maintenance windows.
Default credentials persist at scale. Despite years of industry warnings, default usernames and passwords remain one of the most common attack vectors. Many devices ship with credentials that are identical across every unit produced.
Shadow IoT is growing. Devices connect to enterprise networks without security team awareness or approval. Facilities teams install smart building systems. Clinical engineers connect new medical devices. Each one expands the attack surface without appearing in the IT asset inventory.
Protocol diversity complicates monitoring. IoT devices communicate over dozens of protocols, many proprietary, some without built-in encryption. This diversity means that conventional network monitoring tools designed for HTTP/HTTPS traffic miss a significant portion of IoT communications.
Forescout’s 2026 research identified the riskiest device types across four categories. In IoT specifically, VoIP systems, printers, time clocks, network video recorders, and RFID readers led the list. In IoMT (Internet of Medical Things), medication dispensing systems, medical image printers, DICOM gateways, MRI scanners, and healthcare workstations were the most exposed. Financial services recorded the highest average device risk of any industry, followed by government and healthcare.
Related: The Top IoT Cybersecurity Breaches in 2025
Related: IoT Security: Navigating the Connected World
IoT Device Security Fundamentals
Securing individual IoT devices starts with knowing they exist, understanding their risk profile, and applying the right controls given their constraints.
Device Discovery and Inventory
You cannot apply a security policy to a device you do not know is on your network. Inventory is the foundation, and it is harder than it sounds. Enterprise environments routinely discover 15-30% more connected devices than IT teams expected once they deploy proper discovery tools.
There are two primary approaches to device discovery:
Passive monitoring analyzes network traffic without sending any packets to the devices themselves. It observes communication patterns, extracts device identifiers from protocol headers, and builds an inventory from what it sees on the wire. Passive monitoring is critical for environments where active probing could disrupt sensitive equipment, like clinical networks with medical devices that cannot tolerate unexpected traffic.
Active scanning sends probes to devices to elicit responses that reveal their identity, firmware version, and configuration. Active scanning provides more detailed information but carries a risk of disrupting devices that were not designed to handle unexpected queries.
The most effective inventory programs combine both approaches, weighted toward passive methods for sensitive device populations. Asimily’s protocol analyzer uses deep packet inspection to passively discover and automatically categorize IoT devices, their services, connections, and applications without sending traffic that could disrupt clinical or operational equipment. When a new device type appears on the network, Asimily’s rapid protocol analysis capability allows it to be identified and classified quickly, rather than waiting for a signature database update.
A complete device profile goes beyond make and model. It should include the manufacturer, firmware version, operating system, communication patterns and peers, open ports, known vulnerabilities, and the device’s function within the organization. That last element, function, matters because it determines the business impact if the device is compromised or taken offline.
Vulnerability Assessment and Risk Prioritization
A large hospital network might have 50,000 connected devices carrying a combined total of hundreds of thousands of CVEs. Treating every CVE equally would bury the security team in work that does not meaningfully reduce risk.
CVSS scores alone are insufficient for IoT vulnerability prioritization. A critical CVSS score on a device that sits on an isolated network segment with no internet connectivity and no known exploit in the wild presents far less actual risk than a medium-severity vulnerability on an internet-facing device with a published proof-of-concept exploit.
Effective IoT vulnerability management requires contextual analysis: Is there a known exploit? Is the device reachable from the internet or from other compromised network zones? What is the business criticality of the device? Are compensating controls already in place?
Asimily approaches this through a combination of human analysis from Asimily Labs, AI/ML-based techniques, and structured use of the MITRE ATT&CK framework. Rather than using MITRE ATT&CK only for classification (as many platforms do), Asimily uses the framework for actual attack path analysis, determining whether a vulnerability on a specific device in a specific network context is realistically exploitable. This approach can reduce the list of devices requiring immediate action by an order of magnitude compared to raw vulnerability scanning, letting teams focus remediation effort where it reduces the most risk.
Firmware Security and Patch Management
When patches are available, applying them quickly matters. But for many IoT devices, patches arrive slowly, require vendor-specific deployment procedures, and demand scheduled maintenance windows that can stretch weeks or months into the future.
This is where compensating controls become essential. Virtual patching applies network-level protections that block exploitation of known vulnerabilities without modifying the device itself. Segmentation policies restrict what a vulnerable device can communicate with, containing the blast radius if it is compromised. Configuration hardening removes unnecessary services and hardens the device’s attack surface within whatever management capabilities it provides.
Asimily’s patching methodology combines direct firmware updates (when available and tested) with automated compensating controls for devices that cannot be patched immediately. The platform can model the risk impact of a remediation action before it is executed, giving teams confidence that a change will actually improve their security posture without disrupting operations.
Related: Maximize Uptime and Minimize Vulnerabilities with Automated IoT Patching
Related: How to Manage IoT Device Configurations at Scale
Related: Passive vs. Active Scanning: What Is the Difference?
IoT Network Security and Segmentation
For devices that cannot protect themselves, the network is the security control plane. This section covers the strategies that make network-level IoT protection work in practice.
Why the Network Layer Matters Most for IoT
Traditional endpoint security assumes the endpoint cooperates: it runs an agent, it accepts policies, it reports its status. IoT devices do none of these things reliably. The network is the one layer that provides visibility and control over every connected device, regardless of whether that device can host its own defenses.
Network-based controls serve as the compensating mechanism for every IoT limitation. Cannot patch? Segment the device and restrict its communications to only what is required. Cannot install an agent? Monitor its traffic patterns at the network layer and alert on deviations. Cannot enforce authentication? Place the device behind network access controls that verify trust before allowing connections.
Network Segmentation: Reducing Blast Radius
Network segmentation for IoT means isolating connected devices into dedicated network zones that limit their ability to communicate with systems and users they do not need to reach. If an attacker compromises an IP camera, segmentation prevents that camera from becoming a launching point into the electronic health record system or the domain controller.
At the most basic level, VLAN-based segmentation groups IoT devices onto separate network segments with firewall rules governing traffic between segments. This approach works and is a significant improvement over flat networks, where every device can reach every other device. But VLAN segmentation has practical limits. The number of policies required grows quickly as device populations and use cases expand, and maintaining those policies manually creates operational drag that causes segmentation projects to stall.
Microsegmentation: Device-Level Precision
Microsegmentation takes isolation further, applying policies at the individual device or workload level rather than at the subnet level. A microsegmented network can enforce that a specific MRI scanner communicates only with the PACS server, its vendor’s update service, and the network management system, denying all other connections.
The challenge with microsegmentation has always been policy creation. Writing granular policies for thousands of heterogeneous devices, each with different communication requirements, is a project that overwhelms most security teams before it delivers results.
This is where device intelligence changes the equation. When the segmentation platform understands what each device is, what it does, and what its normal communication behavior looks like, it can generate segmentation policies automatically rather than requiring manual rule-writing for each device. Asimily combines its deep device inventory (built from passive deep packet inspection) with behavioral baselines to produce recommended segmentation policies that teams can review, simulate, and deploy. The platform integrates with existing network infrastructure, including Cisco ISE and other NAC solutions, firewall platforms, and switch infrastructure, so segmentation enforcement happens through the equipment already in place.
The Asimily approach to segmentation is built on the premise that you need to understand the device before you can segment it correctly. A generic “IoT VLAN” treats a medical infusion pump and a smart TV identically. Intelligence-driven segmentation recognizes that these devices have entirely different risk profiles, communication needs, and business criticality, and enforces policies accordingly.
Related: Segmentation Orchestration from Asimily
Continuous Monitoring and Threat Detection
Segmentation reduces the blast radius, but monitoring detects threats within and across segments. Behavioral analytics establishes a baseline of normal communication for each device type and alerts when a device deviates, connecting to an unexpected destination, transferring unusual data volumes, or communicating over a protocol it has never used before.
Effective monitoring for IoT requires the ability to parse the protocols IoT devices actually use, not just standard IT protocols. Asimily’s threat detection engine uses a policy engine alongside threat intelligence feeds and supports custom detection rules that can be built without programming, allowing teams to encode organization-specific logic. When detection triggers, automated response options range from alerting to quarantining the device at the network switch. Asimily also provides packet capture on detection events, a capability that gives incident responders the raw data they need for forensic analysis.
Related: Network Segmentation Security Best Practices
Related: Targeted Segmentation: Manage IoT Risk 10x Faster
Related: Network Segmentation and Microsegmentation Solutions
IoT Security Best Practices
A practical checklist for security teams managing IoT environments:
- Discover and inventory every connected device. Automated, continuous discovery (not a one-time scan) is essential because new devices connect to networks constantly. Your inventory should include device identity, firmware version, communication patterns, and business function.
- Segment IoT devices onto dedicated network zones. At a minimum, IoT devices should not share network segments with sensitive IT systems. Ideally, segment by device function and risk profile.
- Prioritize vulnerabilities by exploit likelihood and business impact. Raw CVSS scores overcount low-risk findings and underweight exploitable vulnerabilities on critical devices. Use contextual risk scoring that accounts for network exposure, known exploits, and compensating controls.
- Apply compensating controls for devices that cannot be patched immediately. Virtual patching, segmentation policy tightening, and configuration hardening all reduce risk without requiring firmware changes.
- Monitor device behavior continuously. Baseline what normal looks like for each device type and alert on deviations. Behavioral monitoring catches threats that signature-based tools miss.
- Eliminate default credentials. Enforce credential changes at deployment and audit for default passwords on a regular cycle. This single action closes one of the most exploited attack vectors.
- Encrypt data in transit and at rest. Where devices support encryption, enable it. Where they do not, use network-layer encryption and segmentation to protect the data path.
- Maintain an incident response plan that includes IoT. Your IR plan should address IoT-specific scenarios: how to quarantine a compromised medical device without disrupting patient care, how to isolate a factory floor sensor without halting production, and who has authority to take a device offline.
- Evaluate device security before purchase. Procurement is the earliest opportunity to reduce IoT risk. Assess manufacturer security practices, patch support commitments, and end-of-life policies before devices enter your environment. Tools like manufacturer disclosure statements (MDS2 in healthcare) provide structured security data for pre-purchase evaluation.
- Audit and update on a regular cadence. IoT environments change constantly. New devices appear, firmware versions drift, and threat intelligence evolves. Quarterly reviews of inventory accuracy, segmentation policy effectiveness, and vulnerability remediation progress keep the program current.
Want this as a downloadable reference? Get the IoT Security Best Practices Checklist (PDF) →
IoT Security Standards, Frameworks, and Compliance
NIST Cybersecurity Framework for IoT
The National Institute of Standards and Technology established its Cybersecurity for IoT Program in 2020 with the goal of developing standards and guidance for IoT device security. The NISTIR 8259 series defines a core baseline of cybersecurity capabilities that IoT device manufacturers should build into their products, covering device identification, configuration, data protection, logical access, software updates, and cybersecurity awareness.
For organizations deploying IoT devices, the broader NIST Cybersecurity Framework (CSF) provides the risk-management structure, organized around five functions: Identify, Protect, Detect, Respond, and Recover. Mapping IoT security controls to the CSF gives security teams a common language for communicating IoT risk to leadership and auditors.
EU Cyber Resilience Act
The European Union’s Cyber Resilience Act introduces mandatory security requirements for all products with digital elements sold in the EU market. The compliance timeline is phased: EU member states must appoint conformity assessment bodies by June 2026, incident reporting obligations take effect in September 2026 (requiring manufacturers to notify authorities of actively exploited vulnerabilities within 24 hours), and full compliance becomes mandatory in December 2027. For organizations that sell or deploy IoT devices in European markets, the CRA will reshape procurement and vendor management processes.
Industry-Specific Regulations
Healthcare: HIPAA’s Security Rule requires covered entities to protect electronic protected health information (ePHI), and IoT/IoMT devices that process or transmit ePHI fall squarely within scope. The FDA has also strengthened premarket and postmarket cybersecurity requirements for medical devices, making security a regulatory prerequisite for market clearance.
Energy and Utilities: NERC CIP standards require cybersecurity controls for critical infrastructure in the bulk electric system, including connected monitoring and control devices.
Industrial: IEC 62443 provides a framework for securing industrial automation and control systems, applicable to manufacturing, chemical processing, and other ICS environments.
MDS2 for Medical Devices
The Manufacturer Disclosure Statement for Medical Device Security (MDS2) is a standardized form that provides structured security information about a medical device’s capabilities, including authentication, encryption, audit logging, and update mechanisms. HDOs (healthcare delivery organizations) use MDS2s during procurement to evaluate whether a device meets their security requirements before purchase. Asimily’s ProSecure database maintains a comprehensive library of device security profiles, including MDS2 data, making pre-purchase security evaluation practical even for organizations managing thousands of device types.
Related: What Are MDS2s and Why Should You Care?
Related: Medical Device Security Standards 2025: What HDOs Need to Know
Choosing an IoT Security Solution
If you are evaluating IoT security platforms, the following capabilities separate tools that work in production from those that work only in demos.
Core Evaluation Criteria
Agentless discovery that actually covers your device types. Any platform can find standard IT devices. The test is whether it can identify and classify the niche IoT and OT devices specific to your industry: infusion pumps, PLCs, building automation controllers, and laboratory equipment. Ask vendors how they handle devices they have not seen before. Asimily’s rapid protocol analysis capability addresses this directly, allowing new device types to be added without waiting for a full product release cycle.
Risk-based vulnerability prioritization, not just vulnerability scanning. Scanning produces a list. Prioritization tells you which items on that list actually matter given your network context, device criticality, and existing compensating controls. Look for platforms that analyze exploit likelihood using structured frameworks like MITRE ATT&CK, not just CVSS re-ranking.
Automated segmentation policy generation. Manual policy creation is the single biggest reason segmentation projects fail to deliver results at scale. Evaluate whether the platform can recommend policies based on observed device behavior and allow you to simulate the impact of those policies before enforcement.
Integration with your existing infrastructure. IoT security tools that require forklift replacement of your network equipment will not survive procurement review. Look for platforms that enforce policy through your current NAC, firewall, and switch infrastructure.
Industry-specific intelligence. Healthcare IoT, manufacturing OT, and smart building systems have different device populations, regulatory requirements, and operational constraints. Generic device fingerprinting is not enough.
The Vendor Evaluation
When evaluating platforms, request a proof-of-concept deployment in your actual environment, not a sanitized demo network. Key questions to answer during evaluation:
What percentage of your devices does the platform discover and correctly classify? How does it handle devices it does not initially recognize? What is the time-to-value from deployment to actionable risk prioritization? Can it generate segmentation policies you trust enough to enforce? Does it integrate with your existing security workflows (SIEM, SOAR, ticketing)?
See how Asimily manages IoT security across healthcare, manufacturing, and enterprise networks →
IoT Security by Industry
Healthcare and Medical Device Security
Healthcare faces the most complex IoT security challenge of any industry. A mid-size hospital may have 10,000 to 50,000 connected devices across clinical, facilities, and IT functions. Many clinical devices directly affect patient safety. Downtime is not an abstract business cost; it can delay treatment.
The regulatory environment compounds the complexity. HIPAA, FDA cybersecurity guidance, and the 2026 HIPAA Security Rule update all impose requirements on how connected devices must be secured. MDS2 compliance, medical device lifecycle management, and the growing threat of ransomware targeting healthcare systems all demand a security program purpose-built for this environment.
Asimily works with healthcare delivery organizations across the U.S. to provide IoMT visibility, risk prioritization, and segmentation. The platform’s healthcare-specific intelligence covers medical device protocols, clinical workflow patterns, and regulatory compliance mapping that generic IoT security tools do not address.
Related: IoT in Healthcare: Examples and Security Implications
Manufacturing and Industrial IoT
IT/OT convergence has connected factory floor equipment, SCADA systems, and industrial controllers to enterprise networks. The Purdue model, which historically separated IT and OT into distinct layers, is being compressed as organizations seek operational data from OT systems in real-time.
This convergence creates new attack paths. A compromised IT system can now reach OT equipment that was previously air-gapped. Industrial IoT security requires visibility across both IT and OT domains, with segmentation that enforces boundaries between them.
Related: Your Guide to Industrial IoT Security
Smart Cities and Critical Infrastructure
Smart city IoT deployments operate at a massive scale: traffic management, utility metering, environmental monitoring, and public safety. The security challenge is that these systems are physically distributed, often managed by multiple agencies, and increasingly targeted by nation-state actors.
Related: The Role of IoT in Smart Cities
Retail and Hospitality
Point-of-sale systems, surveillance cameras, building automation, and guest-facing IoT all create exposure in retail and hospitality environments. PCI DSS compliance intersects with IoT security for any device that touches cardholder data.
Related: Retail Cyberattacks That Hurt Businesses in 2025
Where IoT Security Is Headed
AI on Both Sides
AI is reshaping IoT security in two simultaneous and opposing directions. On defense, machine learning improves behavioral baseline accuracy, reduces false positives in anomaly detection, and accelerates threat response automation. On offense, generative AI lowers the skill barrier for attackers crafting targeted exploits and social engineering campaigns against IoT operators. The WEF’s 2026 survey found that 87% of the CISOs surveyed identified AI as an increasing cybercrime risk, ranking it above traditional threats like ransomware.
Regulatory Acceleration
The EU Cyber Resilience Act enforcement timeline (conformity bodies by mid-2026, incident reporting by late 2026, full compliance by the end of 2027) will pressure manufacturers to build security in, shifting some burden from operators to OEMs. In the U.S., FDA medical device cybersecurity requirements continue to tighten, and sector-specific regulations for critical infrastructure are expanding. Organizations that invest in IoT security infrastructure now will be better positioned when these regulations move from guidance to mandate.
The Attack Surface Keeps Growing
The WEF flagged physical AI as an emerging concern: intelligent robots in warehouses, ports, and logistics environments that combine IoT connectivity with autonomous decision-making. As these systems scale, the convergence of physical and cyber risk will demand security models that address both domains simultaneously.
Start Securing Your IoT Environment
Effective IoT security comes down to three things: see every device on your network, understand which vulnerabilities actually put you at risk, and enforce segmentation that limits what an attacker can do if a device is compromised. Everything else, compliance, patching, and incident response, builds on that foundation.
Asimily provides the visibility, risk prioritization, and segmentation orchestration that security teams need to manage IoT exposure across their entire cyber asset attack surface. From healthcare to manufacturing to critical infrastructure, the platform addresses the full device lifecycle from purchase to end-of-life.
Talk to an Asimily IoT Security Expert →
Download the IoT Security Best Practices Checklist (PDF) →
Asimily is the next-generation cyber asset and exposure management platform for IT, IoT, OT, and IoMT environments. Learn more about our approach →
Secure Every IoT Device.
Automatically.
Cyber threats move fast — so should you. Asimily gives instant inventory and smart, prioritized risk mitigation insights for every IoT, OT, and IoMT device — so you can take action before threats strike.