This blog is the second of our Tales From the Trenches: CRA Lessons Learned blog series. Our objective in developing these blogs is to help manufacturers, software vendors, and connected-product providers understand practical implementation realities of CRA compliance programs. We will draw on lessons we have learned from working with our customers and in talking to industry leaders. Organizations are learning that sustainable compliance requires governance, visibility, accountability, and lifecycle management capabilities that extend well beyond traditional cybersecurity activities. Building a secure product is not enough to achieve CRA compliance.
CRA Compliance Starts with Product Classification: Why Defining Scope and Security Levels is an Unexpected Challenge for Manufacturers.
Executive Insights
As organizations accelerate their Cyber Resilience Act (CRA) compliance programs, many executives are discovering an unexpected reality: the first challenge is not implementing security controls – it is understanding what products are in scope, how they should be classified, and what cybersecurity obligations apply to each.
When the CRA was first introduced, most organizations assumed the primary effort would involve vulnerability management, secure development, SBOMs, incident reporting, and post-market security activities. While those requirements remain important, manufacturers are finding that everything begins with a much more fundamental question: what products are in scope, and how should they be classified?
CRA Product Scoping and Classification
What products are in scope and how should they be classified?
For companies with extensive product portfolios, answering this question can be surprisingly difficult. A typical manufacturer may have hundreds, possibly thousands, of active products, legacy offerings, embedded software platforms, cloud services, mobile applications, OEM products, and solutions acquired through mergers and acquisitions. Determining which offerings qualify as products with digital elements (PDEs), understanding their risk profile, and assigning the appropriate security obligations has become a major initiative in its own right.
Getting this right is critical because classification decisions drive nearly every downstream CRA compliance activity, including required security controls, documentation requirements, vulnerability management obligations, regulatory reporting requirements, post-market monitoring activities, and more.
Assigning a product to a lower security tier than it should have can create compliance risk for years to come. On the other hand, assigning a product to a higher security tier than required creates unnecessary, and costly, work.
For many organizations, this becomes the foundation for every subsequent CRA activity. Product classification influences cyber risk assessments, required documentation, conformity assessment routes, post-market obligations, executive reporting, and ultimately the cost and complexity of achieving compliance. Errors made during product scoping often cascade throughout the entire compliance program.
Why Product Classification Is So Difficult
Many organizations assume product categorization is a simple administrative exercise. In reality, it often requires extensive collaboration between engineering, product management, legal, compliance, cybersecurity, and executive leadership teams.
Several factors contribute to the complexity:
Mixed Hardware and Software Ecosystems
Today’s products rarely exist as standalone devices. A connected industrial controller may include embedded firmware, mobile applications, cloud management platforms, APIs, analytics services, and third-party software components.
Organizations must determine whether these components should be treated as individual products, supporting services, or elements of a larger product ecosystem.
Legacy Product Portfolios
Many manufacturers maintain products that have evolved over decades. Documentation may be incomplete, ownership may have changed, and security assumptions may no longer be valid. Before products can be classified, organizations often must ensure they have an accurate inventory of what they actually sell and support. For legacy products, they most locate user’s guides and engineering documentation. In worst case scenarios, this documentation must be recreated.
Acquisitions and Product Consolidation
Companies that have grown through acquisition frequently inherit products developed under different processes, architectures, and security models. As a result, similar products may have vastly different levels of cybersecurity maturity and documentation, complicating efforts to establish consistent CRA classifications.
Determining Appropriate Security Levels
Even after identifying products within CRA scope, organizations face another difficult question – determining the appropriate CRA product classification and resulting cybersecurity obligations.
Not every product carries the same risk profile. A consumer IoT device, industrial automation controller, cloud-based management platform, and safety-critical embedded system may be assigned to different security tiers under the CRA. Each tier requires very different security controls and assurance levels.
Determining the appropriate security posture requires evaluating product functionality, connectivity characteristics, potential impact of compromise, customer environments, and operational lifecycle requirements.
Many organizations are discovering that these assessments require far more time, structure, and evidence than originally anticipated. The CRA requires documentation to support all decisions regarding which CRA security level is assigned to each product.
Many OEMs are also finding that the number of products requiring assessment far exceeds initial expectations. Executive teams often start by identifying the main product lines being sold. After performing a detailed product inventory, many organizations discovered that each product line is composed of multiple supported versions and consists of a combination of unique software and hardware offerings, OEM-branded products, cloud services, and mobile applications. The result is often a 5x or larger increase in the number of products under scope.
Another challenge companies face is lack of consistency in how products are classified. Without a standardized classification framework, product teams across business units often apply different definitions of risk and security criticality. As a result, similar products may receive dramatically different security classifications, creating compliance inconsistencies across the organization.
Best Practices for Product Classification and Security-Level Determination
Organizations with mature CRA compliance programs are adopting several common practices:
Establish a Formal Product Taxonomy
Develop a standardized framework for categorizing products, software, services, and supporting components. Consistent terminology and decision criteria reduces confusion and improves decision-making across business units.
Create Cross-Functional Classification Teams
Classification should not be owned exclusively by compliance or security teams. Successful organizations involve product management, engineering, cybersecurity, legal, regulatory, and quality assurance teams.
Implement Risk-Based Security Tiering
Develop defined security tiers based on risk exposure and business impact. This allows organizations to prioritize certification efforts based on business and product risk rather than treating every product identically.
Maintain a Living Product Inventory
Static spreadsheets quickly become outdated. Organizations need continuously maintained inventories that track product ownership, software composition, security classification, lifecycle status, and regulatory obligations.
Document Classification Decisions
Regulators will increasingly expect organizations to explain not only their conclusions but also the rationale behind those conclusions. Maintaining evidence supporting classification decisions is essential.
Establishing The Right Documentation in the Product Profile
Organizations consistently achieve better assessment quality when technical documentation is assembled before assessments begin. Product specifications, architecture diagrams, SBOMs, technical reference manuals, security documentation, and supporting engineering artifacts significantly improve assessment accuracy and reduce unnecessary remediation work later in the process.
Common Pitfalls
In working with our customers, we have seen several common, avoidable mistakes:
Assuming Product Teams Already Know Their Inventory
Many organizations discover hidden products, unsupported versions, acquired technologies, and undocumented software components during CRA readiness efforts.
Treating Classification as a One-Time Activity
Products evolve, features change, connectivity expands, and suppliers update components used to build products. Product classification must be continuously reviewed to maintain appropriate security posture throughout the product lifecycle.
Applying the Same Security Requirements to Every Product
A uniform security model often creates unnecessary costs by applying overly stringent security requirements to lower risk products while failing to focus resources on higher-risk products. The CRA defines multiple security levels to allow organizations to adapt security posture based on risk.
Instead of a single security model applied to all products, companies should adopt a common framework with multiple security tiers mapped to the CRA product security classification tiers.
Ignoring Supplier Components
Third-party hardware and software components, OEM technologies, and open-source software solutions can significantly impact product classification and security obligations. Companies must ensure that suppliers conform to CRA requirements and that they provide appropriate documentation to support CRA compliance programs for end-products utilizing these components.
Action Items for OEMs and Software Vendors
Organizations beginning their CRA journey should consider the following immediate actions:
- Build a complete inventory of all products, software, services, and digital assets.
- Identify products likely to qualify as products with digital elements.
- Develop a formal classification methodology and approval process.
- Create a risk-based security tiering model.
- Establish ownership for every product and platform.
- Map suppliers and software dependencies.
- Document all classification decisions and supporting rationale.
- Implement governance processes to keep classifications current over time.
Companies that address classification challenges early will significantly reduce downstream compliance costs and operational disruptions.
How OmniTrust Certify Can Help
One of the biggest challenges organizations face is not performing the first CRA assessment – it is maintaining accurate product information, cyber risk assessments, regulatory evidence, and classification decisions as products evolve over time.
Certify helps organizations establish a repeatable process by creating a living Product Profile for every connected product. From that foundation, security teams can consistently perform cyber risk assessments, evaluate CRA obligations, maintain supporting evidence, and reassess products whenever documentation, architectures, vulnerabilities, or regulations change.
Rather than relying on disconnected spreadsheets and documents, organizations gain a collaborative system of record that supports product classification, cyber risk governance, regulatory conformity, evidence management, and audit readiness throughout the product lifecycle.
As many early adopters are learning, successful CRA compliance begins long before vulnerability management and incident reporting. It starts with understanding exactly what products you have, what risks they present, and what level of security accountability each product requires.
Getting product classifications right may be the single most important step in building a sustainable CRA compliance program. Click here for more on Certify and our compliance solutions.
Subscribe to the Blog on our blog homepage for notifications on future blogs in this series which continues with “Blog #3: Why Security Maturity is not Enough for CRA Readiness”
