Embedded Security & IoT Solutions
What is Embedded Security?
Embedded Security involves integrating cryptographic protection directly into hardware using components like Secure Elements, HSMs, and TPMs. It establishes a hardware root of trust that protects devices from tampering, cloning, and cyberattacks, ensuring compliance with the EU Cyber Resilience Act and NIS2 Directive for critical infrastructure and IoT.
Embedded security is the practice of building cryptographic protection directly into hardware — using tamper-resistant Secure Elements, Hardware Security Modules (HSMs), and encrypted boot chains to establish a hardware root of trust. Unlike software-only security, hardware-rooted protection cannot be bypassed by malware, memory exploits, or remote code execution attacks.
Inovasense designs IoT devices that are secure by design — compliant with the EU Cyber Resilience Act (EU 2024/2847), NIS2 Directive (EU 2022/2555), IEC 62443 for industrial security, and ETSI EN 303 645 for consumer IoT.
Why Hardware Security Matters in 2026
The EU Cyber Resilience Act enters mandatory enforcement in 2027, requiring all products with digital elements sold in the EU to implement vulnerability handling, software bill of materials (SBOM), and 5-year security update commitments. Products classified as “critical” (network equipment, industrial controllers, smart meters) face third-party conformity assessment.
Hardware-rooted security is no longer a premium feature — it’s a regulatory requirement.
- Tamper-resistant key storage — Cryptographic keys never leave the secure element; extracting them requires destructive physical analysis
- Measured boot — Every firmware stage is cryptographically verified before execution, preventing rootkit persistence
- Physical attack resistance — Active mesh shields, voltage glitch detectors, and light sensors detect and respond to physical intrusion attempts
- Lifecycle security — Secure provisioning, key rotation, certificate management, and end-of-life decommissioning managed through hardware
- Post-quantum readiness — Hybrid key exchange (ML-KEM + X25519) and digital signatures (ML-DSA) protecting against future quantum threats
Our Security Architecture Stack
Hardware Root of Trust
We integrate certified security ICs from leading European manufacturers (STMicroelectronics, Infineon, NXP) to ensure hardware sovereignty:
| Component | Products | Certification | PQC Ready |
|---|---|---|---|
| Secure Elements | STMicroelectronics STSAFE-A110, Infineon OPTIGA Trust M, NXP EdgeLock SE050 | CC EAL6+ | Firmware upgrade path |
| TPM Modules | STMicroelectronics ST33 (TPM 2.0), Infineon SLB 9672 | TCG 2.0, FIPS 140-3 | Yes |
| Java Card | STMicroelectronics ST31 / STPay, NXP JCOP4 | CC EAL6+, EMVCo | Applet-level |
| Secure MCUs | STM32H5 / STM32U5 (TrustZone + ST-ONE), NXP LPC55S | PSA Certified L3 | Library support |
| Secure Enclaves | STM32MP2 (Hardware Isolation), ARM CCA | Isolation certified | Hardware-assisted |
Cryptographic Implementation
- Symmetric: AES-128/256-GCM (hardware accelerated), ChaCha20-Poly1305
- Asymmetric: ECC P-256/P-384, Ed25519/Ed448, RSA-3072/4096
- Post-Quantum (NIST standards): ML-KEM-768/1024 (key encapsulation), ML-DSA-65/87 (digital signatures), SLH-DSA (stateless hash-based signatures)
- Hybrid schemes: X25519 + ML-KEM for TLS 1.3, ECDSA + ML-DSA for firmware signing
- Hashing: SHA-256, SHA-3, SHAKE-256, HMAC for message authentication
- Key management: HKDF derivation, X.509v3 certificate chains, PKCS#11 interfaces, DICE (Device Identifier Composition Engine)
Secure Boot & Firmware Protection
Our secure boot implementation follows the ARM PSA (Platform Security Architecture) model:
- Immutable bootloader — Stored in ROM, cryptographically verifies the next stage using Ed25519 or ML-DSA
- Chain of trust — Each boot stage authenticates the next; root of trust anchored in hardware fuses
- Runtime integrity — Memory protection units (MPU) and TrustZone enforce process isolation
- Secure OTA updates — Signed firmware packages (SUIT manifest) with atomic rollback on verification failure
- SBOM integration — Automated Software Bill of Materials generation for CRA compliance
Wireless Connectivity for IoT
We design connectivity solutions matched to each application’s power, range, and bandwidth requirements:
| Protocol | Range | Data Rate | Power | Best For |
|---|---|---|---|---|
| BLE 5.4 | 100m | 2 Mbps | Ultra-low | Wearables, asset tags, PAwR |
| LoRaWAN 1.0.4 | 15km | 50 kbps | Very low | Environmental monitoring, metering |
| NB-IoT (Rel-17) | Cellular | 250 kbps | Low | Wide-area asset tracking |
| Wi-Fi 7 (802.11be) | 50m | 5.8 Gbps | Medium | Real-time video, gateways |
| Thread 1.3/Matter | 30m | 250 kbps | Low | Smart home/building, interop |
| 5G RedCap (Rel-17) | Cellular | 150 Mbps | Medium | Industrial IoT, autonomous |
| DECT NR+ (2024) | 1km | 3 Mbps | Low | Private industrial mesh, non-cellular |
Ultra-Low Power Design
Our devices achieve multi-year battery life through:
- Sleep mode optimization — Current consumption <500 nA in deep sleep with RTC wake
- Duty cycling — Intelligent scheduling algorithms reduce active time to <0.1%
- Energy harvesting — Solar (indoor/outdoor), thermoelectric, and vibration harvesting circuits
- Power profiling — We measure actual current consumption at every design stage using Otii Arc and PPK2 analyzers
- Battery chemistry optimization — LiFePO4 for extreme temperature, solid-state cells for longevity, supercapacitor hybrid topologies
Compliance & Certification (2026)
| Regulation | Effective | Requirement | Our Approach |
|---|---|---|---|
| EU Cyber Resilience Act (EU 2024/2847) | 2027 mandatory | Vulnerability handling, SBOM, 5-year updates | Secure-by-design architecture, automated SBOM, CRA technical file |
| NIS2 Directive (EU 2022/2555) | Oct 2024 | Supply chain security for essential entities | Secure development lifecycle, incident response plan |
| IEC 62443 | Ongoing | Industrial automation security | Zone/conduit model, SL-T assessment, SDL |
| ETSI EN 303 645 | Ongoing | Consumer IoT security baseline | All 13 provisions: no default passwords, secure storage, minimal attack surface |
| RED Delegated Act (2022/30) | Aug 2025 | Cybersecurity for radio equipment | Secure boot, authenticated updates, network protection |
| GDPR Art. 25 | Ongoing | Data protection by design | Privacy-preserving architecture, local processing, minimal data collection |
| EU AI Act (2024/1689) | 2025–2027 | AI system risk classification | Conformity assessment support for edge AI-enabled IoT |
All security architectures are designed and documented within the European Union. We provide complete threat model documentation (STRIDE/DREAD), security test reports, SBOM deliverables, and compliance gap analyses as standard deliverables.
Frequently Asked Questions
What is embedded security in IoT?
Embedded security in IoT means integrating cryptographic protection directly into hardware using Secure Elements, TPMs, and HSMs. Unlike software-only security, hardware-rooted protection cannot be bypassed by malware or remote attacks. Inovasense designs IoT devices with hardware root of trust compliant with the EU Cyber Resilience Act.
Why is hardware security important for IoT devices?
Software-only security can be bypassed. Hardware security provides a tamper-resistant root of trust that protects cryptographic keys, ensures secure boot, and prevents unauthorized firmware updates — essential for critical infrastructure and connected devices under the EU CRA and NIS2 Directive.
What is the EU Cyber Resilience Act?
The EU Cyber Resilience Act (CRA, EU 2024/2847) is EU legislation requiring all products with digital elements to meet cybersecurity requirements throughout their entire lifecycle, including vulnerability handling, SBOM, and 5-year security updates. It becomes mandatory in 2027. Inovasense designs hardware that is CRA-compliant from the architecture phase.