Independent security and compliance consulting for manufacturers of Linux-based devices. I build the threat analysis, the SBOM and the technical documentation, and I design the security features that make them true.
| Threat scenario | Risk | Treatment |
|---|---|---|
| Unsigned firmware accepted over the update channel | Critical | Verified boot, signed images, anti-rollback |
| Debug UART left open in production | High | Disable console, lock debug fuses |
| Shared default SSH credentials across the fleet | Critical | Per-device credentials provisioned at manufacture |
| Known CVE in a shipped OpenSSL version | Medium | SBOM monitoring, defined patch process |
I help manufacturers of connected products turn the EU Cyber Resilience Act (CRA) into a competitive advantage.
With 40 years in embedded systems, 25 years in cryptography, and 15 years in automotive product security, I cover the full stack: threat & risk assessment, security architecture, secure boot, HSM, ARM TrustZone, Linux hardening, and supplier security.
The result: products that are not just compliant, but demonstrably more secure than the competition.
The Cyber Resilience Act (Regulation (EU) 2024/2847) makes cybersecurity a requirement for CE marking of products with digital elements. Manufacturers carry the responsibility for the whole product lifecycle, including third-party components such as the Linux kernel, bootloader and open source libraries.
Dates as published in the regulation. Confirm applicability to your product category before planning.
Official sources
The CRA entered into force.
Reporting obligations apply. Manufacturers must notify actively exploited vulnerabilities and severe incidents within tight deadlines, starting with an early warning within 24 hours. Notifications go through ENISA’s Single Reporting Platform. Read the Commission’s reporting rules.
Main obligations apply. Products placed on the EU market need security by design, a vulnerability handling process, an SBOM and complete technical documentation.
Practical work products your team can build on, written by someone who has shipped the underlying hardware and software.
A clear view of where your product and processes stand against the essential requirements.
Reference: Commission CRA guidance and FAQs.
Threat analysis and risk assessment that engineers can implement and auditors can follow.
A software bill of materials wired into your build, plus the process to act on what it shows.
Formats: SPDX, CycloneDX. Reference: CRA reporting rules.
Security features designed for your hardware, your constraints and your update model.
The evidence a market surveillance authority or notified body expects to see.
Reference: CRA legal text and summary.
Independent review of algorithm choices, protocols and key handling in hardware and software.
You do not need a security department. You need the right decisions made early and documented as you go.
We define the product, its intended use and the applicable requirements in a short call.
Threat model, SBOM baseline and gap analysis show what must change and what already holds up.
Security features are specified and reviewed with your engineers against real hardware limits.
Evidence is produced alongside the work, so the technical file is ready when you are.
Vulnerability monitoring and update processes keep the product compliant after launch.
Information Security Analyst & Evangelist
I have built embedded Linux systems from the hardware up, and I have worked on cryptography where it is hardest to get right: in silicon, in firmware and in vehicles. That background lets me talk with your developers about boot flows and key storage, and with your management about risk and deadlines.
Automotive cybersecurity taught me what a rigorous, auditable security process looks like. I bring that discipline to your product, scaled to your company.
Tell me what you build and where it is sold. You will get an honest view of what CRA compliance means for you and a proposal for the next step.