IoT security across the whole system
Protecting an IoT product requires device, network, application and operational controls. Start with the intended use and threat model, then choose proportionate controls. Hardware-backed trust can strengthen boot verification and key isolation, but it cannot repair missing API authorisation or prevent every breach.
| Area | Recommended engineering work | Limitation to check |
|---|---|---|
| Identity | Unique credentials, secure provisioning and revocation | A valid device identity does not authorise every action |
| Firmware | Authenticate boot and update images where appropriate | Signed software can still contain vulnerabilities |
| Communications | Appropriate encryption and peer validation | Encryption does not fix an insecure endpoint |
| Interfaces | Least privilege, input validation and debug controls | Review maintenance and recovery access as well |
| Operations | Segmentation, monitoring and controlled patch deployment | Availability and safety constrain change windows |
| Lifecycle | Support dates, vulnerability intake and dependency tracking | A security chip does not replace ongoing support |
Retrofitting deployed devices
Network isolation, access restrictions and firmware patches can improve existing devices. Adding hardware isolation may require a board redesign; enabling boot verification depends on existing silicon, provisioning state and recovery options. Assess the installed fleet before promising either that every device can be upgraded or that security can never be improved after manufacture.
Cost and standards
Estimate component, engineering, provisioning, testing and support costs for the actual product and production volume. There is no universal per-device security price or breach-cost figure that proves project ROI. IEC 62443 and ETSI EN 303 645 can inform relevant designs, but a standard or component certificate does not automatically demonstrate complete CRA conformity. Verify the applicable edition, scope and any legal citation.
Start with the threat model
List the assets that matter: device credentials, signing infrastructure, personal data, control commands and service availability. Identify who can reach each interface and whether an attacker can physically possess the device. Decide which failures could affect safety. Select controls against these risks and record how they will be tested; a component’s security certificate does not certify the complete product.
A practical design and verification sequence
- Define trust boundaries between application, privileged firmware, external peripherals and backend.
- Separate private signing keys from device verification material; plan provisioning, rotation and revocation.
- Select boot, debug and storage protections supported by the exact device revision.
- Authenticate updates and test the recovery path after interrupted writes.
- Restrict exposed services, authenticate users and devices, and enforce authorisation at the API.
- Test negative cases: wrong image, revoked credential, old version, malformed input and lost connectivity.
- Maintain dependency records, vulnerability triage, release evidence and a support plan.
Test results must describe the target, configuration and attack assumptions. A successful secure-boot test does not establish resistance to every physical attack or runtime exploit.
Secure boot: protection and limits
Secure boot authenticates boot software before allowing it to execute. In a common embedded design, protected initial verification code validates a signed bootloader, which validates the application image. The exact stages and algorithms depend on the processor and boot implementation. Secure boot protects against unauthorised image replacement; it does not prove that approved software is vulnerability-free or prevent all runtime exploitation. Measured boot records measurements for later evaluation; measurement by itself does not necessarily block execution. Anti-rollback and a protected recovery path are additional design choices to evaluate and test.
Updates and recovery
An over-the-air (OTA) update delivers software or firmware over a wireless connection. Remote updating can also use wired networks; automatic installation is a separate property. A secure design authenticates the update and its intended target, protects signing keys, checks version policy and handles power loss safely. A/B partitions are one recovery strategy, not a universal requirement. RFC 9019 describes an IoT firmware-update architecture, not a finished mandatory manifest format. The device needs verification material, not the manufacturer’s fleet-wide private signing key. Test corrupted images, wrong targets, interrupted writes, revoked keys and attempts to install disallowed older versions.
CRA and technology choices
CRA requirements are outcome-oriented and technology-neutral, based on the product’s cybersecurity risk assessment and applicability. Secure boot, a hardware root of trust, TPM, TrustZone and wireless OTA can be appropriate engineering controls; they are not universal legal mandates for every product. Document why the chosen controls satisfy the applicable requirements rather than equating one architecture with compliance.
Applicable CRA dates and scope
The CRA entered into force on 10 December 2024. Article 14 reporting has applied since 11 September 2026; the main product requirements apply from 11 December 2027. Article 69 contains transitional rules for previously placed products. Products subject to MDR or IVDR are excluded under Article 2(2); other exclusions and non-commercial free/open-source scope must also be checked.
Support, updates and evidence
CRA Annex I requires applicable secure vulnerability-handling and update mechanisms. Automatic security updates have conditions and exceptions; automatic does not mean wireless. The support period is determined under Article 13(8), normally at least five years; where expected use is shorter, it corresponds to that use, while longer-use factors can require longer support. An SBOM must be machine-readable and cover at least top-level dependencies.
Reporting is a separate obligation
CRA Article 14 concerns actively exploited vulnerabilities and severe incidents affecting product security, not every CVE. Both require an early warning within 24 hours and a notification within 72 hours of awareness. The final vulnerability report is due within 14 days after a corrective or mitigating measure becomes available; the final severe-incident report is due one month after the incident notification. Reporting is separate from conformity assessment and update requirements.
Frequently asked questions
Does CRA universally require secure boot?
CRA requirements are outcome-oriented and technology-neutral, based on the product’s cybersecurity risk assessment and applicability. Secure boot, a hardware root of trust, TPM, TrustZone and wireless OTA can be appropriate engineering controls; they are not universal legal mandates for every product. Document why the chosen controls satisfy the applicable requirements rather than equating one architecture with compliance.
Does a secure element guarantee conformity?
No. It can protect selected keys and operations; conformity concerns the complete product and applicable requirements, including processes and evidence.
Can deployed devices be made more secure?
Often, network controls and firmware patches can help. Hardware changes depend on existing silicon, provisioning and recovery capabilities. Assess each product and fleet.
What does security cost?
Estimate components, engineering, provisioning, testing and lifecycle support for the actual scope. A universal per-unit figure is not reliable.
Sources and further reading
Related guides inEmbedded Security & IoT
Explore all →15 IoT Attack Types: Examples and Defences
Fifteen IoT threat categories, clearly labelled illustrative scenarios, a documented Mirai example and practical risk-based defences.
Hardware Security Design: Trust, Keys and Verification
Design hardware-backed security around a threat model. Understand root-of-trust limits, secure boot, key management and technology-neutral CRA requirements.