Securing IoT devices with AI — why traditional firewalls are no longer enough

I have watched the same conversation play out in boardrooms and security planning sessions more times than I can count: IT leadership presents a firewall and endpoint policy and assumes IoT is covered. It is not. The firewall was designed for a world where you knew what was on your network, where it was, and what protocol it spoke. IoT obliterates all three assumptions simultaneously.

At Sd Pro Technology, we have deployed AI-driven threat detection across industrial IoT, healthcare device networks, and smart infrastructure installations. The pattern we see consistently is this: traditional security tools give organisations a false sense of coverage precisely because they appear to be working right up until the moment the breach occurs. By then, an attacker has often been inside the network for weeks — because the IoT device that served as the entry point never registered as anomalous to a signature-based system.

This post lays out why traditional perimeter security fails in IoT environments, what AI-driven detection can actually do about it, and — critically — how to think about deploying it responsibly in real-world infrastructure rather than in a clean laboratory environment.

The IoT attack surface: what makes it fundamentally different

The defining characteristic of an IoT deployment is heterogeneity at scale. A mid-sized hospital might have 15,000 connected devices spanning MRI machines, infusion pumps, HVAC sensors, access control panels, nurse call systems, and patient monitoring units — each manufactured by a different vendor, running a different operating system, updated on a different schedule, and communicating on a different protocol. A traditional network security model assumes you can define what belongs on the network, apply a consistent policy to it, and monitor deviations. An IoT network makes every one of those assumptions unreliable.

The threat model is also different. In a conventional enterprise environment, the attacker's primary target is data — and the path to data runs through user credentials, application vulnerabilities, and misconfigured cloud resources. In an IoT environment, the target is often operational: disrupting a manufacturing process, manipulating a medical device, disabling a physical security system, or recruiting devices into a botnet. The consequences of a successful attack extend from the digital into the physical world, and the detection window between compromise and real-world impact can be measured in seconds rather than days.

Over 60% of IoT compromises begin with unchanged factory credentials. Automated scanners find these within minutes of device deployment.

Unpatched firmware with known CVEs is present on the majority of enterprise IoT devices. Vendors frequently do not issue patches; devices frequently cannot apply them without manual intervention.

Legacy industrial protocols (Modbus, BACnet, DNP3) transmit in plaintext. An attacker with network access can intercept and modify command traffic without detection.

Compromised IoT devices with no EDR capability are invisible to traditional antivirus. Mirai and its descendants remain highly effective against unmonitored device fleets.

A compromised IoT device on a flat network becomes a stepping stone to IT systems. Printers, cameras, and building management systems have all been used as pivot points in documented breaches.

Malicious firmware inserted at the manufacturing or distribution stage. Harder to detect because the device behaves normally in all respects except the specific exfiltration behaviour.

Why traditional firewalls fail in IoT environments

The firewall has been the cornerstone of network security for three decades. It works on a simple principle: define what traffic is allowed, block everything else, and log anomalies for review. In a well-managed enterprise network with known endpoints, stable applications, and trained users, this model provides meaningful protection. In an IoT environment, five fundamental characteristics undermine it.

• 🔍 IoT devices cannot run endpoint agents

  A traditional security stack depends on software agents installed on every device — antivirus, EDR, DLP. The vast majority of IoT devices run stripped-down embedded operating systems with no capacity to run third-party software. They are, from the endpoint security perspective, invisible. The firewall sees a packet; it cannot see what generated it or whether the device generating it has been compromised.

• 🔐 Encrypted traffic blinds signature-based detection

  Signature-based intrusion detection works by inspecting packet payloads for known malicious patterns. As IoT vendors have begun adopting TLS for device communication — a genuine security improvement — the payload becomes opaque to inspection without a man-in-the-middle decryption proxy. Most IoT devices cannot participate in the certificate negotiation required to make that proxy work.

• 📋 Policy definition is impossible at IoT scale

  A firewall policy is only as good as the inventory it is based on. In a deployment of 10,000 devices across a dozen device categories from fifty vendors, maintaining an accurate, up-to-date policy definition is a continuous full-time task. In practice, organisations default to permissive policies that allow broad categories of traffic, which defeats the purpose of the perimeter model.

• 🔄 Legitimate and malicious traffic are structurally identical

  A compromised IoT device exfiltrating data over port 443 to an external IP looks, to a firewall, exactly like a legitimate device performing a routine firmware check. The traffic is valid protocol, valid port, valid certificate. Only behavioural context — the timing, volume, frequency, and destination pattern — reveals the anomaly. Firewalls do not reason about behavioural context.

