This blog is the tenth and final of our Tales From the Trenches: CRA Lessons Learned blog series.  If you have read the complete series, congratulations! If not, visit our blog homepage for to view the previous blogs in this series.

 

Our objective throughout this series has been to help manufacturers, software vendors, and connected-product providers understand the practical realities of implementing the European Union Cyber Resilience Act.  Spoiler alert  Here’s how OmniTrust Certify can help you address EU CRA time and time again:  Watch the video!.

 

One lesson has become increasingly clear: sustainable CRA compliance requires much more than cybersecurity controls or a successful point-in-time assessment. It requires product visibility, governance, accountability, evidence, remediation, and continuous lifecycle management.

 

And the clock is no longer entirely in the future.

 

Since September 11, 2026, the CRA’s mandatory reporting obligations for actively exploited vulnerabilities and severe product-security incidents have begun to apply. The broader CRA product requirements become fully applicable on December 11, 2027, but manufacturers are already entering the operational phase of the regulation.

The question is therefore shifting from: Are we getting ready for the CRA? to: Can we actually operate the processes the CRA requires?

 

The Next CRA Challenge: Moving From Knowing to Doing

As organizations progress through their CRA programs, an important realization is emerging:

Conducting an assessment is the relatively easy part. Remediating what the assessment discovers is much harder.

Most organizations can assemble a team, review CRA requirements, map existing policies and controls, identify gaps, and produce an assessment report.

The difficult part begins afterward.

An assessment may identify dozens or even hundreds of issues.

How should those gaps be prioritized? Which create the greatest cybersecurity or regulatory exposure? Which affect multiple products? Which can be resolved quickly? Which require architectural changes, engineering investment, supplier involvement, or significant organizational change?

Common findings may include:

  • Inadequate vulnerability-management processes
  • Missing or inconsistent compliance evidence
  • Incomplete or outdated SBOMs
  • Product architectures that lack required security capabilities
  • Legacy products that cannot easily be updated
  • Insufficient security documentation
  • Suppliers that cannot provide required cybersecurity information
  • Unclear ownership of cybersecurity or compliance decisions
  • Weak processes for vulnerability disclosure and incident response

Identifying these problems is straightforward.  Fixing them often is not.

Remediation can require changes to engineering processes, product architectures, software-development practices, supplier relationships, documentation, tooling, staffing, budgets, and sometimes the products themselves.

That leads to one of the most important lessons from CRA implementation:

A gap assessment tells you where you are. It does not get you where you need to go.

Executive Insights

For executives, the distinction between assessment and remediation has significant implications.

A completed assessment can create a false sense of progress.

An organization may have:

  • A completed CRA assessment
  • A risk register
  • A list of compliance gaps
  • A remediation roadmap

and still be a long way from operational readiness.

The critical executive question should therefore not simply be:

Have we completed our CRA assessment?

It should be:

How quickly and effectively can we remediate what the assessment identified?

A mature CRA program needs to connect significant findings to:

  • The affected product or products
  • Cybersecurity risk
  • Relevant CRA requirements
  • Responsible owners
  • Remediation actions
  • Priorities
  • Deadlines
  • Evidence
  • Approval and closure

Without this operating model, organizations risk creating an ever-growing inventory of compliance findings without developing the capability to resolve them.

This becomes particularly important for manufacturers with large product portfolios.

A single systemic weakness, such as inadequate vulnerability tracking, incomplete SBOMs, or inconsistent product-security documentation, may affect dozens or hundreds of products.

The remediation challenge can therefore become significantly larger than the original assessment effort.

Not all findings are equal either.

Some may require a procedural change that can be implemented within days.

Others may require:

  • Significant engineering work
  • Product redesign
  • Changes to product architecture
  • Supplier renegotiation
  • New vulnerability-management processes
  • New cybersecurity controls
  • Replacement of legacy technologies

