Designing secure IT–OT access without disrupting production

Describe each access use case in operational terms. Separate viewing diagnostic information, collecting logs, changing configuration, updating software and modifying control logic. Engineering should specify the authority and verification appropriate to each activity.

For each use case, identify the target equipment, support organisation, local owner and required tools. Record expected connectivity, timing, file exchange and local participation. Where support software needs broad privileges, make those privileges visible in the approval decision.

An operational requirement should include the consequence of unavailable remote support. The response might be delayed maintenance, local intervention or a controlled production restriction. That consequence helps determine the access platform's availability needs and the acceptable emergency process.

Avoid building a general-purpose path before agreeing its permitted use. A remote desktop into a broad engineering environment can convey much more authority than a narrowly defined diagnostic task requires. Where a broad tool is unavoidable, compensate through scoped reachability, supervision and a reviewed operating boundary.

Create a connection register that includes more than enterprise VPNs. Review supplier-installed devices, cellular links, site-to-site tunnels, remote management tools, cloud relays and temporary commissioning arrangements where present. Discovery should combine engineering knowledge with approved technical evidence.

For each route, record its endpoints, owner, operational purpose, authentication, accessible systems and closure method. Include the evidence date and unresolved assumptions. A route shown on an old drawing should not automatically be treated as the route currently in use.

Validate connectivity through methods suitable for the equipment. Do not introduce scanning, agents or configuration changes into production merely to complete the register. If a fact cannot be confirmed safely, mark it as unknown and plan a controlled verification opportunity.

The register should support decisions about consolidation and exceptions. Some legacy routes may require a staged replacement because they support contractual or technical functions. Document the interim controls and retirement conditions rather than leaving the route outside the managed process.

The proposed model separates the external user, the access-control service and the production target. Its intended flow is:

Approved support endpoint → authenticated access service → controlled session gateway → authorised OT zone and target.

A separate controlled process handles file transfer. Administrative access to the gateway and policy platform is restricted and reviewed independently of ordinary vendor use. The exact deployment, including whether any component is hosted externally, depends on the plant's architecture and requirements.

The design should avoid implying that authentication alone secures the maintenance activity. Each component contributes a different control. A gateway cannot compensate for every target limitation, and a target account cannot establish whether the original connection followed the approved route.

Use individually attributable identities where feasible and document how vendor personnel are approved and removed. Authentication should be appropriate to the exposure, with strong multifactor methods where supported. The organisation must also establish how vendor personnel changes reach the access process.

Bind authorisation to the operational request. It should identify the target, intended task, work window and local approval. A vendor's commercial support entitlement is not sufficient to authorise every change to every machine.

Consider separate access profiles for diagnosis and change. A read-only route may be technically possible for some systems and unavailable for others. Where the tool cannot enforce a desired restriction, do not claim that it does; document the resulting authority and decide whether additional supervision or a different method is needed.

Review target credentials separately from gateway identities. A named remote user entering a shared engineering account may preserve individual attribution only to the extent the session and operating records can establish it. Check whether credentials can be reused through another route and whether the account outlives the approved work.

Remote support often involves software packages, diagnostic outputs and configuration files. The proposed process should define which transfers are permitted, who authorises them and where files are checked before reaching the production target.

Use approved staging and validation suitable for the file type and equipment. Verify software provenance and the expected version, and follow engineering requirements for backup and rollback. A generic malware check is useful in some contexts but does not establish functional compatibility or safe process behaviour.

Diagnostic exports may contain plant configuration, credentials or commercially sensitive information. Define where the vendor may send them, which information is necessary and how retention is handled. An approved support session should not automatically authorise unrestricted data export.

Where legacy tools require features that increase reach or privilege, capture the limitation in the access record. Isolate the function as far as practical, time-bound its use and plan how to improve it. The existence of a tool requirement is a design input to assess, rather than a permanent exemption from oversight.

Before connecting, operations should confirm the equipment state and any maintenance conditions. The work request should distinguish diagnosis from an actual change and identify who can approve an expansion of scope during the session.

During work, the local coordinator should be able to identify the participants, understand the current activity and reach the relevant operational owner. The level of supervision should reflect the task and equipment. Continuous observation may be justified for one activity and impractical or unnecessary for another; record the selected arrangement.

After a change, the engineering owner should perform the agreed verification before accepting completion. Preserve the relevant configuration or version record and document unexpected effects. Cybersecurity approval of the connection does not replace engineering acceptance of the result.

If the vendor discovers a need outside the approved scope, pause and obtain the appropriate authorisation. The process should be practical enough to use during maintenance, with a clear escalation route. A cumbersome ordinary process can encourage unrecorded exceptions unless urgent work is explicitly designed for.

Define the normal ending sequence, timeout behaviour and emergency isolation process. Establish what each action affects: a user session, a remote tool, a network route or a broader service. Plant personnel should understand the expected operational consequence.

Session expiry does not necessarily remove accounts, scheduled tasks or installed software. The closure record should identify access created or changed during the work and establish what remains authorised. Check target-side arrangements as well as the gateway.

Test the disconnect function in an appropriate controlled setting. A successful command to terminate access is only part of the evidence; verify the resulting connection state and whether the production process remains in its expected condition. Operational effects should be assessed by qualified personnel.

