Implement the Cyber Resilience Act in practice
Organize and document cybersecurity for products with digital elements throughout their entire life cycle.
The Cyber Resilience Act (CRA) applies to products with digital elements made available on the EU market and to the relevant economic operators. Manufacturers must manage cybersecurity from planning and development through to maintenance and vulnerability handling. The Regulation has applied since 10 December 2024; notification provisions since 11 June 2026, Article 14 reporting obligations from 11 September 2026 and the remainder of the Regulation from 11 December 2027.
Background
Software and connected products often consist of proprietary components, open source libraries, third-party services and multiple release variants. Without a clear product inventory, responsibilities and a maintained vulnerability routine, it remains unclear what has been shipped, what support a product receives and how security vulnerabilities are responded to.
The CRA is therefore shifting the focus from selective security checks to a verifiable product life cycle. He doesn't require every team to use the same tools. It is crucial that the appropriate cybersecurity requirements are implemented on a risk-based basis, documented and maintained during the support period.
Technical context
Regulation (EU) 2024/2847 is a horizontal EU legal framework for hardware and software products with digital elements made available in the context of a commercial activity on the Union market. End products, separately provided components and certain associated remote data processing solutions may be covered. Exceptions and the exact role – such as manufacturer, importer or dealer – must be legally examined on a case-by-case basis.
The main obligations apply to manufacturers who place a product on the market under their name or brand. They must, among other things, carry out a cybersecurity risk assessment, take into account essential requirements of Annex I, prepare technical documentation and carry out the appropriate pre-market conformity assessment procedure. After a successful assessment, the EU declaration of conformity and CE marking follow.
The CRA entered into force on 10 December 2024. Provisions on the notification of conformity assessment bodies have applied since 11 June 2026; the Article 14 reporting obligations for actively exploited vulnerabilities and severe security incidents apply from 11 September 2026. The remaining principal obligations apply from 11 December 2027. The non-binding Commission guidelines of 27 July 2026 explain matters including scope, remote data processing, open source, support periods and interaction with other EU law.
The CRA complements NIS2 but does not replace any organisation-related NIS2 obligations. NIS2 is on the page Implement NIS2 in practice treated; the cluster classification provides Cybersecurity & Resilience.
What companies need to clarify specifically
- Which products, components, versions and associated remote data processing solutions are within the scope of the review.
- What role the company plays for each product and who is responsible for the legal classification.
- How cybersecurity risks are assessed during planning, development, production, delivery and maintenance.
- How vulnerabilities are recorded, assessed, remedied, communicated and tracked over the support period.
- Which technical documentation, user information, conformity documents and proof of operation must be available.
The responsible support period for each product should be determined early on and clearly communicated to users. According to Article 13, the treatment of vulnerabilities must generally be guaranteed for at least five years, unless the expected useful life is shorter. The specific duration, application and exceptions are part of the legal and product-related examination.
Lifecycle artifact set
- Product and version inventory and role decision;
- Cybersecurity risk assessment;
- SBOM or other component detection;
- Process for vulnerability handling and support period;
- technical documentation and compliance documents.
From requirements to implementation
Cybersecurity risk assessment
Risk: Security requirements remain incomplete
Organisational measure: Establish product, risk and release responsibility
Technical implementation: Integrating threat modelling and risk-based security testing into the lifecycle
Possible evidence: Risk assessment, architecture and release documents
Safe development and delivery
Risk: Vulnerabilities or manipulations find their way into releases
Organisational measure: Define security gates, exceptions and release responsibility
Technical implementation: Protected repositories and pipelines, code and dependency checks
Possible evidence: Pipeline logs, review and release evidence
Vulnerability treatment and updates
Risk: Known gaps remain open
Organisational measure: Operate triage, correction, communication and escalation processes
Technical implementation: Vulnerability management, update distribution and version traceability
Possible evidence: Tickets, advisories, update and patch reports
Technical documentation and compliance
Risk: Evaluation is not comprehensible
Organisational measure: Determine documentation responsibility and nursing process
Technical implementation: Manage product, component and configuration information in a versioned manner
Possible evidence: Technical documentation, EU declaration of conformity, evidence for assessment
Reports by Art. 14
Risk: Actively exploited gaps or serious incidents are reported late
Organisational measure: Determine reporting decisions, contacts and escalation path
Technical implementation: Prepare detection, case creation and structured reporting data
Possible evidence: Time stamps, messages, final reports
An SBOM can support transparency about components and dependencies, but is not an end in itself or an automatic statement of compliance. Offer in-depth knowledge SBOM & Dependency Management and Secure Software Lifecycle / DevSecOps. Signatures can support the integrity and provenance of artifacts; However, the CRA does not require code signing as a stand-alone measure. For the strategy see Code Signing / Artifact Signing.
Working with ADIUMENTO
ADIUMENTO supports product, development and security teams in structuring existing delivery routes, dependencies, vulnerability processes and evidence. This can result in a risk-based lifecycle target picture, prioritised security measures and implementable work packages for development, operation and documentation.
The work continues IT Security & Compliance and IT Security & Compliance to. ADIUMENTO does not provide legal advice, does not carry out binding product classification and does not issue any guarantee of conformity, CE performance or certification.
Typical Results
- delineated inventory of products, versions, components and responsibilities;
- Lifecycle target image for security gates, vulnerability management and updates;
- prioritised roadmap for toolchain, documentation and operations;
- Evidence structure for risk assessments, approvals, updates and reports;
- Working basis for coordination with legal advice, conformity assessment and market surveillance.
Limitations and dependencies
Whether a specific product is within the scope of application, what role a company plays, what support period applies and what conformity assessment procedure is required must be assessed legally and product-related. Technical measures alone do not replace this assessment.
The quality of the evidence depends on complete product information, maintained component and version data, reliable supplier information and an actual operational process. ADIUMENTO does not replace legal advice, a notified body, market surveillance authority or conformity assessment.
Further official sources
- Regulation (EU) 2024/2847 – Cyber Resilience Act – EUR-Lex
- European Commission: Cyber Resilience Act – European Commission
- European Commission: CRA – summary – European Commission
- EU Commission: Guidelines on CRA implementation from July 27, 2026 – European Commission
- EU Commission: CRA Reporting and Single Reporting Platform – European Commission
Orientation
Frequently asked questions
When do manufacturers have to report under Article 14 CRA?
The reporting requirements for actively exploited vulnerabilities and serious security incidents apply from September 11, 2026. The Commission summarizes deadlines of 24 hours for an early warning and 72 hours for a report; The applicable requirements and content should be checked on a case-by-case basis.
Does the CRA already apply in full?
No. The regulation came into force on December 10, 2024. Notification requirements apply from June 11, 2026, Article 14 reporting requirements from September 11, 2026; the remaining main obligations apply from December 11, 2027.
Is code signing mandatory after the CRA?
The CRA does not mention code signing as an express individual obligation. A signature can support the integrity and provenance of artifacts in an appropriate security architecture. Which controls are suitable depends on the risk assessment, the basic requirements and the respective product.
Next sensible step
First, be transparent about product scope, responsibilities, components, support periods, and current vulnerability processes. IT Security & Compliance can technically structure lifecycle and supply chain readiness; it does not replace legal assessment or conformity assessment. The Regulatory hub shows the other topics.