Securing the Internet of Things (IoT): Strategies That Survive the Incident

Securing the IoT (the Internet of Things) means protecting the cameras, sensors, badge readers, building systems, medical devices, and industrial controllers that connect your physical operations to your network. Most guides treat that as a device problem. It is also a resilience problem.

The Internet of Things is the network of physical devices embedded with sensors, software, and connectivity so they can collect and exchange data. In a business, that includes industrial IoT and the operational technology (OT) that runs production lines, building systems, cold storage, and utilities.

Every one of those devices is a way in. More important, many of them are things your operations can’t run without. When one is compromised, the question your executives ask isn’t “how did they get in?” It’s “what stops working, and for how long?”

This post covers why the IoT is hard to secure, the controls that matter, and the part most IoT security guides leave out: planning for the day a connected device fails or can’t be trusted.

Why the IoT Is Hard to Secure

The challenges haven’t changed much in a decade. They’ve just multiplied with every device you add.

• No one has a complete inventory. Facilities buys the HVAC controls. Security buys the cameras. Operations buys the sensors. A vendor installs and remotely manages half of them. IT finds out later, or never.
• Weak security by design. Many devices ship with default passwords, weak encryption, and no practical way to update their software. Low processing power limits what security you can add after the fact.
• Patching means downtime. In a plant or a hospital, updating a controller can mean stopping the process it controls. So patches wait, sometimes for years.
• No single standard. Manufacturers use different protocols and different security features. NIST’s IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A) gives buyers and manufacturers a common starting point: device identification, secure configuration, data protection, logical access, software updates, and cybersecurity state awareness. It is voluntary, so you have to write it into your purchasing requirements.
• The data matters. Connected devices collect and transmit operational, personal, and sometimes patient data. A compromised device is a privacy incident as well as an operational one.

Old View	New View
IoT security is a device hardening problem	IoT security is a dependency and recovery problem too
IT owns the connected devices	Facilities, operations, security, and vendors own them; someone has to own the inventory
Prevent the compromise	Prevent it, and plan to run without the device when prevention fails
Isolate the compromised device	Decide in advance who can shut down an operational system, and what the business does next
The vendor handles security	The vendor’s remote access is part of your attack surface; test it and contract for it

The Controls That Matter for Securing the IoT

None of these are new. Most organizations still haven’t finished them.

1. Build and keep an inventory. Every connected device, its owner, its location, what it connects to, and who can reach it remotely. You can’t secure, patch, or recover what you don’t know you have.
2. Kill default credentials. Unique credentials for every device, multi-factor authentication for management interfaces, and certificates for device identity where the device supports them.
3. Segment the network. Keep IoT and OT devices off the networks that run your business systems, and keep OT off the internet. Segmentation limits how far an attacker can move, and it gives you something to disconnect without taking down everything.
4. Verify continuously. A zero trust approach treats every device as untrusted until it proves otherwise, every time. That matters most for the devices you can’t patch.
5. Patch on a schedule you can live with. Plan updates into maintenance windows. For devices that can’t be updated, compensate with segmentation and monitoring, and put a replacement date on them.
6. Encrypt data in transit and at rest where the device allows it, and know which devices don’t.
7. Buy secure. Write the NISTIR 8259A capabilities into procurement. Ask vendors how they update devices, how long they’ll support them, and how they secure their remote access.
8. Train the people who touch the devices. That includes facilities staff, plant technicians, and contractors, not just the IT team.

Plan for the Device You Can’t Trust

Here is where IoT security becomes a business continuity question. Prevention will fail somewhere. When it does, recovery depends on decisions most organizations haven’t made.

The 2021 ransomware attack on Colonial Pipeline is the clearest example. According to the joint CISA and FBI advisory, there was no indication the attackers reached the company’s OT networks. The company proactively disconnected certain OT systems anyway, to ensure their safety. The pipeline stopped because the company couldn’t yet be sure what the attackers could reach.

That was a defensible call. It also shows the real problem. When you can’t see how far an attack goes, your connected operations stop because of what you don’t know. Three things change that outcome.

Map the dependencies. For each critical process, list the connected devices and OT systems it relies on, and what those rely on: networks, cloud platforms, vendors, and power. Our guide to dependency mapping in IT disaster recovery walks through how to build the map. Most organizations find at least one critical process sitting on a device nobody listed.

Know your third parties. Building management, medical device, and industrial vendors often hold standing remote access to your devices. Their compromise is your incident. Tier those vendors by what stops if they go down, not by what you spend with them, and exercise the relationship before you need it.

Plan the manual workaround. If the badge readers, the cold storage monitors, or the line controllers go offline for a week, what does the business do? How long can it sustain that? A workaround that lasts a shift doesn’t cover a recovery that takes days.

Build Connected Devices into Incident Response

Most cyber incident response plans were written for laptops and servers. Connected devices raise questions those plans don’t answer:

• Who can disconnect an OT system or a building system, and on what trigger? Push that authority as close to the operation as you can tolerate, and write it down.
• Who decides whether it is safe to restart, and what evidence they need?
• Who brings in the device vendor, and how fast does the contract require them to respond?
• Where does a physical safety risk (a door system, a medical device, a chemical process) escalate, and how quickly does it reach your crisis team?

Your incident response plan handles detection, containment, and recovery. It needs clear escalation points into the crisis team, which manages customers, regulators, employees, and the business decisions. Our cyber incident response planning work builds those connections across crisis management, business continuity, IT disaster recovery, and third-party risk.

AI in Cybersecurity: What It Changes for Connected Devices

AI is on both sides of IoT security.

On defense, machine learning is good at the thing connected devices make hard: spotting abnormal behavior across thousands of devices that can’t run their own security software. Behavior-based monitoring can flag a camera that suddenly talks to a new server, or a controller that changes its pattern at 2 AM.

On offense, AI is collapsing the time between a vulnerability’s discovery and its exploitation. Anthropic’s September 2026 threat intelligence report described one group whose AI-driven workflow against network appliances produced more than a dozen possible zero-day findings in a single month. Connected devices, which are slow to patch at the best of times, are exactly where that speed hurts.

The response isn’t another tool. It’s decisions made in advance. I wrote about what the AI labs’ warnings leave out in The AI Labs Just Warned You About AI-Enabled Cyber Attacks: decide now who can take a system offline at 2 AM without convening a meeting, exercise at AI speed, and validate that you can actually recover. For connected devices, add one more: know which ones you can’t patch at all, and put compensating controls and a date next to each. For the broader picture of how AI fits into crisis response, see Enhancing Crisis Management through Artificial Intelligence.

Where to Start

1. Inventory one critical site. Every connected device, its owner, and what depends on it. Expect surprises.
2. Write the decision rights. Who can disconnect an operational system, who decides it’s safe to restart, and how it reaches your executives.
3. Run one tabletop where a connected system goes dark for five days. Put operations, facilities, the vendor, and IT in the room, and watch for the decisions nobody owns.

Securing the IoT keeps attackers out of your devices. Planning for the device you can’t trust keeps your operations running when they get in anyway.

Keep Going

A few ways to go deeper if this was useful.

• Read more. Resilience, crisis management, and continuity writing at Bryghtpath Insights, or the structured Ultimate Guide to Business Continuity.
• Test the outage, not just the breach. Exercise in a Day® builds and runs a custom cyber tabletop in one day, with your operations leaders at the table.
• Get a maturity score. Our Resiliency Diagnosis® is a standards-based review that produces a maturity score and a prioritized roadmap.
• Talk to us. Set up a call to think through your connected operations with us.