A hospital radiology department connects a new MRI machine to the network. It runs an embedded Linux kernel from 2019, communicates over DICOM on an unencrypted port, cannot accept an endpoint agent, and the manufacturer says patching it would void the warranty. It is now on the same VLAN as the nurses’ workstations.
A manufacturing plant connects a programmable logic controller to the corporate network so operations can monitor production metrics from their desks. The PLC speaks Modbus TCP with no authentication. It controls a physical process that, if disrupted, shuts down a production line costing the company six figures per hour.
These are not hypothetical scenarios. They are the conversations that Solutions Engineers walk into every week in healthcare and manufacturing accounts. IoT security is not about securing smart thermostats — it is about protecting devices that keep patients alive and factories running, devices that were never designed to exist on an IP network alongside commodity IT infrastructure.
Why IoT Is the Fastest-Growing Attack Surface
IoT Analytics projects over 30 billion connected IoT devices by 2027. But the growth in device counts is not the core problem. The core problem is what these devices are:
- Unpatchable: Many IoT devices run firmware that receives updates rarely or never. Medical devices may go years between FDA-cleared software updates. Industrial PLCs may run the same firmware for a decade.
- Agentless: You cannot install CrowdStrike or Defender on an infusion pump, a security camera, or a SCADA controller. There is no endpoint to protect.
- Protocol-ancient: Industrial environments speak Modbus, BACnet, DNP3, and PROFINET — protocols designed decades before cybersecurity was a concern. No encryption. No authentication. No integrity checking.
- Default credentials: Shodan searches routinely find thousands of internet-facing IoT devices with factory-default usernames and passwords.
- Long-lived: A laptop gets replaced every 3-4 years. An MRI machine runs for 15-20 years. A building automation system might outlive the company that installed it.
The Mirai botnet demonstrated what happens when these devices are compromised at scale — over 600,000 IoT devices generating a 1.2 Tbps DDoS attack. But DDoS is the least concerning outcome. In healthcare, a compromised infusion pump can alter drug dosages. In manufacturing, a compromised PLC can damage physical equipment or endanger workers.
The Purdue Model: Framework for OT/IT Convergence
Before discussing specific technologies, you need a shared vocabulary with the customer. The Purdue Enterprise Reference Architecture provides that vocabulary:

- Level 0-1: Physical process, sensors, actuators, PLCs, RTUs, safety controllers — the devices that directly control equipment.
- Level 2: HMIs, SCADA systems, engineering workstations — where operators interact with the process.
- Level 3: Manufacturing execution systems (MES), historians, site-level operations management.
- Level 3.5 (DMZ): The critical boundary between OT and IT. Data diodes, jump servers, and proxy systems live here. No traffic should flow directly between Level 3 and Level 4.
- Level 4-5: Enterprise IT, ERP systems, email, standard corporate infrastructure, and internet connectivity.
When you walk into a manufacturing account and draw the Purdue model on a whiteboard, you establish credibility immediately. Most OT teams know this framework. Most IT teams do not. Drawing it bridges both teams in the room, and it gives you a visual framework for explaining where your solution fits. The critical architecture point: traffic should flow vertically through defined conduits, never horizontally across levels without inspection.
ISE Profiling: Discovering What Is on the Network
You cannot secure what you cannot see. The first challenge in any IoT security engagement is answering: “What devices are actually on your network?” Most customers cannot answer this accurately. Their CMDB is outdated. Their asset inventory does not include OT devices.
Cisco ISE solves this through device profiling — identifying and classifying devices based on network behavior without requiring an agent. ISE collects attributes from multiple probes:
| Probe | What It Collects | Use Case |
|---|---|---|
| DHCP | Fingerprint, hostname, class identifier | Initial classification when a device joins |
| HTTP | User-Agent string | Identifying device OS and type |
| SNMP | Device description, system OID, CDP/LLDP data | Network devices, managed IoT |
| NMAP | Open ports, OS fingerprint, services | Deep inspection of unknown devices |
| NetFlow | Traffic patterns, destination IPs, protocols | Behavioral profiling |
When a new device connects, ISE classifies it — for example, “GE Healthcare CARESCAPE Monitor” — and assigns the appropriate authorization policy, placing it on the correct VLAN with specific ACLs. ISE continues collecting data and can reclassify devices via Change of Authorization (CoA) as more information becomes available.
SE positioning tip: In discovery calls, ask: “If I asked you right now to give me a complete list of every connected device — every IP camera, badge reader, infusion pump — could you do it?” The answer is almost always no. That opens the door for ISE profiling.
Network Segmentation and Microsegmentation
Profiling tells you what is on the network. Segmentation controls what those devices can talk to.

A typical healthcare VLAN architecture places clinical workstations, critical medical devices, imaging systems, lab equipment, building automation, physical security cameras, and guest WiFi on dedicated VLANs — each with dedicated security policies enforced at the firewall or through Security Group Tags.
For granular control beyond VLANs, Cisco TrustSec assigns Security Group Tags (SGTs) based on device identity. ISE classifies a device and assigns an SGT. Switches and firewalls enforce Security Group ACLs based on source and destination SGTs. Policy is defined in a matrix: “Medical Devices (SGT 10) can talk to Medical Servers (SGT 20) on port 443 only. Medical Devices cannot talk to other Medical Devices.”
The critical rule: IoT devices should reach the specific servers and services they need, and nothing else. An infusion pump needs to talk to the pump management server on one port. It does not need access to the EHR database, the internet, or the device on the next bed.
NAC for Headless Devices: MAB + Profiling

