EU CRA Compliance Checklist: 5 Steps to Prepare Now
For years, software vendors have been told to build secure products, maintain visibility into their dependencies, patch vulnerabilities, and provide customers with meaningful security information.
The European Union Cyber Resilience Act changes the nature of that advice. For many companies, these practices are becoming legal requirements, with reporting obligations beginning this fall and most requirements going into effect at the end of 2027.
That may sound like plenty of time. It is not.
You can generate an SBOM today, but building a reliable process to identify every affected product, classify its risk, maintain accurate component data, monitor vulnerabilities, coordinate remediation, meet short reporting windows, and produce defensible compliance evidence is a much larger project.
The organizations that treat the CRA as a document-production exercise will probably spend 2027 scrambling. The organizations that treat it as an opportunity to make product security repeatable have a much better chance of being ready.
To help you prepare to achieve compliance and maintain it, we’ve put together this guide of everything you need to know.
Identify and remediate new risks and vulnerabilities as they emerge with Anchore Enterprise.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act, formally Regulation (EU) 2024/2847, establishes horizontal cybersecurity requirements for products with digital elements sold or otherwise made available in the European Union.
The regulation is intended to improve product security in two major ways:
- Products must be designed, developed, and produced with an appropriate level of cybersecurity.
- Manufacturers must continue managing vulnerabilities throughout the product’s support period.
This lifecycle perspective here is key. The CRA does not treat security as something manufacturers address only before launch. They must assess cybersecurity risks during development, provide security updates, manage vulnerabilities throughout the product’s support period, maintain technical documentation, and report certain actively exploited vulnerabilities and severe security incidents.
In other words, manufacturers need to remain responsible for the security of covered products after they reach the market. Shipping the product is only the beginning.
Who and What Needs to Comply With the CRA?
The CRA applies primarily to manufacturers of products with digital elements made available on the EU market. It also creates obligations for other economic operators, including importers and distributors.
A manufacturer does not have to be headquartered in the European Union to fall within scope. A US, Canadian, Japanese, or other non-EU company can be affected if it places covered products on the EU market.
What is a product with digital elements?
A product with digital elements is broadly defined as a software or hardware product, including its remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
The definition can cover standalone software, embedded software, connected hardware, and components made available separately.
Which economic operators have obligations?
- Manufacturers carry most of the CRA compliance burden. Among other responsibilities, they must conduct cybersecurity risk assessments, satisfy essential cybersecurity requirements, manage vulnerabilities, prepare technical documentation, complete the applicable conformity-assessment procedure, and issue an EU declaration of conformity.
- Importers must verify that manufacturers have completed required conformity-assessment activities and documentation before placing products on the EU market.
- Distributors must act with due care and verify required elements such as CE marking and accompanying documentation before making products available.
These supply-chain responsibilities mean a manufacturer’s CRA readiness will affect more than its internal security team. Importers, distributors, resellers, customers, and business partners may all begin asking for evidence that covered products comply.
What is excluded?
The CRA contains exclusions or special treatment for certain categories already covered by sector-specific requirements, including…
- Medical devices and in vitro diagnostic medical devices
- Motor vehicles and related components
- Civil aviation products
- Marine equipment
Free and open source software developed or supplied outside the course of a commercial activity is also generally excluded. However, that exclusion does not mean companies can ignore open source dependencies; a commercial product containing open source software may still fall squarely within the CRA. The CRA’s open source exception is about how the software is developed and supplied, not a magical property acquired by publishing code on GitHub.
EU CRA Dates and Deadlines to Know
The CRA rolls out in stages rather than becoming applicable all at once. Here are the key dates both past and future:
- Dec. 10, 2024: The Cyber Resilience Act entered into force.
- Jun. 11, 2026: Provisions concerning the notification of conformity-assessment bodies began to apply.
- Sept. 11, 2026: Manufacturers’ vulnerability and incident-reporting obligations begin.
- Dec. 11, 2027: Most CRA requirements become fully applicable, including conformity assessment and CE-marking requirements for covered products.
The September 2026 deadline matters because it arrives well before the CRA fully applies. Beginning September 11, manufacturers must report actively exploited vulnerabilities and severe incidents, with an early warning generally due within 24 hours and a fuller notification within 72.
Meeting that timeline requires teams to quickly determine which products are affected, whether exploitation is actually occurring, who needs to respond, and what information must be reported. If you cannot map a vulnerable component to the products that contain it, the 24-hour clock will expose that gap fast.
The December 2027 deadline creates a different kind of pressure. Conformity assessment depends on security processes, technical documentation, and evidence collected over time. Trying to reconstruct all of that at the last minute is a bad plan.
CRA Product Risk Classifications
The CRA does not apply the same conformity-assessment process to every product. Products are divided into four broad groups:
- Default products
- Important products, Class I
- Important products, Class II
- Critical products
A product’s classification affects how the manufacturer can demonstrate conformity.
Default products
Most products with digital elements fall into the default category.
Manufacturers of default products can generally use an internal-control procedure, assessing conformity under their own responsibility.
“Self-assessment” should not be confused with “no assessment.” Manufacturers still need to satisfy the CRA requirements, document what they have done, issue a declaration of conformity, and support the CE marking applied to the product.
Important products: Class I
Class I includes categories of products with security-related functionality or elevated cybersecurity relevance.
Examples listed in the CRA include:
- Password managers
- Virtual private networks
- Network-management systems
- Routers and modems intended for internet connectivity
See the CRA’s full list of Important Class I products in Annex III.
Depending on the standards and assessment route used, Class I products may require involvement from a third-party conformity-assessment body.
Important products: Class II
Class II includes products that generally carry greater cybersecurity risk, such as:
- Hypervisors and container runtime systems
- Firewalls, intrusion-detection systems, and intrusion-prevention systems
- Tamper-resistant microprocessors and microcontrollers
Class II products are subject to more stringent third-party conformity-assessment requirements.
Critical products
Lastly, the CRA establishes a category for critical products with digital elements. These products may be subject to European cybersecurity certification requirements specified through delegated acts.
Classification therefore needs to happen early. It influences the standards, documentation, testing, review, and external assessment a manufacturer may need before placing a product on the market.
Key CRA Compliance Requirements
At a high level, the CRA expects manufacturers to do three things: build products securely, continue managing their security after release, and maintain the documentation needed to show that both are happening.
1. Build Products With Security in Mind
Covered products must be designed, developed, and produced based on an appropriate cybersecurity risk assessment. That includes reducing attack surfaces, protecting against unauthorized access, safeguarding data, and making secure configurations the default rather than an optional setting users have to find themselves.
The CRA also expects manufacturers to address known exploitable vulnerabilities before products reach the market. Security cannot be bolted on at the end of development or treated as a final pre-release scan. It needs to shape architecture, dependency choices, testing, and release decisions from the start.
2. Manage Vulnerabilities Throughout the Support Period
CRA obligations continue after a product is released. Manufacturers must monitor for vulnerabilities, investigate whether products are affected, provide security updates, communicate fixes, and maintain a process for coordinated vulnerability disclosure.
They must also be prepared to report certain actively exploited vulnerabilities and severe incidents within the required timelines. That makes vulnerability handling an ongoing product responsibility, not a task teams revisit only when a major CVE appears.
3. Maintain an SBOM and Supporting Documentation
Manufacturers must identify and document the components in covered products, including through a machine-readable SBOM covering at least top-level dependencies.
The SBOM supports more than compliance documentation. It helps teams determine which products contain a vulnerable component, track affected versions, support remediation decisions, and respond more quickly when reporting obligations apply.
It should sit alongside the broader technical evidence required for conformity assessment, including cybersecurity risk assessments, testing records, vulnerability-handling processes, and remediation history.
How to Prepare for the CRA: Your 5-Step Compliance Checklist
No single team can “own” the entirety of CRA compliance. Legal can interpret obligations, but it cannot inventory software dependencies. Engineering can remediate vulnerabilities, but it may not determine reporting thresholds. Security can scan products, but it cannot unilaterally define the support period promised to customers.
A workable compliance program connects these responsibilities.
1. Identify and classify covered products
Start by determining which products your organization makes available in the EU and whether they fall within the CRA’s scope. For each covered product, confirm the responsible legal entity, intended use, supported versions, expected lifetime, and whether an exclusion may apply.
Then classify each product as default, Important Class I, Important Class II, or critical. Document the rationale, applicable standards, expected conformity-assessment path, and whether third-party review may be required.
Remember to classify products based on what they do… not what marketing calls them. A general application with access controls is not automatically an identity-management system, while a product labeled a “platform” may still fall into a regulated security category.
Manufacturers that may need third-party assessment should begin planning early, before demand for assessors increases.
Pro tip: Add CRA scope and classification review to product intake and release planning. It is much easier to resolve these questions before a product is architected, launched, and already in customers’ hands.
2. Build CRA requirements into product development
Once you know which products are covered, translate the CRA’s requirements into the way those products are actually designed, built, tested, released, and maintained.
That includes establishing processes for:
- Cybersecurity risk assessment and threat modeling
- Secure architecture and default configurations
- Dependency, source-code, and artifact scanning
- Security testing and release gates
- Security updates and support-period planning
The goal is not to create a separate CRA workflow that teams use only when someone asks for evidence. Required controls should live inside the development systems and release processes teams already use.
Automate repeatable checks where possible, document exceptions when they occur, and update risk assessments when a product’s architecture, dependencies, deployment model, or intended use changes.
Pro tip: Convert repeatable requirements into policy-as-code controls. Automated release checks create more consistent outcomes—and better evidence—than asking teams to remember another compliance checklist.
3. Generate and maintain SBOMs for covered products
Create a repeatable process for generating accurate, standards-based SBOMs for covered products and supported versions.
Define…
- Which products and build artifacts require an SBOM
- When SBOMs are generated
- Which formats are used
- How each SBOM maps to a product and version
- How SBOM accuracy is validated and maintained
Generate SBOMs as close as possible to the final build artifact. Repository scans can be useful during development, but the released artifact is ultimately what reaches customers.
Different sources—including container images, binaries, packages, and filesystems—may reveal different parts of the software composition. Your process should reflect how each product is actually built and delivered.
Pro tip: Use Anchore’s open source tool, Syft, to generate an SBOM from container images, filesystems, and other software artifacts. As your process scales, Anchore Enterprise can centralize SBOM management, continuously monitor components for new vulnerabilities, and preserve the historical records needed to support CRA compliance.
4. Operationalize vulnerability monitoring, triage, and reporting
Build a repeatable CRA vulnerability management process around the product inventory and SBOM data. The process should allow your organization to:
- Monitor product components for newly disclosed vulnerabilities
- Identify affected products and assess exploitability
- Prioritize and track remediation
- Create, test, and communicate security updates
- Escalate and report qualifying vulnerabilities and incidents within CRA deadlines
Raw vulnerability counts are not enough. A scanner may report hundreds or thousands of CVEs, but some will be unreachable, incorrectly matched, mitigated, or irrelevant to the deployed product. Others will require immediate attention.
Teams need a consistent way to evaluate severity alongside exploitation activity, CISA KEV status, fix availability, product context, and VEX information.
A product security incident response team, or PSIRT, can coordinate decisions across engineering, security, legal, and customer-facing teams. It should also define the CRA reporting path before the first urgent case occurs.
Do not make your first attempt at the 24-hour reporting workflow during an active incident.
Pro tip: Run a tabletop exercise using an actively exploited vulnerability in a common open source dependency. Open source tools like Grype can help identify the vulnerability in affected artifacts, while Anchore Enterprise can map it across products, add exploitability and remediation context, and preserve the evidence needed for CRA reporting.
5. Assemble technical documentation and preserve compliance evidence
Finally, establish a system for collecting and retaining the evidence required to support conformity assessment. Depending on the product and assessment route, that may include cybersecurity risk assessments, architecture and design records, SBOMs, vulnerability-handling policies, security-testing results, remediation history, support and update policies, applicable standards, and the EU declaration of conformity.
The key word is evidence. A policy tells an assessor what should happen; your records show what actually happened.
If every release is supposed to receive an SBOM, preserve the SBOMs. If critical vulnerabilities are supposed to block a release, preserve the results and any approved exceptions. If a vulnerability is classified as not exploitable, preserve the analysis behind that decision.
Link this evidence to the correct product and version. A folder full of unrelated scan reports may technically count as documentation, but it will not make conformity assessment any easier.
Pro tip: Treat compliance evidence as a byproduct of your software-delivery process. Automatically retain SBOMs, scan results, policy evaluations, VEX records, and remediation history instead of asking teams to reconstruct them before an assessment.
Achieve and Maintain EU CRA Compliance With Anchore
Anchore helps teams turn CRA requirements into repeatable software supply chain security practices. Anchore Enterprise provides centralized SBOM generation and management, continuous vulnerability monitoring, contextual risk analysis, VEX support, policy enforcement, and historical records across products and versions. This gives engineering, security, and PSIRT teams a shared view of what is in each product, which vulnerabilities matter, and how those issues were handled.
By connecting software inventories, vulnerability data, policy results, and remediation history in one place, Anchore Enterprise can help organizations maintain accurate component records, prioritize the risks that matter most, preserve evidence for conformity assessment, and respond more quickly when CRA reporting deadlines apply.
EU CRA Compliance FAQs
Is an SBOM mandatory under the CRA?
Yes. Manufacturers must create an SBOM for covered products in a commonly used, machine-readable format, including at least the product’s top-level dependencies.
What are the penalties for CRA non-compliance?
Violations of the CRA’s essential cybersecurity requirements can result in administrative fines of up to €15 million or 2.5% of the company’s total worldwide annual turnover for the preceding financial year, whichever is higher.
Other violations can carry different maximum penalties. Market-surveillance authorities may also restrict or prohibit a product, require corrective action, or order its withdrawal or recall.
The practical consequence of non-compliance may therefore extend beyond a fine. A manufacturer could lose the ability to sell an affected product in the EU.
How does the CRA compare with NIS2, DORA, and ISO 27001?
The CRA focuses on the security of products with digital elements, while NIS2 and DORA focus more broadly on organizational cybersecurity and operational resilience. ISO 27001 is a voluntary information security management standard, not an EU regulation.
These frameworks can overlap in areas such as vulnerability management, incident response, risk assessment, governance, and supply-chain security. Compliance with one does not automatically establish compliance with another, but mature processes and shared evidence can reduce duplicated work.
What tools can help manage EU CRA compliance?
Useful CRA compliance tools can include:
- SBOM generation and management tools
- Software composition analysis tools
- Vulnerability scanners
- VEX creation and management tools
- Policy-as-code engines
- CI/CD security controls
- Governance, risk, and compliance platforms
- Incident-response and case-management systems
- Product and asset-inventory systems
Anchore Enterprise combines SBOM management, continuous vulnerability scanning, contextual risk analysis, policy enforcement, VEX, and historical product-security records. This helps engineering, security, and PSIRT teams work from a shared source of software supply-chain data instead of attempting to reconcile several incomplete inventories during an urgent vulnerability investigation.
