Tag Archive for: Tracability

Tag Archive for: Tracability

Cybersecurity by Design: Preparing for the Cyber Resilience Act

What Is the Cyber Resilience Act and How to Prepare

A vulnerability report arrives, and the question is no longer whether your team can fix it. The real question is whether you can say, within hours, which products contain the affected component and which EU markets they ship to. With components mapped to products in advance, that answer takes minutes. Without it, the day disappears into spreadsheets while a regulatory clock runs.

By September 11, 2026, manufacturers selling connected products in the European Union (EU) must report actively exploited vulnerabilities within 24 hours of discovery through the Single Reporting Platform operated by the European Union Agency for Cybersecurity (ENISA). Most other obligations under the Cyber Resilience Act (CRA) apply from December 11, 2027.

This guide covers what the regulation requires, who it applies to, the compliance timeline, and how to prepare before the first reporting deadline arrives.

What Is the Cyber Resilience Act?

The Cyber Resilience Act is a horizontal EU regulation that sets cybersecurity requirements for products with digital elements placed on the EU market. A product with digital elements is any software or hardware product, including components sold separately, whose intended or foreseeable use includes a direct or indirect connection to a device or network.

The European Commission created the regulation to fill a gap. Hardware and software products were previously covered by cybersecurity requirements primarily through sectoral frameworks rather than a single horizontal framework that spans all such products. The CRA sets conditions for developing secure hardware and software, requires that users receive adequate security information, and works to make supply chains more secure so that final products and their components carry fewer weaknesses.

The regulation applies to any product placed on the EU market, regardless of where it is produced or where the company is headquartered. Products already covered by sector-specific EU legislation, including medical devices, vehicles, and aircraft, as well as maritime equipment and products used exclusively for national security or defense, fall outside its scope.

Products and Companies Covered by the Cyber Resilience Act

Connected hardware, standalone software, and manufacturer-developed remote data processing, all essential to a product’s function, fall within scope. Software offered solely as Software as a Service (SaaS) is out of scope, provided it does not qualify as a manufacturer-developed remote processing component.

The regulation assigns obligations based on the economic operator’s role. Manufacturers bear the primary burden for security through design, vulnerability reporting, and security updates for the expected product lifetime or for 5 years after market placement, whichever is shorter. Importers act as a verification checkpoint, confirming that manufacturers have met their obligations before products reach the EU market. Distributors carry lighter duties, mainly verifying CE marking and notifying manufacturers of discovered vulnerabilities. Any party that markets a product under its own name or makes substantial modifications becomes a deemed manufacturer and inherits full manufacturer obligations.

Free and open-source software published outside commercial activity is exempt. Once that software is integrated into a commercial product, the manufacturer of that product inherits full CRA duties for those components. The regulation also creates a legal category, the open-source software steward, for legal persons that systematically support open-source development intended for commercial use. Stewards must document cybersecurity policies and actively report on vulnerabilities that are being exploited, though they are exempt from administrative fines.

Cyber Resilience Act Requirements

Every in-scope product must meet the Annex I security obligations, and certain important or critical products face additional or stricter requirements. Products must ship with no known exploitable vulnerabilities, secure default configurations, and controls for authentication, data protection, and minimized attack surfaces. Ongoing security updates are central to staying compliant once a product is on the market.

Vulnerability handling obligations apply throughout the product’s support period. Manufacturers must maintain a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies. They must remediate vulnerabilities without delay, publish a Coordinated Vulnerability Disclosure (CVD) policy, conduct regular security testing, and provide free security updates for at least 5 years after market placement.

The conformity assessment pathway depends on how a product is classified and which assessment route applies.

  • Default products: Self-assessment under Module A by the manufacturer, with no mandatory third-party involvement. This covers the majority of products.
  • Important Class I: Self-assessment is permitted only when harmonized standards are applied. Otherwise, a notified body assessment is required.
  • Important Class II: Notified body involvement is always mandatory, either through Module B plus C or through Module H full quality assurance.
  • Higher-risk products: Certain products may be subject to additional conformity assessment requirements.

