For manufacturers of machines and devices with embedded software, we build a regime that generates the software bill of materials, keeps the component and licence inventory current, monitors known vulnerabilities and establishes notification and update processes.
For a machinery exporter, the product long consisted of nothing but mechanics and electrics. Today the same machine contains a control board, an operating system, communication libraries, an interface application and, more often than not, remote connectivity. Most of that software is not written from scratch either; it is assembled from ready-made components and open source libraries. The problem is that most manufacturers do not know exactly which components, at which versions, are inside their own product.
That blind spot squeezes from two sides. First, security: when a widespread vulnerability is disclosed in a library in use, the manufacturer's first question is whether its own product is affected — and a firm without an inventory cannot answer that question for days. Second, regulation: under the European Union's Cyber Resilience Act, the obligations on reporting actively exploited vulnerabilities and serious incidents begin on 11 September 2026, with defined timeframes for early warning, detailed notification and a final report after remediation. The full set of additional requirements becomes binding on 11 December 2027.
At the centre of the regime we build is the inventory. A software bill of materials is generated and stored for every version of the product; the answer to which component, at which version, under which licence, sits in which product and at which customer lives in one place. Known vulnerability sources are connected on top of this inventory; when a new vulnerability is disclosed, the affected products and versions are flagged automatically. Response time then depends on decision time, not search time.
The second piece is process. How will vulnerability reports be received, who will assess them, which notification is made in which case, how will the security update reach the customer, and how will you know whether the machine in the field has been updated? Without written answers to those questions, the inventory alone is not enough. Let us also draw an honest line here: the legal scoping assessment — which category your product falls into and which obligations it is subject to — is your legal adviser's territory. We build the technical infrastructure and the process.
Firms building machines that contain a control board, touch panel or remote connectivity. In these products, software has become part of after-sales responsibility, and the job does not end when the machine is delivered.
Businesses that develop their own electronics and interfaces, or embed bought-in modules into their products. The software inside a bought-in module is part of the inventory too — and is usually its darkest corner.
Firms providing support by connecting remotely to machines at customer sites. That connection is an attack surface as much as a service advantage; how it is protected is now a question customers ask too.
Manufacturers placing products on the European market with technical documentation obligations. The software section has been the fastest-growing part of that file in recent years.
For every version of the product, the components inside it, their versions and their sources are compiled by machine. The list is not maintained by hand; it is made an output of the build process, because a hand-maintained inventory stops reflecting reality after the first release.
The licences of the open source components in use are extracted and their compatibility with how your product is distributed is assessed. Some licences carry obligations to supply source code with the product or to give notice; discovering these after export is costly.
Known vulnerability sources are matched against the inventory; when a new vulnerability is disclosed, which product and which version is affected is flagged automatically. Being affected is a matter of how a component is used, not merely whether it is present; an assessment step is defined in the process to make that distinction.
How vulnerability reports are received, who assesses them, which notification is made at which threshold and how the timeline is kept are put in writing. Because the deadlines are short, who does what at the moment of an incident has to be settled in advance.
How an update is prepared, signed and delivered to the customer, and how the version running on each field device is known, is established. Without field version data, there is no knowing whether a published update has actually worked.
Which product version went to which customer is kept on record. When a vulnerability emerges, the list of customers to inform comes from this record; without it, notification is either incomplete or far too broad — and both create problems.
We map which software runs in which products, who developed it and what the bought-in modules contain. For bought-in modules, information has to be requested from the supplier; that request is often the first hurdle and should be planned from the start.
It is wired into the build process; the list is generated and stored automatically for every release. A one-off, hand-prepared list does not solve this, because it becomes invalid every time the product is updated.
The inventory is matched against known vulnerability sources and notification rules are set up. The first run usually produces a large number of records; prioritising them and separating those that genuinely have an impact is a piece of work in itself.
The intake, assessment, decision and reporting processes are written and owners assigned. A short drill is run: the timeline is rehearsed against a hypothetical vulnerability. Processes being read for the first time during a real incident is the riskiest scenario.
The update publishing route and field version tracking are established. The customer notification template is prepared. The process is handed over to the team and the outputs destined for the technical file are defined.
The scoping assessment is a legal question and your legal adviser's territory; the nature of your product and how it is placed on the market are decisive. The technical fact we can state is this: a manufacturer without an inventory cannot quickly say whether its own product is affected when a vulnerability is disclosed — in scope or out of it. That capability is necessary regardless of the regulation.
You are the party placing the product on the market; that is a fact independent of your contract with the supplier. What should be done in practice is to request a software bill of materials and an update commitment from the supplier, and to tie both into the contract. The request is becoming widespread, and suppliers are increasingly prepared for it.
Formal penetration testing is subject to a separate authorisation regime; we do not provide that service. Our work is the audit of code, architecture and components, and the establishment of the process. If you have a penetration test report, we can work on closing its findings.
This is the most neglected part of the job and depends on the machine's connectivity. For remotely connectable products, signed update distribution can be set up; for those without connectivity, updates happen through service visits and the field version inventory is kept manually. We determine the right route by looking at the product and the customer base.
The inventory is a beginning, not the product. The real value is the inventory updating itself automatically with every release and being connected to vulnerability monitoring. A one-off list becomes misleading within a few releases; that is why we place the work inside the build process from the start.
A software bill of materials generated automatically for every product version; a component and licence inventory; a vulnerability monitoring and impact-flagging regime; a written notification and response process; a security update distribution route and a field version inventory. Everything produced, the inventory and source code included, is one hundred per cent yours.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We build an infrastructure where product-level material composition, production history, supply chain trail and repair information is collected, versioned and published through a data carrier. The way to be ready when the date is set is to start accumulating the data today.
Details →If your business depends on a program whose developer can no longer be reached, whose source code is incomplete or which has no documentation at all, we take that system over, establish how it works on the basis of evidence, and bring it back to a state where it can live on.
Details →We find the cause of systems that lock up at end-of-day close, month-end reports that never open, and screens that stall when a few users log in at once — by measuring. Not with guesswork, but with query plans and profiling data, measuring before and after with the same rig.
Details →We protect your critical business flows with automated tests: written acceptance criteria, end-to-end scenarios, a regression suite and automated pre-release runs. What an update broke should be learnt from the tests, not from a customer.
Details →We run security audits on delivered or inherited applications: authorisation and data access flaws, authentication weaknesses, injection risks, secrets and key management, dependency vulnerabilities. We also work on the side of closing the findings.
Details →We assess your existing software estate independently: an architecture map, a technical debt inventory with prioritisation, dependency and vendor lock-in risk, the team's way of working and a realistic roadmap. It is a piece of work that sets direction without writing code.
Details →
