Paul Vandamme (Spotit): from CRA compliance to business continuity

Paul Vandamme, Head of Consulting at Spotit, opened the afternoon with the bigger picture. He used two cases as a starting point: NotPetya in 2017, which caused 10 billion dollars in damage worldwide after one update to one accounting package brought everything to a halt (Maersk alone lost 300 million dollars and had to replace 45,000 PCs), and the ransomware attack on Collins Aerospace in September 2025, which forced Brussels Airport into manual paper check-in. Two examples, one lesson: one upstream incident creates downstream victims.

His central message: cybersecurity no longer stops at the edge of your network. In the past, a CISO protected users, infrastructure, and data inside the company. From now on, that responsibility travels with every product with digital elements you place on the market, through the full chain from company to product to customer to ecosystem, and for the entire support period of the product.

He gave five concrete steps for when a product incident occurs: record the moment of awareness (Time Zero) with evidence, declare the product incident internally to activate the crisis governance, immediately form the cross-functional team (PSIRT, engineering, legal, product, support, communications, management), define the scope (which products, versions, components, and customers are affected), and start the reporting process right away. Do not wait until every technical detail is known. The CISO runs the governance, but does not patch alone.

Willem Magerman (Cingulum): the concrete steps of Article 14

Willem Magerman from Cingulum translated the regulation into a workable process. His main warning: do not confuse vulnerability management with regulatory reporting. These are two processes that cross paths but are not the same thing. Finding a vulnerability leads to a simple question: is our product or component compromised? If not, documenting and monitoring is enough. Is there evidence of active exploitation, or a severe incident affecting the product's security? Only then does the reporting duty kick in, with its tight timeline of 24 hours for an initial notification, 72 hours for a full report, and 14 days for a final report.

To make this tangible, he had the room think through a tabletop scenario: it is 03:00 and exploitation has just been confirmed. Who records Time Zero? Who reports within 24 hours? Who decides whether production stops or continues? His advice: assign one name per question in advance. If you only look for those names at the moment of an incident, you are already too late.

Stijn Boussemaere (Spinae): the SBOM as the ingredients list of your software

Stijn Boussemaere, co-founder of Spinae, built his session on experience from more than 25 ongoing CRA projects. His starting point was a familiar scenario: a director reads in the newspaper that a similar company got hacked through a vulnerable software component, and immediately asks "can this happen to us?" To answer that question, you need to know which components are inside your own products. This is where the SBOM (Software Bill of Materials) comes in: a formal document listing all components, libraries, and frameworks that make up your software product. In short: the ingredients list of your code.

This is not optional advice. Under Annex I, Part II of the CRA, manufacturers of products with digital elements must identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used and machine-readable format, covering at least the top-level dependencies. The SBOM does not need to be made public, but it does need to exist and stay current. Without that list, you cannot quickly answer whether a newly discovered vulnerability in a popular library also affects your products.

Koen Pauwelyn (Siemens): CRA for machine builders

The afternoon closed with Koen Pauwelyn from Siemens, in a session aimed at machine builders, a group that is particularly large in Flanders. His key point: make a clear distinction between components and systems. A component supplier and a machine builder are both responsible for the conformity of their own part, but those responsibilities are not interchangeable.

He illustrated this with a concrete example: a Belgian machine builder building an automated packaging line for food producers using a Siemens SIMATIC S7-1500 PLC, ET 200 distributed I/O, an HMI panel, and a SCALANCE switch. Siemens is responsible for the security of its own products and publishes advisories for vulnerabilities. The machine builder is responsible for correct integration, secure configuration, the PLC application logic, and the final risk assessment and CRA compliance of the complete machine. Even when every component already carries its own CE mark, the combination, meaning the new machine, must be reassessed and, where needed, recertified.

On the technical side, he showed what a "protected machine" looks like in practice: network segmentation through a DMZ between IT and OT, firewalls with routing capability between cells, and redundancy on the critical network structure. Risk reduction starts with segmentation, not with a single security layer. Koen also explained some Siemens products that can help, like Vilocify and SINEC Security Guard for vulnerability management