---
title: Machine & plant builders
canonical: https://www.secnostic.com/en/solutions/machine-builders
language: en
dateModified: 2026-08-23
alternate-de: https://www.secnostic.com/de/solutions/machine-builders
---

# Machine & plant builders

- URL: https://www.secnostic.com/en/solutions/machine-builders
- Audience: Installed base for machine builders
- Positioning: From FAT to lifecycle: every machine in view

secnostic documents which digital components are installed in every delivered machine, at which firmware level, and with which communication relationships. That creates a reference state at delivery, and from it one central view of the installed machine base.

**From FAT to lifecycle**

From 20 January 2027, Machinery Regulation 2023/1230 requires that relevant interventions in hardware, software, and configuration become traceable. The Cyber Resilience Act requires vulnerability handling during the support period for products within its scope. Both kinds of evidence start from the real state of every delivered machine, which the sensor records passively.

**Situation.** Between design, control cabinet assembly, software development, and commissioning, components and version levels change. What matters is not what was planned, but what is actually inside the machine at delivery. With the CRA and the Machinery Regulation, that real product state becomes commercially relevant.

**Challenges**

- the target structure from engineering and the controllers, HMIs, industrial PCs, switches, and drives actually installed drift apart until acceptance
- firmware and software levels of delivered machines can only be reconstructed from project folders and service reports after handover
- a vendor advisory for one firmware version triggers a search for which projects, customers, and machines are affected at all
- during a warranty incident it is unclear whether the machine's state still matches the state that was delivered
- the CRA and the Machinery Regulation require technical evidence and vulnerability handling across the support period, without the installed base being known centrally

**Approach.** Every machine or machine segment receives a secnostic sensor. Assets, firmware levels, and communication relationships come together in secnostic inventory: before delivery as the reference state, afterwards with the operator's approval. Changes, vulnerabilities, and lifecycle stay assigned per machine and customer.

**Outcomes**

- a documented reference state of every machine at delivery
- one central installed base across customers and machines
- affected machines found precisely when an advisory lands
- technical evidence for the CRA and the Machinery Regulation

**What stays open without a documented machine state**

After handover, the real question begins: what is inside which machine at which customer?

- **Target and actual drift apart**: Between engineering, cabinet assembly, and commissioning, components and versions change until acceptance.
- **Firmware levels live in project folders**: After handover, software and firmware levels can only be reconstructed from project folders and service reports.
- **An advisory with no link to the base**: A vendor advisory for one firmware version starts a search across projects, customers, and machines.
- **Warranty without a reference**: During a warranty incident it is unclear whether the machine still matches the state that was delivered.

**From engineering to the installed base**

Six stations in a machine's life where the same documented state keeps working.

1. **Engineering** What should be inside the machine? Target structure, approved components, and documented target levels from engineering form the reference for the later comparison.
2. **FAT and final inspection** What is actually inside? The secnostic sensor passively captures the reachable controllers, HMIs, industrial PCs, switches, and drives with addresses and firmware levels, where technically available. Target and actual are compared before acceptance.
3. **Delivery** Which state leaves the factory? The approved state is documented as the reference: the technical fingerprint of the delivered machine.
4. **Warranty and service** Does the machine still match delivery? Only with the operator's approval does the sensor keep observing. Changes against the reference state then become traceable: replaced components, new firmware levels, additional devices.
5. **Vulnerability management** Which machines does a new vulnerability hit? A vendor advisory becomes a query against the installed base: component, version, affected machines, customers. The assessment stays with the manufacturer.
6. **Lifecycle** How does the base age? Hardware, firmware, EOL/EOS, and changes stay assigned to each machine and customer, from a single asset to the whole installed base.

**Across the machine's life, four situations**

Four recurring situations between factory, customer, and installed base, each as a concrete flow.

