Connected Machinery and Remote Access: Cyber Risk on the Shop Floor

A machine builder offers remote diagnostics with a new CNC machining centre or injection-moulding press. Its engineers can investigate faults, adjust approved settings or support an update without waiting for a site visit. A stoppage that might otherwise last days may be resolved in hours.

That is a real operational benefit. The connection may reduce downtime, avoid travel delay and give the manufacturer faster access to specialist knowledge.

The risk does not arise simply because the machine is connected. It arises when the business cannot explain what that connection reaches, who controls it, what the supplier can do through it or how production would recover if the connection had to be removed.

Remote access can therefore be both a useful control and a critical dependency. The right question is not, “Should connected machinery be banned?” It is:

If this connection became unavailable or untrustworthy tomorrow, could we isolate it safely, keep control of the machine and recover production without discovering the design for the first time?

The connection has earned its place—but not permanent exemption from review

Manufacturers adopt remote diagnostics because it works. That matters. A security discussion that ignores the operational benefit will be dismissed, and rightly so.

The purpose of review is not to disconnect useful equipment by default. It is to make the benefit and the dependency visible enough for leadership to decide which controls are proportionate.

The National Cyber Security Centre's operational-technology guidance begins with this balance. It recommends documenting the requirement for a connection, the business benefit it creates and the risks that accompany it. That makes connectivity a governed business decision rather than an inherited commissioning setting.

A connection that was justified when a machine was installed may still be justified five years later. But the supplier, contract, software, network and importance of the machine may all have changed in the meantime. “That is how the vendor set it up” is a history, not an ownership model.

Why the office-network assumption needs testing

Connected production equipment is usually part of operational technology, or OT: the hardware and software that monitors or controls physical processes.

OT and office IT share many security principles, but they do not always share the same operating constraints. A laptop may be restarted after an update with limited consequence. Restarting a controller during a live production cycle may affect equipment, material, quality or safety. Some industrial equipment also depends on older operating systems, specialist applications or protocols that cannot be treated like ordinary office devices.

This does not mean established IT controls are irrelevant. Firewalls, identity management, secure configuration, monitoring, backups and disciplined change control can all contribute. It means their scope and suitability must be verified for the production environment rather than assumed.

The NCSC notes that availability is often prioritised in OT to maintain continuous operation, while resilient design must also protect integrity and confidentiality. The balance has to reflect what the machinery actually does.

That makes this a shared management problem. Engineering understands the machine and safe operating state. IT or security understands identity, networks, monitoring and external access. The vendor understands its product and support route. Leadership owns the operational and financial consequence if those three views do not meet.

Six questions behind every connected machine

1. What does the machine actually connect to?

Begin with the route, not the label on the support contract.

Remote access may use the public internet, a site-to-site VPN, a vendor-managed appliance, a mobile connection or another private service. It may connect only to a defined controller, or the design may allow access to other systems around it.

The NCSC recommends maintaining a clear record of what each OT asset needs to communicate with, which assets it depends on and which assets depend on it. The record should also justify why each connection exists and be reviewed periodically.

For a connected machine, that means being able to show:

• the machine, controller, gateway and supporting devices involved;
• the internal and external systems they communicate with;
• the network path, protocols and ports required;
• the business purpose of the connection;
• the owner who approved it; and
• the controls intended to stop it reaching anything else.

An invoice saying “remote support included” is not a connectivity map.

2. Who can use the access, and when?

The words “vendor access” can hide several different arrangements.

Access might be permanently available to a shared supplier account, limited to named engineers, enabled only after the manufacturer approves a request, or routed through a monitored privileged-access service. Those designs do not create the same exposure.

NCSC guidance treats connections from external vendors and integrators as low-trust because the manufacturer has limited control over the third party's security measures. It also notes that some OT support arrangements still rely on fixed VPNs providing round-the-clock access.

Low trust does not mean the supplier is dishonest. It means trust should be created through controls rather than assumed from the commercial relationship.

