This article is for general information and is not legal advice. Regulatory requirements depend on your product and market, so confirm your obligations with qualified counsel.
Shipping a connected device without a security plan used to be a risk. In 2026, it is also a compliance problem. This IoT security checklist for manufacturers walks you through 12 practical steps to build secure-by-design IoT devices, from the first architecture sketch to the day you retire the product. Whether you build smart sensors, industrial gateways, or consumer gadgets, the same fundamentals apply. They also line up closely with what the EU Cyber Resilience Act (CRA) now expects. If you want the regulatory side in detail, read our guide to Cyber Resilience Act compliance for IoT manufacturers.
Quick summary: Secure by design means security is built into the product from the start, not patched on afterward. The 12 steps below cover threat modeling, hardware root of trust, secure boot, unique credentials, signed firmware updates, SBOMs, encrypted communication, vulnerability handling, and secure end-of-life.
What Does Secure by Design Mean for IoT Devices?
Secure by design means a device is engineered to resist attack from the beginning. Security requirements are treated like performance or battery-life requirements: defined early, tested often, and owned by someone on the team. It rests on two ideas:
- Secure by design: The architecture itself limits what an attacker can do, even if one component fails.
- Secure by default: The device ships in its safest configuration. The customer should not have to change settings to be protected.
This matters because IoT devices are attractive targets. They are often always on, rarely monitored, and deployed for years. Default passwords, unpatched firmware, and unencrypted traffic remain the easiest ways attackers get in — and all three are preventable at the design stage.
Why Manufacturers Can't Treat This as Optional Anymore
Security-by-design is moving from best practice to legal requirement across major markets:
- European Union: The Cyber Resilience Act applies to most products with digital elements sold in the EU. Vulnerability and incident reporting obligations became binding on 11 September 2026, with the main security-by-design obligations applying from 11 December 2027.
- United Kingdom: The PSTI Act has banned universal default passwords on consumer connectable products since April 2024.
- United States: The FCC's voluntary Cyber Trust Mark label for consumer IoT is built on NIST IR 8425, and it is expected to influence federal procurement of consumer IoT.
Manufacturers who build these controls in now will spend far less than those who retrofit them under deadline pressure.
Phase 1: Design and Architecture
1. Run a threat model before you write firmware
List what your device does, what data it handles, who might attack it, and how. Methods such as STRIDE help structure this. The output should be a ranked list of risks and a matching list of security requirements. Identify every interface: Wi-Fi, Bluetooth, USB, debug ports, cloud APIs, mobile apps. Decide which attacks you must defend against and which you accept. Revisit the model whenever you add a feature or component.
2. Minimize the attack surface
Every open port, running service, and unused library is a door. Remove what you don't need:
- Disable or physically protect debug interfaces (UART, JTAG) in production units.
- Turn off unused network services and protocols.
- Strip unnecessary packages from the operating system image.
Phase 2: Hardware and Device Identity
3. Anchor trust in hardware
A hardware root of trust — such as a secure element or TPM — protects cryptographic keys and makes it far harder to clone or tamper with your device. Software-only key storage is easy for a motivated attacker to extract. Store keys and certificates in tamper-resistant hardware where your risk level justifies it, and give each device a unique cryptographic identity at manufacturing time.
4. Implement secure boot
Secure boot ensures the device only runs firmware signed by you. Each stage of the boot process verifies the next, forming a chain of trust. Sign bootloader and firmware images with protected signing keys, reject unsigned or modified images, and protect the signing keys in a hardware security module (HSM) — never on a developer laptop.
5. Eliminate default and shared credentials
One factory password shared across thousands of units is how large botnets have been built. Each device needs its own credentials, or a forced setup step that requires the user to create one. Use unique per-device passwords or keys, never hard-code credentials in firmware, and enforce a setup flow that sets a strong credential before the device goes online.
Phase 3: Software and Firmware
6. Secure your firmware development pipeline
Secure coding and automated testing catch problems before customers do. Follow a secure coding standard and use static analysis in your CI pipeline, run fuzz testing against network-facing parsers and protocol handlers, require code review for security-sensitive changes, and commission an independent penetration test before launch.
7. Create and maintain an SBOM
A Software Bill of Materials lists every component inside your firmware, including open-source libraries. When a new vulnerability is announced, an SBOM tells you in minutes whether you are affected. The CRA also expects manufacturers to document the components in their products. Generate an SBOM in a standard format such as SPDX or CycloneDX, update it with every release, and monitor your components against vulnerability databases continuously.
8. Build signed, secure over-the-air (OTA) updates
A device that can't be patched becomes a liability the moment a flaw is found. But an insecure update channel is just as dangerous, because it lets attackers push malicious firmware. Sign every update and verify the signature on the device before installing. Deliver updates over an encrypted, authenticated channel. Include rollback protection and a recovery mode so a failed update never bricks the device. Keep security updates separable from feature updates where possible.
Phase 4: Data and Communication
9. Encrypt data in transit and at rest
Use current TLS versions for all network communication and validate certificates properly. Encrypt sensitive data stored on the device. Avoid proprietary or home-made cryptography — use well-reviewed libraries and standard algorithms.
10. Authenticate every connection
Devices, cloud services, and apps should prove who they are to each other. Don't trust a connection just because it comes from inside the local network. Use mutual authentication (certificates or tokens) between device and cloud. Apply least privilege: a device should only access the data and functions it needs. Secure your APIs and mobile apps, since these are common weak points in the wider product ecosystem.
Phase 5: Lifecycle and Response
11. Set up vulnerability handling and disclosure
Researchers will find flaws in your product. A clear process turns that into an advantage. Publish a vulnerability disclosure policy and a security contact (a security.txt file helps). Define internal triage, fix, and notification steps. Prepare to report actively exploited vulnerabilities and severe incidents within the CRA's 24-hour early-warning window if you sell in the EU.
12. Declare a support period and plan end-of-life
Customers deserve to know how long they will receive security updates. The CRA expects manufacturers to provide security updates for the product's expected lifetime, generally no less than five years unless the product will be used for a shorter period. State the support period clearly on the product page and packaging. Provide a secure factory reset and data wipe for decommissioning. Tell customers what happens when support ends.
Quick Reference: IoT Security Checklist
| # | Control | Phase |
|---|---|---|
| 1 | Threat model completed and maintained | Design |
| 2 | Attack surface minimized, debug ports locked | Design |
| 3 | Hardware root of trust for keys | Hardware |
| 4 | Secure boot with signed images | Hardware |
| 5 | No default or shared credentials | Hardware |
| 6 | Secure CI pipeline, fuzzing, pen test | Software |
| 7 | SBOM generated and monitored | Software |
| 8 | Signed OTA updates with rollback protection | Software |
| 9 | Encryption in transit and at rest | Data |
| 10 | Mutual authentication, least privilege | Data |
| 11 | Vulnerability disclosure and response process | Lifecycle |
| 12 | Support period declared, secure end-of-life | Lifecycle |
Common Mistakes IoT Manufacturers Make
- Adding security at the end. Fixes after hardware is finalized are costly and sometimes impossible.
- Leaving debug access open in production. A single exposed serial port can give an attacker full control.
- Reusing one signing key everywhere. If it leaks, every device is at risk.
- Ignoring third-party components. Most vulnerabilities in your firmware will come from code you didn't write.
- No plan for updates. If you can't patch it, you can't secure it.
- Treating compliance as paperwork. Regulators expect evidence that controls actually work, not just documents saying they exist.
Standards That Help You Prove It
You don't have to invent your own framework. These widely used standards map well to the checklist above:
- ETSI EN 303 645: Baseline security requirements for consumer IoT.
- NIST IR 8425: Cybersecurity baseline for consumer IoT products, the basis of the US Cyber Trust Mark.
- IEC 62443: Security for industrial automation and control systems.
- ISO/IEC 27001: Information security management for your organization.
Frequently Asked Questions
What is an IoT security checklist?
An IoT security checklist is a structured list of security controls that a manufacturer applies across a connected product's lifecycle, from design and hardware through firmware, communication, updates, and end-of-life. It helps teams build consistently and show evidence of due diligence.
What does secure by design mean in IoT?
It means building security into a device's architecture from the beginning rather than adding it later. Examples include secure boot, unique device credentials, encrypted communication, and signed updates. It is usually paired with secure by default, meaning the device ships in its safest configuration.
What are the most important IoT device security best practices?
The highest-impact practices are removing default passwords, enabling secure boot, encrypting communication, shipping signed OTA updates, maintaining an SBOM, and running a vulnerability disclosure process. Together they close the most common routes attackers use.
Do I need an SBOM for my IoT product?
In practice, yes. An SBOM lets you quickly identify whether a newly disclosed vulnerability affects your firmware. The EU Cyber Resilience Act also expects manufacturers to identify and document the components in their products, and many enterprise buyers now request SBOMs during procurement.
Does the EU Cyber Resilience Act apply to my IoT devices?
The CRA applies to most products with digital elements that are placed on the EU market, including connected devices, embedded software, and network equipment, regardless of where the manufacturer is based. Some categories are covered by other regulations. Check the scope carefully for your product.
How long must manufacturers provide security updates?
Under the CRA, manufacturers must handle vulnerabilities and provide security updates for the product's expected lifetime, with a support period that is generally at least five years. Always state the support period clearly to customers.
How is IoT security different from regular IT security?
IoT devices have limited processing power and memory, are deployed for many years, are often physically accessible to attackers, and are hard to patch at scale. That makes design-time decisions such as hardware trust, update mechanisms, and minimal attack surface much more important than in typical IT systems.
How much does it cost to secure an IoT product?
It varies widely by product complexity and risk level. Building security in early is far cheaper than redesigning later, and far cheaper than the cost of a recall, a breach, or regulatory penalties. Start with the low-cost, high-impact steps: unique credentials, signed updates, encryption, and an SBOM.
Conclusion: Start With the Basics, Then Build Up
Securing an IoT product doesn't require perfection on day one. It requires a deliberate process: model the threats, protect your keys, sign your firmware, encrypt your traffic, and plan for the entire life of the device. The manufacturers who treat security as a core product feature will earn customer trust and meet new regulatory expectations with far less pain. Use the 12-step checklist above as a starting point, assign an owner to each item, and review it at every release.
If you're deploying or securing smart devices in your business, our guide on securing business smart devices walks you through the same principles from the buyer's side.
Want help applying this to your product? CyberKartel can help you assess your devices against this checklist and the Cyber Resilience Act.