Machine builders standardize remote service by turning it into a productized operating model: define what support includes, identify the exact resources each job needs, assign customer and OEM responsibilities, install one of a small number of approved site patterns, test service readiness at handover, and run every case through the same intake, authorization, diagnostic, change, closure, and review stages.
The goal is consistency without pretending every customer plant is identical. Standardize the outcomes, evidence, and decision points. Let the customer retain authority over its network, production schedule, machinery safety, and change process.
Why does installed-base support become difficult to scale?
The first few delivered machines often rely on personal knowledge. One engineer remembers the PLC version, another knows which VPN profile reaches the customer, and a third has the only usable backup. As the installed base grows, that informal model creates queues and exceptions. Service teams spend time reconstructing context before diagnosis begins.
Customer environments also differ in addressing, firewalls, identity rules, engineering workstations, and supplier policies. Define the required controls and a small set of approved patterns instead of demanding one flat network design.
The ISA/IEC 62443 series treats automation cybersecurity as shared responsibility among asset owners, product suppliers, integrators, and service providers across the system lifecycle. That is a useful starting point: an OEM remote-service offer should state where its responsibility begins and ends instead of implying the machine builder controls the customer’s whole OT environment.
What should the remote-service catalog contain?
Define a service catalog before choosing technology. Each capability should have its own target, privilege, prerequisites, and evidence.
| Service capability | Typical target | Permission boundary | Required local role | Example completion evidence |
|---|---|---|---|---|
| Status and alarm review | Published dashboard, HMI view, or historian | Read-only application functions where technically supported | Operations contact confirms machine and time range | Findings and recommended next check |
| Application support | Named MES, SCADA, report, or machine service app | One application and assigned role | App owner authorizes support case | Configuration or incident record |
| Managed workstation support | OEM engineering or maintenance workstation | Remote desktop to one host; downstream flows constrained | Local coordinator available for consequential work | Session linked to a case and results recorded |
| Approved file exchange | Controlled transfer location or managed workstation | Named users, file type and destination policy | Customer reviews transfer procedure | File identity, scan or validation result, and recipient |
| PLC or HMI engineering | Managed engineering workstation and selected device flow | Separate privileged role and protocol | Authorized local person confirms work window and machine state | Backup, approved change, validation, and baseline update |
| Software or edge-app update | Site-side platform or named application | Signed or controlled package to an identified target | Customer change owner approves timing | Version, result, rollback status, and open issues |
Do not sell “full remote access” as a single capability. Observation, configuration, and controller changes have different consequences. Separating them makes both customer approval and OEM support training clearer.
Which parts should be standardized across every machine?
Create a machine service record at order or design release, then maintain it through retirement. At minimum, standardize:
- machine, customer, site, and responsible-owner identifiers
- product family, controller, HMI, drive, robot, edge, and application baselines
- the approved service capabilities and exact remote targets
- site-side gateway or workstation pattern and its maintenance owner
- OEM roles and customer roles allowed to use each capability
- backup location and who verifies restoration
- commissioning acceptance, service-readiness, and outage test status
- customer-specific restrictions and approved exceptions
- access review, certificate, license, warranty, and support dates where relevant
- decommissioning state and confirmation that access and stored secrets are removed
Do not copy credentials or sensitive network details into an uncontrolled spreadsheet. Keep each data class in its authorized system and link it by a stable machine ID.
The NIST Manufacturing Profile describes a voluntary, risk-based approach for manufacturing systems and using current and target profiles to communicate desired cybersecurity outcomes. An OEM can use the same principle internally: document the target remote-service state for a machine family, compare each deployment with it, and track justified gaps.
How should OEM and customer responsibilities be divided?
Publish a responsibility matrix as part of the service offer and repeat it in the customer handover.
| Lifecycle activity | Machine builder / OEM | Customer asset owner | Local site or operations role |
|---|---|---|---|
| Service design | Defines supported targets, toolchain, versions, and OEM support roles | Defines site policy, risk expectations, and acceptable patterns | Advises operational constraints |
| Site onboarding | Supplies configuration and acceptance tests | Approves network placement, identities, routes, and data handling | Confirms machine identity and local readiness |
| Routine diagnosis | Assigns a named engineer and records findings | Authorizes access according to the support arrangement | Provides symptoms, machine state, and local observation |
| Process-affecting change | Proposes change, backup, validation, and rollback | Approves through its change procedure | Confirms safe state, witnesses behavior, and can stop work |
| Platform maintenance | Maintains OEM-controlled components and support compatibility as contracted | Maintains customer-controlled network and identity dependencies | Coordinates maintenance window and production impact |
| Incident response | Disables or investigates OEM-side access as required and communicates impact | Leads response for the customer environment | Protects safe local operation and supplies observations |
| Retirement | Removes machine from OEM service systems and documents closure | Removes site access, accounts, routes, and retained data as applicable | Confirms equipment disposition |
One company may hold multiple roles, but every row needs a named owner. Service contracts and local rules determine the final division; the table is an operating template, not a legal allocation of liability.
What site architecture can be repeated without forcing one network?
Offer a small pattern library. One customer may approve application-level publishing for a dashboard. Another may require a managed engineering workstation in a boundary zone. A third may permit a narrowly constrained gateway path to a machine resource. Define the same security outcomes for each pattern:
- unique human identity wherever the platform supports it
- access limited to the approved machine resource and job
- separate routine and privileged engineering roles
- no dependency of local control on the remote connection
- documented owners for the site component, updates, certificates, and backups
- tested removal, outage, reconnect, and recovery behavior
- no unintended route to adjacent customer assets
The NIST Guide to OT Security explains why OT controls must respect performance, reliability, and safety constraints. Do not turn a security pattern into a production dependency. The PLC and local safety system remain authoritative when the remote service, gateway, identity provider, or internet link is unavailable.
For detailed architecture tradeoffs, compare VPN, jump servers, and ZTNA for OT. Use the remote-access rollout checklist to test each site pattern consistently.
What should the standard support runbook look like?
Make the runbook short enough to use and strict enough to stop ambiguous work.
- Intake: record the machine ID, customer contact, symptoms, production state, urgency, and requested outcome.
- Classify: select the service capability and decide whether the case is observation, configuration, or process-affecting engineering.
- Authorize: confirm the customer authorization reference, named OEM engineer, target resource, permitted window, and local coordinator required.
- Prepare: check version compatibility, backups, approved files, communications, stop conditions, and rollback.
- Connect: verify identity and machine target, then begin at the lowest privilege that can complete diagnosis.
- Diagnose: capture observations and distinguish evidence from hypotheses. Do not widen access merely to explore.
- Change if approved: use the separate change procedure; record before-and-after state and validate locally.
- Close: summarize work, remaining risk, customer action, access state, and whether the service record needs an update.
- Learn: review repeated exceptions, missing telemetry, tool incompatibilities, and training gaps in a regular service meeting.
Remote access tools are also used by threat actors, as the joint CISA remote-access guide notes. Inventory support agents and remove redundant or unauthorized tools. Ensure the customer can disable the path without stopping local machine control.
How is service readiness accepted at handover?
Add a remote-service acceptance test to the machine commissioning package. It should prove more than “the engineer connected once.” Test:
- named OEM and customer identities, role separation, and removal
- every published app, workstation, or device against its approved scope
- failed attempts to reach an adjacent target
- observation and engineering permissions as different tests
- the supported PLC/HMI functions, including any discovery or file-transfer requirements
- performance under representative latency and packet loss
- loss of internet, identity, gateway, remote client, and session
- current backup availability and the local recovery briefing
- who receives operational and security notifications from each dependency
- how the customer requests, authorizes, pauses, and ends a support case
Use the remote machine commissioning checklist to integrate these tests with startup and handover. Record exceptions rather than declaring readiness when a required test was skipped.
Which measures show whether the standard is working?
Choose measures that reveal process health without promising a business outcome the data cannot support. Useful examples include the percentage of active machines with a named service owner, current technical baseline, tested support path, recoverable backup, completed access review, and closed onboarding exceptions. Track cases that required unplanned access expansion, unsupported engineering versions, or missing local coordination.
Operational measures such as time to assign a qualified engineer or time to establish the approved support path can help identify friction, but they are not the same as reduced downtime or avoided travel. Those outcomes depend on failure type, parts, staffing, customer decisions, and many other factors. Measure them only with a defined baseline and comparable cases.
The NIST Cybersecurity Framework 2.0 organizes outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. Use those functions as a review lens: Are responsibilities governed? Is the installed base identified? Are paths protected? Can misuse be detected? Can OEM and customer respond together? Can access and machine service recover safely?
What are the limitations, exceptions, and lifecycle controls?
Standardization cannot make every legacy protocol supportable or every task safe to perform remotely. Give each exception an owner, reason, compensating measures, review date, and exit plan. Contain broad legacy protocols behind a managed workstation rather than extending them to every user. If the customer forbids remote engineering, define a diagnostic-only tier and local service procedure.
Review the service record after controller replacement, HMI migration, customer network change, gateway update, ownership change, contract change, or security incident. At retirement, remove identities, links, certificates, licenses, stored project copies, and machine entries according to the agreed data-retention rules. Confirm the customer-side component is removed or transferred to an identified owner.
ISO/TR 22100-4 highlights cybersecurity threats that can influence machinery safety. Revisit the machine risk assessment when a new remote function or update capability can affect a safety-related outcome. A remote-service standard is not evidence of machinery conformity or standards certification.
Where can Orenda fit in a machine-builder service standard?
Orenda Connect can be evaluated as the OEM user interface to approved customer resources within the selected project. Orenda Box can provide a repeatable site-side platform for selected machine data and local applications. The machine-builder solution supports starting with one service workflow. The installed machine base remote service page explains how teams can document and reuse the pattern across individual customer projects and boxes; each site still needs separate validation.
Orenda does not replace the customer’s approval workflow, service desk, comprehensive per-human audit system, machinery-safety process, PLC change record, backup discipline, or local response plan. Orenda vendor links are target-scoped bearer links that are revocable and can use optional expiry; sharing a link does not by itself establish the identity of the individual using it. Define which product evidence is available and combine it with the OEM and customer systems required by the service standard.
Pilot the model on one machine family and a small set of service capabilities. Validate the exact protocols, customer roles, resource boundaries, outage behavior, maintenance ownership, access removal, and handover evidence before extending the service offer across the installed base.
