CRA: bringing products with digital elements to market securely

Your device with firmware, app and cloud backend is meant to stay on sale in the EU after 11 December 2027. A distributor or key account asks for CE conformity and an SBOM. Or a security researcher reports a vulnerability and there is no process yet to receive it. In all three cases it comes down to the same question: does your product meet the CRA requirements, and can you demonstrate it?

What the CRA requires

Regulation (EU) 2024/2847, the Cyber Resilience Act, has been in force since 10 December 2024 and applies in three stages: the rules for notified bodies since 11 June 2026, the reporting obligations for actively exploited vulnerabilities and severe security incidents since 11 September 2026, and the remaining manufacturer obligations from 11 December 2027. Products placed on the market from then on must meet all requirements. An existing product counts as newly placed on the market after a substantial modification, such as a major update.

Covered are products with digital elements that can be connected directly or indirectly to a device or network: from the networked hardware component and embedded systems to delivered software, including custom developments. Pure SaaS offerings do not fall under the CRA, but cloud functions without which a product cannot work do. The core obligations for manufacturers:

• Cybersecurity across the entire product lifecycle, from the risk assessment in design (Article 13) through security by design and security by default to security updates over the support period. That period is as a rule at least five years, its end date has to be stated at the time of purchase, and security updates must be free of charge and delivered separately from feature updates.
• Vulnerability management (Annex I Part II): a machine-readable software bill of materials (SBOM), regular security testing, a contact point for vulnerability reports and a process for coordinated disclosure. The CRA requires the SBOM, not its publication.
• Reporting obligations (Article 14), in force since 11 September 2026: early warning within 24 hours of becoming aware, notification with an initial assessment within 72 hours, final report for vulnerabilities no later than 14 days after a remedy is available and for incidents one month after the 72-hour notification. Reports go through ENISA’s Single Reporting Platform.
• Conformity assessment, technical documentation and CE marking: the documentation under Annex VII contains the risk assessment, the SBOM, the CVD policy and explicitly the reports on the tests used to verify conformity.

The assessment procedure depends on the product class, which Implementing Regulation (EU) 2025/2392 describes technically. For standard products, the manufacturer’s self-assessment is sufficient. Important products of class I (Annex III, such as password managers, routers, operating systems) may stay with it if they fully apply harmonized standards; otherwise a notified body is mandatory. For class II (such as firewalls, hypervisors) and critical products (Annex IV, such as smart cards and smart meter gateways), there is no way around a notified body or a European certification scheme. Harmonized CRA standards are in progress, but as of September 2026 none has been published in the Official Journal. Until then, class I effectively leads to a notified body as well.

Are you affected?

The first question is your role. Manufacturers carry the main obligations, from design to reporting. Importers (Article 19) and distributors (Article 20) may only place conforming products on the market and have to check the manufacturer’s conformity assessment, CE marking and documentation. Anyone who sells a product under their own brand or substantially modifies it counts as the manufacturer (Article 22), which affects white-label and OEM business. Open-source software stewards have reduced obligations (Article 24), and non-commercial open-source software is exempt. Whether you are based in the EU does not matter: what counts is that the product is made available on the EU market.

The second question is the product class, because it determines the procedure. We clarify both with you in the initial call.

Security evidence: our entry point

Annex VII requires reports on the tests used to verify conformity. The requirements in Annex I, such as access protection, data integrity and a minimized attack surface, cannot be demonstrated with scanners and code reviews alone. As a BSI-certified provider for IS penetration testing (provider ID BSI-APS-9080), we deliver that evidence for hardware, firmware, apps and backends, following the methodology the BSI itself has defined for penetration tests. For orientation we use the BSI guideline TR-03183, which specifies the CRA requirements from the German authority’s perspective but does not establish a presumption of conformity.

For class II and critical products, the penetration test does not replace the notified body’s assessment. It prepares for it: findings are fixed before the body finds them, and the report is filed with the documentation.

How we work

1. 1
   Classification
   Clarify role, product class and assessment procedure.
2. 2
   Risk assessment
   Threat modeling and architecture review against Annex I.
3. 3
   Implementation
   Anchor secure development, SBOM and vulnerability handling.
4. 4
   Evidence
   Product pentest and test reports for the technical documentation.

How we support you

• Classification and product categorization under Annex III and IV as a clearly bounded first step. Result: role, class, assessment procedure and the concrete need for action.
• Architecture reviews and threat modeling for the risk assessment under Article 13, most effective before implementation.
• Product penetration tests for hardware, embedded systems, apps and backends, as the test report for Annex VII. If your product contains AI components, we test them with a dedicated methodology.
• Secure development: we anchor the secure development process in your teams, from policies and SBOM generation in the build to training.
• Coordinated vulnerability disclosure: we know the process from both sides. We report vulnerabilities to manufacturers ourselves, for example in BookStack, and we know where reports fail (both in German). With you we set up the contact point, triage and disclosure so that a report takes the right path on the day it arrives.
• Reporting readiness for Article 14: tabletop exercises so that the 24-hour early warning works when it matters.
• The ISMS route to Module H: under BSI TR-03183-H, full quality assurance can be realized through an ISO 27001-compliant ISMS extended to product development and vulnerability handling. We prepare your existing or new ISMS for it; the assessment is carried out by the notified body.
• Preparation for the notified body: we compile the technical documentation under Annex VII in audit-ready form, with risk assessment, test reports, SBOM and CVD policy.

We credit existing processes, for example from IEC 62443-4-1, an ISMS or FDA documentation, rather than starting from scratch. If you also fall under NIS-2 as an operator, we plan assessments so that one test serves several forms of evidence.

Manufacturer responsibility stays with you: the EU declaration of conformity, CE marking, notifications to the CSIRT and ENISA, support commitments. We deliver the technical evidence and provide expert support, but we are not a notified body and do not replace legal advice, for example on classifying borderline cases.