The importance of having remote support for incidents

When a line stops, the clock works against you

In any automated industrial facility — a packaging plant, an extrusion line, a public-building BMS or a water treatment plant — incidents always happen at the worst possible moment. And almost never during office hours.

The real cost of a production stop is not measured only in lost hours. You also have to add wasted raw material, missed delivery dates, energy spent on restart and cool-down, contracts with SLA penalties and, in some sectors, regulatory fines. In sectors such as food, pharmaceutical or ceramics, an extended outage can cost between €2,000 and €20,000 per hour, depending on line size and product.

The biggest driver of that cost is not the issue itself, but how quickly you start solving it. That is where remote support makes the difference.

The problem with the "fully on-site" model

For many years, the standard support model in industrial automation has been reactive and on-site: the plant calls, the integrator or manufacturer dispatches a technician, the technician travels, arrives, diagnoses and finally resolves. In that linear flow, the typical times accumulate as follows:

• Notification and incident validation: 15-45 minutes.
• Technician assignment: 30 minutes to several hours, especially out of hours.
• Travel: 1-4 hours depending on distance, up to days for international travel.
• On-site diagnosis: 30 minutes to several hours.
• Resolution: variable, often limited by the lack of spare parts on hand, missing programming software licences or outdated copies of the PLC programme.

The typical result: a problem that an engineer could have diagnosed in 10 minutes from the office ends up causing half a day of downtime. Worse still, the technician does not always arrive with the full context of what the machine was doing right before the failure.

What changes with a properly designed remote support

Remote support is not just "having a VPN to connect to the PLC". A properly designed remote support service combines five elements:

1. Secure technical access: an encrypted, segmented and audited channel that lets engineers reach the PLC, HMI, SCADA or BMS from anywhere.
2. State visibility: the remote engineer must be able to see active alarms, historical data, process values and communication traces — not just download the programme.
3. Defined response procedures: what is done first, who decides what, when to escalate and how to document.
4. Project knowledge: the remote team must hold the programme copy, electrical drawings, signal lists and operating documentation for every machine they support.
5. Agreed availability: a realistic SLA covering critical production hours, not just the integrator's working hours.

Response time comparison: on-site vs remote

The less obvious benefits of remote support

Reducing incident response time is the most evident benefit, but not the only one. When a plant has a well-managed remote support channel, several additional advantages compound over time:

• Data-driven preventive maintenance: the remote engineer can periodically review diagnostics, hour counters, cycle counts and trends to anticipate problems before they become outages.
• Continuous programme improvement: small optimisation tweaks (cycle times, regulation tuning, exception handling) can be applied incrementally without dispatching a technician.
• Automatic programme backups: essential for any critical facility. An outdated PLC programme copy is one of the biggest hidden risks in a modern plant.
• Real-time operator support: during an incident, the remote engineer can guide the plant operator step by step while observing actual system behaviour.
• Traceability and audit: every access is logged: who connected, when, what was changed. Critical in regulated sectors (pharmaceutical, food, water, public infrastructure).
• Lower carbon footprint: fewer site visits mean fewer emissions, an increasingly relevant argument in public-sector projects and companies with ESG commitments.

Cybersecurity: the part you cannot improvise

One of the most legitimate concerns about remote support is security. And it is legitimate because, badly implemented, remote access can become the entry point for an attack on the OT network. The European NIS2 directive and the IEC 62443 standard set increasingly strict requirements on access to industrial networks, and any professional remote support service must comply with them.

A secure remote support must include, as a minimum:

• Encrypted VPN with modern protocols (WireGuard, IPsec/IKEv2, OpenVPN).
• Mandatory multi-factor authentication (MFA) for every access.
• Network segmentation: the remote technician only reaches the devices strictly required for the intervention.
• On-demand access: the connection is enabled only when needed, through explicit authorisation from the plant (a physical key switch, the maintenance manager's permission or platform-side validation).
• Full activity log: audit of access, executed commands and applied changes.
• Credentials policy: named users (never shared), key rotation and immediate revocation when a technician leaves the team.

A remote support provider that cannot clearly explain how it complies with these points should not have access to your plant.

What to look for in a remote support service

Not all remote support contracts are equivalent. When evaluating a proposal, look at:

• SLA with concrete response times, distinguishing blocking from non-blocking incidents and the covered hours.
• Identified technical team, not just a generic support email. Knowing who will respond matters.
• Real project knowledge: the integrator who designed the installation, or a team that has gone through a complete handover, will resolve faster than generic helpdesk support.
• Living documentation: drawings, up-to-date programme, signal list, operating modes description. Without this, remote support becomes guesswork.
• Hour bank or monthly retainer: pay-per-use models tend to work better for occasional incidents; monthly retainers make sense when there is recurring activity.
• Clear escalation procedure: what happens if first-line support cannot resolve the issue, when a specialist is mobilised, in which cases someone is dispatched on-site.

How we approach remote support at Bluemation

At Bluemation, every project is designed with future support in mind from the start. That involves several decisions early on:

• Documenting the project to a quality level that allows resolving incidents without having to rebuild knowledge from scratch.
• Recommending and installing the appropriate remote access infrastructure for each case, from an industrial VPN router — such as the remote connection kit via RU901 — to architectures with a segmented jump server.
• Setting realistic SLAs, calibrated to each plant's criticality, and communicating them transparently.
• Keeping a versioned copy of the programme and the electrical drawings in our internal systems, immediately available when an incident occurs.
• Complying with each customer's cybersecurity requirements, including environments subject to NIS2 or IEC 62443.

If your facility still relies on reactive on-site support and you want to explore how to move to a professional remote support model — or if you already have remote access but you are not sure it meets current security standards — get in touch with us. We carry out a no-commitment assessment of the current situation and propose an improvement plan tailored to your reality.