Robot vendor remote access needs an access plan

Trace access revocation and session end separately — method added 9 October 2026

When a support ticket closes, ask two questions: can the identity still establish access, and what happened to the session that was already running? A record of one does not establish the other. The useful handoff names the affected identity, path and target, identifies the evidence for each result, and leaves unresolved behaviour visible to the site owner.

The joint OT connectivity principles published and reviewed on 15 January 2026 recommend enabling connectivity when needed and disabling it otherwise. They also call for controlled access and monitoring. The principles describe desirable end-states rather than minimum requirements. They support asking for closure evidence, but do not prescribe RobotAtom's fields or prove how a particular gateway handles an existing session. The page was checked on 9 October; this is not a claim that a newer edition was issued.

NIST's SP 1800-45 public abstract describes three demonstrated remote-access architectures for water utilities; its document history identifies the final publication as 24 June 2026. That sector and configuration scope matters. A reference architecture is useful context for qualified design review, not evidence that a buyer's installed robot path has closed. Only the public abstract and history were reviewed for this addition, not the full implementation guide.

Start the revocation side with the approved action record: which identity or permission was affected, the scope of that action and its recorded time. Keep a separate reference for any later-access check, its expected and observed result, and the qualified reviewer. A disabled account screenshot may be relevant evidence, but the reviewer must determine what it covers. If the result is failed, documented only or unavailable, retain that state rather than writing 'revoked successfully' from a completed ticket.

On the session side, identify the evidence for the connection that was already active. Retain its end time where evidenced, the customer-held session log and the owner's review of exceptions. If no active session existed, document the basis for that conclusion and its scope instead of inventing an end event. A supplier's statement, a local application window closing and a buyer-held connection log are different records; name which one was actually reviewed.

In a hypothetical support handoff, the account revocation is documented and a later-access check is rejected, but the existing-session log cannot be located. The revocation evidence remains useful. Session closure remains unresolved until the site's owners review the missing record or determine a safe next step. The inverse also matters: a session-end record can be complete while the permission for another session remains unverified. Do not merge either case into a single green 'closed' status.

The local register now carries three revocation references and three session-closure references. Missing fields remain open independently: filling the revocation side does not clear a session gap. The download preserves the recorded failures, restrictions and next actions. This is an evidence-handoff method, not an automatic verdict; a complete form can describe an unresolved or failed result. The existing disposition and installed-cell checks remain separate.

Agree the observation boundary with the site's cyber, engineering and safety owners before checking live behaviour. This guide supplies no disconnection command, fault-injection procedure or permission to test a running cell. RobotAtom's tool only assembles references in the browser; it does not disable identities, end connections, inspect logs, certify security or approve remote support. Revisit affected evidence when the path, identity service or support arrangement changes.

Remote support is an access path, not a feature checkbox

A provider may need remote access for monitoring, diagnostics, file transfer, software updates, configuration or control. Those purposes are not equivalent. Each creates a different path into robot-related operational technology and needs a named owner, boundary and operating rule.

The useful requirement is therefore not simply "remote support available". It identifies who or what may connect, the assets and actions allowed, the approved time, the security controls, the evidence retained, the way access is revoked and what site operations do when the connection is unavailable or an incident occurs.

Start with purpose, assets and control direction

List every remotely reachable component in the proposed solution: the robot and controller, engineering workstation, fleet manager, PLC, HMI, server, gateway and cloud service where applicable. For each one, state whether the connection is interactive human access or system-to-system communication and whether it can read, write, update, configure or command.

Then ask whether the proposed path is necessary. NIST's final June 2026 operational-technology remote-access guide discusses safety before two-way access and notes that one-way alarming or on-site work can be alternatives in some cases. The guide was built for water and wastewater utilities, but NIST says its concepts are generally relevant to OT operators. That makes it a useful requirements source, not a universal robot architecture.

Put the minimum access plan into the requirement brief

• Give each person and system an attributable identity; do not make a shared or default account the operating plan.
• Define where multi-factor authentication is enforced and which assets, ports, protocols, commands and files each role can use.
• Terminate external sessions at a protected network boundary and restrict traffic to the agreed operational need.
• Set approval and maintenance windows, automatic expiry where appropriate, and an immediate revocation path.
• Inventory remotely accessible hardware, software and services; assign endpoint, gateway, vulnerability and patch responsibilities.
• Log access and material actions, state where evidence is retained and name the person responsible for review.
• Coordinate remote work with site operations and define local fallback, disconnection, incident isolation and recovery steps.

Make ownership part of the provider offer

Remote access often crosses customer, integrator, robot manufacturer, software provider and cloud-service boundaries. The provider offer should say who owns the identity service, gateway, certificates or keys, security configuration, patches, logs, change approval, incident response and evidence export. It should also cover credential removal and customer data handling when a person leaves or the service ends.

IEC PAS 62443-2-2:2025 describes an industrial automation and control system protection scheme spanning technical, physical and process measures across development, validation, operation and maintenance. That public scope supports treating remote access as an asset-owner lifecycle responsibility rather than one product feature. It does not establish that a named system conforms to the full IEC specification.

Test the rejected, expired and disconnected paths