In-scope products placed on the EU market must bear the Conformité Européenne (CE) marking as of December 11, 2027. The classification tier changes only the assessment pathway, not the underlying security requirements.

Mandatory Reporting Requirements Under Article 14

Article 14 reporting starts on September 11, 2026, which makes it the earliest binding obligation, and it applies to products already on the EU market. Two event types trigger reporting: identified vulnerabilities and severe incidents affecting product security. Both follow a three-stage cascade, with manufacturers reporting once through the Single Reporting Platform, which routes notifications to the competent Computer Security Incident Response Teams (CSIRTs) and makes them available to ENISA.

The 24-hour early warning requires minimal content. Manufacturers must confirm that an event exists, state whether a vulnerability is actively exploited, and identify which EU Member States the product is available in. The 72-hour notification adds product details, the nature of the exploit, corrective measures taken, interim measures for users, and an initial assessment of the vulnerability or incident.

The final report for an actively exploited vulnerability is due within 14 days after a corrective measure becomes available. It must include the vulnerability description with severity and impact, any available information about the malicious actor, and details of the security update. The 24-hour and 72-hour deadlines run from the moment the manufacturer becomes aware, not from the completion of any investigation.

The Cyber Resilience Act Compliance Timeline

CRA obligations phase in between December 2024 and December 2027, with Article 14 reporting arriving first. The regulation entered into force on December 10, 2024. The conformity assessment body notification framework applies from June 11, 2026. Mandatory vulnerability and incident reporting under Article 14 begins September 11, 2026. Full compliance with remaining obligations, including Annex I security requirements, CE marking, and completed conformity assessments, is required by December 11, 2027.

Penalties scale with the type of failure. Non-compliance with essential cybersecurity requirements or Article 14 reporting can reach the highest tier, up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher. Procedural and documentation failures, including CE marking and importer and distributor obligations, fall under a separate maximum tier. Providing false, incomplete, or misleading information to authorities can draw fines of up to 5 million euros or 1 percent of turnover. Beyond fines, market surveillance authorities can withdraw products from the EU market, prohibit availability, or order recalls.

Why Meeting the Reporting Windows Depends on Traceability

Meeting the reporting windows depends on knowing immediately which products contain an affected component and where those products are available in the EU. Filing a 24-hour early warning means answering those questions on the spot. Without a pre-existing component-to-product mapping, the search alone can consume the full window before a submission begins.

The 72-hour notification raises the bar. Teams must determine which downstream products inherit the vulnerable component, assess the scope of impact, and document corrective measures already underway. That work depends on a traceability chain linking the vulnerability identifier to the specific component version, the component version to every product release that includes it, and those releases to the shipped or deployed versions currently in scope.

Audit trails face the same time pressure. A manufacturer that assembles the early warning by hand cannot easily reconstruct the decision trail under later scrutiny. The record must capture the component inventory, the logic that classified the event as actively exploited, and the basis for severity, all of which were recorded at the time of the event.

How to Prepare for the Cyber Resilience Act

Teams get the most value when they treat CRA cybersecurity requirements as design inputs that trace through architecture, implementation, and verification and validation. The CRA’s Annex I requirements align with existing secure development frameworks, and the NIST Secure Software Development Framework provides a structured reference for building security into the development lifecycle. A product-level risk assessment early in development, threat modeling during design, and security testing within the development cycle all align with the regulation’s secure-by-design and vulnerability-management expectations.

SBOM generation belongs in the build pipeline rather than in a separately maintained file. A manually updated SBOM drifts out of date as dependencies change. The statutory minimum covers top-level dependencies, yet capturing transitive dependencies is the only way to correlate components against Common Vulnerabilities and Exposures (CVE) databases with enough depth to support the 24-hour reporting window.

