How do you secure IoT devices in the enterprise?

To secure enterprise IoT devices, find them all, put them on their own network segments, replace default credentials, track firmware updates and buy only from vendors that document security features. Most of these devices cannot run agents, so the network and the purchasing process do the protecting.

Why is IoT hard to secure?

NIST's IR 8259 starts from a blunt observation: IoT products often lack cybersecurity capabilities their customers can use to reduce risk. Cameras, badge readers, printers, building controls and sensors ship with fixed credentials, no update path or no logging, and they stay installed for years.

Note the version. NIST withdrew the original IR 8259 on 20 April 2026 and superseded it with IR 8259 Rev. 1, which now uses the word products rather than devices. Cite the revision, and check it for the current activity list.

What does the manufacturer owe you?

IR 8259 is written for manufacturers. It describes activities they should perform before products are sold, so that customers need less effort to run them safely: providing needed security functionality, and giving customers the cybersecurity information they need.

As a buyer you can turn that into questions. Does the device support unique credentials per unit? How are updates delivered and for how long? Is there a way to disable unused services? Can it log events somewhere you control? A vendor that cannot answer has told you something.

How do you find all the devices?

Discovery comes first, because the common problem is not a weak camera but an unknown one. Use network access control records, DHCP leases, switch tables, passive traffic monitoring and facilities and procurement lists. Each source misses something.

Record for every device an owner, a location, a function, the vendor, the firmware version and the network segment. Unowned devices are the first thing to resolve.

Where should IoT sit on the network?

Apart from everything else. NIST SP 800-207 on zero trust architecture describes moving defences from static, network based perimeters to users, assets and resources, and assumes no implicit trust based on network location. For IoT that translates into default deny rules. A badge reader talks to its controller and nothing else. A camera sends video to the recorder and cannot reach the finance servers.

NIST SP 800-41 gives the firewall policy side: allow only the traffic a function needs, and review rules regularly.

A constructed example

A hospital wing has 60 networked infusion pumps and 120 other connected devices. During a discovery pass, the team finds a printer with an open management interface and a default admin password, on the same segment as clinical workstations.

They move all medical devices to a dedicated segment with rules that allow only the pump management server, change the printer credentials, and turn off the unused interface. They also add a line to the purchasing checklist requiring a documented update policy. The fix cost one afternoon. The checklist stops the next one at the door.

What about remote access and logging?

Vendors often keep a remote management path for support. Ask whether it can be switched off, and if not, route it through a gateway you control instead of leaving it open to the internet. Send device logs to a collector on another network, so a compromised device cannot erase its own trail. Even basic logs, such as logins and configuration changes, answer the first question in any investigation.

What about patching?

Patching is slow. Many devices need a maintenance window or a vendor tool. Track versions in your inventory, subscribe to the vendor's advisories, and cross-check the CISA Known Exploited Vulnerabilities catalogue for products you own. If a device has known exploited flaws and no fix, isolate it harder or retire it.

How to check or apply this

1. Build a device inventory from at least three sources and assign owners.
2. Put each device class on its own segment with default deny rules.
3. Replace default credentials and disable services you do not use.
4. Record firmware versions and watch vendor advisories and the KEV catalogue.
5. Add NIST IR 8259 Rev. 1 questions to procurement and refuse products that cannot answer.
6. Log device traffic to a place the device cannot alter.
7. Plan end of life: remove devices when support ends.

Quick check

Sources

• NIST IR 8259 (withdrawn 20 April 2026)
• NIST IR 8259 Rev. 1
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• CISA, Known Exploited Vulnerabilities Catalog

Last reviewed: 18 October 2026.