The first major Cyber Resilience Act (CRA) deadline is nearly here.

Beginning September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The broader CRA requirements become fully applicable on December 11, 2027.

The first deadline will test whether teams can determine which products are affected, coordinate with suppliers, assess the real-world risk, identify appropriate mitigations, and produce accurate information within hours.

That challenge is particularly significant for industrial systems, vehicles, and embedded device manufacturers with complex supply chains, legacy components, safety requirements, and product lifecycles that can extend for a decade or longer.

During the virtual event “CRA in Practice: Cross-Industry Lessons from Industrial, Automotive, and Medical Device Security,” security leaders from Schneider Electric, May Mobility, GE Healthcare, and RunSafe Security shared ways for product teams to prepare.

Their collective advice is that CRA readiness starts with a repeatable operating model for understanding products, evaluating vulnerabilities, coordinating decisions, and supporting those products throughout their operational lives.

Here are six practical steps organizations should prioritize.

Watch the full CRA webinar here.

1. Test the Reporting Process Before the CRA Deadline

The CRA reporting obligations begin September 11, 2026. Manufacturers will generally need to submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a more complete notification within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available.

Those timelines leave little room to assemble a process after an incident occurs.

Hemanth Tadepalli, Senior Cybersecurity and Compliance SME at May Mobility, recommended testing the entire workflow now with a real vulnerability.

“Don’t wait to be compliant. Run the fire drill right now,” Tadepalli said.

Tadepalli suggested selecting a recent CVE and treating it as a tabletop exercise. Teams should measure how long it takes to triage the vulnerability, identify affected products, scope the impact across the deployed fleet, contact suppliers, assess available mitigations, and prepare a regulatory notification.

The exercise should reveal whether the organization can produce the information required under actual reporting conditions.

A useful fire drill should test whether the organization can answer:

• Which products and versions contain the affected component?
• Where have those products been deployed?
• Is the vulnerable functionality enabled, reachable, or exploitable?
• Is there evidence of exploitation in the field?
• Which supplier owns or maintains the component?
• What mitigations can customers apply immediately?
• Who approves and submits the notification?

Whatever time the exercise takes represents the organization’s actual level of readiness. A process that requires several days to identify affected products will not meet a 24-hour reporting window simply because the deadline has arrived.

2. Start with One Accurate, Component-Level SBOM

Organizations do not need to generate perfect Software Bills of Materials (SBOMs) for every product to make progress. They do, however, need to prove that they can create an accurate SBOM for at least one real product.

Tadepalli offered a direct starting point: “Get one real SBOM done. Pick your most important product.”

His recommendation was to create an accurate, component-level SBOM, compare it against known vulnerabilities, and use that work to make the CRA’s requirements concrete. As he explained, organizations cannot report or remediate what they cannot see.

That first SBOM should not be a spreadsheet created at product launch and left unchanged. It should represent the software that was actually built and should be repeatable as the product changes.

Joseph M. Saunders, CEO and Founder of RunSafe Security, warned that embedded software introduces complications that conventional software composition processes can miss. Build systems and compilers may introduce dependencies that were not obvious to the development team.

“It’s also very important … to understand those transitive dependencies that are in your embedded software.”

A library may depend on another open source component. A compiler may pull additional code into a binary. A communications stack, operating system, chipset, or third-party module may introduce software that does not appear in the development team’s direct dependency list.

A practical SBOM readiness project should therefore:

1. Select a high-value or high-risk product
2. Generate the SBOM from the actual build process
3. Capture direct and transitive dependencies
4. Record versions, suppliers, licenses, and component relationships
5. Validate the results against the final software artifacts
6. Establish a process for regenerating the SBOM with each release
7. Connect the SBOM to vulnerability monitoring and product records

Once the organization can do this reliably for one product, it has a process that can be improved and scaled across the portfolio.

3. Evaluate Actual Risk, Not Just Vulnerability Severity

A vulnerability alert is only the beginning of the decision-making process.

