Guide | 6 min read
Industrial remote access review guide
How to trace an industrial remote-access path, test ownership and authorisation, and retain evidence without disrupting legitimate support.
Start with the complete access path
A remote-access service is more than the VPN or jump host. Trace the route from the user's managed device and identity source through approval, authentication, network enforcement and the account used on the target asset.
Record who needs the route, why it exists, which assets it can reach, who enables it and how the session is closed. Do not remove a route until the operational support dependency and recovery plan are understood.
| Review point | Question | Evidence |
|---|---|---|
| Identity | Is the human user attributable throughout the session? | Named account, identity-provider record and target-system account mapping |
| Authorisation | Who approves access, for which system and for how long? | Request, approval, expiry and emergency-access procedure |
| Path | Can the session reach anything beyond the approved target? | Current architecture, firewall rules, jump-host configuration and route test |
| Activity | Can important session and administration events be reconstructed? | Time-synchronised access, system and security logs with defined retention |
| Close-out | How is access disabled and reviewed after work? | Session closure, account disablement and periodic supplier-access review |
Shared accounts break attribution
A named VPN identity does not provide end-to-end attribution if every engineer then uses the same local administrator account. Where a legacy target cannot support individual accounts, record the limitation and design compensating evidence at the closest controllable point.
Possible measures include one approved user per session, time-bound access, session recording, enhanced jump-host logging and a controlled checkout process for the shared credential. These measures manage a constraint; they do not make the shared account equivalent to individual identity.
Worked example: time-bound vendor support
| Stage | Expected control | Evidence retained |
|---|---|---|
| Request | A named engineer, target system, reason and maintenance window are approved. | Access request and approver record |
| Connect | MFA is completed and the authorised route reaches only the approved jump host or target. | Authentication event and connection log |
| Work | Administrative activity is attributable and system time supports log correlation. | Session record plus target security or change log |
| Close | The connection is ended, temporary rights are removed and the engineering change is recorded. | Closure record, account state and change reference |
Test the full installed route during SAT or commissioning when the factory setup cannot represent site firewalls, identity services or log destinations. Agree safe methods before testing a live system.
This is a worked technical example, not a completed Meridian client engagement.
Review outcome
The output should identify each access path, business owner, target, identity model, approval control, network restriction, logging point and close-out action. Unknown or always-on routes should remain explicit in the action register.
The aim is controlled supportability: remove unnecessary exposure while preserving a route that operations can authorise, observe and withdraw when genuine support is needed.
Related support and guidance
Where this connects to project work
If the issue described here forms part of a wider assessment or engineering programme, Meridian's ot cybersecurity assessments covers the scope, evidence and technical decisions needed for a defined engagement.