01
Discovery and scope
identify the product, versions, business role, markets and available evidence. Agree assessment boundaries and access rules.
Cyber Resilience Act
CRA: assess and implement
Developing software or devices for the EU market? We help establish the scope of the Cyber Resilience Act, identify gaps and plan changes. Implementation of safeguards, vulnerability handling and product documentation is agreed as a separate scope.
Trusted by
Companies and institutions that need stable IT.
Does CRA apply to your product?
The Cyber Resilience Act, Regulation (EU) 2024/2847, concerns products with digital elements made available on the EU market in the course of commercial activity. It covers hardware and software whose foreseeable use involves a direct or indirect connection to a device or network. We start with your product, distribution model and role as manufacturer, importer or distributor. Small businesses are not automatically exempt. The manufacturer is responsible for product security and vulnerability handling. Importers verify the manufacturer’s conformity assessment and documentation; distributors check CE marking and required information and act on identified non-conformity.
CRA assessment: what we review
You receive a requirements and gap map, evidence from the review and an action plan. We agree technical testing and access to source code before starting.
Scope and product classification
We examine functions, cloud dependencies, components and your role. We check exclusions and important or critical product categories that affect the conformity assessment route.Risks and safeguards
We review the risk assessment, default settings, authentication, data protection and update mechanisms. Agreed tests address Annex I requirements.Vulnerabilities and components
We check the software bill of materials (SBOM), external dependencies, vulnerability reports, fixes and support period. We review responsibility throughout the product lifecycle.Documentation and evidence
We review technical documentation, instructions and test records. The report separates verified findings, gaps and areas we could not verify.CRA implementation: how we can help
You choose the next steps after the assessment. We can use our report or review an existing assessment. Changes to the product itself require its owner and development team to participate.
Secure development and updates
We organise security requirements, change reviews and testing. We help plan remediation and secure update delivery with agreed acceptance criteria.Vulnerability handling and reporting
We establish reporting channels, responsibilities and response rules. We practise event classification, escalation and collecting information for reporting through the ENISA platform.Product documentation
We help prepare risk assessments, component records, support policies and technical documentation. We link requirements to evidence of implementation.Remediation checks
We recheck safeguards and processes within the agreed scope. You receive results, remaining risks and ongoing tasks for the product team.Cooperation process
You can commission an assessment on its own or a separately agreed implementation scope. Cost and timing depend on product numbers, architecture, documentation and testing.
02
Assessment and priorities
review documentation, speak with the team and perform agreed checks. Deliver a gap report and work plan.
03
Implementation
after agreeing a separate scope, prepare processes and documentation and support the team with technical changes.
04
Verification and maintenance
check remediation, identify remaining risks and agree reviews, updates and support responsibilities.
Practical scope
CRA dates and event reporting
Information reviewed on 24 September 2026. The Regulation entered into force on 10 December 2024; different obligations apply from different dates.
Article 14 manufacturer reporting duties for actively exploited vulnerabilities and severe incidents affecting product security already apply. They also cover products placed on the market before 11 December 2027.
after becoming aware, manufacturers submit an early warning and a further notification. The final vulnerability report is due within 14 days of a corrective or mitigating measure becoming available; the severe incident report within one month of the 72-hour notification.
most CRA requirements become applicable. Products placed on the market earlier generally become subject to them following a substantial modification from that date; reporting follows a separate rule.
generally at least five years, unless expected use is shorter. The period must be justified against the product type, intended use and user expectations.
Assessments, standards and conformity
A gap assessment and implementation support prepare your product and evidence. They do not replace the required conformity assessment procedure, EU declaration of conformity or CE marking. The route depends on the product category and specifications used; certain cases require a notified body. We do not present Virtline as a notified body. CRA requirements, including Annex I, are the starting point. We select standards and specifications against product risks, rather than an industry label alone. CEN, CENELEC and ETSI work under request M/606 includes horizontal and product-specific standards. A draft or publication of a standard alone does not automatically establish a presumption of CRA conformity. Before relying on a standard, we check its version, scope and publication of its reference in the Official Journal of the EU. The presumption covers only the requirements addressed by that standard.
Legislation, guidance and standardisation
Official sources for checking scope and dates. Guidance explains the rules but does not replace the Regulation. Standards are checked for the specific product.
Questions about CRA
How does CRA differ from NIS2?
+
CRA addresses the cybersecurity of products with digital elements and obligations across their lifecycle. NIS2 addresses the security of organisations within its scope. A business may be subject to both. A NIS2 assessment or ISO 27001 certificate alone does not establish product conformity with CRA.
Does CRA cover SaaS and open source?
+
Not every cloud service falls within CRA. Remote data processing may be covered where it meets the definition of a solution needed for a product to perform a function. Free and open-source software supplied outside commercial activity is excluded, but separate rules apply to open-source software stewards. Free access alone does not establish an exemption. We review the specific delivery model.
Does CRA apply to every device?
+
No. Exclusions include products covered by medical device rules, certain automotive rules, aviation certification or marine equipment legislation. Products exclusively for defence or national security are treated separately. The relevant legal basis and intended use must be checked before relying on an exclusion.
Does the assessment provide a CRA certificate and CE marking?
+
No. You receive a report covering the agreed review and an action plan. Implementation, retesting and documentation support are agreed separately. The manufacturer remains responsible for the applicable conformity assessment, EU declaration and CE marking; notified body involvement depends on the product category and route.
Discuss your product and the work required
Tell us what software or device you develop or distribute, your markets and whether you need an assessment, implementation or a reporting readiness review. A product description is enough to start.
Discuss CRA assessment or implementation