# Embedded device security: secure boot, OTA, key management | OneStack > Embedded security from Brescia, Italy: risk assessment, secure boot, protected debug, signed updates, encryption and SBOM. Ready for the Cyber Resilience Act. URL: https://www.onestack.it/en/embedded-security Cybersecurity · Embedded security # 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. [Proposal in 48 hours](/en/contact)[What the CRA and RED require](/en/cyber-resilience-act) ## 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 [Cyber Resilience Act dates and requirements →](/en/cyber-resilience-act) An example ## 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 ## Secure updates in the field [ ![3D render of the control board: microcontroller in the centre, connectors for the two isolated channels on the side, pluggable terminal blocks and power and service connectors](/_astro/interfaccia-rugged.CkQk4iYb_1A6Ozp.webp)![](/_astro/interfaccia-rugged-xray.CZb6dpZZ_Z1kxhOu.webp) 23 tests in ~75 s Systems for harsh environments ### A rugged interface that updates in the field and never bricks A portable, battery-powered unit that powers and controls two remote devices over isolated channels. The hard part was making it reliable far from any lab. Its firmware updates in the field and, if something goes wrong, rolls back on its own to the last working version. Read the case → ](/en/case-studies/rugged-interface-secure-ota) ## 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. [Request a proposal](/en/contact)[Urgent? Call +39 030 535 7183](tel:+390305357183)