Now, design phase
Chipset, operating system baseline, kernel branch, crypto stack and update mechanism decide whether a product can be kept compliant for its support period. Correcting this after tape-out is a redesign.
Your machines run on open source software. Can you prove what is inside?
A modern PLC, robot controller, telematics unit or line HMI is typically built from hundreds or even thousands of open source components: embedded Linux, RTOS stacks, crypto libraries, protocol drivers, plus copied or AI generated snippets or vendor code that nobody ever declared. For most manufacturers that composition has never been written down, let alone maintained. The Cyber Resilience Act turns this invisible bill of materials into a regulated, auditable product obligation.
We analyze your product source code and dependencies to make that composition visible, provable, and maintainable across the product lifecycle. The output is not a dashboard; it is evidence you can hand to an auditor, an OEM customer or a notified body.
Request a Compliance Assessment
Built for products, not just IT
- Source-code and snippet-level scanning of your code repositories
- Full-scan clearance of supplied source drops and vendor SDKs
- Binary scanning: firmware images, not just source repos
- Copyleft clearance completed before the device leaves the plant
- CRA, NIS2, IEC 62443 and UNECE R155/R156 evidence held in one place
- Vulnerability monitoring that survives long product lifecycles
Why open source compliance behaves differently in a product business than in enterprise IT
| Facts & Figures | What it means |
|---|---|
| 70 to 90 percent | Typical share of an embedded codebase made up of open source and third-party code, most of it never formally cleared. |
| Snippet level |
Copied functions, AI generated code, vendor SDK drops and forked drivers carry license obligations that a package-manager view never sees. |
| 10 to 20 years | Service life of an industrial asset, long after the upstream community stopped patching the library inside it. |
| December 2027 | Full CRA obligations apply to products with digital elements placed on the EU market, so design decisions taken today are already in scope. |
Why manufacturing is different
-
Embedded code is copied, not just imported
Reference drivers, vendor SDK samples, forked upstream files, and AI generated code are pasted straight into the firmware tree. There is no manifest entry, no package manager record and no declaration, yet the license obligations travel with the code all the same. Only snippet-level source code scanning brings that code back into view.
-
Distribution triggers copyleft
Unlike a hosted backend, a machine is distributed. GPL, LGPL and AGPL obligations become concrete: complete corresponding source, a written offer, installation information and license texts in the manual. Discovered at shipment rather than at design time, a single copyleft finding is enough to stop a launch.
-
You cannot simply upgrade the library
A CVE in a crypto or protocol stack inside a certified safety controller means re-validation, re-qualification and possibly re-certification. What engineering needs is a prioritized, context-assessed short list with a documented justification for everything excluded, not a four-thousand-line raw vulnerability dump.
-
Your product outlives its dependencies
A line commissioned today will still be running in 2040. Kernel branches reach end of life; packages are abandoned, and maintainers disappear long before the asset is decommissioned. Someone must own that obsolescence risk for the entire installed base, and increasingly the regulator expects it to be the manufacturer.
-
OT constraints block the usual fixes
Air-gapped cells, hard real-time loops, no agents permitted on the controller and change windows that open once a quarter. Compliance evidence has to be produced from development artefacts, without touching a running line.
-
Customers now audit you
OEM procurement, defense and automotive customers request SBOMs, license documentation and CRA conformity evidence in the request for quotation itself. No SBOM increasingly means no bid, which makes compliance a sales qualifier rather than a back-office exercise.
Application security platforms assume you own the source, build daily, and patch on demand. Industrial products break every one of those assumptions, which is why generic tooling produces findings your engineers cannot act on.
Our service catalogue:
CRA readiness and conformity evidence
A gap assessment against the essential requirements of the Cyber Resilience Act, translated into engineering work packages rather than legal prose.
- Policies, processes and tools
- Actionable roadmap to compliance
SBOM creation for firmware & embedded products
We create a component-accurate SBOM per device, variant and firmware release from source, or directly from the binary image when no source exists.
- Full-file and snippet matching against our comprehensive open-source knowledge base
- SPDX and CycloneDX output, ready for customer portals
- Per-variant SBOMs mapped to part numbers and release trains
Vulnerability monitoring and risk assessment
Continuous CVE matching against your SBOM inventory, filtered down to what is genuinely relevant in your device configuration, with a written justification behind every exclusion.
- Documented assessment and technical details per finding
- Severity scoring
- Individual risk assessment
License clearance and copyleft strategy
Every component classified and every obligation resolved before the device ships, rather than during a customer audit or in response to an enforcement letter.
- Copyleft exposure map covering GPL, LGPL, AGPL, MPL and EPL boundaries
- Static versus dynamic linking analysis across the source tree
- Written offer, attribution and license notice packages
- Complete corresponding source bundles per release
Supplier and tier-n SBOM governance
Compliance is only as strong as your weakest supplier. We operate SBOM requirements across contracts, supplier onboarding, and incoming inspection.
- SBOM clauses for purchasing terms and development agreements
- Incoming SBOM quality gates and automated validation
- Verification scans of delivered source drops and SDKs against the declared SBOM
Compliance as a managed service
Compliance is not a project that ends. We run the tooling, the triage and the evidence pipeline for your installed base so that your engineers stay on product development.
- Scanning support and customer SBOM request handling
- Quarterly obsolescence and end-of-life component reviews
- Audit-ready evidence archives per product and per release
Request a Free Compliance Assessment
Submit a representative source code package or firmware image and receive a preliminary SBOM, licence analysis, and vulnerability review. This gives your team a practical basis for deciding what a portfolio-wide open source compliance programme should look like.
Contact our expertThe Cyber Resilience Act is a product-engineering deadline
Products designed this year will still be on the market when full obligations apply. Anything with a digital element placed on the EU market falls in scope, including machines, controllers, gateways, and the software updates delivered to them.
Regulatory timeline
1
September 2026
Reporting obligations start. Actively exploited vulnerabilities and severe incidents must be reported to ENISA and the national CSIRT, with an early warning within 24 hours.
2
December 2027
Full application. Essential cybersecurity requirements, vulnerability handling, technical documentation, SBOM maintenance, and conformity assessment apply to products placed on the EU market.
3
Beyond
Security updates must be provided across the expected product lifetime, which for industrial assets is usually far longer than a five-year default assumption.
4
What compliance requires from you
Each obligation translates into concrete work on the shop floor and in the development organization.
| Obligation | What it means in practice |
|---|---|
| Component inventory | A maintained SBOM per release, covering at least top-level dependencies, retrievable years later. |
| Vulnerability handling | Monitoring, triage, remediation, and documented coordinated disclosure policy. |
| Secure updates | Signed, verifiable and deliverable updates, including devices sitting behind an OT firewall. |
| Documentation | Risk assessment, test evidence, declaration of conformity, and the conformity file, retained for ten years. |
| Transparency | The support period communicated to customers, and end of support handled deliberately rather than by silence. |
What sets our approach apart
Reading a manifest file tells you what your developers intended to use. Scanning the code tells you what is in the product: the copied driver, the forked kernel patch, the SDK sample that quietly brought a copyleft license into a machine that will run until 2040. Our practice is built around that gap.
We scan snippet-deep rather than manifest-deep, using the same class of platforms your customers already trust, so that copied and AI generated code surfaces alongside declared packages.
Try before you buy
Give us access to a single representative component source tree. You get back a component-accurate SBOM, a license risk map including snippet-level findings and a triaged vulnerability picture for that codebase. That is a concrete basis on which to decide what a portfolio-wide program needs to look like.
Frequently Asked Questions
-
Does the Cyber Resilience Act require an SBOM?
The Cyber Resilience Act requires manufacturers to maintain information about software components and vulnerabilities as part of their compliance and security processes.
-
How can manufacturers identify open source software in firmware?
Manufacturers can identify open source software through source-code analysis, binary scanning, firmware analysis, and snippet-level detection techniques that uncover embedded open-source components.
-
What is Software Composition Analysis (SCA)?
Software Composition Analysis (SCA) helps organizations identify open source components, track vulnerabilities, and monitor license obligations within software products.