CRA remediation is therefore a portfolio-management problem as much as a compliance problem.

The September 2026 Milestone Changes the Conversation

The operational challenge became more immediate on September 11, 2026.

CRA reporting obligations for actively exploited vulnerabilities and severe product-security incidents are now in effect for applicable manufacturers.

That means vulnerability management is no longer simply part of preparing for the CRA’s full application in 2027.

Manufacturers now need processes capable of rapidly determining:

  • What vulnerability or incident has occurred?
  • Which products are affected?
  • Which software components are involved?
  • Is the vulnerability being actively exploited?
  • What is the potential product-security impact?
  • What remediation or mitigation is available?
  • Does the event trigger CRA reporting obligations?
  • Who owns the response?
  • What evidence supports the organization’s decisions?

The CRA reporting process includes an initial early-warning requirement within 24 hours for reportable events, followed by additional notification and reporting requirements.

The challenge is therefore becoming operational.

Organizations need more than a policy saying they will respond to vulnerabilities. They need product intelligence that enables them to determine what is affected and act quickly.

Real-World Examples

Initial CRA programs frequently begin by assessing a connected-product portfolio.

Organizations may discover that their products were generally developed using sound engineering and cybersecurity practices, but the evidence supporting those practices is inconsistent.

One team may maintain risk assessments in spreadsheets.  Another may store cybersecurity information in engineering systems.  Another may rely heavily on institutional knowledge.  Product documentation, SBOMs, vulnerabilities, controls, supplier information, risk assessments, test results, and compliance evidence may all live in different places.

Reconciling the assessment methodology and establishing a consistent baseline may take weeks or months.

Fixing what the assessments uncover can take considerably longer.  Organizations may need to:

  • Establish a common assessment methodology
  • Recreate historical product information
  • Generate or improve SBOMs
  • Establish ownership
  • Implement review and approval processes
  • Collect missing evidence
  • Build vulnerability-response processes
  • Implement new cybersecurity controls
  • Maintain information throughout the product lifecycle

Only then can remediation become systematic.

The Software Supply Chain Example

Software supply chains illustrate the problem particularly well.

An organization may discover during a CRA assessment that it does not have complete visibility into open-source or third-party software dependencies across its products.

Identifying that gap is relatively straightforward.

Remediating it may require:

  • Integrating software-composition analysis into development pipelines
  • Creating or improving SBOM processes
  • Generating SBOMs for existing products
  • Establishing continuous vulnerability monitoring
  • Identifying which products contain vulnerable components
  • Assessing exploitability and product risk
  • Determining remediation priorities
  • Coordinating fixes with suppliers
  • Tracking evidence of remediation
  • Establishing escalation and CRA reporting procedures

Since September 11, organizations must also be prepared to determine whether newly identified vulnerabilities or incidents trigger the CRA’s mandatory reporting obligations.

The common pattern is clear:

Remediation requires changing how the organization operates.

Best Practices for CRA Remediation

Turn Assessment Findings Into Actionable Work

A compliance assessment should not end with a list of gaps.

Every meaningful finding should include:

  • Clearly defined issue
  • Affected product or products
  • Relevant CRA requirement
  • Associated cybersecurity risk
  • Priority
  • Responsible owner
  • Required remediation
  • Target completion date
  • Status
  • Supporting evidence
  • Final approval or acceptance decision

This transforms a CRA assessment from a static report into an operational remediation program.

Prioritize by Risk and Business Impact

Organizations should avoid treating every finding equally.

Prioritization should consider factors such as:

  • Exploitability
  • Customer exposure
  • Product criticality
  • Regulatory significance
  • Number of affected products
  • Business impact
  • Available mitigation
  • Remediation complexity and effort

A systemic issue affecting 100 products may deserve considerably greater attention than a low-risk issue affecting a single product.

Address Systemic Problems, Not Just Individual Findings

One of the most valuable outcomes of assessing multiple products is the ability to identify recurring problems.

