10 Things to Do for Cyber Resilience Act Compliance

The EU Cyber Resilience Act introduces mandatory cybersecurity requirements for any product with digital elements sold in the EU — hardware devices with software components, standalone software, and apps. The regulation places obligations not only on manufacturers but on importers and distributors as well.

Vulnerability reporting obligations begin in September 2026. Full enforcement starts December 2027. The timeline is shorter than it appears — conformity assessments and technical documentation need to be in place before products can legally carry CE marking. Here is what you need to do.

1. Determine your product classification

The CRA establishes three classification tiers, and your classification determines your conformity assessment route.

Default products cover most software and hardware. A self-assessment against the CRA's requirements is sufficient.

Class I (important) products are those where a cybersecurity failure would have a significant impact. Examples include password managers, VPNs, network monitoring tools, identity management systems, remote access tools, browsers, and operating systems for industrial use. Class I allows either a standards-based self-assessment using harmonised standards or a third-party assessment.

Class II (critical) products are those in the most sensitive categories: operating systems, hypervisors, firewalls, intrusion detection systems, hardware security modules, microprocessors, and industrial control systems. Class II requires a mandatory third-party assessment by a notified body.

Get the classification right before doing anything else — it determines the entire compliance pathway.

2. Create a Software Bill of Materials

The CRA requires manufacturers to identify and document all components of their product, including all open-source software, third-party libraries, and dependencies. This is your Software Bill of Materials (SBOM).

The SBOM must be kept current throughout the product's supported lifetime. It is the basis for your vulnerability management: you cannot track and remediate vulnerabilities in components you haven't identified. Standard SBOM formats (SPDX, CycloneDX) are widely used and supported by tooling.

3. Write and publish a vulnerability disclosure policy

Before your product ships, you must have a publicly accessible vulnerability disclosure policy. The policy must explain:

• How security researchers and users can report vulnerabilities to you
• What information you need in a vulnerability report
• What your process is for triaging, investigating, and responding to reports
• What your response timelines are

This policy must be accessible before the product is placed on the market. If you don't have one, draft it now. Coordinate your Contact for Vulnerability Disclosure registration through ENISA once the relevant systems are in place.

4. Build a patch management process

The CRA requires that security updates are made available for the entirety of the product's expected lifetime. You must also define and communicate what that supported lifetime is.

This creates two distinct obligations: the internal process for producing security patches in a timely manner, and the customer-facing commitment that defines how long support will continue. Both must be documented. Customers need to know when support ends; your development and security teams need to know how to produce and deliver patches when vulnerabilities are found.

5. Set up ENISA reporting capability

Actively exploited vulnerabilities and previously unknown security issues must be reported to ENISA (the EU Agency for Cybersecurity) within tight timeframes:

• Early warning: within 24 hours of becoming aware of an actively exploited vulnerability
• Vulnerability notification: within 72 hours — with an initial assessment of severity and impact

This is faster than GDPR breach notification (72 hours to DPA). The 24-hour early warning window in particular requires that your team can identify an actively exploited vulnerability, make the determination that it is "actively exploited," and trigger the notification process — all within a day.

Build the internal detection, triage, and reporting process now. Assign roles. Test the workflow.

6. Conduct your conformity assessment

Once your security measures are in place, you must conduct the appropriate conformity assessment based on your product classification:

• Default: self-assessment against the CRA's essential requirements. Document the methodology and findings.
• Class I: standards-based self-assessment against harmonised CEN/CENELEC standards, or third-party assessment by a notified body.
• Class II: mandatory third-party assessment by a notified body.

The conformity assessment must be completed and documented before you CE-mark the product. For Class II products, engage a notified body early — capacity is limited and timelines are long.

7. Prepare your technical documentation

Before CE marking, you must compile a technical documentation file for each product. The technical documentation must include:

• General description of the product and its intended purpose
• Design and development documentation, including architecture diagrams
• Threat modelling and risk assessment methodology
• Security testing results (penetration testing, vulnerability scanning, static analysis)
• Known vulnerabilities in the product and their mitigations
• Conformity assessment documentation
• SBOM

This file must be maintained and updated throughout the product's lifetime. Regulators and market surveillance authorities can request it. It is not a one-time document — when the product is updated, the technical documentation must be updated to reflect the changes.

8. Implement secure by default configuration

Products covered by the CRA must ship with security settings enabled. This means:

• Default configurations must be secure — not permissive settings left to users to harden
• Where authentication is required, default passwords must either be unique per device or absent (requiring the user to set a password before use). Universal default passwords that are the same across all units of a product are prohibited.
• Attack surfaces must be minimised in the default configuration

Review your product's default configuration against this requirement. Many products historically shipped with permissive defaults for ease of setup. The CRA requires the opposite approach.

9. Establish post-market monitoring

CRA obligations don't end when the product ships. You must monitor your deployed product base for vulnerabilities, security issues, and changes in the threat landscape throughout the product's supported lifetime.

This means: tracking CVEs and security advisories for all components in your SBOM, monitoring for new vulnerabilities in your own codebase, maintaining a process for receiving and triaging vulnerability reports from external sources, and producing and deploying security patches when vulnerabilities are confirmed.

Post-market monitoring is an ongoing operational capability, not a periodic review.

10. Affix the CE marking correctly

CRA compliance is a prerequisite for CE marking of products with digital elements sold in the EU. You cannot CE-mark a product that hasn't completed the required conformity assessment and technical documentation.

Premature CE marking — marking a product before the requirements are met — exposes you to market withdrawal and fines. Incorrect CE marking, or CE marking maintained after a product falls out of compliance, carries the same risks.

The CE mark certifies conformity with all applicable EU legislation, not just the CRA. Ensure that other applicable directives and regulations (Radio Equipment Directive, Machinery Regulation, GDPR as applicable) have also been addressed.

Vulnerability reporting obligations start September 2026. Full enforcement: December 2027.

If you are building software products for the EU market, compliance needs to be designed in — not retrofitted at launch.

Knowing the 10 steps and having them documented, monitored, and auditable are two different things.

This article is for informational purposes only and does not constitute legal advice. For legal advice specific to your situation, consult a qualified attorney licensed in your jurisdiction.