A structured intake and handling process closes the gap between awareness and submission. Documented triage and escalation workflows let a team produce a Stage 1 submission within 24 hours of first awareness, which is the kind of secure development practice that pays off under pressure. Coordinated vulnerability disclosure is widely considered good practice for addressing issues before public disclosure, so teams should register with the Single Reporting Platform during the testing period leading up to the September 2026 go-live and identify the CSIRT associated with their main EU establishment.

How Jama Connect Supports Cyber Resilience Act Reporting

Meeting CRA reporting windows depends on knowing which components sit in which products, what changed, and what evidence supports each decision. Jama Connect® is a cloud-based requirements management and traceability platform for complex, regulated product development, and that traceability is what turns a vulnerability report into a fast, defensible answer about affected products.

When a vulnerability surfaces, Live Traceability™ provides upstream and downstream visibility into affected products and linked components without manual review, and suspect-link notifications flag which downstream artifacts need attention when an upstream security requirement or component record changes. Baseline capture preserves the state of each release at market placement, so the record behind a vulnerability classification stays available when authorities ask.

Building Reporting Readiness Before the Deadline

The September 2026 deadline rewards teams that built cybersecurity traceability into development rather than bolting it on afterward, and the difference is invisible until the first report arrives. The companies that absorb the CRA most easily will be those that already treat each shipped release as a queryable record, because a reporting obligation is only as fast as the data beneath it.

Jama Connect supports this workflow by linking each security requirement to its component, control, test case, and evidence, so a team can trace a single CVE to every affected product release on demand. That connected record is what lets an early warning go out in hours instead of days. If you want to see how that traceability holds up under a real reporting timeline, start a free 30-day trial of Jama Connect.

Frequently Asked Questions About the Cyber Resilience Act

When does the Cyber Resilience Act take effect?

The CRA phases in, and its first operational deadline is September 11, 2026, for Article 14 reporting. The regulation entered into force on December 10, 2024, and full compliance with CE marking and conformity assessment is required by December 11, 2027. Because reporting applies earlier to products already on the market, waiting until late 2027 leaves a gap of more than a year on the most time-sensitive obligation.

What products does the Cyber Resilience Act apply to?

It applies broadly to hardware and software products with digital elements that connect directly or indirectly to a device or network. That includes connected hardware, standalone software, and manufacturer-developed remote processing essential to a product’s function, while pure SaaS generally falls outside the scope. Products covered by sector-specific EU legislation, such as medical devices, vehicles, and aircraft, are excluded because their own frameworks already address cybersecurity.

What are the Cyber Resilience Act reporting deadlines?

The clock starts the moment a manufacturer becomes aware of a qualifying event rather than after the investigation closes. A 24-hour early warning is followed by a 72-hour notification with general information and an initial assessment, including exploit details and remediation actions. A final report is issued within 14 days after a corrective measure becomes available for actively exploited vulnerabilities, or within 1 month of the initial notification for severe incidents.

What are the penalties for Cyber Resilience Act noncompliance?

The steepest fines attach to failures in core security requirements and Article 14 reporting, reaching up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher. Other obligations carry their own maximum tiers, and providing misleading information to authorities can draw fines up to 5 million euros or 1 percent of turnover. Market surveillance authorities can also pull products from the EU market or order recalls, which often costs more than the fine itself.

 

Best Practices for Efficient and Compliant Risk Traceability from Design to Manufacturing

Best Practices for Efficient and Compliant Risk Traceability from Design to Manufacturing

Intro

Those familiar with medical device development know that risk traceability and risk management is an important aspect that threads through the entire product development process and lifecycle.

Many see risk management as discrete deliverables completed by different team members at certain phases of product development. For example, a risk analysis that focuses on the intended use and reasonably foreseeable misuse is typically first drafted at the onset of design controls by primarily those in touch with the user’s point of view – human factor engineers, marketing, clinicians, etc. While a risk analysis focused on the design occurs during the detailed design and development phase with heavy input from the design engineers. And yet another team, mostly of those on the manufacturing team contributing to the manufacturing risk analysis.