If ten products lack adequate cybersecurity documentation, the best solution may not be ten separate documentation projects.

The real issue may be the absence of a standardized product-security documentation process.

Similarly, if multiple products contain incomplete SBOMs, organizations may need to improve their software-development and release processes rather than manually repairing every SBOM.

The most effective remediation programs fix the process that created the gap.

Build Remediation Into Existing Development Processes

CRA remediation should not become a parallel compliance bureaucracy.

Organizations should address root causes and integrate the resulting improvements into normal product operations.

This may include changes to:

  • Secure SDLC processes
  • Product lifecycle management
  • Quality-management processes
  • Software release processes
  • Vulnerability management
  • Supplier management
  • Product-support processes
  • Incident response
  • Product change management

The objective should be simple:

Make cybersecurity and regulatory conformity part of normal product operations.

Maintain Evidence of Remediation

Closing a gap is not enough.

Organizations need to be able to demonstrate that remediation occurred.

Evidence may include:

  • Updated procedures
  • Product documentation
  • Security controls
  • Test results
  • Approvals
  • Risk assessments
  • Updated SBOMs
  • Vulnerability records
  • Architecture documentation
  • Supplier evidence
  • Engineering artifacts

Ideally, that evidence should remain connected to the product, original finding, applicable requirement, and remediation decision.

Common Pitfalls

Creating an Unmanageable Remediation Backlog

Organizations can quickly identify hundreds of issues without establishing clear priorities or ownership.

The result is a backlog that grows faster than teams can resolve it.

Assessment volume should therefore be balanced with remediation capacity.

Assigning Everything to Security

Many CRA findings cannot be resolved by the security organization alone.

Remediation may require participation from:

  • Engineering
  • Product management
  • Quality
  • Compliance
  • Legal
  • Procurement
  • Supplier management
  • Executive leadership

Security teams cannot remediate problems belonging to other functions without appropriate ownership and authority.

Using Spreadsheets as the Long-Term System of Record

Spreadsheets may be useful during an initial assessment.

They become much harder to manage as products, vulnerabilities, suppliers, controls, evidence, assessments, and requirements continuously change.

The larger the product portfolio becomes, the more important it is to establish a connected and continuously maintained product cybersecurity system of record.

Focusing Only on New Products

Existing and legacy products require careful consideration.

Products placed on the EU market before December 11, 2027 are generally not subject to the CRA’s full product requirements unless they subsequently undergo a substantial modification.

However, the CRA’s Article 14 reporting obligations already apply to applicable products made available on the Union market, including products placed on the market before full application of the regulation.

Manufacturers therefore still need sufficient visibility into existing products, their software components, vulnerabilities, support status, and potential security incidents.

Action Items for Manufacturers and Software Vendors

Organizations progressing from CRA assessment into remediation should consider the following actions:

  • Establish an executive-sponsored process for managing CRA findings from identification through closure.
  • Assign an owner to every significant finding.
  • Prioritize systemic problems that affect multiple products.
  • Quantify remediation effort, including engineering resources, tooling, suppliers, staffing, and budget.
  • Establish clear remediation deadlines.
  • Require evidence before significant findings are formally closed.
  • Integrate remediation into development, release, vulnerability-management, supplier-management, and support processes.
  • Maintain visibility into software components and vulnerabilities across the product portfolio.
  • Establish a clear process for determining whether vulnerabilities or incidents trigger CRA reporting requirements.
  • Continuously reassess products as software, architecture, suppliers, vulnerabilities, and requirements change.

For software and connected-product vendors, this should also be viewed as a competitive opportunity.

Customers increasingly want evidence that suppliers can manage cybersecurity throughout the product lifecycle.

Organizations capable of demonstrating mature CRA processes may therefore gain an advantage over suppliers that cannot.

The Bigger Lesson: Compliance Is a Continuous Improvement Process

