Cyber Resilience Act (CRA): What manufacturers of digital products need to know now

A router that stops receiving security updates after two years. A networked machine control system where no one can say for sure which open-source libraries are inside. Such cases were long an annoyance, but not a legal violation. That is now changing: With the Cyber Resilience Act (CRA), the EU has established binding cybersecurity requirements for connected products for the first time. For manufacturers, the first major operational compliance date was September 11, 2026. 

What is the Cyber Resilience Act?  

The Cyber Resilience Act (CRA) is an EU regulation that introduces uniform cybersecurity requirements for so-called “products with digital elements”. This refers to hardware and software that are directly or indirectly connected to other devices or networks. The regulation was published in the Official Journal of the EU on November 20, 2024, and entered into force on December 10, 2024.  

The underlying concept: Cybersecurity should no longer be something that is retrofitted after an incident, but a feature that is considered across the entire product lifecycle – from concept through development and production to the usage phase. As an EU regulation, the CRA applies directly in all member states; no national implementation is required.  

Thus, the CRA aligns with a logic familiar from product safety law: Anyone placing a product on the European market must be able to prove that it meets certain requirements. What is new is that cybersecurity is now explicitly included.  

Who is affected by the CRA?  

 Manufacturers, importers, and distributors of products with digital elements placed on the EU market are affected. The scope of application is intentionally broad, ranging from consumer devices like smartwatches and baby monitors to industrial components, IoT sensors, firewalls, and routers. Pure software products also fall under its scope.  

The CRA differentiates based on risk: In addition to the default category, there are “important” and “critical” products with digital elements, for which stricter conformity assessment requirements apply. For manufacturers, this means first of all: It is worth assessing your own portfolio early on to determine which products fall under the scope of application at all and which category they belong to.  

Another point that is easily overlooked is also important: The reporting obligations from September 2026 apply not only to products newly placed on the market after this date. They also cover products that have already been in the field for years. For many companies, this means having to deal with an installed base whose software versions are not consistently documented.  

The supply chain adds another layer of complexity. Today, hardly any connected product consists solely of proprietary code – open-source libraries, purchased modules, and firmware from suppliers are the rule. Responsibility toward the market remains with the manufacturer, regardless of where a vulnerability originates.  

Timeline and Deadlines  

The CRA becomes effective in stages. Here are the dates you should have on your calendar:  

The reporting deadlines are the part that experience shows puts organizations under pressure first. 24 hours is not a time frame in which a reporting chain can still be improvised – the processes, responsibilities, and contact channels must be established beforehand.  

The Key Obligations for Manufacturers  

In terms of content, the requirements of the CRA can be boiled down to a few key points:  

Risk assessment over the lifecycle. Manufacturers must assess, document, and implement appropriate cybersecurity risk protection measures – not just once, but continuously across design, development, production, and usage.  

Software Bill of Materials (SBOM). A machine-readable bill of materials of the contained software components must be maintained for every affected product, at least down to the level of direct dependencies. Common formats are SPDX and CycloneDX. The SBOM does not need to be published, but it belongs in the technical documentation and must be presented to market surveillance authorities upon request. And it must stay up to date: Every update potentially changes the software version.  

Vulnerability and patch management. Security updates must be provided over an appropriate support period. This requires manufacturers to know which software version and configuration were delivered with a particular product and which versions are currently installed in the field. 

Technical documentation and CE marking. From December 2027, CE marking is a prerequisite for market access. It is based on documentation that makes conformity verifiable.  

The sanctions are substantial: Non-compliance can be penalized with fines of up to 15 million euros or 2.5 percent of total worldwide annual turnover.  

What Companies Should Do Now  

Companies that have not yet completed their reporting readiness should treat this as an immediate operational priority. Four steps are a sensible starting point:  

  1. Clarify applicability. Which products fall within the scope of application and which risk class applies?  
  1. Set up reporting processes. The 24-hour deadline starting in September 2026 is the immediate hurdle. Who reports, to whom, via which channel – and who decides whether a vulnerability is “actively exploited”?  
  1. Build SBOM capabilities. This should not be understood as a one-off project, but as part of the development and release process.  
  1. Clarify responsibilities. The CRA affects security, product development, quality assurance, and compliance simultaneously. Without clear assignment, the task gets lost between departments. 

