8 Ways to Prepare for the Cyber Resilience Act (CRA)

The following steps turn CRA preparation into a product-specific implementation programme:

1. Map products and determine scope.
2. Confirm your role and product category.
3. Assess cybersecurity risks throughout the lifecycle.
4. Integrate security requirements into development and release.
5. Establish component and dependency visibility.
6. Define vulnerability handling and security support.
7. Prepare reporting and escalation procedures.
8. Organise technical documentation and conformity evidence.

The Cyber Resilience Act (CRA) changes how companies design, release and maintain digital products sold in the European Union. Cybersecurity is no longer only a customer expectation or an internal security objective. For products within scope, it becomes a condition of market access, supported by documented assessments, vulnerability-handling processes and conformity evidence.

For technology companies, the challenge extends beyond fixing vulnerabilities. The organisation needs to understand which products are covered, which responsibilities it holds, how long it must provide security support and how it will respond when exploitation is discovered.

These are the practical questions addressed in PrivaLex’s webinar this week, “The Cyber Resilience Act: What Changes for Your Product.” Its central message is that CRA preparation must connect legal scope, product engineering, security operations and evidence throughout the product lifecycle.

8 Steps to Prepare for the Cyber Resilience Act

1. Map products and determine scope

Start with an inventory of the products the company develops, brands, imports or distributes. Include software applications, hardware, separately marketed components and relevant remote processing functionality.

For each product, record its purpose, intended users, distribution model, connectivity, supported versions and responsible teams. Identify whether it is made available on the EU market and whether a specific exclusion may apply.

The output should be a documented scope decision, not a general statement that “the company is a SaaS provider.” Product boundaries can differ even within the same business.

PrivaLex’s webinar emphasises this starting point because an incorrect scope decision affects every later task, from risk assessment to support planning and conformity assessment.

2. Confirm your role and product category

Determine whether the organisation acts as a manufacturer, importer, distributor or another relevant participant. Then assess the product’s core functionality against the CRA categories.

Category	Illustrative examples	Conformity implications
Default category	Many ordinary applications and connected products not listed as important or critical	Manufacturer self-assessment is generally available.
Important products: Class I	Password managers, operating systems and certain network products	Self-assessment depends on meeting the applicable conditions; otherwise, third-party assessment is required.
Important products: Class II	Firewalls and certain virtualisation products	Third-party assessment is generally required, subject to specific statutory exceptions.
Critical products	Certain secure elements, hardware security modules and smart meter gateways	Stricter assessment requirements apply; relevant certification rules must also be checked.

These examples are not a substitute for examining the legal descriptions of each category. The Commission’s conformity assessment explanation provides an authoritative starting point.

Classification should happen early because it can affect assessment costs, technical preparation and launch schedules.

3. Assess cybersecurity risks throughout the lifecycle

The risk assessment should consider how the product is intended to operate and how it could reasonably be used or misused.

Relevant scenarios may include unauthorised access, compromised updates, exposed interfaces, vulnerable dependencies, data manipulation and disruption of important functions. The assessment should cover the product’s architecture and relevant remote processing components.

Each significant risk should connect to a security requirement, treatment decision, responsible owner and verification activity. A generic company-wide risk register may provide useful context, but it does not replace product-specific analysis.

A consistent cybersecurity risk assessment approach helps teams explain why particular controls were selected and what evidence demonstrates their effectiveness.

Revisit the assessment when architecture, functionality, dependencies or intended use changes materially.

4. Integrate security into development and release

Translate the assessment into requirements that engineering teams can apply during design, development, testing and release.

Depending on the product and identified risks, this may include secure default settings, appropriate authentication, protection of sensitive information, reduced attack surfaces, secure update mechanisms and security-related monitoring.

Release decisions should consider whether known exploitable vulnerabilities remain, whether relevant tests have been completed and whether corrective work has been verified.

