Cyber Resilience Act (CRA) compliance checklist

Key takeaways

• The Cyber Resilience Act specifies mandatory cybersecurity requirements for any manufacturer placing software or digital products on the EU market, including non-EU organizations.
• CRA compliance requires embedding secure-by-design principles, continuous vulnerability management, structured disclosure processes, and software bill of materials (SBOM) transparency across the entire product lifecycle.
• Organizations must maintain documented risk assessments, conformity assessment records, and evidence of remediation to demonstrate compliance and support CE marking obligations.
• Strict reporting timelines – including 24-hour early warning and 72-hour notification requirements for actively exploited vulnerabilities – significantly raise operational expectations.
• Invicti’s unified application security platform supports CRA readiness by providing continuous, validated vulnerability detection, SBOM-aligned component visibility, and centralized posture reporting across applications and APIs.

What is the Cyber Resilience Act?

The Cyber Resilience Act (CRA) is an EU regulation that establishes mandatory cybersecurity requirements for products with digital elements placed on the EU market. It requires manufacturers to design, develop, and maintain secure products throughout their expected lifetime. The CRA forms part of a broader shift in EU cybersecurity regulation, alongside frameworks such as the Digital Operational Resilience Act (DORA).

The CRA is a product regulation, not a general services law. It applies to software and connected devices that can directly or indirectly connect to a network, including embedded systems, firmware-driven products, and certain remote data processing solutions that are necessary for a product to function.

In practical terms, the CRA introduces legally enforceable obligations covering secure-by-design development, vulnerability management, incident reporting, technical documentation, conformity assessment, and CE marking.

Note that this article is intended as a handy starting point and reference but is not exhaustive and does not constitute legal advice – always refer to the official CRA documents for binding guidance.

Who must comply with the Cyber Resilience Act?

Any manufacturer that places a product with digital elements on the EU market must comply with the CRA, regardless of where that organization is headquartered.

Under the regulation, a “manufacturer” is any legal or natural person that develops or has a product developed and places it on the EU market under its name or trademark, whether sold for payment or provided free of charge as part of commercial activity. This means non-EU organizations selling software or digital products into the EU are also within scope.

CRA scope clarifications

Because the CRA is a product law, applicability depends on how a digital offering is structured:

• Pure SaaS services that do not form part of a product with digital elements are generally outside scope.
• Remote data processing developed as part of a product’s functionality may fall within scope.
• Non-commercial open-source projects that are not placed on the market as part of commercial activity are generally not considered manufacturers. The CRA also introduces the concept of an “open-source steward” for certain nonprofit entities that support OSS projects without commercializing them.
• Certain products are excluded where other EU regulations apply, including medical devices, motor vehicles, civil aviation, marine equipment, and products developed exclusively for national security or defense purposes.

Organizations should evaluate each product individually to determine whether it falls within scope and how it is classified under the CRA’s product tiering framework.

When does the Cyber Resilience Act take effect?

CRA requirements apply after a transition period, giving organizations limited time to adapt development and security practices.

The regulation entered into force on 10 December 2024. Reporting obligations related to actively exploited vulnerabilities and incidents apply from 11 September 2026. The main cybersecurity and conformity assessment obligations apply from 11 December 2027.

In addition, frameworks for notifying conformity assessment bodies apply from mid-2026, and Member States are expected to designate sufficient notified bodies by December 2026 to support assessments of important and critical products.

Failure to comply with essential requirements or reporting obligations may result in administrative fines. Depending on the nature of the infringement, these could be up to €15 million or 2.5% of global annual turnover, whichever is higher.

While the final date may still seem distant, CRA compliance requires long-term structural changes to development workflows, vulnerability handling processes, documentation practices, and product certification planning.

What is a Cyber Resilience Act compliance checklist?

A CRA checklist provides a structured way to translate the EU Cyber Resilience Act’s legal requirements into concrete security, development, documentation, and conformity assessment controls.

Rather than treating compliance as a documentation exercise, a well-designed checklist helps organizations embed cybersecurity throughout the product lifecycle – from design and release to ongoing maintenance and end-of-life – while also preparing for CE marking and potential third-party conformity assessments.

Why is CRA compliance challenging for software organizations?

CRA shifts cybersecurity from best practice to legal obligation and requires continuous security processes, not one-time assessments.

The regulation introduces enforceable requirements around:

• Secure-by-design and secure-by-default principles
• Ongoing vulnerability management across a product’s expected lifetime
• Structured vulnerability disclosure and coordinated handling
• Mandatory incident and vulnerability reporting within defined timelines
• SBOM generation and maintenance in a commonly used, machine-readable format
• Conformity assessment and CE marking obligations
• Evidence-backed risk assessments and technical documentation

This lifecycle responsibility is a significant shift. Compliance cannot be achieved through a single audit or penetration test but requires operationalized security practices that generate defensible evidence on demand.

What are the core cybersecurity requirements of the Cyber Resilience Act?

CRA mandates secure development, vulnerability handling, ongoing risk management, and formal conformity assessment.

At a high level, manufacturers must:

• Design and develop products with appropriate cybersecurity measures
• Identify, document, and manage vulnerabilities throughout the product lifecycle
• Draw up and maintain a software bill of materials (SBOM)
• Provide security updates and patches in a timely manner
• Establish a vulnerability disclosure and handling process
• Conduct and maintain technical documentation and risk assessments
• Complete applicable conformity assessment procedures before affixing the CE marking

Products are categorized into tiers – default, important (Class I and II), and critical – with increasing conformity assessment obligations. Most products fall under a default category and may be self-assessed, while important and critical products require the involvement of a notified body.

