Meeting Cyber Resilience Act Requirements with ArmorCode

With less than 90 days remaining until the CRA’s first major compliance milestone, organizations that develop or sell Products with Digital Elements (PDEs)  need to be prepared for new vulnerability reporting obligations. 

Meeting Cyber Resilience Act requirements starts with having the right processes, workflows, and visibility in place, because beginning September 11, 2026, manufacturers will be required to report actively exploited vulnerabilities within strict timelines.

To help organizations operationalize these requirements, ArmorCode recently introduced new CRA-focused capabilities designed to support product classification, exploit-aware risk prioritization, disclosure workflows, software supply chain visibility, and audit-ready reporting. In this blog, we’ll explore how security teams can leverage these capabilities to align their security programs with key CRA requirements.

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act (CRA) is a European Union regulation that establishes mandatory cybersecurity requirements for Products with Digital Elements (PDEs) placed on the EU market. It requires manufacturers to implement secure development practices, manage vulnerabilities throughout the product lifecycle, maintain software component visibility, and provide evidence that these processes are working. The main objective is to ensure that products placed on the EU market are not released with known exploitable vulnerabilities.

The CRA entered into force in December 2024 and introduced a phased implementation timeline. Mandatory reporting requirements for actively exploited vulnerabilities and severe security incidents become applicable on September 11, 2026. Organizations must be able to identify affected products, assess impact, and meet strict reporting timelines through ENISA’s reporting platform. These reporting obligations include a 24-hour early warning notification, a 72-hour vulnerability or incident notification, and a final report within 14 days after corrective measures become available for actively exploited vulnerabilities.

Full CRA compliance, including secure development, vulnerability management, technical documentation, conformity assessments, and CE marking requirements, becomes mandatory on December 11, 2027.

It is also important to note that the CRA is not a voluntary framework like SOC 2 or ISO 27001 that organizations can choose to adopt. Instead, it is a legally binding EU regulation that imposes mandatory cybersecurity obligations on manufacturers of PDEs placed on the EU market.

Who Does the Cyber Resilience Act Apply To?

The Cyber Resilience Act applies horizontally to Products with Digital Elements (PDEs), including both software and hardware products that are made available on the EU market. This includes software vendors, SaaS providers (depending on deployment model and product characteristics), hardware vendors, IoT and connected device manufacturers, and organizations that develop products containing digital components. It applies even if the company is headquartered outside the EU, as long as products are placed on the EU market.

Certain products and services are excluded from its scope. Products already covered by sector-specific EU cybersecurity regulations, such as medical devices, civil aviation systems, automotive products, and certain marine equipment, are generally governed by their respective regulatory frameworks. The CRA also excludes non-commercial open-source software that is developed or supplied outside the course of a commercial activity. 

How ArmorCode Helps Organizations Meet CRA Requirements

ArmorCode’s Agentic AI Platform helps organizations operationalize Cyber Resilience Act (CRA) requirements. Processing more than 300 billion findings annually across 375+ native integrations, ArmorCode brings together findings, assets, software components and threat intelligence into a unified risk context that enables security teams to prioritize vulnerabilities, orchestrate remediation, maintain software supply chain visibility, and generate the evidence required for compliance and reporting.

CRA Requirements for Product Classification

One of the first steps toward CRA compliance is identifying which products fall within the scope of the regulation and classifying them. The CRA applies to Products with Digital Elements (PDEs), the regulation’s term for software or hardware products that rely on software or digital connectivity to perform their intended functions.

ArmorCode provides native PDE classification capabilities that allow organizations to categorize products and sub-products according to CRA. Teams can classify products as Default, Important Class I, Important Class II, or Critical, aligning directly with the CRA’s product categorization framework.

• Not Applicable: Products that fall outside the scope of the CRA.
• Default: Consumer-grade or lower-risk products where a compromise would have limited systemic impact. Examples include basic applications, connected consumer devices, and non-critical software. 
• Important Class I: Technologies that manage sensitive data or security-related functions, such as password managers, VPNs, web browsers, identity systems, and smart home security devices. 
• Important Class II: Core software and infrastructure technologies such as operating systems, hypervisors, industrial firewalls, and other foundational platforms whose compromise could affect large numbers of users or dependent systems. 
• Critical: These represent the highest level of scrutiny under the CRA and include technologies such as Hardware Security Modules (HSMs), smart card readers, and other security-critical components that form the trust foundation of digital ecosystems.