Rather than running these activities as a separate compliance project alongside product development, companies should embed them into existing development and release processes. Requirements that live only in a separate proof folder quickly become outdated – those anchored in the release process remain up to date.  

Where a Consistent Product Database Helps  

Most CRA requirements ultimately lead back to the same question: Can you state – even five years after delivery – which components a particular product contains, which requirements applied to it, and which software version and configuration were delivered?  

This is precisely where a PLM platform comes in. CONTACT Elements maps the product lifecycle end-to-end and links requirements, components, documents, and revision statuses with one another. This traceability is not CRA compliance in itself – but it is the foundation on which SBOM maintenance, technical documentation, and proof management for authorities can be organized in a practical manner, rather than scrambling to gather them from scattered sources in an emergency.  

If you are considering how to integrate CRA requirements into your existing development processes, please feel free to contact us.  

Conclusion  

The Cyber Resilience Act shifts cybersecurity from a voluntary quality issue to a prerequisite for market access. The deadlines in September 2026 and December 2027 may seem comfortable at first glance, but they affect processes that cannot be built overnight – in particular, reporting chains and a reliable documentation of your own software inventory. The best time to start is well before the deadline. 

Shipbuilding meets digitalization: two years in the SEUS research project

Two intense years in the European research project SEUS are now behind me. Our shared goal: to drive the digitalization of European shipbuilding forward. The need for this remains as pressing as ever. The EU continuously funds research and development projects in the maritime sector to strengthen Europe’s position in global competition – which is vital for survival given the low-wage countries and extensive subsidies in markets outside of Europe.

Although European quality is highly valued in the maritime industry, cost pressures are forcing even this traditional sector to achieve massive efficiency gains and optimize its processes. This is exactly where we at CONTACT came in: as an integral partner in this research and a driving force behind the transformation, our goal was to provide the crucial data backbone required for successful digitalization.

A floating city – and what it has to do with PLM

First, we had to dive deep into the complex requirements and processes of shipbuilding to truly understand them. Through intensive discussions with shipyards, in-depth analyses, and a thorough review of the current state of research, we were able to build a comprehensive foundation of knowledge.

What really impressed us was the meticulous care with which the shipyards in this project process enormous volumes of information, collaborate securely across disciplines, and confidently navigate strict classification requirements. This involves tens of thousands of pages of test reports, calculations, manuals, and technical specifications.

What is being built here is nothing less than a small, self-sustaining city floating across the oceans – a construction process that never fails to fascinate. This is just as true for classic cargo and container vessels as it is for highly specialized cable-laying vessels, complex research ships, or military vessels.

The data backbone: connecting the maritime world

The greatest challenge lies in efficiently managing and transparently controlling the diverse information generated across all disciplines, engineering phases, and construction stages. To address this, we developed a data model specifically tailored to shipbuilding that connects all types of information, including project schedules, CAD models, simulation results, engineering designs, and supplier contracts.

Viewing the ship as a “physically massive and complex system” is crucial here. This means that instead of a few individuals keeping track of the entire vessel, a large number of engineers divide the work into smaller areas of responsibility. Depending on the engineering task and phase, they look at the ship from different angles. For example, while designing the propulsion unit focuses primarily on the architecture of that specific system, designing the ship’s hull centers on spatial layout.

A traditional product structure, which hierarchically organizes parts and assemblies based on how they fit together, cannot meet these demands. There is not one “true” product structure; instead, there are multiple viewpoints: systemic, spatial, production-centric, and module-oriented.
Many shipyards and engineering offices use a centralized system structure, as a large portion of the work involves designing, engineering, and integrating systems of all kinds. In Europe, the “SFI Group System” has established itself as the de facto standard for this purpose. This three-level standard catalog contains 4,080 entries for systems and subsystems that can be found in any type of vessel.

Schematic Diagram of Shipbuilding
CONTACT’s data model expands the standard catalog with additional perspectives.

Our IT architects designed a data model that systematically maps these other perspectives around this standard (for details, see our paper on Zenodo). In early-stage ship design, systems are first roughly dimensioned using placeholders. For example, you might specify that an engine is needed, but not yet which particular model. These placeholders – referred to below as “items” – are organized according to the SFI Group System catalogs.