• Confirm an authorized user can perform only the agreed actions on the agreed assets.
• Reject an unknown identity, an invalid second factor and an action outside the assigned role.
• Expire and revoke access, then verify that active and later sessions are handled as designed.
• Interrupt the connection and check the robot system's local fallback, operational notification and recovery process.
• Exercise approved file transfer or update, backup, rollback and post-change testing with the exact proposed versions.
• Verify logs contain the identity, time, target and material action needed for the agreed review and incident process.

Show the installed-cell evidence, not only the access policy

An access policy says what should happen. An as-built diagram shows the proposed path. Neither proves what the installed cell permits today. Before commissioning remote support, ask the provider and site owners to walk one versioned evidence bundle from approved purpose through a witnessed session, an unsuccessful attempt and a clean exit. Keep the contract or change-ticket reference with it.

The Australian Signals Directorate's procurement guidance, updated 3 September 2026, discusses customer-approved service-provider tools, source addresses and windows, and customer-controlled logging for systems including operational technology. These are useful buyer controls, not a certificate for any robot cell or a claim that every private buyer has the same legal obligations. Joint OT connectivity guidance from January 2026 also favours brokered, time-bounded access and a maintained boundary; the exact site design still needs qualified review.

• Record the actual robot, controller, engineering workstation, broker, identity provider and cloud endpoints the path can reach. Keep network direction, ports, software versions and allowed actions with the diagram. Separate observation and diagnostics from file transfer, configuration or command authority.
• Name each human or service identity, customer approver, approved tool and source, connection window and automatic expiry. Preserve the buyer-controlled configuration reference rather than treating a generic vendor security statement as proof of this installation.
• Ask an authorised site team to witness an allowed session and appropriate rejected cases: unknown account, wrong role, unapproved source or expired window. Capture expected and actual result, observer, time, cell version and buyer-held log reference. Plan disruptive tests with engineering, cyber and safety owners; do not fault-inject a live cell from a web checklist.
• Prove how the customer disables the path after a personnel change, contract exit or incident. Record whether existing sessions end, which owner reviews exceptions and what change requires a new access test.

Keep the trace in the buyer's hands

The 2025 joint Secure by Demand procurement guide asks OT buyers to expect authentication, tamper and configuration-change logs that an owner can use. For the proposed installed version, ask for a redacted export showing account, target, timestamp, action and outcome. A screenshot held only by the vendor does not demonstrate that the buyer can investigate or preserve the record independently. Agree alert review and retention with the site's security owner.

Suppose a supplier offers a VPN and a policy promising limited access, but cannot show that an out-of-window attempt is rejected or that the site receives an independent session log. The evidence state is still open. The site can request a witnessed test or redesign the access boundary; it should not call the remote-write path accepted from the policy alone. This is a hypothetical procurement example, not a report of a customer failure.

Carry the proof through changes and exit

Tie every remote configuration or logic change to an approved ticket, the exact changed file or version, post-change checks and the owner who accepted the result. Reopen the access evidence when the gateway, identity service, vendor personnel, network, robot software or support process changes. The separate backup and restoration plan owns how production returns to a known-good state; an access register should point to it, not pretend that logging itself is recovery.

A useful disposition distinguishes observed on this cell, documented only, owner-accepted exception and missing or failed test. A material failed boundary check should hold remote-write access until the site resolves it under its own risk and safety process. RobotAtom's register is a scoping aid; it cannot inspect a network, approve OT tests or certify cyber security.

Treat platform security and supplier statements as scoped evidence

Current ROS 2 documentation demonstrates that traffic can be clear text when security is not enabled and separately documents enforced security, keystores, identities, permissions, governance policies, enclaves and private-key protection. A statement that a product "uses ROS 2" therefore does not show which security configuration is active, who owns its keys or whether a remote-access gateway is controlled.

NIST's examples are voluntary lab reference designs and do not endorse their commercial participants. IEC's public catalogue states a high-level protection-scheme scope, and ROS 2 provides platform instructions. None independently certifies a robot, provider, integration or site. RobotAtom records the access requirement, ownership and evidence state; it does not certify cybersecurity, safety or compliance.

Session disposition method added 2 October 2026

A maintenance window describes when work may be considered. It is not the customer authorization for a particular session, and it does not show that a live session has ended. Keep three records separate: the proposed scope, the site's decision to permit a named activity, and the evidence that the activity and connection closed. The January 2026 joint OT connectivity principles recommend enabling connectivity only when required and disabling it otherwise. They describe desired end-states, not a minimum rule or a certificate for a robot cell.

For one support event, record a redacted authorization reference tying the named identity to the exact target and action. Identify who may stop the session, which approved record contains its end time, and who reviews the retained log. A ticket marked complete is documentary evidence; an observed end to the installed connection is a different fact. The site decides which checks are safe to witness and what unresolved evidence prevents access. Do not perform live disconnection or failed-path tests from this article.

Keep an active session, unknown closure or revoked-but-unverified connection visible as unresolved. Even a complete local record is not an access grant. The evidence register now distinguishes proposed, site-authorized and closed dispositions, and retains documented-only checks as open rather than converting them into observed results. This is RobotAtom's recordkeeping method derived from the guidance, not an official assurance standard.