Remote Maintenance Is Disconnected—Can Machine Parameters Still Change at Night?

Remote maintenance has been disconnected, why are machine parameters still likely to be changed at night?

At 9 p.m., the equipment vendor completes remote troubleshooting and the engineer confirms that the connection is closed. During startup the next morning, the team finds that a speed parameter group differs from the previous day. Production says no one operated the machine, while the equipment team says the remote session had already ended, leaving responsibility unresolved.

The most dangerous aspect of such scenarios is not just that parameters may have been changed, but that the factory can only prove that the connection is currently disconnected, yet cannot clarify who, at what time, through which entry point, and what parameters were modified.

The conclusion of remote maintenance should not rely solely on closing a window. It should form a chain of evidence that can be replayed, reviewed, and traced for accountability.

The first breaking point: the entrance is still there, but people have left

A common practice is to provide the equipment vendor with a long-term account, and upon encountering a fault, verbally notify them to log in. After maintenance is completed, the account remains active, and jump servers, VPNs, or device-specific channels may not be synchronized to close.

CISA's industrial control remote access guidelines remind that remote connections bring external users, suppliers, and operational assets into the critical process, thus requiring clear management of access policies rather than treating 'being able to connect' as a default convenience.

NIST's OT security guidelines also emphasize that industrial control systems must balance performance, reliability, and security. For production equipment, an unconfirmed parameter change may affect quality, cycle time, and even personnel safety.

The second breakpoint: the operation has results but no process

Many factories only note "alarm has been restored" on maintenance tickets. There is no structured record of what remote personnel viewed, downloaded, or modified, or whether the program was restarted.

When anomalies occur the next day, teams can only review chat records, ask individuals, and compare a few screenshots. If the handover spans shifts, judgments often become conflicting.

Effective records should at least include five elements: applicant, approver, connection start and end time, target of operation, and before-and-after values. If program downloads are involved, the version, verification result, and rollback point should also be saved.

The third breakpoint: the connection is broken and the permissions are not recovered

After remote sessions, it is essential to confirm that the session has been closed, temporary accounts have expired, shared account passwords have been rotated, and there are no ongoing services, automatic logins, or backup channels.

Equipment personnel should also compare parameter snapshots with baseline values. Just seeing the equipment running does not mean the change has been accepted; merely closing the remote window does not confirm the access has ended.

Turn a remote maintenance into four actions

First, clearly document the equipment, fault, allowed operation scope, and time window before starting work. Second, record key commands and parameter changes during the connection. Third, have shop-floor personnel confirm disconnection and reclaim authority at the end. Fourth, verify programs, parameters, safety interlocks, and first-off results against the baseline before resuming operations.

This approach is suitable for growing factories with connected equipment, external maintenance, and multi-shift handover. Small factories can start with key equipment and avoid building a complex platform from the beginning.

Factory owners should actually be asking whether the system can leave sufficient evidence after anyone leaves. Trust can support collaboration, but permissions and records are essential for protecting production.

If leaving change records is seen as taking responsibility, operators will tend to under-report or delay reporting. Shift supervisors should escalate according to permissions, hand over to equipment engineers for handling and closure, avoiding making the person who identified an issue the problem itself.

Not all factories need complex platforms. Mature factories can perform centralized audits, while small factories should focus on key equipment first. However, authorization, responsibilities, rollback, and handover cannot be overlooked.

During weekly reviews of remote maintenance, focus on three things: whether any changes exceeded authorization, whether any entry points were left open, and whether baseline and first-off inspections were completed after changes. A closed evidence chain ensures that parameters changed at night won't become mysteries the next day.

I am Huang Chaoxing, the inventor of the TreeMES stack-light MES system. Follow me for insights into the management logic behind frontline stories in manufacturing.