• ⚡ Zero-day exploits have no signature to match

  Signature-based detection is by definition reactive. A novel exploit targeting a vulnerability in a specific IoT firmware version will not match any existing signature. The average time between a zero-day exploit being used in the wild and a signature being published is days to weeks — more than enough time for significant damage in an IoT context where devices cannot be taken offline for patching without operational disruption.

Firewalls answer the question: "Is this traffic permitted?" In IoT security, the more important question is: "Is this permitted traffic behaving normally?" That is a fundamentally different question — and it requires a fundamentally different approach.

How AI changes the detection equation

AI-driven IoT security does not replace perimeter controls — it adds a layer of behavioural intelligence that signature-based systems cannot provide. The core technique is anomaly detection: building a statistical model of what normal looks like for each device, each device category, and each network segment, and alerting when observed behaviour deviates from that baseline beyond a defined threshold.

This approach has three properties that make it uniquely suited to IoT environments. First, it does not require knowledge of specific attacks or vulnerabilities — it detects anything that looks abnormal, including zero-day exploits and novel attack patterns. Second, it scales to heterogeneous device fleets without requiring per-device policy configuration. Third, it can operate on network traffic metadata alone, without requiring access to packet payloads, which means it functions even in encrypted-traffic environments.

Passive network traffic analysis identifies and classifies every device on the network — vendor, device type, firmware version, protocol usage — without requiring agent installation. ML classifiers trained on device behaviour signatures can identify a Siemens HVAC controller from its traffic pattern alone.

Unsupervised ML (autoencoders, clustering) builds a dynamic model of normal behaviour for each device and device group over a 2–4 week observation window: typical communication partners, traffic volume distributions, connection timing, protocol mix, geographic destinations.

Streaming inference scores every network flow against the device's behavioural baseline, producing a continuous anomaly score. Flows exceeding a dynamic threshold — calibrated per device category to balance sensitivity and false positive rate — trigger an alert.

A supervised classifier maps anomalous behaviour to known threat categories (lateral movement, C2 communication, data exfiltration, scanning). Threat intelligence feeds enrich alerts with known malicious IP reputation data, recent CVE information, and attack campaign context.

High-confidence, high-severity alerts trigger automated responses: network segmentation (isolating the device to a quarantine VLAN), rate limiting, or blocking. Lower-confidence alerts route to a human analyst with full context — device history, similar incidents, recommended actions.

"An IoT device does not need to be running malware to be a security risk. It just needs to start behaving differently from what it normally does — and no human team can monitor that at scale."

The techniques that work: ML approaches for IoT anomaly detection

Not all machine learning approaches perform equally in IoT security contexts. The specific characteristics of IoT traffic — high volume, low per-flow complexity, significant device-category variation, and the rarity of true positive events — favour certain model architectures over others.

Neural networks trained to reconstruct normal traffic. High reconstruction error on anomalous input. Effective for detecting novel attacks with no labelled examples, making them ideal for zero-day detection in IoT fleets.

Unsupervised anomaly detection that isolates outliers by randomly partitioning the feature space. Computationally efficient, interpretable, and effective on the high-dimensional metadata features typical of IoT traffic analysis.

Long Short-Term Memory models capture temporal patterns in device communication sequences — ideal for detecting slow-burn attacks that unfold over hours or days and would be invisible in per-flow analysis.

Supervised classification of known attack types from labelled threat data. High accuracy, fast inference, interpretable feature importance. Works well as a second-stage classifier after unsupervised anomaly scoring.

Models network topology as a graph, detecting lateral movement and coordinated attack patterns that span multiple devices. Increasingly practical for deployment as inference hardware becomes more accessible.

Combining unsupervised anomaly scoring with supervised classification and network graph analysis produces the lowest false positive rate in production deployments — at the cost of higher infrastructure complexity.

In Sd Pro Technology deployments, the highest-performing configuration combines an Isolation Forest for per-device baseline anomaly scoring with an LSTM layer that captures sequential communication patterns over 24-hour windows. This two-stage approach reduces false positives by approximately 60% compared to single-model approaches — critical in operational environments where alert fatigue is a real and well-documented failure mode.

A manufacturing client operating an Export Processing Zone facility had 340 connected industrial devices across its production floor — PLCs, conveyor sensors, quality control cameras, and environmental monitors — sitting on the same network segment as their enterprise IT systems with no traffic segmentation. A penetration test had failed to find vulnerabilities because the testers were looking for known exploits in known systems. Three weeks after deploying our AI monitoring stack, the system flagged a PLC that had begun initiating outbound connections to an IP range in Eastern Europe at 02:00 daily — behaviour completely outside its normal operational profile. Investigation revealed the device had been compromised via a supply-chain firmware modification. No malicious payload had been executed; the exfiltration had been ongoing for an estimated 60 days before detection. The firewall had logged the traffic as permitted. The AI system detected it because no other PLC in that category had ever made that connection.