Define who may initiate an emergency isolation and who coordinates the plant response. Avoid a blanket instruction that the security team should automatically disconnect all OT access whenever an alert appears. The response must reflect both the threat and the operational conditions.

Centralising access can improve consistency, but it also concentrates control. A compromised policy administrator or unavailable gateway can affect several vendor relationships. Include this platform in security, recovery and administrative-access reviews.

Separate management access from ordinary support sessions. Review who can change policies, approve their own privileges or suppress evidence. Protect recovery configurations and verify that authorised staff can restore the platform without relying on the same unavailable dependency.

Plan for loss of the access service. The approved response might use local support, defer work or activate a tightly controlled alternative. A permanent unrestricted bypass weakens the design. If an emergency route is necessary, document its prerequisites, owner, permitted scope and closure evidence.

The availability objective should reflect how the plant uses remote support. A monitoring-only service and an urgent engineering intervention may require different arrangements. The architecture should make that decision visible instead of relying on a default product configuration.

Keep records that connect a session to the work request, approved individual, target and outcome. Depending on the technology, useful evidence may include authentication events, gateway records, network metadata, configuration changes and engineering acceptance.

Distinguish connection evidence from command or action evidence. A recording may show a screen without establishing every operation on the target. Encrypted or proprietary protocols can limit inspection. State these limits rather than claiming complete visibility.

Synchronised timestamps and an identifiable work reference improve correlation. Assign responsibility for reviewing alerts and exceptions; collecting logs without a review route provides limited operational assurance. Protect sensitive recordings and define access and retention according to the plant's actual requirements.

The following proposed test matrix is intended for adaptation in a lab or approved maintenance setting. Safe test methods and expected operational effects must be agreed before execution.

Testing should produce specific findings. A failed destination restriction requires technical correction or a revised approved boundary. An unclear isolation authority requires governance work. A logging gap may require a narrower assurance claim while a proportionate improvement is planned.

Do not generalise from one successful route to the whole estate. Identify the vendors, protocols, equipment and conditions covered. Retest after changes that could alter the result, such as access-platform upgrades, new remote tools or significant plant network modifications.

During the first month, choose one production area and document its support uses and current routes. Establish ownership, operational constraints and supplier participation. Classify unknowns and select verification methods that are appropriate for the equipment.

During the second month, design the target path and session process. Include files, target privileges, local approval, normal closure and emergency handling. Review the design with operations, engineering, security and relevant suppliers before implementing changes.

During the third month, validate representative sessions in the approved setting. Record findings, refine the process and determine which old routes can be retired safely. Where retirement depends on a supplier change, keep the exception visible with interim controls and a review date.

Expand in stages based on operational consequence and implementation readiness. A group-wide rollout should preserve site differences and maintenance windows. Avoid counting a site as complete simply because a gateway has been installed.

The plant owner is accountable for the operational boundary and acceptable consequences. Engineering defines and accepts equipment changes. OT architecture and security validate the access design and evidence. Supplier management coordinates commercial obligations and personnel changes. These roles need an agreed escalation route for unresolved tradeoffs.

Useful indicators include approved routes with confirmed owners, active exceptions past review date, sessions linked to a work request and target-side access left open after completed work. Define the denominator and evidence period for each measure.

Management should also see access-platform dependencies and validation gaps. A high percentage of sessions using the central gateway does not establish that alternate routes are closed. Combine adoption measures with evidence about actual reach and closure.

Legacy equipment and support constraints can prevent immediate adoption of the target design. The proposed exception record should state the equipment, route, operational purpose, technical limitation and consequences of withdrawing access. Name both the operational acceptance owner and the person responsible for the improvement plan.

Describe compensating measures precisely. “Monitored access” should identify what is observed, by whom, during which period and with what response authority. “Temporary access” should identify the mechanism that ends it and the evidence of closure. If either condition cannot be demonstrated, retain that as an unresolved limitation.

Include the conditions under which the exception must be reconsidered. A new support tool, equipment replacement, change in vendor or expanded network reach can invalidate the original acceptance. Review dates should not become automatic renewals without checking whether the assumptions remain true.

An exception is a management decision within a defined boundary. It should not silently become the default architecture for additional equipment. Where several sites share the same limitation, consider a coordinated engineering solution while preserving site-specific operating approval.

New equipment is an opportunity to reduce future access constraints. Before selection, ask the supplier to demonstrate its support route, identity options, required privileges, file-transfer process and available records. Establish which functions remain usable without an external connection and what happens when the supplier's support service is unavailable.

Request a description of how remote access is enabled and disabled, how supplier personnel changes are handled and how customer authorisation is enforced. Identify any account or connection that the supplier expects to retain permanently. Confirm how updates and support tools interact with the plant's engineering change process.

Treat demonstrations as evidence with a scope. A supplier showing a feature in its own environment does not establish integration with the plant's network and identity design. Record the acceptance checks needed during commissioning and before production use.

Build route registration, documentation handover and closure testing into commissioning. Assign responsibility for removing temporary installation access after acceptance. This gives the plant a clear starting record and avoids leaving commissioning arrangements outside the normal operating process.