Useful questions include:

• Is access persistent or just in time?
• Are individual users identified and strongly authenticated?
• Is access limited to the machine and functions required?
• Who approves each session?
• Are actions logged, monitored or recorded?
• Can the manufacturer revoke access without relying on the supplier?
• Does the support contract restrict the controls the manufacturer can impose?

3. Who owns the decision?

Connected machinery often falls into an organisational gap.

Engineering may have procured the machine. IT may manage the firewall. The vendor may control the remote-support appliance. Operations carries the production consequence. Each party can therefore believe someone else has assessed the whole arrangement when each has only seen one part.

One accountable owner should be able to bring those views together and answer three questions: who accepts the connection, who authorises changes to it and who can order isolation during an incident?

This is not necessarily a full-time cyber role. In a smaller manufacturer, it may be a named operations or engineering leader supported by IT and the supplier. What matters is that ownership is explicit and survives staff changes.

4. Does the business control the information needed to rebuild?

If a controller, industrial computer or gateway had to be replaced, the manufacturer might need current configuration files, machine parameters, software versions, network settings, licences, encryption material and an understood recovery sequence.

Some of that information may legitimately be held or managed by the machine builder. The dependency becomes material when the manufacturer does not know what exists, what it is entitled to receive, how quickly the supplier could provide it or what happens if that supplier is unavailable or itself affected by a cyber incident.

NCSC guidance includes configuration files, asset inventories and technical diagrams within the information required to understand OT architecture. It also stresses that backups must remain available during incidents and should be protected against ransomware.

An “independent backup” does not necessarily mean copying proprietary vendor material without permission. It means having a documented, contractually valid recovery position that the manufacturer has tested: what it holds, what the supplier holds and how the complete machine would be restored.

5. Could the connection be isolated safely?

During a suspected compromise, the instinct may be to disconnect everything. In an OT environment, an unplanned disconnection can itself affect production or safety.

The NCSC recommends an isolation plan linked to wider business-continuity arrangements and tested regularly. The plan should consider supplier contracts, the consequences of losing remote support and the data flows that must remain available.

For one critical machine, the plan should identify:

• who has authority to isolate the connection;
• the technical step that removes or restricts access;
• the safe state of the machine before that step is taken;
• what production functionality would be lost;
• whether on-site vendor attendance would then be required;
• how the business would operate during the interruption; and
• what evidence and checks are required before reconnection.

The test is not whether someone could pull a cable. It is whether the business understands the operational result of doing so.

6. What does safe recovery look like?

Isolation stops or contains a route. Recovery restores a trusted operating state.

That may require validating configurations, changing credentials, rebuilding a gateway, checking controller logic, confirming machine parameters, inspecting affected product and coordinating with the vendor before production restarts.

There may be no credible manual fallback for a highly automated machine. Attempting to improvise one could introduce a different operational or safety risk. Equally, a machine may continue locally without remote support but take longer to diagnose if it fails.

The answer must therefore be established machine by machine. “We would run manually” and “the vendor would sort it” are both assumptions until the method, authority, competence, timing and safety implications are understood.

Composite example: the connection that had never failed

About this example: This is a composite scenario built from recurring connected-machinery and third-party-access patterns. Details and timings have been altered. It is not a named client case, a confirmed cyber incident or a prediction of another manufacturer's outcome.

A precision-engineering business installs a CNC machining centre with the builder's remote-diagnostics package. When difficult faults occur, the supplier can examine the machine remotely and guide recovery without first sending an engineer to site.

The connection performs exactly as intended. It causes no known incident and helps shorten several stoppages.

Two years later, a customer security questionnaire asks which suppliers can remotely access production equipment, what systems they can reach and how that access is controlled.

The manufacturer cannot answer confidently. Engineering knows the supplier uses a support connection. IT can see a route through the network but did not approve the original machine configuration. The support contract describes availability, not the precise access model. No one can confirm whether the current controller configuration is held independently or explain what would happen if the connection had to be disabled immediately.

