Secure by Design
Embedded Security Engineering for Connected Devices
The EU Cyber Resilience Act (CRA) and tightening customer requirements have moved security out of the release notes and into the architecture. For product teams, this is not a legal question but an engineering one across hardware and embedded software.
Promwad helps OEMs and product companies build security inside the device.
With 21+ years of embedded engineering, we turn CRA requirements into concrete implementation from secure boot and trusted updates to device architecture and identity.
Embedded Security for Global OEMs
Why Promwad
Embedded security belongs to embedded engineers, because the closer security is implemented to the hardware and firmware levels, the more reliable it is — and the lower the risk of compromise at the software level.
Our Tech Stack
What we actually work with inside shipping products
Hardware & Boot Integrity
- Secure boot & hardware root of trust: chain-of-trust from boot ROM upward, on MCU and FPGA platforms
- Anti-rollback protection: enforced at the bootloader level
- Hardware security review: schematic and PCB review, physical inspection, component-level protection against unauthorized access
- Tamper-resistant chips & secure storage elements: where the threat model requires hardware-level defenses
- Platform primitives: TPM, TrustZone, and secure elements, applied against vendor SDKs and reference designs
Identity, Crypto & Updates
- Device identity & provisioning: factory key injection, per-device certificates, mutual authentication, secure cloud onboarding
- Cryptographic libraries: MbedTLS and OpenSSL
- FIPS 140-2-aligned cryptographic modules: where the product requires it
- Trusted updates: signed OTA with MCUboot, rollback protection, dual-bank failure-safe flows, controlled recovery paths
Out of scope: we do not develop proprietary cryptographic algorithms.
Software Discipline & Runtime
- Secure coding standards: MISRA, SEI CERT C, applied in the daily workflow
- SBOM generation: SPDX/CycloneDX as a release-pipeline step
- Vulnerability-aware engineering: software components CVE tracking
- Threat & vulnerability frameworks: MITRE EMB3D™ for embedded threat modeling, CWE for weakness classification, CVSS for severity scoring
- Runtime protection: defenses implemented in firmware
- Monitoring integration: into your chosen fleet and security platforms
Out of scope: we do not ship a proprietary monitoring product.
Standards & Regulatory Alignment
- ISA/IEC 62443: industrial
- ISO/SAE 21434: automotive
- ETSI EN 303 645: consumer IoT
- EU Cyber Resilience Act (CRA): secure-by-design practice mapped at the engineering level
- ENISA baseline guidance: applied as product engineering input
- Attestation: concepts understood and applied where relevant; we are open about the limits of our hands-on practice
Out of scope: we do not provide certification, formal audit, or legal advisory services.
Where It Applies
Embedded security shows up differently in every domain — in the integrity of an industrial controller, the update chain of a connected consumer device, the ECU of a vehicle, the edge of a telecom network. We work primarily where our engineering depth is strongest.
Industrial & IIoT — Primary
Controllers, gateways, and industrial edge devices where ISA/IEC 62443-aligned engineering, secure boot, and signed updates are core to asset integrity.
IoT & Connected Products — Primary
Consumer and B2B connected products where CRA readiness, device identity, and OTA hygiene decide whether a product ships — and stays shippable.
Automotive — Supporting
ECUs, gateways, and supporting control units where ISO/SAE 21434-aligned engineering complements our broader automotive hardware and software work.
Telecom & Networking Devices — Supporting
CPE, routers, and edge equipment — hardened firmware, provisioned identity, managed update flows.
Medical Devices — Selective
Device-level security engineering only, where the work is genuinely embedded.
Broadcasting & Pro AV — Selective
Included where the device-security angle is real, not as a generic fit.
The Security Hardening Path
Whether you are hardening a shipping product or building a new one secure-by-design, the path is the same shape — a short, concrete engineering engagement, not an open-ended consulting track.
Assess
We review your architecture, firmware flows, update chain, and key handling. The deliverable is an engineering-level risk-and-gap view anchored in your product.
Design
We translate risks and requirements into concrete firmware, hardware, and update-chain decisions, co-developed with your product team.
Implement
The bulk of the engagement: secure boot, signed OTA, provisioning, anti-rollback, device identity, crypto integration — delivered as working code and verified hardware flows.
Harden
For existing products: close gaps in update flows, key handling, and device identity — without rewriting what you already ship.
Sustain
SBOM maintenance, CVE monitoring against your release, security updates and patch delivery across the CRA support period, and integration with your monitoring and fleet platforms — so security does not decay after release.
Our Case Studies
Every project below was delivered inside a real, shipping product.
Router Cybersecurity Audit for CRA Compliance
A full-stack security audit of an OpenWRT-based router covering hardware, firmware, and compliance readiness.
Pain
The client needed to bring their router — built on the Realtek RTL9615C platform — into compliance with the Cyber Resilience Act and a stack of overlapping standards including FIPS 140-2, GDPR, and UL 2900-1. Without a structured audit, hidden vulnerabilities and untracked dependencies posed both regulatory and product risk.
Solution
We ran a four-layer audit: threat analysis using the MITRE model, hardware inspection of circuits and unused platform features, firmware analysis with SBOM generation and CVE mapping, and penetration testing. Each finding was mapped to concrete mitigations across the OpenWRT/prplOS stack.
Result
The router achieved documented compliance with CRA, FIPS 140-2, GDPR, and UL 2900-1 — with a full SBOM and remediated vulnerabilities ready for regulatory submission and customer-facing security documentation.
Industrial Switch Cybersecurity Audit
A multi-layer security audit of a Microchip-based industrial switch covering hardware, firmware, and network protection.
Pain
The client needed to validate the security posture of their industrial switch against real-world threats and meet a demanding compliance stack — GDPR, FIPS 140, and IEC 62443 — without a clear picture of existing vulnerabilities across hardware, firmware, and network layers.
Solution
We ran a five-layer audit: MITRE-based threat analysis, hardware inspection against CWE Most Important Hardware Weaknesses, firmware hardening with CVE elimination and SBOM creation, network protocol analysis with attack prevention measures, and full penetration testing across the Microchip VSC7448YIH-01 platform.
Result
The switch achieved documented compliance with GDPR, FIPS 140, and IEC 62443 — with a clean SBOM, remediated CVEs, and hardened network stack ready for industrial deployment and regulatory review.
CRA Threat Model for a Linux-Based Measuring Device
EMB3D-based threat modeling and mitigation roadmap for a networked industrial measurement device.
Pain
A European manufacturer of professional measurement and data-acquisition equipment needed to demonstrate CRA readiness for a Linux-based device with network connectivity and local UI — but had no structured threat model or documented evidence of hardware and software security controls.
Solution
We applied MITRE EMB3D™ threat modeling to map device properties to threats across hardware and software layers, prioritise risks, and produce a concrete HW/SW mitigation roadmap. The analysis covered boot-chain integrity, firmware update security, cryptographic configuration, network surface hardening, and hardware Root of Trust.
Result
The manufacturer received a CRA-ready evidence package: 41 documented mitigations (36 SW, 5 HW), a prioritised action plan covering secure boot, signed updates, HW RoT, and off-device logging — ready to support regulatory submission and product security architecture decisions.
How We Ensure Quality
If you are going to let us sign your firmware and provision your devices, you need to know how we keep that trust intact.
Secure development lifecycle
Security requirements, threat considerations, and verification live inside the engineering workflow — tracked, reviewed, and owned by the same team that ships the code.
Secure coding, code review, static and dynamic analysis, dependency scanning
aligned with MISRA C / MISRA C++ and SEI CERT C standards, applied with a vulnerability-aware discipline.
SBOM and vulnerability-aware releases
SPDX and CycloneDX outputs ship with relevant releases, with CVE and CWE tracking wired against the SBOM and severity prioritized with CVSS.
End-to-end traceability
Requirements → design → test → release. Valuable when you are preparing for certification — although certification itself stays with you and your assessors.
Key and secret handling
Provisioning workflows, HSM-backed key injection where the product calls for it, and a clear rule: your keys stay yours. We do not custody production key material.
Testing and external coordination
We run engineering-level security testing and verification in-house, and bring in specialized external partners for penetration testing and formal audit when the product calls for it.
Trusted by Product Companies and OEMs
Turn CRA Pressure into a Concrete Engineering Plan
In a 30-minute call with our embedded security engineers, we review your product, propose concrete security mechanisms, and scope a pilot. No commitment.
FAQ
What does Promwad actually implement in embedded security?
Does Promwad provide certification or compliance services?
Do you do formal security audits?
Can you help us prepare for the EU Cyber Resilience Act?
Which MCU and SoC platforms do you work with for secure boot and root of trust?
Do you work with existing products or only new designs?
How do you handle keys and cryptographic material during development and provisioning?
What does a typical engagement look like?