As development progresses, we link these items to additional structures that form the basis of the other perspectives. Using the previous propulsion example, this could mean selecting a specific engine for that item. In addition to relevant documents, requirements, specifications, and project tasks, a CAD model can also be linked. Our partner Cadmatic enables this through a deep integration of CAD tools.

Although the project is not yet complete, a shipbuilding-specific PLM backbone, the flexible and modular CONTACT Elements platform, and the deep integration with marine CAD software already form a solid foundation for further application-level development. The sheer scale of these projects highlights why this is so critical: if even ten documents, such as specifications, CAD files, analyses, manuals, and test reports, are associated with each of the up to 4,000 possible subsystems, you quickly end up with massive amounts of data that would be uncontrollable without structured management.

On top of that, each of these documents goes through its own lifecycles, reviews, and approvals that must be coordinated both internally and with external partners. Seamless, traceable document management across corporate boundaries is therefore absolutely vital, and thanks to an extension in CONTACT Elements for shipbuilding, it is fully achievable.

To learn more about the background and the partners involved, check out the SEUS Annual Report 2025.

From hype to reality: Why AI system integration is critical

The hype surrounding Artificial Intelligence in engineering is massive. Almost every software vendor now offers smart AI features. When applied correctly, AI-powered solutions deliver maximum leverage right where engineers and designers waste valuable time every day, whether on tedious routine work or background tasks. Examples include automated test case generation, understanding complex documents, or quickly assessing minor design changes.

But behind the scenes, the industry’s reality paints a sobering picture. According to a CIMdata study, while about 80% of software vendors already offer AI features in their portfolios, the actual adoption rate among industrial customers is only 8% to 33%. Nearly nine out of ten industrial companies use AI in less than a quarter of their projects, leaving most initiatives stuck in pilot mode. So why is adoption stalling?

The challenge: the invisible data wall

The biggest hurdle isn’t the algorithm itself, but what comes next: AI integration. For industrial customers, seamless connection to existing systems is a key selection criterion. Yet software and service providers systematically underestimate this barrier. In practice, service providers encounter unexpected issues with legacy systems 2.4 times more often than customers anticipate. When new AI tools are bolted onto existing systems in isolation, they fail when faced with the reality of complex engineering processes. As our Chief Product Officer Frank Patz-Brockmann puts it: “The real pain point isn’t buying the software but getting it activated.”

Integration over API patchwork

CONTACT Software is tackling this problem head-on with Fourier AI. We need to view AI system integration as a fundamental architectural decision, not an afterthought or a quick DIY project. Instead of connecting an isolated external AI via standard interfaces, Fourier AI is deeply embedded as a fully integrated intelligence layer within our proven CONTACT Elements platform.

In customer discussions, we sometimes encounter an urge to throw established data structures overboard and replace them with a “data lake” or even a “data swamp” in the hope that the AI will somehow piece the information together on its own. However, this is entirely the wrong approach, because AI thrives on structured data.

That’s why with Fourier AI, we rely on a clear, bottom-up layered architecture:

  1. A Single Source of Truth (PLM) as the foundation: At the very base is still the PLM system with its highly structured data. This foundation is essential and serves as the reliable starting point for any intelligence.
  2. Context building: Simply storing data somewhere isn’t enough. A precise context must be constructed for the AI. For example, if a user submits a prompt like “Give me all data on this Engineering Change,” this context layer needs to know exactly which data belongs to it, who created it, and how everything is connected.
  3. The model layer: Sitting above that is the model layer. In addition to leading external models, we offer our own specialized models, such as for 3D similarity search. The system automatically selects the right model for specific platform tasks while giving companies the freedom to choose which models they want to access for their custom use cases.
  4. AI orchestration & governance: To evaluate and continuously improve answers, generated execution traces are captured and logged. The system filters data so the model only returns information the specific user is authorized to see via integrated permission controls.
  5. User interaction (the PLM chatbot): At the top layer is the user, who interacts directly by typing a query into the PLM chatbot, for example.

Conclusion: Foundation first, value follows

This deep architectural approach initially requires more diligence when structuring data and preparing systems. But that’s precisely where the key advantage lies: because the foundation is cleanly built from day one, the AI layer automatically adapts whenever a customer expands their data model in CONTACT Elements – without writing a single line of additional code. This is how we bridge the gap between mere tech gimmicks and genuine, productive value in day-to-day engineering.

Learn more about this topic in our Live Talk: