The recurring IoT security issues are default or shared passwords, no way to update software, exposed interfaces and services, weak protection of stored secrets and traffic, and no visibility into device state. NIST IR 8259A and ETSI EN 303 645 turn each into a requirement you can test before you buy.
Why are IoT devices a different problem?
They are small, long lived, and often sit where nobody logs in. A laptop is patched by a management agent. A camera in a ceiling may run for ten years on the firmware it shipped with, behind a vendor that may have stopped updating it. The owner may not know it is on the network. Add that many cannot run an agent or a supplicant for network access control, and ordinary endpoint practices do not apply.
What does NIST IR 8259A require of a device?
NIST IR 8259A defines a core baseline of device cybersecurity capabilities, meaning functions a device provides through its own hardware and software. The baseline has six capabilities:
- Device Identification: the device has a unique logical identifier, which supports asset management.
- Device Configuration: authorized users can change the device's software and firmware configuration.
- Data Protection: the device can protect data it stores and transmits, supporting access management and data security.
- Logical Access to Interfaces: the device limits logical and physical access to its local and network interfaces, which reduces attack surface.
- Software Update: the device's software can be updated by an authorized process, supporting vulnerability management.
- Cybersecurity State Awareness: the device can report on its cybersecurity state, which helps with investigating compromises and identifying misuse.
Read it as a procurement checklist. A device that cannot be uniquely identified, updated or restricted is a problem you will carry for its whole life.
What does ETSI EN 303 645 add?
ETSI's standard for consumer IoT sets thirteen provisions. They are: no universal default passwords, a means to manage reports of vulnerabilities, keep software updated, securely store sensitive security parameters, communicate securely, minimize exposed attack surfaces, ensure software integrity, ensure that personal data is secure, make systems resilient to outages, examine system telemetry data, make it easy for users to delete user data, make installation and maintenance easy, and validate input data.
The first one is the most important in practice. Provision 5.1 says that where passwords are used in any state other than the factory default, they must be unique per device or defined by the user, and that pre installed unique passwords must be generated with a mechanism that reduces the risk of automated attacks against a class or type of device. Shared defaults are what let one discovered password open thousands of devices.
The OWASP Internet of Things project also maintains a list and testing guides for IoT security, which are a useful companion for hands on assessment.
A constructed example
A facilities team installs 200 networked sensors. The vendor datasheet says they use "secure communication", but a pre purchase review against the baseline finds no firmware update mechanism documented, a shared admin password across the batch, and a management web interface open on every network port. The team asks for a dated update commitment and per device credentials, and puts the sensors on an isolated segment that can only reach their collector. Two of the three asks are met, and the unmet one, the open management interface, is handled with a firewall rule and a note in the risk register.
How to check or apply this
- Inventory every IoT device you own, by type, owner and network location. Unknown devices cannot be managed.
- Before buying, score each product against the six IR 8259A capabilities and ask for written answers.
- Change default credentials at install, and refuse products that use one shared default.
- Ask for the support period and the update process, and put the end of support date in your asset record.
- Segment devices. Allow each only the destinations it needs, and block inbound access from user networks.
- Turn off unused services and interfaces.
- Collect logs or flow data from the segment, and alert on new destinations.
- Plan retirement. Replace devices before they leave support.
Quick check
What is the single biggest IoT security issue?
There is no single answer, but shared default passwords and missing update mechanisms cause a large share of avoidable exposure, which is why both lead the standards.
Can I secure a device that cannot be updated?
Only by surrounding it: isolate it, restrict its traffic, monitor it and plan its replacement. Treat it as a known risk with an owner and an end date.
Sources
- NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline
- NIST IR 8259A full text (PDF)
- ETSI EN 303 645 V2.1.1, Cyber Security for Consumer Internet of Things: Baseline Requirements
- OWASP Internet of Things project
Last reviewed: 18 October 2026.