In addition to PDE classification, ArmorCode allows organizations to track the EU markets where a product is sold and manage its lifecycle status, including In Development, Pre-release, Released, Near End of Life, and End of Life.

Prioritizing Vulnerabilities Based on Real-World Risk

One of the key challenges for security teams is determining which vulnerabilities require immediate attention.

While severity ratings such as CVSS provide useful context, they don’t always reflect actual risk. A vulnerability with a high CVSS score may never be exploited, while a lower-scoring vulnerability that is actively being weaponized could pose a much greater threat.

ArmorCode addresses this challenge through exploit-aware risk prioritization. Findings are enriched using multiple sources of risk intelligence, including EPSS, CISA Known Exploited Vulnerabilities (KEV), CVSS scoring, asset context, business impact, and ArmorCode Advanced Threat Intelligence (AATI). 

ArmorCode’s Exploit Status field helps organizations assess vulnerabilities based on likelihood and maturity of exploitation. Vulnerabilities can be classified as Unknown, No Exploit, Proof of Concept Available, Available, Known Exploited, Exploitable, and Actively Exploited. These classifications are automatically populated and updated using ArmorCode Advanced Threat Intelligence (AATI).

• Unknown: Exploitability has not yet been determined.
• No Exploit: The vulnerability exists, but there is no known exploit code or evidence of exploitation.
• Proof of Concept Available: Public proof-of-concept code exists, demonstrating how the vulnerability could be exploited.
• Available: Mature exploit code is available, making exploitation more accessible to attackers.
• Known Exploited: Credible evidence indicates the vulnerability has been exploited in real-world attacks.
• Exploitable: Analysis confirms the vulnerability can be exploited within the organization’s specific environment based on factors such as exposure, accessibility, and asset configuration.
• Actively Exploited: The vulnerability is currently being exploited and impacting the affected product or environment.

When a vulnerability is identified as “Actively Exploited”, it is automatically elevated in priority, helping security teams focus remediation efforts on the risks most likely to impact the business.

Building a CRA-Ready Vulnerability Disclosure Process

Many organizations still manage disclosure activities through email threads, spreadsheets, ticketing systems, and ad hoc coordination between security, product, and compliance teams. While these approaches may work for occasional disclosures, they become difficult to sustain when regulatory reporting deadlines are involved.

ArmorCode tracks the regulatory reporting lifecycle through a dedicated CRA Notification Status field. Once a finding is classified as “Actively Exploited”, ArmorCode automatically initiates the CRA reporting workflow and tracks the vulnerability through each stage of the ENISA disclosure process.

• Not Required: The finding does not currently meet CRA reporting criteria and no notification is required.
• Pending Review: The vulnerability is awaiting review to determine whether CRA reporting obligations apply.
• Early Warning Released (within 24 hours):: The initial early warning notification has been submitted to the designated CSIRT and ENISA.
• Vulnerability Notification Released (within 72 hours): The detailed vulnerability notification has been submitted to the designated CSIRT and ENISA.
• Final Report Released (within 14 days): The final report has been completed and submitted, closing the regulatory reporting process.

These statuses are tied to automated due-date calculations for the CRA’s reporting obligations. When a vulnerability is determined to be actively exploited and meets the CRA’s reporting criteria, ArmorCode automatically calculates the associated deadlines, including the Early Warning Due date (24 hours), Vulnerability Notification Due date (72 hours), and Final Report Due date (14 days).

To help organizations stay on track, ArmorCode can trigger alerts through Slack, email, or connected ticketing systems as reporting deadlines approach, so teams do not miss the 24-hour or 72-hour windows while working across time zones or tool stacks.

In addition, the CRA requires manufacturers to notify users when corrective measures become available. ArmorCode tracks this requirement through a dedicated User Disclosure Status field with Pending, Delayed, and Notified states.

Using SBOMs and VEX to Strengthen Software Supply Chain Security

ArmorCode helps organizations operationalize software supply chain security through integrated SBOM and VEX capabilities. The platform ingests, stores, and manages SBOMs from existing scanning tools and supports both SPDX and CycloneDX formats, two widely adopted industry standards.

ArmorCode also supports the generation of composite SBOMs that combine software supply chain data from multiple repositories and services. Teams can generate composite SBOMs that consolidate software supply chain data from multiple repositories and services at the product level.

Maintaining Audit-Ready Evidence