Useful implementation records include security requirements, architecture reviews, test results, remediation tickets and release approvals. Together, they show how security decisions influenced the product.

The aim is to make CRA compliance part of the development lifecycle, rather than a documentation exercise performed after the product is ready to launch.

5. Establish component and dependency visibility

Manufacturers need to identify and document product components and vulnerabilities. The CRA includes a requirement for a software bill of materials, or SBOM, in a commonly used, machine-readable format covering at least top-level dependencies.

An SBOM should support operational decisions. Teams need to connect components to product versions, vulnerability information, maintainers and available fixes.

Supplier reviews should also consider security support, vulnerability communications and the consequences of a dependency becoming unsupported.

A component list that cannot identify affected releases during an incident offers limited practical value. Ownership and maintenance matter as much as the initial generation of the file.

The CRA does not impose a general requirement to publish the entire SBOM publicly. Documentation and disclosure arrangements should reflect the applicable obligations.

6. Define vulnerability handling and security support

Create a process for receiving vulnerability reports, investigating findings, prioritising corrective action and delivering security updates.

The process should define a contact point, coordinated disclosure arrangements, remediation responsibilities and communication with affected users. It should also address how the organisation confirms that a fix works.

Support planning needs particular attention. The CRA generally establishes a minimum support period of five years, unless the product’s expected use is shorter. Products reasonably expected to remain in use longer may require longer support.

The company should document the reasoning behind its chosen period and ensure that engineering resources and dependency arrangements can sustain it.

A five-year figure should not become an automatic expiry date for every product. Support commitments must reflect the product’s nature and expected use.

7. Prepare reporting and escalation procedures

Manufacturers need to distinguish routine vulnerability management from events that trigger mandatory reporting.

The principal reporting timelines are:

Reportable event	Early warning	Follow-up notification	Final report
Actively exploited vulnerability	Within 24 hours of awareness	Within 72 hours of awareness	Within 14 days after a corrective measure becomes available
Severe incident affecting product security	Within 24 hours of awareness	Within 72 hours of awareness	Within one month after the follow-up notification

Notifications are submitted through the CRA Single Reporting Platform. The Commission’s reporting requirements explain the process.

Internally, define who assesses reportability, approves submissions, preserves evidence and communicates with users. These responsibilities need backup arrangements for weekends, absences and out-of-hours incidents.

Test the workflow through a realistic simulation. Keep records of the exercise, decisions and corrective actions, using the same discipline needed to demonstrate staff competence during an audit.

8. Organise technical documentation and conformity evidence

The technical documentation should explain the product, its intended purpose, cybersecurity risk assessment, applicable requirements and measures used to demonstrate conformity.

Supporting evidence may include architecture descriptions, component information, test results, vulnerability-handling procedures and the basis for the support period.

The manufacturer must then complete the appropriate conformity assessment route and fulfil the applicable EU declaration of conformity and CE-marking requirements.

Self-assessment does not mean that evidence is optional. It means the manufacturer takes responsibility through an assessment route permitted for that product.

The distinction between a written policy and proof that a control operates is equally important when documenting security controls. Product versions, decisions and evidence should remain traceable as the product changes.

What is the Cyber Resilience Act?

The CRA is an EU regulation establishing cybersecurity requirements for products with digital elements. Its scope includes many hardware and software products whose intended or reasonably foreseeable use involves a direct or indirect connection to a device or network.

The regulation addresses two connected areas:

• The cybersecurity properties of the product, including secure design, configuration and protection against relevant threats.
• The manufacturer’s processes for identifying, handling and resolving vulnerabilities throughout the support period.

This means that a secure release is only part of the obligation. Manufacturers must also be able to maintain the product, deliver security updates, communicate relevant information and demonstrate how their processes operate.

A company outside the EU may also have responsibilities when its products are placed on the EU market. The assessment therefore starts with the product and its distribution model, not simply the location of the business.