The false positive problem — and why it is not optional to solve

The single biggest operational challenge in AI-driven IoT security is not detection accuracy — it is false positive rate. A system that generates hundreds of false alerts per day will be tuned down by frustrated security teams, defeating its purpose. In IoT environments, where device behaviour can change legitimately due to firmware updates, seasonal operational patterns, or configuration changes, the baseline drift problem is particularly acute.

There is no technical shortcut here. Managing false positives in production IoT deployments requires three things: a device inventory system accurate enough to flag when a firmware update or configuration change explains a behaviour shift; a tiered alert system that routes high-confidence alerts to automated response and low-confidence alerts to human review rather than treating all anomalies identically; and a feedback loop from analyst decisions back into the model, so that confirmed false positives contribute to baseline recalibration rather than recurring indefinitely.

A security system that security teams learn to ignore is worse than no system at all — because it creates the illusion of coverage while providing none. Tuning for a false positive rate your analysts can actually work with is not a compromise on security; it is a prerequisite for achieving it.

Implementation roadmap: from perimeter-only to AI-augmented IoT security

For organisations moving from a traditional perimeter model toward AI-augmented IoT security, the transition is best approached as a staged programme rather than a single deployment event. Each stage builds the data and operational foundation the next stage requires.

Deploy passive network monitoring to discover and classify every device on the network. Do not attempt to enforce policy at this stage — the goal is visibility. Most organisations are surprised by both the number of devices they find and the protocols they are running. An accurate inventory is the prerequisite for everything that follows.

Segment IoT devices from IT systems using VLANs or microsegmentation. This is the single highest-return security action available to most organisations — it limits blast radius if a device is compromised and makes anomalous lateral movement detectable. Implement based on device category, not arbitrary network topology.

Deploy AI monitoring in observation-only mode and allow baseline behaviour models to develop over a minimum of four weeks — longer is better, to capture weekly and monthly operational cycles. Resist the temptation to enable alerting too early; premature alerting on an immature baseline produces the false positive rates that kill adoption.

Enable alerting with conservative thresholds, routing high-confidence alerts to automated response and lower-confidence alerts to analyst review. Track false positive rates by device category and adjust thresholds iteratively. Establish the feedback loop from analyst decisions to model recalibration before increasing sensitivity.

Integrate threat intelligence feeds, tune thresholds as the baseline matures, and conduct quarterly red team exercises specifically targeting IoT vectors. Update device inventory continuously as new devices are added. Review model performance metrics monthly — drift in precision or recall is an early indicator of either changing attack patterns or operational changes that are distorting the baseline.

Network infrastructure variability across African enterprise environments — intermittent connectivity, mixed-generation switching hardware, shared network infrastructure in multi-tenant buildings — creates specific challenges for AI IoT security deployments that are underaddressed in most vendor documentation. Edge inference architectures that process traffic locally and sync to central management asynchronously are significantly more resilient in these contexts than cloud-dependent monitoring approaches. This is a design decision that must be made before procurement, not after.

Kenya's Data Protection Act 2019 and the emerging East African Community cybersecurity harmonisation framework have direct implications for IoT security architecture — particularly around data residency for device telemetry and network logs, consent requirements for monitoring in healthcare IoT, and breach notification timelines. Security architects in the region need to design compliance requirements into the monitoring stack from day one, not retrofit them after deployment.

The perimeter is already gone — the question is what replaces it

The organisations that are winning at IoT security are not the ones with the biggest firewalls. They are the ones that have accepted a fundamental shift in how security must work: from boundary enforcement to behavioural intelligence, from static policy to dynamic baseline, from signature detection to anomaly reasoning.

AI does not make this problem easy. It makes it tractable — which is different. The scale of modern IoT deployments, the diversity of device types, and the sophistication of threat actors mean that no human team can monitor individual device behaviour at the granularity required. Machine learning can. But it needs accurate device inventories to classify against, clean network data to learn from, human analysts to close the feedback loop, and deployment architects who understand the operational context it is being asked to work in.

The firewall is not going away. It remains a necessary first line. But treating it as sufficient — in 2026, with 18 billion connected devices and counting — is not a security posture. It is a liability waiting to be discovered.

Doreen is CEO of Sd Pro Technology Ltd, where she leads development of AI-driven threat detection systems for IoT and enterprise environments. She holds a Cisco CCNA, a Certified Cybersecurity Technician credential (Learnovate, 2025), an MCSA, and a Master's in Data Analytics from KCA University. She lectures in Cyber Forensics at Riara University, Nairobi, and is completing her PhD at USIU-Africa.

Dr Doreen Bundi

IT Professional, Researcher & University Lecturer. Data-driven IT and research professional with 7+ years of experience spanning data analytics, AI-driven solutions, and academia. Proven expe