The weaknesses that recur in IoT devices are shared or default passwords, no way to receive security updates, unused network services left open, insecure storage of secrets, weak communications security and firmware that is not verified. ETSI EN 303 645 turns the opposite of each into a baseline requirement for consumer devices.
Where does the baseline come from?
ETSI EN 303 645 is a European standard of baseline security provisions for consumer IoT devices. It is high level, it covers the device and not its associated services, and it excludes devices primarily intended for manufacturing, healthcare or other industrial use. Its provisions are a useful checklist even outside that scope, because they describe what a securable device looks like.
NIST has published related manufacturer guidance. NIST IR 8259, Foundational Cybersecurity Activities for IoT Device Manufacturers, notes that IoT devices often lack cybersecurity capabilities customers can use, and that manufacturers can help by making devices more securable and providing the information customers need. The NIST page we fetched states that IR 8259 was withdrawn on 20 April 2026 and superseded by IR 8259 Rev. 1, so check the current revision before citing it.
Which weaknesses come up most?
Default and shared passwords. ETSI Provision 5.1-1 says that where passwords are used, and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user. The reason this exists is plain: one published default opens every unit of that model.
No update path. Provision 5.3-1 says all software components should be securely updateable. Where updates arrive over a network, the device must verify their authenticity and integrity. The standard also expects manufacturers to publish a defined support period.
Devices that cannot be patched. ETSI addresses this directly. For constrained devices that cannot have software updates, the manufacturer should publish the rationale, the hardware replacement support period and method, and a defined support period. The product should be isolable and the hardware replaceable. For an operator, that last sentence is the practical advice: if you cannot patch it, you must be able to fence it off.
No way to report a flaw. Provision 5.2-1 requires a publicly available vulnerability disclosure policy with at least contact information and timelines. Without it, a researcher who finds a problem has nowhere to send it.
Exposed interfaces. Provision 5.6-1 says all unused network and logical interfaces shall be disabled. Open debug ports and unneeded services are classic entry points.
Weak storage and communications. Sensitive security parameters in persistent storage shall be stored securely (5.4-1), and the device shall use best practice cryptography to communicate securely (5.5-1).
Unverified software. The device should verify its software using secure boot mechanisms (5.7-1), so tampered firmware does not run.
Unvalidated input. Software shall validate data input through user interfaces or transferred over networks (5.13-1). Missing validation is how many web interfaces on devices become injection points.
What can a buyer or operator do?
You rarely control the device design, but you control the purchase and the network. Ask suppliers for their disclosure policy and support period before buying. Change default credentials at install. Put devices on a separate network segment with only the outbound access they need. Keep an inventory with model, firmware version and owner, so a new advisory can be matched in minutes.
A constructed example
A facilities team installs forty network cameras. All ship with the same default admin password, and the vendor's support page does not mention a support period. The operator changes each password to a unique value stored in a password manager, places the cameras on an isolated VLAN that can reach only the recording server, and blocks all other outbound traffic. Six months later a firmware advisory appears. Because the inventory lists the firmware version of each camera, the team finds the affected ones in an afternoon. When the vendor announces that the model will not get the fix, the isolation limits the exposure until replacement.
How to check or apply this
- Inventory every connected device with model, firmware version, owner and location.
- Replace default credentials at installation, with unique values per device.
- Segment IoT from corporate systems, and deny internet access that is not required.
- Before buying, ask for a vulnerability disclosure policy and a stated support period.
- Subscribe to advisories for the models you run, and match them to your inventory.
- Plan replacement dates for devices that cannot be updated.
- Disable unused services and interfaces during setup.
Quick check
Do these standards apply to industrial devices?
ETSI EN 303 645 states that devices primarily intended for manufacturing, healthcare or other industrial applications are outside its scope. Industrial devices have their own standards, though the same basics apply.
Can we just rely on the manufacturer to patch?
Only if they commit to it. Check the support period before buying and plan for devices that go out of support.
Sources
- ETSI EN 303 645 V2.1.1, Cyber Security for Consumer Internet of Things: Baseline Requirements
- NIST IR 8259, Foundational Cybersecurity Activities for IoT Device Manufacturers
Last reviewed: 18 October 2026.