Cyber Resilience Act deadlines

CRA obligations apply in stages. Companies should distinguish the reporting requirements that already apply from the broader product requirements coming into effect in 2027.

Date	Milestone	Practical significance
10 December 2024	The CRA entered into force	The transition towards the new product-security requirements began.
11 June 2026	Provisions concerning conformity assessment bodies began applying	The framework for assessing and notifying these bodies became applicable.
11 September 2026	Manufacturer reporting obligations began applying	Companies need procedures for reporting actively exploited vulnerabilities and severe product-security incidents.
11 December 2027	Most remaining CRA requirements begin applying	In-scope products must meet the applicable cybersecurity, documentation and conformity requirements, subject to the regulation’s transitional provisions.

The European Commission’s CRA implementation timetable explains these milestones.

Waiting until December 2027 is therefore not a complete preparation strategy. Reporting readiness is already relevant, while changes to development practices, supplier arrangements and support commitments may require substantial lead time.

Which products and companies are covered?

Manufacturers carry the primary responsibility for product compliance. This can include companies that develop a product themselves or have it developed and market it under their own name or trademark.

Importers and distributors have separate obligations. A company that only buys and uses a product does not automatically become its manufacturer, although it should still assess the security and support arrangements behind important purchases.

Specific exclusions exist for products covered by certain sector-specific rules, including defined medical-device and vehicle legislation. These exclusions should be assessed precisely: a product is not automatically outside the CRA merely because it is used in healthcare or another regulated industry.

SaaS and cloud services need a specific scope assessment

“SaaS” is not, by itself, a reliable answer to whether the CRA applies.

A remote processing solution can fall within scope when its software is developed by the manufacturer, or under its responsibility, and its absence would prevent the product from performing one of its functions. A connected application and its necessary backend may therefore need to be assessed together.

Conversely, not every cloud service used by a business becomes part of a CRA-regulated product. The analysis needs to distinguish product functionality from the organisation’s wider IT environment.

These distinctions follow the definitions and scope provisions in the Cyber Resilience Act legal text.

Open source is not a blanket exemption

Free and open-source software supplied outside a commercial activity is treated differently from commercially supplied products. There are also tailored obligations for qualifying open-source software stewards.

However, incorporating open-source components into a commercial product does not remove the manufacturer’s responsibilities. The company still needs to understand its dependencies, exercise appropriate due diligence and address vulnerabilities affecting the finished product.

Building CRA Product Readiness with PrivaLex

CRA preparation brings together questions that often sit with different teams: legal scope, product architecture, security testing, supplier dependencies, support commitments and regulatory reporting. The challenge is making those decisions consistent and ensuring that responsibilities remain clear as the product evolves.

At PrivaLex, we help technology companies translate these requirements into an implementation programme with defined owners, realistic priorities and evidence that reflects how the product is developed and maintained.

We begin with product scope and role assessment. This includes reviewing the distribution model, product functionality, relevant remote processing, potential exclusions and the company’s position in the supply chain. We then assess the product category and applicable conformity route, identifying decisions that could affect development plans, assessment requirements or market access.

From there, we connect the cybersecurity assessment to a prioritised roadmap. Each action identifies the requirement it addresses, the responsible team, the deadline, the expected outcome and the supporting evidence. A structured risk management framework helps connect identified risks with treatment decisions, ownership and ongoing review. This makes it easier to distinguish genuine product-security gaps from missing documentation or unclear accountability.

Our support can include vulnerability-handling procedures, coordinated disclosure policies, support-period planning and supplier-review criteria. We help teams define how findings are received, prioritised, remediated and verified, and how security updates reach affected users. For third-party components, we review how dependency visibility, maintenance arrangements and supplier communications support the product’s security commitments.

Reporting readiness is another priority. PrivaLex helps establish escalation thresholds, decision roles, notification workflows and evidence-preservation procedures. Through incident simulations, teams can test whether engineering, security, legal and leadership can coordinate within the applicable reporting timelines, including when key individuals are unavailable.