802.1X is the gold standard for network access control, but IoT devices cannot do 802.1X. They have no supplicant, no certificates, no user credentials. The solution is MAC Authentication Bypass (MAB) combined with profiling:
- Device connects to the switch port.
- Switch detects no 802.1X supplicant response after EAP timeout.
- Switch sends the MAC address to ISE via RADIUS.
- ISE looks up the MAC, checks profiling data, and returns the authorization policy.
- ISE assigns VLAN, downloadable ACL, or SGT based on device profile.
MAB alone is weak — MAC addresses can be spoofed. Strengthen it with profiling validation (ISE checks DHCP fingerprint and traffic patterns, not just the MAC), sticky MAB (alert on MAC changes per port), Change of Authorization to quarantine anomalous devices in real time, and port security to limit MAC addresses per port.
Healthcare-Specific Considerations
The FDA’s premarket cybersecurity guidance (updated 2023) requires manufacturers to include cybersecurity controls in device design. Newer medical devices may support 802.1X, encrypted communications, and software updates. Ask about device vintage — the conversation changes significantly based on pre-2020 vs. post-2020 equipment. Manufacturers now provide Software Bills of Materials (SBOMs) listing components and known vulnerabilities.
HIPAA does not explicitly mandate segmentation, but the Security Rule’s access control requirements (45 CFR 164.312(a)(1)) effectively require it. If medical devices transmit ePHI and sit on the same VLAN as guest WiFi, the customer has a compliance gap. That is a powerful talking point in customer meetings.
Healthcare organizations increasingly deploy Medical Device Management platforms — Claroty (Medigate), Armis, Ordr, and Cynerio — for passive discovery, vulnerability assessment based on SBOMs, and integration with ISE for automated segmentation. These complement ISE by providing deeper clinical context about medical devices.
Manufacturing-Specific Considerations
Manufacturing environments use industrial protocols that predate cybersecurity. Modbus TCP has no authentication or encryption — commands are sent in plaintext. EtherNet/IP and CIP support security extensions but rarely see them deployed. PROFINET’s real-time requirements make encryption difficult. OPC UA is the modern successor with built-in security, but legacy OPC Classic connections persist across most facilities.
Many manufacturing customers claim their OT network is air-gapped. In practice, few truly are. Common violations include USB drives for firmware updates, vendor remote access VPNs for equipment maintenance, historians bridging OT and IT, and engineers connecting laptops to both networks. SE discovery question: “When your equipment vendor needs to troubleshoot remotely, how do they connect?” The answer almost always reveals a bridge.
In manufacturing, cybersecurity intersects with physical safety. A compromised PLC can alter temperature setpoints, disable safety interlocks, or override emergency shutdowns. Security controls must never interfere with safety systems — safety instrumented systems should be on separate, hardened network segments, and security solutions should monitor, not inline block, traffic to safety-critical systems.
Phased Deployment and Customer Conversation
Map technologies to the customer’s maturity level in a phased approach:
Phase 1 — Visibility (Months 1-3): Deploy ISE profiling in monitor mode plus passive NDR (Cisco Cyber Vision or Claroty) for OT visibility. Deliverable: complete device inventory with risk assessment.
Phase 2 — Segmentation (Months 3-6): Implement VLAN segmentation for IoT categories, MAB + profiling for NAC, and firewall policies between IoT segments and enterprise IT.
Phase 3 — Microsegmentation and Monitoring (Months 6-12): Deploy TrustSec SGTs for granular control, integrate ISE with SIEM for monitoring, and implement automated CoA response for anomalous devices.
Structure the customer conversation around three questions: “What is on your network that you do not manage?” opens visibility. “If one of those devices is compromised, what can it reach?” opens segmentation. “How would you know if a device was compromised?” opens monitoring. These map directly to the three-phase deployment and to a multi-year deal structure that starts with quick wins and builds toward a comprehensive IoT security architecture.
Related Posts in This Series
- Network Segmentation: VLANs, Microsegmentation, and TrustSec — Segmentation is the primary control for isolating IoT devices
- Secure Campus Network Reference Architecture — IoT devices connect through the campus network; understand the full design
- Cisco ISE vs Aruba ClearPass vs Forescout — NAC platforms that profile and enforce policy on IoT endpoints
- How to Run a Technical Discovery Call for Security Deals — Discovery techniques for uncovering unmanaged IoT and OT devices
- The SE’s Guide to Reading a Vulnerability Report — IoT vulnerabilities are a key input for risk-based segmentation decisions
Practice with free flashcards, quizzes, and hands-on lab scenarios at cciesec.it-learn.io — built specifically for the CCIE Security v6.1 written (350-701 SCOR) and lab exam.