The distinction between assessment and remediation ultimately points to a larger CRA lesson.

Compliance is not a document or an assessment. It is an organizational capability.

An assessment provides a snapshot of the current state.

Remediation improves that state.

Continuous monitoring helps ensure that the product remains appropriately managed as circumstances change.

And connected products are constantly changing.

Software dependencies change.

New vulnerabilities emerge.

Suppliers change.

Products are updated.

Architectures evolve.

Organizations acquire businesses and product lines.

Support commitments change.

Regulatory expectations evolve.

As a result, an assessment that is accurate today may no longer accurately represent the product several months from now.

Organizations therefore need an ongoing lifecycle approach.

Continuous assessment, remediation, evidence, monitoring, and reassessment are what turn CRA compliance from a one-time project into sustainable product cybersecurity governance.

How OmniTrust Certify Can Help

Assessment is only valuable if organizations can turn the findings into action and maintain an accurate understanding of the product as it evolves.

OmniTrust Certify creates a living system of record for product cybersecurity risk and regulatory conformity throughout the product lifecycle.

Rather than beginning with a questionnaire alone, Certify starts by understanding the product itself.

Build a Living Product Profile

Certify can intelligently analyze existing product documentation and extract information such as:

  • Product assets
  • Components
  • Interfaces
  • Data assets
  • Trust zones
  • Capabilities
  • Processes
  • Product architecture
  • Data flows
  • Existing security controls

The result is a structured, continuously maintainable Product Profile that becomes the foundation for subsequent cybersecurity and regulatory assessments.

Generate or Ingest SBOMs

Organizations can provide existing SPDX or CycloneDX SBOMs or use Certify to generate software-composition information from inputs such as:

  • Source code
  • Firmware
  • Binaries
  • Existing SBOM files

This enables software composition and vulnerability information to become part of the broader Product Profile rather than remaining isolated in another system.

Establish the Baseline Cyber Risk Assessment

Certify uses the Product Profile to perform a structured cyber risk assessment or TARA.

The assessment can identify:

  • Threats
  • Damage scenarios
  • Attack paths
  • Cybersecurity risks
  • Existing controls
  • Recommended mitigations

This creates the product’s baseline cybersecurity risk position.

Assess Regulatory and Standards Requirements

The same Product Profile and risk information can then be evaluated against applicable regulatory, standards, and guidance frameworks.

For CRA, this means identifying applicable requirements, gaps, evidence requirements, and remediation actions.

The same product can also be assessed against additional industry-specific and cross-industry frameworks where appropriate, creating a reusable compliance model rather than restarting the process for every new requirement.

Apply Human-in-the-Loop Validation

Certify is not intended to remove human judgment.

Engineering, product, security, compliance, legal, and other stakeholders can review and validate:

  • Product information
  • Risk findings
  • Threat applicability
  • Regulatory assessments
  • Remediation decisions
  • Evidence
  • Risk acceptance

Teams can collaborate, assign tasks, make decisions, and maintain accountability throughout the process.

Turn Findings Into Remediation

Identified risks and regulatory gaps can be connected to:

  • Required controls
  • Owners
  • Remediation actions
  • Tasks
  • Evidence
  • Status
  • Approval and closure

This turns the assessment into a continuously managed operating process rather than another static report.

Maintain Evidence

As controls are implemented and remediation activities are completed, organizations can maintain the supporting evidence alongside the product, risk, requirement, and remediation record.

This creates traceability from:

Requirement → Risk → Finding → Control → Action → Evidence → Decision

Continuously Monitor Vulnerabilities

New cybersecurity risk can emerge even when the product itself has not changed.

New vulnerabilities may be discovered in software components that have been present in a product for months or years.

Certify continuously monitors external vulnerability intelligence and can match newly disclosed or updated vulnerabilities against components and dependencies associated with Product Profiles.

That helps teams identify potentially affected products, investigate the risk, determine appropriate remediation, and initiate reassessment when necessary.

