These fifteen threat categories overlap. The scenarios below are illustrative engineering examples, not claims about named incidents. Controls reduce particular risks; no chip or boot mechanism prevents all attacks. A documented incident is identified separately and linked to its source.
1. Malware
An exploited service runs unwanted code on a gateway.
Patch exposed software, limit privileges and monitor execution.
2. Ransomware
An attacker encrypts gateway storage or disables a service.
Restrict access, prepare offline backups and test recovery.
3. Man-in-the-middle
A false endpoint modifies commands or update traffic.
Validate peers and authenticate commands and updates.
4. DDoS
A compromised device sends traffic that exhausts a target.
Limit exposed services, segment networks and monitor traffic.
5. Physical tampering
Someone probes an accessible debug port or external memory.
Control debug access and evaluate physical protection.
6. Side channels
Timing or power behaviour reveals information about a secret.
Use suitable cryptography and assess implementation leakage.
7. Device spoofing
A rogue endpoint presents another device’s identity.
Use unique credentials, secure provisioning and revocation.
8. Injection
Untrusted input becomes a command or unsafe parser action.
Validate input, avoid unsafe interpreters and test parsers.
9. Replay
An attacker resends a previously valid control message.
Bind commands to freshness and reject duplicate transactions.
10. Firmware replacement
An unauthorised image replaces approved firmware.
Authenticate images and protect boot and recovery policy.
11. Eavesdropping
An unauthorised party receives private sensor data.
Protect access, minimise collection and secure communications.
12. Information disclosure
Logs or a diagnostic API expose credentials or sensitive data.
Restrict diagnostics, redact secrets and protect storage.
13. API authorisation failure
A valid user controls another customer’s device.
Enforce object-level authorisation on each request.
14. Credential attacks
Default or reused passwords allow unauthorised access.
Remove shared defaults, limit attempts and protect remote access.
15. Cryptojacking
Unwanted mining consumes an edge computer’s resources.
Patch services, limit executable workloads and monitor usage.
Documented example: Mirai
The FBI describes Mirai infecting internet-exposed IoT devices in 2016 using common default credentials and using them for DDoS. Read the FBI account. This case illustrates credential and exposure risks; it does not prove that a hardware root of trust would have prevented every stage.
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.
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.
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.
Sources and further reading
Related guides inEmbedded Security & IoT
Explore all →IoT Security Best Practices for Product Engineers
Practical IoT security across firmware, identity, APIs, updates and operations, with realistic hardware limits and accurate CRA obligations.
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.