Skip to main content

Cybersecurity

Secure Development Outsourcing for the EU CRA

From security requirements to secure boot, firmware signature verification and security updates, we design and implement the security functions of your products for the EU market, and also take care of secure coding checks and SBOM creation.

From security requirements to secure boot, firmware signature verification and security updates, we design and implement the security functions of your products for the EU market, and also take care of secure coding checks and SBOM creation.

Why You Need This

The CRA Requires Security in Design and Development

Can security be added just before release?
The CRA requires products to be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. Motor vehicles and components designed exclusively for them are excluded, but general-purpose components, robots, agricultural machinery and construction machinery may be in scope. Parts that are fixed together with the hardware, such as the code that first verifies the boot or the component that stores the keys, are hard to change just before release.
Is signed firmware secure?
A signature only shows that the firmware comes from a legitimate source and has not been altered. It does not prevent flaws in the code. The CRA product requirements include making products available on the market without known exploitable vulnerabilities, and secure coding, static analysis and checking the SBOM against vulnerability information are ways to meet this during development.
Can your product still be fixed after release?
Manufacturers must handle vulnerabilities and provide security updates throughout the support period (in principle at least 5 years), and, where technically feasible, provide security updates separately from functionality updates. This is why the update signing scheme and the update structure are decided at the design stage.

Service Introduction

SeonENS CRA Secure Development

Drawing on our experience in developing secure bootloaders and HSM-based security software, we design, implement and verify the security functions of your product and leave the development evidence needed for the CRA technical documentation.

Security Requirements and Architecture
We turn the results of the risk assessment into security requirements and decide which components and software handle the trusted boot chain, firmware integrity, key protection and encryption of sensitive data. If there is no risk assessment yet, we carry it out with you.
Security Function Development
We implement secure boot and firmware signature verification, security updates, integration with embedded hardware security modules (HSM), and reset and data deletion functions.
Secure Coding and Security Verification
We build secure coding rules, code review, static analysis and security function testing into the development process, and create an SBOM at build time to check it against known vulnerabilities.
Development Evidence for Technical Documentation
We keep the development outputs that go into the CRA technical documentation, such as design information, test reports and the SBOM, and continue with conformity preparation through our CRA compliance consulting.

Service Areas

CRA Secure Development Services

Security Design
  • Threat analysis, security requirements
  • Security architecture, key storage structure
  • Update and decommissioning design
Security Function Development
  • Secure boot, firmware signature verification
  • Security updates
  • HSM integration
Security Verification
  • Secure coding, static analysis
  • Security function testing
  • SBOM generation, vulnerability checks

CRA Requirements and Our Development Work

CRA Requirement SeonENS Development Work
Designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks Security requirements and architecture defined from the risk assessment
Made available on the market without known exploitable vulnerabilities SBOM for each build, checks against known vulnerabilities, static analysis
Confidentiality of data, integrity of data and programs Secure boot, firmware signature verification, key protection, data encryption
Vulnerabilities addressed through security updates, provided separately from functionality updates where technically feasible Signed updates, an update structure that allows separate security updates
Users can securely and easily remove all data and settings on a permanent basis Reset and permanent deletion functions
Technical documentation (including design information, test reports and the SBOM) Preparation and organization of development outputs

The requirements for making products available without known exploitable vulnerabilities, for protecting the confidentiality and integrity of data, and for permanent deletion (Annex I, Part I, point (2)) apply on the basis of the cybersecurity risk assessment and where applicable, so the risk assessment of each product decides which functions are implemented and to what extent.

From Day One of Design to Decommissioning

Stage SeonENS Work
Design Risk assessment input, security requirements, review of key storage location and components
Prototype Checking the secure boot, key and certificate structure on evaluation boards
Development Security function implementation, secure coding, static analysis, SBOM for each build
Production Security requirements for the procedure that injects per-device keys and certificates
After release Update signing procedure design, security update development
Decommissioning Reset, data and credential deletion functions

CRA Secure Development Process

Phase 1: Requirements Definition
  • Product configuration, risk assessment review
  • Derivation of security requirements
  • Agreement on development scope and outputs
Phase 2: Security Design
  • Security architecture, key storage structure
  • Boot, update and decommissioning design
  • Design review
Phase 3: Implementation and Verification
  • Security function implementation
  • Secure coding, static analysis
  • Security function testing, SBOM
Phase 4: Delivery and Maintenance
  • Delivery of design and test outputs
  • Vulnerability fixes, security update development
  • Link to technical documentation

Expected Benefits

Practical Benefits

  • Security Decided at the Design Stage
  • We decide early, together with the hardware, the security structure that is hard to change after shipment.
  • Your Team Stays on Product Features
  • Leave security function development and verification to us while your developers focus on product features.
  • Development Evidence for Technical Documentation
  • Design and test records and the SBOM produced during development go straight into your CRA technical documentation.

Build CRA Security In from the Design Stage

Build CRA Security In
from the Design Stage

Tell us about your product configuration and development schedule, and we will propose the scope of security development you can outsource and how we would carry it out.

Tell us about your product configuration and development schedule, and we will propose the scope of security development you can outsource and how we would carry it out.