When a software supplier announces a vulnerability, a machine builder needs to answer: “Which of our delivered machines contain this component?” If engineering, purchasing and service must reconstruct the answer from separate lists, the technical records are missing useful links.
A CRA technical file should explain the delivered product’s security design and how that design was verified. Model, hardware, software version, test evidence and support records must describe the same product. When a customer receives a different release, the relevant documentation must follow it.
Start with an identifiable product
Define the model and its supported configurations. Include the controller, HMI, industrial computer, local applications and remote services needed for the product’s functions. Show the interfaces between them. Make the boundary between the customer’s network and the manufacturer’s service access visible.
Connect the model to each delivered machine through its serial number, hardware revision, installed software version and delivery record. Record later service changes too. “This model uses this software” and “this customer has this release installed” answer different questions.
| Record | Question it should answer |
|---|---|
| Product definition | Which functions and configurations belong to the product? |
| Architecture and data flows | Which components communicate, through which interfaces? |
| Cybersecurity risk assessment | Which design decision addresses each identified risk? |
| Software component inventory | Which component versions are included in the release? |
| Verification evidence | Which requirement was tested, on which setup, with what result? |
| Support and update plan | Who prepares a correction, and how does it reach customers? |
The CRA technical documentation requirements cover product design and the assessment of conformity. These working records help teams maintain the connections needed to explain their product.
Record what an access test proves
“Remote access worked” does not identify the control being tested. Record the release, user permission, target application and expected result. Can the service engineer open the diagnostic application? Can that identity reach another resource without a grant? What happens after the customer removes the partner’s permission?
An illustrative acceptance record might state: “The service group opened the diagnostic application. Access to the production management application was denied. After removal of the partner permission, a new attempt to open diagnostics was denied.” Attach the configuration, date and result to the relevant version.
Test denied operations as well as successful ones. A successful login alone cannot show that the permission boundary works. When an access component changes, the release review should identify which tests need to run again.
Worked example: from a component notice to a customer correction
Suppose a supplier reports a vulnerability in a library used by a diagnostic application. Engineering checks the component inventory for machine software release 3.4. Service identifies the serial numbers running that release. The team can now work from affected installations rather than asking customers to guess their software version.
The developer prepares a correction while the security owner evaluates the vulnerability’s effect on the product. Verification checks the fix, access rules and core application functions. Release approval, test evidence and installation instructions all refer to the same corrected version.
Service arranges the installation with customers and tracks completed and outstanding updates separately. The final record should show more than the existence of a new package: it should connect the affected machines, approved correction and customer delivery. The reporting owner assesses whether the facts meet the Article 14 conditions for active exploitation or a severe incident, and starts the relevant notification process when required.
Keep hardware availability and security support distinct
Orenda offers 10-year hardware availability for Orenda Box. That commitment helps with replacement planning and additions to an installed machine fleet. The security-support period for software is a separate product decision.
Under the CRA, the support period must reflect expected product use and is generally at least five years, with an exception for products expected to be used for less time. A long-lived industrial machine needs an assessment of its own use; the minimum is not a reason to stop planning at five years.
State the support end in customer information. Consider what happens if a software dependency reaches the end of its support before the machine does. Keep the decision, responsible owner and update method with the product records.
Where Orenda fits in the technical file
Orenda Box provides a TPM root of trust and signed update releases. Orenda Connect gives authorized users encrypted access to selected resources without public inbound service ports. Organization users and groups provide a defined basis for access decisions.
App Market applications use shared identity and access controls, with permissions approved by the Box administrator. Developers can include those controls in their application design. The machine manufacturer can record the deployed version, approved permissions and tested service connection alongside the rest of the product evidence.
During a CRA architecture discussion, we can review your system diagram, release records and service method together. The useful outcome is a clear path from the machine at the customer’s site to its components, test evidence and support decisions.