- **FAT and delivery**: Capture: At the FAT, the sensor captures the actual state of the machine without disturbing the test run.; Reconcile: The target structure and approved components from engineering are compared with the actual state.; Resolve: Deviations are resolved before acceptance instead of being discovered later at the customer.; Document: The approved state is recorded as the reference of the delivered machine.
- **An incident under warranty**: Report: A customer reports an incident on a machine that is still under warranty.; Pull the reference: The documented delivered state shows what was installed and at which level.; Compare: The comparison with the current state shows replaced components, changed levels, and new communication paths.; Decide: Service and warranty questions rest on a documented state instead of assumptions.
- **A vendor advisory arrives**: Advisory: A component vendor reports a vulnerability in one specific firmware version.; Query: The advisory becomes a query: component, version, vulnerability, affected machines, customers.; Prioritize: Affected machines are sorted by customer, deployment, and support commitments.; Decide: Assessment, action, and customer communication stay with the manufacturer, backed by a dependable base instead of a project-folder search.
- **Retrofit and lifecycle**: Review the base: EOL/EOS levels and discontinued components become visible across the whole base.; Group: Machines with the same discontinued components are grouped into retrofit candidates.; Approach: Service approaches customers with a concrete machine reference instead of a bulk mailing.; Track: Retrofits are documented as the new reference state with the operator's approval.

**Deployment steps**

1. **Engineering**: Target structure, approved components, and documented target levels form the reference against which the real state is compared later.
2. **FAT and final inspection**: The secnostic sensor captures the actual state of the machine: reachable controllers, HMIs, industrial PCs, switches, drives, addresses, firmware levels, and communication relationships. Target and actual are compared.
3. **Delivery**: The approved state is documented as the reference: the digital fingerprint of the delivered machine.
4. **Warranty and service**: With the operator's approval, changes against the delivered state become traceable: replaced components, new firmware levels, additional devices, and new communication paths.
5. **Vulnerability management**: New vulnerabilities are checked against the installed machine base: which delivered machines contain the affected component in the affected version?
6. **Lifecycle**: Hardware, firmware, EOL/EOS, changes, and service information stay assigned to the individual machine, from a single asset to the worldwide installed base.

**What becomes visible**

- **Delivered state**: Controllers, remote I/O, HMIs, industrial PCs, switches, drives, and intelligent field devices with vendor, device type, addresses, and firmware levels at the moment of handover.
- **Installed base**: All delivered machines with customer, site, components, and hardware and firmware levels in one central view.
- **Changes**: Replaced components, changed firmware levels, additional devices, and new communication relationships against the documented reference state.
- **Vulnerabilities and lifecycle**: Affected machines per vulnerability, EOL/EOS levels, retrofit candidates, and service information across the whole base.

**FAQ**

- Q: Does secnostic replace the risk assessment, the SBOM, or the CE process?
  A: No. Risk assessment, SBOM, conformity assessment, and CE marking remain the manufacturer's tasks. secnostic provides the technical transparency those processes build on: to assess a vulnerability, you first need to know which components and versions are actually used in which machine.
- Q: What does the secnostic sensor capture in a machine?
  A: The reachable digital components such as controllers, remote I/O, HMIs, industrial PCs, switches, drives, and other intelligent field devices with IP and MAC address, vendor, device type, and software and firmware levels where technically available, plus the communication relationships inside the machine. Components that are not IP-based or sit behind gateways need supplementary engineering or vendor data.
- Q: How does the documented delivered state help during warranty?
  A: During an incident, the analysis no longer starts with the question of what is installed there. The reference state is documented, and the comparison with the current state shows whether components were replaced, firmware levels changed, devices added, or communication paths introduced.
- Q: Does the sensor stay in the machine after delivery?
  A: That is decided by the machine builder and the operator together. The sensor can remain part of the delivered machine and, with the operator's approval, keep observing passively; the data stays assigned to the operator and the individual machine. Without a sensor in operation, the documented delivered state still remains as the reference.
- Q: What role do the CRA, the Machinery Regulation, and NIS2 play?
  A: EU Machinery Regulation 2023/1230 applies from 20 January 2027 and adds cyber safety to the essential requirements. The main obligations of the Cyber Resilience Act apply from 11 December 2027 to new products with digital elements that fall within its scope, including risk assessment, technical documentation, and vulnerability handling during the support period. NIS2 addresses organizations, not products; affectedness has to be assessed per organization, so for the delivered machine NIS2 is only a supporting consideration.
