Your product contains software and is sold in the EU? Then it is likely to fall under the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847. It requires manufacturers to ensure that products with digital elements are secure throughout their entire life cycle – and that this can be demonstrated. We review your product from a technical perspective, show you where it stands and, if you wish, implement the necessary measures together with you.
The Deadlines
- Since 11 September 2026: Reporting obligations for actively exploited vulnerabilities and severe security incidents. They also apply to products that are already on the market.
- From 11 December 2027: The regulation applies in full, including the essential cybersecurity requirements, conformity assessment and CE marking.
Products placed on the market before 11 December 2027 only have to meet the remaining requirements if they are substantially modified after that date.

What We Review for You
1. Inventory
Which products and versions are affected, what software do they contain, and what interfaces and data connections are there? We clarify from a technical point of view whether your product falls within the scope and which classification is likely – default product, important product or critical product. This determines whether you can assess conformity yourself or need a notified body. Some product groups, such as medical devices, are excluded because they are subject to their own rules.
2. Software Bill of Materials (SBOM)
The CRA requires you to know and document the components of your product, at least the top-level dependencies, in a commonly used machine-readable format. We record libraries, open-source components and purchased modules with their versions and set up SBOM generation, for example in CycloneDX or SPDX format, so that it is produced automatically with every build.
3. Vulnerability Management
We check your components against public vulnerability databases, assess the matches for your product and propose fixes. This includes a process for how you will deal with vulnerabilities in future: a contact address for external reports, a coordinated vulnerability disclosure policy and regular reviews.
4. Update Process
Security updates must reach your customers promptly, securely and, where possible, separately from feature updates. We examine how updates are currently created, signed and distributed, and how you cover the support period. As a rule, this is at least five years, or correspondingly less if the expected period of use is shorter.
5. Product Security
We check the essential requirements for the product itself: no known exploitable vulnerabilities on delivery, secure default settings, protection against unauthorised access, encryption, the smallest possible attack surface and logging of security-relevant events. Methodologically, we use our quality audit with code review and security review for this.
6. Technical Documentation
For the declaration of conformity, you need technical documentation: product description, architecture, cybersecurity risk assessment, vulnerability handling procedures and information for users. We review what already exists and produce the technical parts that are missing.
7. Reporting Obligations
If a vulnerability in your product is actively exploited, an early warning is due within 24 hours and a more detailed notification within 72 hours – via ENISA's single reporting platform. Together with you, we define who detects, assesses and reports such information, and we prepare the technical details so that no time is lost in an emergency.
What You Receive from Us
- A report on the status of your product for each area of requirements, clear enough for management and product management too
- A list of measures, ranked by urgency and with estimated effort
- Implementation if you wish: SBOM in the build, remediation of vulnerabilities, update mechanism, documentation
- Ongoing support where needed, for example through support and maintenance
Who This Is For
Our service is aimed at manufacturers of machines and devices with their own control software, at providers of laboratory and measurement technology, and at companies that sell desktop software or CAD add-ins for AutoCAD, BricsCAD or Revit. We review software we have developed ourselves as well as software from other manufacturers and legacy code in C#/.NET or C++.
Please note: We carry out the technical review and implementation, not legal advice. We coordinate legal questions, such as the binding classification of your product, with your legal department or your lawyers.
Your Next Step
In an initial consultation, we clarify which products could be affected and where you should best begin. You can find more about our quality and security services in the overview.