Cyber Resilience Act compliance checklist

The following checklist translates CRA obligations into practical security domains that organizations can evaluate and implement.

Product design and development

Secure-by-design and secure-by-default principles must be embedded early in product planning and architecture decisions:

• Documented security requirements for new products and major updates
• Threat modeling for software products and core APIs
• Minimization of exposed services, ports, and unnecessary functionality
• Secure configuration defaults
• Clear product risk classification under CRA tiering

Reducing attack surface at design time supports both Annex I essential requirements and conformity assessment preparation.

Application and product vulnerability management

Continuous identification, validation, and remediation of vulnerabilities is central to CRA compliance:

• Ongoing vulnerability identification for applications, APIs, and components
• Runtime testing of deployed applications to detect exploitable flaws
• Risk-based prioritization aligned with product impact
• Defined remediation timelines and ownership
• Tracking of vulnerabilities through verified resolution

CRA also requires manufacturers to report actively exploited vulnerabilities within strict deadlines: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, followed by a more detailed notification within 72 hours.

Secure software development lifecycle (SSDLC)

Security must be integrated into CI/CD and release processes:

• Security testing embedded in CI/CD pipelines
• Regular reassessment of updates and patches
• Automated testing of web applications and APIs prior to release
• Change management and version control processes
• Evidence retention to support audits and conformity assessment

Continuous testing helps prevent regressions that could affect CE-marked product security.

Vulnerability disclosure and handling

The CRA requires a documented vulnerability handling process:

• Public vulnerability disclosure policy
• Coordinated handling and triage procedures
• Defined remediation workflows
• Processes to communicate fixes and mitigations
• Reporting mechanisms aligned with 24-hour and 72-hour obligations

These processes must be documented and auditable.

Monitoring, detection, and incident response

Manufacturers must detect and respond to incidents affecting their products, which requires:

• Monitoring capabilities to detect exploitation
• Product-focused incident response plans
• Escalation paths and reporting workflows
• Post-incident review and corrective actions

Operational readiness is essential given the non-negotiable reporting deadlines.

Documentation, SBOM, and audit readiness

CRA compliance depends on the ability to produce evidence and technical documentation. Organizations should maintain:

• Product-level risk assessments
• Technical documentation supporting conformity assessment
• A current SBOM in a commonly used, machine-readable format
• Records of security testing and remediation
• Logs of vulnerability disclosures and regulatory notifications
• Documentation supporting CE marking decisions

Centralized posture visibility and automated evidence generation can help organizations simplify compliance reporting and reduce manual documentation overhead.

Supply-chain and third-party risk

Modern software products rely heavily on third-party components and open-source libraries. To secure the software supply chain, CRA compliance requires:

• Inventory and tracking of third-party components
• SBOM alignment with dependency tracking
• Assessment of inherited vulnerabilities
• Monitoring for newly disclosed component vulnerabilities
• Defined patch and update processes

Supply-chain risk management must integrate with application and API security visibility to maintain lifecycle compliance.

How does application security testing support CRA compliance?

CRA requires ongoing identification and remediation of vulnerabilities throughout a product’s expected lifetime, which makes application security testing a foundational control. A continuous testing process provides:

• Ongoing visibility into exposed attack surface
• Detection of vulnerabilities introduced through updates
• Validation of remediation effectiveness
• Evidence of due diligence for conformity assessment and regulatory reporting

While CRA applies broadly to hardware, firmware, and embedded systems, organizations developing web applications, APIs, and software-driven products must ensure runtime security visibility across those digital components.

For more background on regulatory alignment in the context of application security testing, see how DAST supports compliance across standards such as PCI DSS, ISO 27001, HIPAA, and SOC 2.

How Invicti helps organizations meet Cyber Resilience Act requirements

Invicti’s application security platform supports CRA compliance by enabling continuous, validated vulnerability management and posture-level visibility across applications and APIs.

As a unified application security platform, Invicti combines built-in dynamic testing, API security, proof-based validation, component visibility, and posture management with any connected external scanners to create a single, integrated environment. This enables organizations to manage CRA-related security obligations holistically rather than relying on disconnected point tools.

Proof-based vulnerability detection

Invicti’s proof-based scanning technology automatically confirms exploitable vulnerabilities wherever possible, helping teams prioritize demonstrably real risk and support defensible reporting decisions. This runtime approach complements other scanners and security signal sources integrated into the Invicti platform and brings their findings into sharper focus.

Continuous application and API security testing

Invicti delivers automated dynamic testing for web applications and APIs throughout development and production environments.

• Continuous discovery and scanning
• CI/CD integration
• Automated remediation validation
• Integrated API discovery

Posture visibility and reporting

Invicti centralizes findings across tools and environments, supporting:

• Consolidated product-level risk reporting
• Evidence collection for audits and conformity assessment
• Prioritized remediation workflows
• Executive-level security posture visibility

Learn more about Invicti’s broader application security compliance support across regulatory frameworks.

Final thoughts: Building durable CRA readiness

The Cyber Resilience Act represents a structural shift in EU product cybersecurity regulation. CRA compliance is an ongoing lifecycle obligation tied to product classification, conformity assessment, CE marking, and enforceable reporting timelines.

Organizations that embed continuous vulnerability management, SBOM visibility, runtime testing, and centralized posture reporting into their development processes will be better prepared for regulatory scrutiny and operational risk.

To see how continuous, validated application security testing and posture management on the Invicti platform can support your CRA readiness, request a demo.

‍