Services · Cyber Security
Secure out of the box.
We build devices that start, update and connect securely. And we monitor them for as long as they are in the field.
What we stand for
Security by design, from concept into the field
The measures follow from the threat analysis
First the threat and risk analysis, then the security requirements, then the architecture.
From the component to the cloud
Secure boot on the device, encrypted storage, a protected connection, roles in the application. One gap is enough for an attacker. So we build every link of that chain.
Safety and security go hand in hand
Both start with analysis: hazard analysis for safety, threat analysis for security. Their requirements feed into the same architecture and the same development. The result is one evidence package for both.
Secure throughout the operating life
The Cyber Resilience Act requires vulnerabilities to be monitored and fixed throughout the support period. We take on that task for as long as the device is on the market.
- Cyber Resilience Act
- IEC 62443
- EN 18031
- NIS2
- ISO 27001
- prEN 50742 (draft)
What we take on
Threat and risk analysis
We identify your product's attack surfaces, assess them and derive the security requirements from them.
Secure boot and secure updates
The bootloader only accepts signed versions. If an update fails, the device falls back to the previous version and keeps running.
Keys throughout the device's life
Keys and certificates are installed at the end of the production line and renewed during operation. Special cases are covered too.
Encryption, roles and permissions
Encrypted storage, disabled services, separated permissions. Who may do what belongs in the data model.
Software bill of materials and CVE monitoring
The SBOM lists every third-party component with version and licence. We assess reported vulnerabilities against the requirements and tell you which of them affect you.
Evidence for the CRA and the RED
Risk assessment, SBOM, test reports and the vulnerability handling procedure belong in the technical documentation that the CRA and the RED require.
Security lasts only as long as someone keeps working on it.
Your benefits at a glance
Fewer reports that concern you
Not every reported vulnerability affects your device. We check against the version and configuration actually installed before we pass anything on to you.
The 24-hour deadline is workable
The Cyber Resilience Act requires an actively exploited vulnerability to be reported within 24 hours. With continuous monitoring, you can use that time for the decision.
An update path that works
A patch is only useful once it reaches the device. The route there is designed into the architecture and tested before series production starts.
Security and regulatory approval in one package
The evidence for the CRA, the RED and functional safety comes out of the same project. That saves a second round with the assessment body.
From threat to evidence
On request as a fixed-price contract.
Classification
Which rules apply to your product: the Cyber Resilience Act, the Radio Equipment Directive with EN 18031, IEC 62443, and for machinery in future prEN 50742.
Threat analysis
Attack surfaces, the attacker model and the assets to be protected. Assessed by likelihood and impact.
Security concept
The measures are defined for each requirement: signatures, key management, encryption, roles. Plus the question of where a key is generated and who may renew it.
Implementation
Electronics, firmware and services are developed according to this concept. Every version passes through static analysis, review and test.
Evidence
Risk assessment, SBOM, test reports and the vulnerability handling procedure go into the technical documentation.
Monitoring in the field
New vulnerabilities are assessed against the requirements, and security updates are built and delivered for as long as the support period runs.
Build on our foundation
Operating systemViewqdCoreX
Buildroot-based Linux with a mainline LTS kernel. Fail-safe updates, logging and certificate management are already built in.
View
IoT platformViewqdCloud
Device management, OTA updates and the certificate service. The route a correction takes to reach the device.
View
Production testViewqdTest
Programming and testing at the end of the production line. This is where keys and certificates go into the device.
View
Transparency from the start
Does the Cyber Resilience Act apply to our product?
If it has digital elements and is placed on the EU market, most likely yes. The reporting duties apply from 11 September 2026, the requirements on the product and on vulnerability handling from 11 December 2027. We classify your case at the outset.
Who reports a vulnerability to the authority?
The duty lies with the manufacturer, which means you. We provide the basis: we detect the vulnerability, assess it against your device and prepare the content of the report.
Our device is already in the field. Is it too late?
No. We go through the software, produce the missing SBOM and tell you which gaps exist and what an update path would cost.
Where is the work done?
In Offenburg, and nowhere else. We work with our own people. Whoever designs the key management sits in the same building as the people who build the firmware and the production test.
Do you work with AI?
Yes, systematically. Anything a tool contributes goes through the same checks as every other line of code: static analysis, review, test. We build our AI system ourselves, so we know what it does, and we keep improving it.
Tell us about your next project.
Tell us about your product and your schedule. We will tell you how we would approach the project and whether we see any major risks. The assessment, up to an indicative price, is free of charge.