Saunders emphasized that teams must go beyond asking whether a vulnerability is present:

“Not just, ‘Do I have a vulnerability?’ but, ‘Is it reachable? Is it exploitable?’”

Understanding reachability, exploitability, and the available defensive layers helps organizations determine where to patch, where to apply compensating controls, and where a vulnerability may not create meaningful product risk.

This context is especially important in safety-critical environments.

Shantanu Shastri, Staff Cyber Security Engineer at GE Healthcare, explained that medical device vulnerability response cannot be driven solely by a CVSS score. A vulnerability with a high score may pose limited practical risk if the affected service is disabled, isolated, or protected by multiple controls. Conversely, a medium-severity vulnerability that affects an essential clinical workflow may require immediate attention.

Medical device teams consider questions such as:

• Can the vulnerability realistically be exploited?
• Could exploitation affect patients, clinicians, or healthcare delivery?
• Can the device continue operating safely?
• What verification and validation would a software change require?
• Which compensating controls are already present?
• Can the customer apply a temporary mitigation?

“Security is not always about finding the fastest solution. It is about finding the safest solution,” Shastri said.

Sometimes the correct response will be an immediate patch. In other cases, monitoring, segmentation, access restrictions, configuration changes, or vulnerability mitigation may provide risk reduction while a patch is tested and validated.

CRA readiness, therefore, requires a documented vulnerability decision process, not just a vulnerability scanner. Teams need a consistent way to record the technical severity, product context, safety implications, exploitability, mitigating controls, remediation plan, and rationale behind the final decision.

4. Design Products to Be Secure by Default and Safely Updated

The CRA will also increase scrutiny of how products are configured when they leave the manufacturer.

Andrew Kling, Vice President of Cybersecurity at Schneider Electric, highlighted secure-by-default configuration as a critical part of secure-by-design development. Products should not begin their operational lives with unnecessary services, insecure functionality, or weak default credentials enabled.

“If you have capabilities or functions in your product that are insecure, they should be disabled by default,” Kling said.

Kling compared the principle to a seatbelt warning. A product should either begin in a secure state or clearly warn the user when a configuration creates an acknowledged risk.

Teams should review:

• Default accounts and credentials
• Unused communications interfaces
• Debugging and administrative services
• Remote access functionality
• Cryptographic settings
• Logging and monitoring defaults
• Customer-facing security warnings
• Permissions and access controls

Secure configuration is only one half of the lifecycle challenge. Organizations must also be able to change products safely after deployment.

Tadepalli described CRA readiness for long-lived vehicles as depending on two basic questions: Does the manufacturer know what is in the product, and can it safely change that product throughout its supported life?

That requires more than the technical ability to transmit an update. Manufacturers need trusted update mechanisms, signing and verification, rollback procedures, deployment monitoring, safety validation, and a clear support policy. They must also plan for components whose original maintainers or suppliers may no longer provide updates years after the product was released.

Product teams should identify unsupported and soon-to-be-unsupported components now. Waiting until a critical vulnerability appears is too late to negotiate new supplier terms, replace a foundational library, or redesign an update architecture.

5. Put CRA Requirements into Supplier Relationships

No manufacturer can demonstrate CRA readiness using information from its own engineering team alone.

Modern connected products may include software from open source projects, commercial libraries, operating systems, chipset vendors, Tier 1 integrators, Tier 2 suppliers, and internal development groups. An actively exploited vulnerability may originate several layers down that chain.

Kling described conformity as a transitive responsibility. Product manufacturers must be able to ask their suppliers how they are demonstrating conformance, while those suppliers must be able to do the same further down the software supply chain.

Supplier notification speed will also affect the manufacturer’s ability to meet the CRA reporting deadlines. A manufacturer cannot provide accurate information within 72 hours if a supplier takes a week to confirm whether its component is affected.

Procurement and product teams should update supplier requirements to address:

• Delivery of accurate, machine-readable SBOMs
• Notification of actively exploited vulnerabilities and severe incidents
• Response times that support the manufacturer’s reporting deadlines
• Security update and patch commitments
• End-of-life and end-of-support notification
• Access to vulnerability and remediation evidence
• Responsibilities for inherited open source components
• Support for investigations and regulatory reporting
• Secure development and vulnerability disclosure practices

These expectations need to be defined before contracts are signed and architectures are frozen. Retrofitting them into an established product and supplier network will be slower, more expensive, and less reliable.

6. Make CRA Readiness a Cross-Functional Operating Model

CRA responsibilities cannot remain isolated within the cybersecurity or compliance team.

Product security may identify a vulnerability, but engineering must assess the affected code. Procurement must contact the supplier. Product management must understand the affected releases. Legal and compliance must evaluate reporting obligations. Customer support must communicate available mitigations. Safety, quality, and regulatory teams may need to approve changes before deployment.

Tadepalli warned against allowing security and compliance to appear only as a gate at the end of development. By that point, supplier contracts have been signed, and the architecture is largely fixed. Security requirements must instead be incorporated into supplier selection, architecture, development, release, and long-term product support.

Organizations should establish:

• A named executive sponsor
• A cross-functional CRA working group
• Clearly assigned product and reporting owners
• Escalation paths for urgent vulnerabilities
• A shared system of record for products, components, and decisions
• Defined supplier communication procedures
• Evidence retention and documentation requirements
• Regular tabletop and reporting exercises

Existing standards and programs can provide a foundation. Automotive teams may already have processes aligned with ISO/SAE 21434 and UNECE R155. Industrial organizations may build from IEC 62443. Medical device manufacturers may already have disciplined quality, safety, and vulnerability management processes.

Mapping existing controls and evidence to the CRA helps identify the gaps and improve the underlying processes.

The same principle applies to AI governance.

Shastri noted that organizations are increasingly expected to document training data, model updates, model drift, integrity protections, explainability, and the security of the AI lifecycle. That work cannot belong exclusively to cybersecurity or data science.

“AI governance is not the responsibility of one team,” Shastri said.

Engineering, clinical or domain experts, quality, legal, regulatory affairs, compliance, and cybersecurity all have a role in demonstrating that AI-enabled products remain trustworthy throughout their lifecycles.

What Product Teams Should Do Next

The immediate objective should not be to write the longest CRA policy. It should be to prove that the organization can operate the process.

Over the next several months, embedded product teams should:

1. Run a vulnerability reporting fire drill using a recent CVE
2. Produce and validate an accurate, build-time SBOM
3. Connect component data to products, versions, customers, and deployments
4. Document a risk-based vulnerability triage process
5. Review default product configurations for unnecessary exposure
6. Test secure update, rollback, and customer mitigation procedures
7. Add vulnerability notification and support obligations to supplier contracts
8. Establish a cross-functional CRA working group with named owners
9. Map existing standards, processes, and evidence to CRA requirements
10. Record the gaps uncovered and assign deadlines for closing them

The organizations best positioned for CRA compliance will not necessarily be those with the longest policies or the largest compliance teams.

They will be the organizations that can quickly answer four practical questions:

What is in the product? Is the product affected? What can reduce the risk? Who is responsible for acting?

Turn CRA Requirements into Repeatable Engineering Processes

The CRA raises the standard for product security, but it also gives manufacturers an opportunity to improve their understanding of, security of, and support for embedded products.

RunSafe Security helps embedded product teams prepare for CRA requirements by generating build-time SBOMs, identifying vulnerable components, and reducing the exploitability of software that cannot be immediately patched.

RunSafe Identify provides visibility into components and vulnerabilities for embedded software, including complex C/C++ environments. RunSafe Protect adds runtime protection that makes memory-based vulnerabilities more difficult to exploit without requiring organizations to rewrite existing software.

Talk to the RunSafe team to discuss where SBOM generation, vulnerability analysis, and exploitability reduction can support your CRA readiness program.

Watch the full webinar with Andrew, Joe, Hemanth, and Shantanu for more on lessons for CRA readiness.