The customer questionnaire did not reveal that the connection was insecure. It revealed that the manufacturer had never assembled enough evidence to know whether it was secure, contained or recoverable.

That distinction matters. The failure was not adopting remote diagnostics. It was allowing a valuable connection to operate without a single accountable view of the dependency surrounding it.

Warning signs

• No one can produce a current list of production equipment with external or remote connectivity.
• A vendor connection remains permanently available because that was the commissioning default, not because persistent access has been reviewed and approved.
• Engineering, IT and the supplier give different answers about what the connection can reach.
• Remote sessions are not linked to named people, approvals or useful activity logs.
• The business cannot revoke supplier access without contacting the supplier.
• A critical controller's recovery information exists only with the machine builder, with no tested contractual recovery route.
• The effect of isolating a connection on production and machine safety has never been tested.
• “The firewall covers it” is used as an answer without a current network or data-flow record.
• The business-continuity plan addresses cyber disruption to office systems but not loss of connected production equipment or remote support.

Six questions for the board

1. Do we have a current list of every machine with external or remote connectivity and the business purpose of each connection?
2. Which suppliers can remotely access production equipment today, what can they do and is that access persistent or approved only when needed?
3. Who owns each connection across engineering, operations, IT and the vendor—and who has authority to isolate it?
4. Could we rebuild the critical machine's controller, gateway and configuration if the supplier or its remote service were unavailable?
5. Have we tested what happens to production and safety when the most critical remote connection is isolated?
6. Has someone verified which existing security controls actually apply to OT, rather than assuming that office-network policy covers it?

Five actions to take now

1. Map one critical connection. Record the machine, gateway, internal and external destinations, business purpose, supplier and accountable owner.
2. Challenge standing access. Ask the supplier what access permits, who uses it, how sessions are authenticated and logged, and whether access can be enabled only when required.
3. Confirm the recovery position. Document which configurations, software, licences and backups the business holds, which remain with the vendor and how they would be retrieved during an incident.
4. Run a controlled isolation test. With engineering, IT and the supplier involved, test how remote access would be removed, what functionality changes and how a trusted connection would be restored. Do not improvise isolation on live equipment without appropriate technical and safety planning.
5. Close the ownership gap. Name the person who approves the connection, reviews it after change and can coordinate an isolation decision when production and cyber priorities collide.

The InduX view

Connectivity is not the enemy. Unexamined dependency is.

Remote diagnostics can make a manufacturer more resilient by shortening faults and widening access to specialist support. The same arrangement can make recovery dependent on a supplier, gateway, credential, network route or configuration the business does not control.

The objective is to keep the operational benefit while making the dependency governable.

Start with one critical machine. Follow its connection through the InduX sequence:

CHANGE → EXPOSURE → DEPENDENCY → IMPACT → CONTROL → DEFENSIBILITY → RESPONSE

What changed when the machine was connected? What can the route reach? Which vendor, person, service and configuration does production now depend on? What happens if access is lost or misused? Which controls limit that consequence? Can the business demonstrate how the connection is governed? Who decides whether to isolate and restore it?

If leadership cannot answer those questions, the problem is not necessarily that the connection is unsafe. It is that the business is relying on something it cannot yet explain.

---

Sources and further reading

• Secure connectivity principles for operational technology — National Cyber Security Centre
• Identify and document connectivity within your OT system — National Cyber Security Centre
• Understand and document third-party risks to your OT system — National Cyber Security Centre
• Establish an isolation plan — National Cyber Security Centre
• Using privileged-access workstations in OT environments — National Cyber Security Centre

This article provides general information and prompts for management discussion. It is not cyber-security, engineering, legal, safety, insurance or other professional advice. Connected equipment, isolation and recovery arrangements should be assessed by appropriately competent people for the specific machinery, network and operating environment.