However, it’s important that risk management is treated holistically, with traceability and connections from design to manufacturing. This traceability and connection has many benefits, including compliance with ISO 14971, the standard for the application of risk management to medical devices and meeting FDA expectations for a ‘risk-based’ approach for design and manufacturing of a medical device. Other important reasons include consistency, more efficient risk analysis, and ensuring risks identified at any point throughout the product development and lifecycle are appropriately passed along and mitigated to the various team members and stakeholders addressing those issues.

Here are my best practices for ensuring risk traceability throughout the product lifecycle, from design to manufacturing, and to post-market surveillance.

RELATED: Design Transfer: Best Practices for Translating Your Device Design into Manufacturing Specifications

Main points for How

1: Create a ‘master list’ of hazards, hazardous situations, harms and severity of harms

A common early step in risk management is creating a preliminary list of hazards. I extend this concept to hazardous situations, the resulting harms from those hazardous situations, and associated severity of those harms.

As the team starts its first risk analysis, say from the application or use point of view, note the hazardous situations that tend to repeat or are very close in description to one another. After the first team session or two, take a moment to review the hazardous situations that have been named to date, determine the unique hazardous situations, and create a ‘master list’ of hazardous situations.

Next is to determine the corresponding harms and severity of those harms associated with these hazardous situations. And add these to the ‘master list.’ Again, the corresponding harm(s) to a hazardous situation is finite and doesn’t generally change. For example, take a device with a small cutting edge. The hazardous situation is the user’s exposure to the sharps edge. Let’s say the resulting associated harm is a cut with a minor severity. Thus, anytime a foreseeable event is determined by the team to lead to the hazardous situation of the user’s exposure to the sharp edge, the associated harm of a cut with a minor severity can quickly also be listed. This prevents the team needing to reassess from scratch what the associated harm should be in each future instance that this hazardous situation arises.

Use this ‘master list’ for the future risk assessments to standardize risk practices and optimize efficiency by reusing the same risk content. Picking from a list is an efficient way for the team to identify and document the associated hazardous situations for each foreseeable event, keep wording consistent, and make it easier for new team members to understand the common outcomes. Of course if a truly unique and new hazardous situation does arise, it can be added.

2: Ensure risk assessments is available for all risk management team members and partners

Given that the functions and specific team members working on risk management will change over time, it is important that there is an effective way to share and notify the team members and partners over time. For consistency and team efficiency, ensuring access to the ‘master list’ described above to the manufacturing team and vendors will give them visibility and insight to the risks they should be on guard against, as one example.

Another example is if a design feature is identified as a mitigation for a use error, this information needs to be passed along to the design engineers to ensure said feature is designed in. To build upon the sharps example from above – After the sharps hazard is first identified, the team decides to implement a physical guard around the sharp edge. This requirement needs to be passed along to the design engineers to ensure it is designed in, not added after design freeze, when changes are more costly and time consuming. Similarly, this risk can be traced to the manufacturing team to evaluate the risks of manufacturing said sharps guard to ensure it is assembled correctly and does not fail in the field. Also, if the sharps guard design changes or becomes obsolete, you would want team members to know it’s a risk control mitigation and ensure the risk concerns remain addressed and documented.

3: Pick an appropriate tool to stay organized and efficient

Traceability of risk management and requirements arising from risk management can quickly become unwieldly, especially for complex systems, electromechanical devices, and those with software. Using traditional tools like Microsoft Word™ and Excel™ documents for risk management and requirements traceability are difficult to manage and prone to mistakes and gaps due to the manual input and review required.

Using a tool like Jama Connect® allows for easier visibility to gaps in traceability, allows for automated review and notification workflows, and features that ensure consistency, all leading to a compliant risk management file with less of the errors and inefficiencies associated with manual tools. It also has ways to manage the ‘Master List’ described above and create a Global Library of risk content that can be leveraged for new projects, allowing organizations to expand its portfolio and scale efficiently.

RELATED: Understanding Integrated Risk Management for Medical Device

Conclusion

Risk management done right is holistic and connected throughout product lifecycle from design to manufacturing, and beyond. Follow these best practices for both a compliant and efficient way to manage risk.