Silent Fleets, Loud Breaches: What Your IoT Infrastructure Is Telling Attackers (That You're Not Hearing)

Silent Fleets, Loud Breaches: What Your IoT Infrastructure Is Telling Attackers (That You're Not Hearing)

By Indrasol Security Research Team · March 2026 · 15 min read

For security architects, OT engineers, and technology leaders managing connected device fleets at scale

BEFORE YOU READ THIS

If you're already segmenting IoT devices, rotating certificates, and running behavioral baselines — this paper is for you. We're not going to cover default passwords or "patch your firmware." You know that.

What we're going to cover is the layer beneath: the architectural assumptions, protocol blindspots, and operational patterns that experienced teams get wrong — and that sophisticated adversaries actively exploit. The failures we document in client environments aren't the result of negligence. They're the result of applying sound IT security thinking to an environment with fundamentally different physics.

At Indrasol, we've spent years embedded in industrial, healthcare, and enterprise IoT environments — designing fleet security architectures, running red team exercises against connected infrastructure, and responding to incidents that started with a sensor and ended with an OT network shutdown. What follows is distilled from that work.

PART 1: THE ARCHITECTURE ASSUMPTIONS THAT ARE GETTING YOU COMPROMISED

The Perimeter Illusion

Most organizations have graduated from "IoT devices are on a separate VLAN" to believing that means they're secure. Segmentation is necessary — we've written extensively about it — but it's not sufficient, and treating it as a security destination rather than a foundation is where sophisticated attackers find their entry.

Here's what we see repeatedly in assessments: IoT VLANs are isolated from corporate workstations, but they share egress paths with operational systems. The firewall rules permit outbound traffic to cloud telemetry endpoints — which is correct — but they're written as destination-IP rules rather than FQDN + protocol + payload-validated rules. An attacker who compromises a temperature sensor doesn't need to pivot to your ERP. They need to pivot to your OT historian, which shares the same egress path and is reachable via the same firewall rule that permits port 8883 to your IoT cloud platform.

The fix isn't more VLANs. It's understanding that segmentation is a topology control, not a trust model. Zero Trust requires per-flow verification, not per-VLAN trust assignment. The difference sounds theoretical until you're explaining to a client how an attacker moved from a BACnet controller to a Modbus TCP segment that was "in a different VLAN."

The Management Plane Attack Surface Nobody Talks About

When security teams think about IoT attack surface, they think about devices. Adversaries think about the management plane first.

Your IoT fleet management console, OTA update infrastructure, certificate authority, device shadow/twin service, and telemetry pipeline are the crown jewels. A credential compromise on your fleet management platform gives an attacker authenticated, authorized access to every device in your fleet — with the ability to push firmware, modify configuration, and observe all telemetry. It's a better position than compromising individual devices one by one.

In our red team engagements, we compromise the management plane before we compromise devices in roughly 70% of exercises. The vectors are consistent: spear-phishing of fleet operators, exploitation of unpatched fleet management software running on-premises, weak API key management in CI/CD pipelines that automate OTA deployments, and — most commonly — cloud misconfiguration in the IAM policies governing IoT platform access.

The critical insight: your devices can be perfectly hardened and your fleet can still be fully compromised. Management plane security is not optional and not secondary.

The Protocol Trust Problem

IoT environments run a rich ecosystem of protocols that most security tools treat as opaque blobs. MQTT, CoAP, AMQP, OPC-UA, BACnet, Modbus, DNP3, Zigbee, Z-Wave, LwM2M — each has different security characteristics, different vulnerability profiles, and different inspection requirements. The operational reality is that most organizations have a heterogeneous mix of these, and their security tooling understands maybe two of them.

This creates a systematic blind spot. Your SIEM sees traffic flows — source IP, destination IP, port, bytes — but has no visibility into what's happening at the application layer within those flows. A compromised MQTT broker that's being used to relay C2 commands to a fleet of industrial sensors looks identical to a healthy MQTT broker at the flow level.

The more dangerous version of this problem is protocol downgrade. Many IoT devices that support encrypted protocols also support their unencrypted predecessors for "backward compatibility." Attackers who can position themselves on-path — which is easier in OT environments than in IT environments due to older switching infrastructure — can force protocol downgrades silently. If your monitoring doesn't verify protocol versions and enforce minimums, you'll never see it happen.

PART 2: WHAT SOPHISTICATED ADVERSARIES ARE ACTUALLY DOING

Living Off the Land in IoT Environments

The security community has internalized "living off the land" as an IT concept — attackers using built-in system tools (PowerShell, WMI, certutil) to avoid dropping malware that gets detected. The IoT equivalent is less discussed but equally dangerous.

Modern IoT devices run real operating systems — embedded Linux, VxWorks, QNX, INTEGRITY — with real tooling. A compromised ARM Cortex-A device running embedded Linux has BusyBox, wget or curl, a shell, and often Python. An attacker who achieves code execution on such a device has a capable pivot platform. They don't need to drop custom malware. They use the tools the device already has to beacon home, scan the network, exfiltrate data, and maintain persistence.

Detection is difficult because these tools are legitimate. The temperature sensor should be running wget to fetch updates. It should be running shell scripts as part of its operational cycle. The only distinguishing characteristic is behavioral — when it runs these tools, what arguments, what destinations, what frequency. This is why behavioral baselines on a per-device, per-process level are the correct detection primitive, not signature-based endpoint detection that doesn't exist for most IoT platforms.

The Firmware Implant Problem Is Worse Than You Think

When most practitioners think about firmware compromise, they think about nation-state actors with the resources to develop custom implants for specific platforms. That threat is real but niche. What's more operationally significant — and far more common than the industry acknowledges — is opportunistic firmware tampering at the supply chain and update delivery layers.

At Indrasol, we've assessed multiple organizations where third-party maintenance vendors had push access to device firmware without any cryptographic verification of what they were pushing. The firmware update workflow was: maintenance vendor uploads new firmware to a shared S3 bucket, devices poll the bucket and install whatever they find. No signature verification. No rollback telemetry. No differential analysis of what changed between versions.

An attacker who compromises that S3 bucket — or the maintenance vendor's deployment system — has authenticated, persistent access to every device in the fleet, through a mechanism designed to look exactly like normal operations. The indicators are at the update delivery layer, not the device layer. You'll never see it in endpoint telemetry.

Mitigations require end-to-end firmware integrity: manufacturer-signed firmware images, device-side signature verification before installation, immutable audit logs of what was installed on each device and when, and differential analysis of firmware changes to detect unexpected code additions. Most organizations have none of these. Some have one.

Certificate Sprawl Is the New Shadow IT

The shift to certificate-based device identity is correct and necessary. What we consistently find in mature IoT security programs is that they've solved the device certificate problem while creating a certificate management crisis.

The specific failure mode: organizations deploy IoT PKI, issue certificates to thousands of devices, and then lose track of them. Certificate lifetimes are set to two or three years because short lifetimes create operational burden. Revocation infrastructure exists on paper but isn't operationally tested. OCSP responders or CRL distribution points are reachable from IT networks but not from IoT network segments due to overly restrictive firewall rules.

The consequence: when a device is compromised or a private key is exposed, the path to credential revocation is unclear, manual, and slow. Meanwhile the device's certificate — which was supposed to be the cornerstone of your Zero Trust posture — continues to authenticate successfully. We've encountered organizations with compromised devices that continued to authenticate to fleet management platforms for weeks because certificate revocation wasn't operationally practiced and the process broke down under incident pressure.

The correct posture is 90-day certificate lifetimes, fully automated renewal via EST or a comparable protocol, revocation infrastructure that's reachable from every network segment where devices operate, and quarterly revocation drills where you deliberately revoke a certificate and verify the device loses access within the expected time window.

PART 3: THE CONVERGENCE PROBLEM NOBODY HAS SOLVED

IT/OT/IoT Is Three Different Security Philosophies in One Network

The industry talks about IT/OT convergence as a technical problem — how do you connect networks with different protocols, different latency requirements, different availability profiles? That's solvable with modern network architecture. The harder problem is that IT, OT, and IoT security represent three fundamentally different philosophical approaches to risk, and convergence forces them into conflict.

IT security: confidentiality-first. Patch aggressively. Assume breach. Detect and respond quickly. Take systems offline to remediate.

OT security: availability-first. Patch conservatively or not at all. Physical safety is paramount. Change management is rigorous. Taking systems offline has physical world consequences.

IoT security: scale-first. Devices are disposable and replaceable. Policy must be automated. Individual device security is less important than fleet-level policy enforcement.

When these philosophies converge in a shared infrastructure, the result is organizational friction that becomes a security gap. The IT security team wants to force-patch a firmware vulnerability on industrial sensors. The OT engineering team says patching requires a maintenance window that's six months away. The IoT operations team says the patch will break a sensor calibration that took three weeks to configure. The result: the vulnerability stays.

We've helped organizations resolve this through converged security governance models — not by merging the teams, but by establishing shared risk acceptance frameworks that give each discipline appropriate authority while requiring explicit, documented decisions when philosophies conflict. The key principle: security debt must be visible and owned. "We're accepting this risk because of operational constraints" is a legitimate position. "We didn't know about this risk" is not.

The Data Historian Is Your Most Exposed Asset

In industrial and building automation environments, the process data historian — the system that aggregates telemetry from OT and IoT devices for trend analysis, reporting, and operational intelligence — is typically the most exposed high-value asset in the converged environment.

Here's why it's structurally dangerous: the historian must receive data from OT/IoT networks (pulling it toward operational systems), and it must serve data to IT networks and business intelligence platforms (pulling it toward enterprise systems). It sits at the intersection of every trust zone. It runs Windows. It has SQL Server. It has network shares. It's often not patched on the same cycle as IT systems because OT teams manage it and operate under conservative change management practices.

From an attacker's perspective, the historian is the pivot point. Compromise it from the IoT side, and you have access to the enterprise side. Compromise it from the enterprise side via a phishing email, and you have reach into the OT network. In multiple incident response engagements, we've seen exactly this: the historian as the bridge that turned an IT breach into an OT disruption.

The mitigation is architectural: historians should be in a dedicated DMZ with strict unidirectional data flows enforced at the network level (not just firewall rules, but data diodes for the highest-security environments), independent authentication from both IT and OT directories, and aggressive patching cycles enforced by the security team, not the OT team.

PART 4: DETECTION ENGINEERING FOR IOT AT SCALE

Why Your Current SIEM Rules Won't Catch IoT Attacks

Most SIEM detection rules are written for IT environments and IT attack patterns. They look for lateral movement between Windows hosts, credential stuffing against Active Directory, abnormal PowerShell execution, data exfiltration via HTTP. IoT attacks have different signatures, different patterns, and different data sources.

The specific gaps we find in every SIEM assessment:

No coverage for IoT protocol anomalies. If you don't have a parser for MQTT, you have no visibility into what commands are being sent to your device fleet via your broker. An attacker who has compromised your MQTT broker and is pushing commands to devices is invisible in your SIEM.

No device-specific behavioral baselines. Generic "this device sent more traffic than usual" rules generate too many false positives to be operationally useful in IoT environments with variable duty cycles. Effective detection requires per-device baselines that account for operational schedules, seasonal patterns, and maintenance cycles.

No coverage for management plane events. Fleet console logins, API key usage, OTA update pushes, certificate issuance — these are the events that matter most for detecting management plane attacks, and they're almost never integrated into SIEM detection logic.

No physical-cyber correlation. A door access control device that starts making outbound HTTPS connections at 3am when the facility is empty is suspicious in a way that the SIEM alone can't detect. Effective IoT detection requires correlating network security events with physical world context — occupancy sensors, access logs, production schedules.

Building effective IoT detection requires custom detection engineering, not out-of-the-box SIEM rules. At Indrasol, we develop detection logic that is specific to each client's device population, protocol mix, and operational patterns. Generic rules are a starting point, not a destination.

Threat Hunting in IoT Environments

Reactive detection — waiting for alerts — is insufficient for sophisticated adversaries who operate below alert thresholds deliberately. Threat hunting in IoT environments requires proactive hypothesis-driven investigation with IoT-specific hunting playbooks.

Effective IoT threat hunting hypotheses to work through periodically:

Beacon hunting. Are any devices communicating on a suspiciously regular schedule to endpoints outside their documented communication profile? Malware beaconing is often more regular than legitimate traffic and appears in intervals — every 60 seconds, every 300 seconds — that deviate from expected device behavior patterns.

Protocol anomaly hunting. Are any devices using protocols outside their documented capability profile? A sensor that has never used SSH suddenly accepting SSH connections is a strong compromise indicator.

Credential usage anomaly hunting. Are any device certificates being used from multiple source IPs? Certificate cloning or theft typically manifests as the same device identity appearing to authenticate from different network locations simultaneously.

Firmware version anomaly hunting. Are any devices running firmware versions that don't match your authorized version manifest? Unauthorized firmware changes are one of the clearest indicators of supply chain or update-path compromise.

East-west traffic hunting. Are any devices communicating with other devices in patterns not reflected in their documented data flows? Device-to-device communication that wasn't there before — and isn't in your architecture documentation — is almost always a red flag.

PART 5: WHAT GOOD LOOKS LIKE

The Maturity Markers We Look for in Client Assessments

After years of assessing IoT fleet security programs, Indrasol has developed a clear sense of what separates programs that are genuinely resilient from programs that are compliant-on-paper. The markers of genuine maturity aren't about tools or budgets — they're about operational discipline.

Device identity is automated end-to-end. New devices get cryptographic credentials issued automatically at provisioning, renewed automatically before expiration, and revoked automatically upon decommissioning. No human touches this workflow in normal operations. Manual certificate management at fleet scale is operationally unsustainable and creates the gaps we described in Part 2.

The fleet inventory is authoritative and real-time. Not a spreadsheet updated quarterly. Not a CMDB that's 80% accurate. A live inventory that reflects the actual state of the fleet, updated automatically as devices connect and disconnect, and used as the authoritative source for security policy enforcement. When a device appears on the network that isn't in inventory, it's blocked and alerted — not silently permitted.

Security and operations are co-owners of fleet policy. Not "security sets policy, operations complains about it." Joint ownership means joint accountability. Security understands operational constraints deeply enough to set realistic policy. Operations understands security risk deeply enough to make informed tradeoffs. This doesn't happen without organizational structure that puts both functions at the same table.

Incident response has been practiced on IoT. Not tabletop exercises where everyone agrees the process works. Actual drills where a device is deliberately quarantined, the operations team responds to the resulting alert, forensics are attempted, and the process is timed and measured. The organizations that handle IoT incidents well are the ones that have practiced the specific, concrete steps with the specific, concrete tools in their environment.

The management plane is treated as a Tier-0 asset. Fleet console, OTA infrastructure, PKI, device shadow services — all governed by the same privileged access management controls as Active Directory domain controllers and production databases. MFA required. Session recording enabled. Just-in-time access for routine operations. Quarterly access reviews. Because it is Tier-0: full fleet access with legitimate credentials is the highest-value target in your environment.

The Conversation We Have With Every Client

At the end of every IoT security assessment, we have a version of the same conversation. The client's security posture is better than average. They've done the basics well. They have segmentation, they have some monitoring, they've addressed the most obvious credential issues. And they want to know: what's the one thing we're getting wrong?

The answer is almost always the same: you're securing your devices but not your fleet.

A fleet is not a collection of devices. It's a system — devices plus management infrastructure plus operational processes plus the humans who administer it. The attack surface of a fleet is the attack surface of all of those components combined. And the weakest component, consistently, is not the device. It's the management plane that was stood up quickly to make device operations efficient, secured to a standard appropriate for an internal tool rather than a Tier-0 asset.

The shift in mindset — from device security to fleet security — is the difference between thinking about individual locks on individual doors and thinking about the security of the building as a system. You can have perfect locks on every door and still have the security office unmanned, the master key hanging on a hook in an unlocked closet, and no alarm on the window.

IoT fleet security is a systems problem. Solve it that way.

ABOUT INDRASOL

Indrasol is a technology and security consulting firm specializing in enterprise IoT security architecture, OT/IT convergence, and connected infrastructure risk management. Our team brings deep practitioner experience from industrial, healthcare, and large-scale enterprise IoT environments — designing secure architectures, conducting red team assessments against connected infrastructure, and building the operational programs that sustain security at fleet scale.

We work with organizations that are past the basics and ready to build programs that are genuinely resilient — not just compliant.

To discuss your IoT fleet security posture, reach out to our team at indrasol.com

Tags: IoT Security · Fleet Architecture · OT/IT Convergence · Zero Trust · Threat Detection · Industrial Security · Indrasol Research