This capability becomes particularly important now that CRA vulnerability and incident reporting obligations are operational.

Continuously Reassess

Product cybersecurity is not static.

Certify supports reassessment when relevant lifecycle events occur, including:

  • Product or architecture changes
  • Software updates
  • New vulnerabilities
  • Security incidents
  • Supplier changes
  • New regulatory requirements
  • Internal audit or review events

Rather than replacing the previous assessment, the organization can maintain a history of how the product, its risks, and its compliance posture have evolved.

Generate Reports and Audit-Ready Outputs

Because the Product Profile, cyber risk assessment, regulatory assessment, decisions, controls, and evidence are maintained together, Certify can generate structured reports and compliance artifacts from the same living record.

The objective is to reduce the manual effort required to repeatedly recreate information for internal reviewers, auditors, customers, regulators, and conformity-assessment processes.

From Assessment to a Living Product Risk and Compliance Record

For organizations managing dozens, hundreds, or thousands of products, the distinction is significant.

Instead of asking only:

What CRA gaps did we find?

teams can continuously answer:

  • What is this product?
  • What software and components are in it?
  • What cybersecurity risks exist?
  • Which vulnerabilities affect it?
  • Which regulations and standards apply?
  • What gaps remain?
  • Who owns the remediation?
  • What actions are underway?
  • Which controls have been implemented?
  • What evidence demonstrates completion?
  • What risks have been accepted?
  • What has changed since the previous assessment?

That is the difference between completing a CRA assessment and operating a sustainable product cybersecurity governance program.

 

OmniTrust TLM Can Help Implement Technical Controls

Some remediation findings require more than process changes or documentation.  They require technical cybersecurity controls.

Where appropriate, the broader OmniTrust Trust Lifecycle Management (TLM) platform can help organizations implement controls identified through Certify.  Depending on the product and identified risk, these capabilities can include areas such as:

  • Device identity and lifecycle trust
  • PKI and certificate management
  • Keys and secrets
  • Secure signing and software lifecycle capabilities
  • Identity and trust controls
  • AI and agent controls

Certify identifies, governs, tracks, and helps prove the risk and compliance work.

The broader OmniTrust TLM platform can help implement selected technical controls where appropriate.

Summary

Assessment tells you what is wrong. Remediation makes it right. Continuous governance keeps it right.

Organizations that approach CRA compliance as a continuous product-risk, remediation, evidence, and lifecycle-management process will be better positioned to meet regulatory obligations, respond to vulnerabilities, and demonstrate conformity over time.

And since September 11, 2026, the ability to identify, investigate, and respond to relevant vulnerabilities and severe product-security incidents is no longer simply preparation for the CRA.  For manufacturers of applicable products, those reporting obligations are already here.

OmniTrust Certify helps turn CRA compliance from a point-in-time assessment into continuous product risk and regulatory governance by connecting the Product Profile, SBOM, cyber risk, regulatory requirements, remediation, evidence, vulnerability intelligence, reporting, and reassessment throughout the lifecycle.  And where remediation requires technical trust controls, the broader OmniTrust Trust Lifecycle Management platform can help put those controls into practice.

The goal is no longer simply to assess compliance. It is to create the organizational capability to continuously understand, improve, and prove the cybersecurity posture of the products you put into the market.

Learn more about how OmniTrust Certify can help your organization manage CRA assessments, remediation, evidence, controls, and product cyber risk throughout the lifecycle at www.omnitrust.com/certify.

Subscribe to the Blog on our blog homepage for notifications on future blogs or to revisit the full CRA Lessons Learned blog series.  Meantime, if you missed the spoiler alert earlier and would like to see how OmniTrust Certify can help you address EU CRA now and time and time again – Watch The Video – and get in touch if you’d like help establishing a system of record for EU CRA and other Cyber Risk & Regulatory compliance frameworks.