The CRA requires manufacturers to maintain evidence of security activities, track remediation efforts, and demonstrate that reporting obligations have been met throughout the product lifecycle.

With ArmorCode, teams can generate reports using configurable templates that document how findings were reviewed, prioritized, remediated, and disclosed. Every status change, exception approval, and disclosure event is recorded in an immutable audit trail tied to the specific finding, providing inspectors, auditors, and compliance teams with a single source of evidence. The platform also supports multi-tier SLAs at the product and sub-product level, covering triage, remediation, and resolution activities.

ArmorCode also offers a dedicated CRA dashboard that enables security and leadership teams to continuously monitor their organization’s overall CRA readiness from a single view. The dashboard surfaces key metrics such as Actively Exploited Findings, Early Warning Due, Notification Due, Final Report Due, and User Disclosure Due.

How ArmorCode Supports Key CRA Requirements

CRA Requirement	What Companies Must Do	How ArmorCode Helps
Product Classification	Understand which products fall under CRA classifications and apply appropriate controls throughout their lifecycle.	Native PDE Classification and Product Lifecycle Status tracking for products and sub-products.
Vulnerability Management	Identify, assess, prioritize, remediate, and track vulnerabilities throughout the support lifecycle.	Unified Vulnerability Management with exploit-aware risk prioritization powered by EPSS, CISA KEV, AATI, CVSS, and business context.
Actively Exploited Vulnerability Response	Detect and respond rapidly to vulnerabilities that are actively exploited.	Exploit Status becomes a first-class field and directly influences risk scoring. Actively exploited vulnerabilities are automatically surfaced and prioritized.
Vulnerability Disclosure & Reporting	Meet CRA reporting obligations and vulnerability disclosure timelines.	CRA Notification Status tracks disclosure workflows and automatically calculates reporting deadlines. Automated workflows trigger alerts and escalations as deadlines approach.
Software Supply Chain Security	Understand software components, dependencies, and third-party risk.	SBOM and VEX generation, software supply chain visibility, dependency tracking, and vulnerability correlation across products and versions.
Continuous Monitoring	Monitor products for newly discovered vulnerabilities and emerging threats after release.	Continuous monitoring of vulnerabilities, exploit status, affected products, and supply chain components through a centralized platform.
Remediation Orchestration	Track ownership, remediation progress, and policy compliance.	SLA management, exception workflows, automated alerts, remediation tracking, and policy-driven workflows.
Technical Documentation & Evidence	Maintain documentation that demonstrates compliance activities and security decisions.	Immutable audit trails, evidence capture, remediation documentation, and one-click compliance reporting.
Compliance Reporting	Demonstrate compliance to regulators, auditors, customers, and executives.	Real-time dashboards, CRA-specific reporting, audit-ready evidence, and configurable report templates.

Getting Started

With the September 2026 reporting deadline fast approaching, now is the time to assess your organization’s CRA readiness. Explore the resources below to learn more about CRA and take the next steps toward meeting the CRA requirements.

CRA Readiness Calculator – Assess your organization’s readiness against key CRA requirements.

CRA Product Tour – Explore the capabilities ArmorCode provides for product classification, vulnerability management, disclosure workflows, software supply chain security, and compliance reporting.

Watch this Purple Book Community session to learn how organizations can operationalize CRA requirements and prepare for upcoming reporting obligations.

Frequently Asked Questions About Cyber Resilience Act Requirements

Q: Does the CRA apply to my company if we are not based in the EU?

A: Yes. The CRA applies to any manufacturer that places a Product with Digital Elements (PDE) on the EU market, regardless of where the company is headquartered. If your software, device, or connected product is made available in the European Union, you may be subject to CRA requirements.

Q: Is pure SaaS exempt from the CRA?

A: Generally, SaaS products fall outside the scope of the CRA. However, the boundaries can become less clear when SaaS offerings are delivered alongside products such as mobile applications, desktop software, on-premises deployments or connected devices. Organizations should assess their specific deployment model and product architecture to determine whether CRA obligations apply.

Q: What are the CRA notification timelines for actively exploited vulnerabilities?

A: Manufacturers must submit an early warning notification to ENISA and the relevant CSIRT within 24 hours of becoming aware of an actively exploited vulnerability. A more detailed vulnerability notification must follow within 72 hours, and a final report must be submitted within 14 days of a corrective measure becoming available. Each stage requires different information and serves a specific purpose within the CRA reporting process.