Where ISO 27001, NIS2 or GDPR also apply, we identify shared controls without treating the frameworks as interchangeable. Existing risk management, training and incident processes can support CRA readiness, while product-specific requirements and separate notification duties remain visible. This reduces duplicated work without suggesting that an existing certification automatically demonstrates CRA conformity.

We also help organise technical documentation, connect records to relevant product versions and prepare teams for the applicable assessment process. Where a notified body is required, its independent assessment remains separate from our advisory and implementation support.

The objective is a CRA programme that remains useful beyond the initial assessment: one that supports release decisions, responds to new vulnerabilities and gives the organisation a clear basis for explaining its product-security practices to customers and authorities.

What PrivaLex’s CRA Webinar Will Address

“The Cyber Resilience Act: What Changes for Your Product” focuses on the decisions companies need to make before they can build a credible compliance programme.

The session addresses six central questions:

• Does the CRA apply to your product?
• What belongs within the product boundary?
• Which category and assessment route apply?
• What security and vulnerability-handling requirements must be implemented?
• How will the company demonstrate conformity?
• What happens when a vulnerability is actively exploited?

These questions are relevant to product leaders, engineering teams, security specialists, compliance managers and executives responsible for market access.

The webinar can provide a common starting point across those roles. Afterwards, its lessons should be translated into assigned actions, targeted workshops and a role-based compliance training plan, rather than remaining a one-off awareness session.

How CRA, NIS2, GDPR and ISO 27001 Fit Together

These frameworks can overlap, but they regulate different things.

Framework	Main focus	Relationship with CRA preparation
CRA	Cybersecurity of products with digital elements	Requires product-specific security, vulnerability handling and conformity evidence.
NIS2	Cybersecurity risk management for covered entities	Organisational processes may support CRA implementation, but scope and reporting duties must be assessed separately.
GDPR	Protection of personal data	Product-security measures can support privacy obligations, but CRA compliance does not establish GDPR compliance.
ISO 27001	An information security management system	Provides useful governance and evidence processes, but certification does not replace CRA conformity assessment.

The same principle applies when assessing overlapping NIS2 and DORA obligations: shared processes can reduce duplicated work, but framework-specific responsibilities must remain identifiable.

A product incident may require more than one legal assessment. Teams should coordinate those assessments without assuming that one notification satisfies every regime.

4 Common Mistakes That Weaken CRA Preparation

1. Treating the CRA as a 2027-only project

This overlooks reporting obligations that already apply and underestimates the time needed to change development, support and supplier arrangements. Separate immediate reporting readiness from the remaining implementation roadmap.

2. Assuming an ISO 27001 certificate is enough

Certification can demonstrate a mature management system, but it does not establish conformity for a particular product. Product scope, essential requirements and the applicable assessment route still need attention.

3. Assigning everything to the security team

Engineering, product management, legal, support and leadership all hold information needed for CRA decisions. Security teams cannot independently determine commercial support commitments or resolve every product-classification question.

4. Collecting documents without testing the process

A vulnerability policy is not proof that the company can investigate, escalate, report and remediate an actual event. The same practical approach used when preparing for a cybersecurity compliance audit applies here: test the workflow and retain evidence of what happened.

Conclusion

Cyber Resilience Act compliance begins with a clear understanding of the product: what it does, which components it depends on, how it is maintained and who is responsible when something goes wrong.

The strongest preparation programmes connect those decisions to engineering practices, vulnerability handling, support commitments and traceable evidence. They also recognise that reporting readiness cannot wait for the broader December 2027 deadline.

PrivaLex’s webinar provides an opportunity to clarify these questions and identify the next practical actions. Book a strategic session with PrivaLex to review your product scope, reporting readiness and implementation priorities.

Frequently Asked Questions (FAQs)