Secure devices, from board to firmware
A device’s security is decided at design time: a debug port left open, a memory too small for updates or a key hard-coded in firmware cannot be fixed later. We design board and firmware with the measures required by the Cyber Resilience Act and the Machinery Regulation, and document them for your technical file.
Why it starts on day one
When security comes at the end, it often takes a new board revision: an unplanned secure element, flash to double for updates, interfaces to redesign. That is why security requirements go into the feasibility study and the specification, together with all the others.
What we do
Risk assessment
What needs protecting, from whom and through which interfaces. It produces the security requirements in the specification and the documentation for the technical file.
Board-level security
Protected or lockable debug ports, external interfaces reduced to what is needed, root of trust and secure element where needed, memory sized for updates.
Secure boot and updates
Boot chain with signed images, protection against rollback to vulnerable versions, A/B boot with automatic return to the last working version, power-fail-safe OTA.
Data and communications
Critical functions isolated with TrustZone, flash protected from external reads, data encrypted at rest and in transit, TLS, log of accesses and changes.
Production
We design the production test bench to load unique keys and certificates into every device and lock the debug port at the end of the test.
After the sale
Firmware SBOM, vulnerability monitoring of libraries and RTOS, security updates for the support period, under a maintenance contract. Penetration testing with specialised labs.
From requirements to board and firmware
The Cyber Resilience Act requirements are written for any product. On an embedded device they become specific design choices.
| Requirement | On the board | In the firmware |
|---|---|---|
| Limited attack surface | Protected debug, service connectors not exposed | Debug locked in production, unused services disabled |
| Software integrity | Memory for multiple images, root of trust | Secure boot with signatures, anti-rollback |
| Security updates | Memory and power sized for updating | Signed OTA, A/B boot with automatic rollback |
| Data confidentiality | Secure element for keys | Encryption at rest and in transit, TLS |
| Device identity | Unique key for every board | Certificates loaded in production |
| Secure by default | — | No shared default passwords, factory reset |
| Event logging | Non-volatile memory for logs | Logs of accesses, changes and updates |
| Third-party components | BOM with component lifecycle | SBOM of libraries, RTOS and SDKs |
Security written into the specification
In a recent project, a connected device on a microcontroller with TrustZone, security requirements went into the specification from the first draft.
- Critical functions run in the secure side of the microcontroller, isolated from the rest of the firmware.
- Flash memory is protected from external reads and writes.
- Penetration tests are planned in the hardening phase, before production.
What you get
- Risk assessment and security requirements in the specification
- Documented security architecture
- Firmware with secure boot and signed updates
- Procedure and tools to load keys in production
- Machine-readable SBOM
- Documentation for the technical file
FAQ
Can you work on a device that is already on the market?
Yes. We review board and firmware, tell you what is missing and fix it. If the board already exists, much can be done in firmware: locked debug, signed images, secure updates.
Do you do penetration testing?
We plan it into the project and have it carried out by specialised labs. Then we fix what comes up.
Do you issue CRA certification?
No: for most products the manufacturer declares conformity, and some categories need a notified body. We design the technical measures and give you the documentation for the technical file.
Who handles security updates after delivery?
You, or us under a maintenance contract: vulnerability monitoring of components, fixes and release of updates for the support period.
Got a deadline?
Tell us about your project: within 48 hours you get a proposal with phases and dates. If needed, we sign an NDA before seeing your files.