Vendor remote access into operational technology should be treated as a controlled path with evidence at every handoff. The final NIST SP 1800-45 practice guide describes access by authorized outside personnel, including vendors and contractors, and maps safeguards for authentication, permissions, logs, time limits and protected network termination. A buyer needs to verify those safeguards in its own environment before a support route becomes the assumed safe route.
Quick answer. An OT vendor remote access test should prove who can enter, through which gateway, at what time, to which approved resource, with what monitoring and with what revocation path. Active testing belongs on written-authorized external, identity, IT and DMZ components; production controllers, HMIs, safety systems and industrial protocols need an OT-led lab or tabletop decision under NIST SP 800-82 Rev. 3. Stingrai can test the human-led network and segmentation portion of that boundary and provide findings and retest evidence.
This is a procurement and acceptance tool, not a universal architecture drawing. A utility may use a managed cloud gateway, a plant may operate its own jump environment, and a remote station may use a machine-to-machine link. The test should follow the actual route rather than assume that a VPN or jump host is inherently safe. NIST SP 1800-45 is a voluntary practice guide for water and wastewater systems; NIST says its concepts are generally relevant to OT operators. Its final publication date is June 2026. At this article's October 2026 cutoff, SP 800-82 Rev. 3 remains final, while Rev. 4 is an initial public draft.
The decision this matrix supports
An asset owner normally asks for this work at a vendor contract renewal, a new integrator connection, a gateway migration, a merger of site networks, or a change to remote support hours. The procurement question is not just whether a provider can find vulnerabilities. It is whether the provider can demonstrate the owner's intended access policy against the route suppliers use without disrupting operations.
A good statement of work names the vendor persona, the owned identity, the external entry point, the broker or jump host, the approved destination class, and the log owners. It identifies where active actions stop. It also assigns the plant operator the authority to pause the exercise. Those details let the owner compare bids on work and evidence, not on broad promises to test OT.
The closest existing Stingrai guide, manufacturing penetration testing, covers the wider plant attack surface and IT/OT segmentation. This matrix narrows the lens to the vendor access route and the proof a buyer should receive for each control. The network testing service can assess authorized perimeter and internal paths; the OT operator defines any production exclusions in the rules of engagement.
Figure 1: Editorial mapping of vendor identity, gateway, DMZ broker and approved destination to evidence collection points. Sources: NIST SP 1800-45, sections 3.3 and 4.1 and MITRE ATT&CK for ICS, External Remote Services.
Separate the three kinds of remote connection
Interactive vendor support is a person connecting from outside the organization's managed infrastructure. NIST's water-sector guide explicitly includes employees, vendors, contractors and consultants in this category. The owner can ask whose identity was used, who approved the session and which resource was reached. This is the main subject of the matrix below.
Operator remote access can use the same technology but a different authority model. A shift operator may have operational duties a vendor should never inherit. The evidence needs to preserve that distinction. A vendor test account must not quietly gain an operator's role, and an operator's exceptional privileges should not be used to make a vendor route look functional.
System-to-system communication is an automated connection between assets through externally managed infrastructure. NIST describes it separately from user-initiated access. It calls for asset identity, allowed peer, route and encryption evidence rather than a human MFA prompt. Treating these links as ordinary vendor accounts can conceal a persistent route that no named person owns. The matrix can be adapted to them, but the test plan must use a different persona and an OT-approved method.
An inventory should include contractor laptops and managed workstations where relevant, gateway addresses, identity provider applications, approved jump environments, remote support appliances, firewalls, cloud control planes, remote sites and emergency paths. Ask the supplier to show its diagrams and contract terms. Ask the internal OT owner to mark the exact protected resources and any safety or availability constraints. If a route cannot be mapped, record it as a discovery gap; do not probe farther merely to complete the drawing.
Source-mapped OT vendor remote access acceptance matrix
The table is an original buyer tool. Each pass condition is a proposed acceptance criterion to agree in the rules of engagement, not a NIST mandate. "Active" means a limited, authorized test against the gateway, identity layer, IT host or DMZ broker. "Review" means configuration and records only. A lab or tabletop exercise replaces any disruptive production step. Record a scenario ID for each row so the same case can be retested after a fix.
Buyer objective and source | Authorized safe mode | Telemetry to preserve | Pass/fail proof | Retest evidence |
|---|---|---|---|---|
Known entry points. Match every approved public route to the asset inventory. NIST SP 1800-45, table 3; ICS T0883. | Review owner inventory, gateway configuration and passive exposure records; limited external validation only for named IPs and services. | Asset record, change ticket, firewall policy, gateway connection log. | Pass when observed routes match approved inventory and have an owner; fail when an unowned public route remains. | Updated inventory and rule export plus a repeat of the same narrow external validation. |
Named vendor identity. Connect a real support contract to a unique test identity and approved role. NIST SP 1800-45, table 3; ICS T0859. | Review role mapping; attempt only pre-agreed positive and negative logins with supplied test identities. | Identity sign-in, gateway decision, role assignment, contract owner. | Pass when the approved account works and an unassigned account is denied; fail if shared or unowned access prevents attribution. | Identity export and successful/denied test events with the same scenario ID. |
MFA at the external path. Require a second factor for interactive remote access. NIST SP 1800-45, table 3; ICS T0822. | Review policy and conduct a bounded test with a test account whose second factor is withheld. | Identity provider challenge and denial event, gateway result, policy version. | Pass when the session is denied before resource access; fail if an approved route bypasses the factor. | Updated policy export and repeated denied challenge, followed by an approved positive case. |
Least-privilege destination. Limit a supplier to named resources and duties. NIST SP 1800-45, table 3; ICS T0822. | Compare role policy to the approved asset list; test denial against an IT-side canary or lab destination, not a controller. | Broker authorization decision, firewall flow, approved access request. | Pass when allowed destinations work and the canary is denied; fail when the account can traverse to an unapproved destination. | New allowlist, denied canary event and approved resource session record. |
Protected termination. Verify the external session ends at a managed boundary before any separate OT connection. NIST SP 1800-45, section 4.1. | Review architecture and firewall policy; limited path validation to a DMZ listener placed by the owner. | Gateway session, DMZ broker log, firewall allow and deny records. | Pass when the observed route matches the approved broker path; fail on a direct route or unexplained bypass. | Diagram, revised rules and repeat listener trace through the intended broker. |
Time and approval. Vendor access should expire when support ends. NIST SP 1800-45, table 3. | Review approval workflow; use a temporary test entitlement and wait for its configured expiry. | Request, approver, expiry event, sign-in and denial logs. | Pass when access stops at the agreed time without manual ambiguity; fail when it remains usable past approval. | Time-stamped expiry record and denied repeat sign-in after entitlement removal. |
Session attribution and monitoring. Correlate person, gateway, broker and destination. NIST SP 1800-45, table 3; ICS T0822 technique. | Generate a benign named session and one buyer-defined unusual-time or source case at the entry layer. | Identity and MFA events, gateway record, broker activity, and any locally required SOC alert. | Pass when analysts can reconstruct the route and distinguish approved from unexpected activity; fail when a hop loses identity or a pre-agreed local gateway alert rule does not fire. | Correlated event timeline and analyst disposition from the repeated case. |
Change and file route. Keep support files and changes on an approved, traceable path. NIST SP 1800-45, section 4.1. | Review transfer policy and simulate a benign file approval in a lab or nonproduction broker; do not transfer to a live control asset. | Request, scan or approval result, broker transfer log, change record. | Pass when the route and approval are documented; fail when the file can bypass the defined control. | Corrected policy and repeat benign lab transfer with full chain of records. |
Rapid disablement. Give the owner a tested way to close a supplier route. NIST SP 1800-45, table 3. | Tabletop the emergency decision and disable a dedicated test identity or lab route only. | Revocation event, gateway session closure, incident ticket, plant notification. | Pass when the owner can revoke the path and identify active sessions; fail if ownership or session state is unknown. | Completed tabletop record and a denied reconnect with the disabled test identity. |
Supplier terms and accountability. Define permitted access, support windows and incident contacts before testing. NIST SP 1800-45, table 3. | Contract and procedure review with procurement, OT and security owners. | Signed terms, access roster, escalation tree, review record. | Pass when the technical route is covered by current terms and an owner can authorize it; fail when the contract and actual route disagree. | Amended terms and approved access request tied to the corrected route. |
The matrix deliberately uses both a positive and a negative case. A successful login alone says little about whether the next supplier can log in, whether an account remains active after maintenance, or whether the session can reach too much. Conversely, a blocked connection can be an artifact of the test account rather than evidence of a healthy control. Each negative result needs the policy decision and a matching log.
Build a safe scope before anyone connects
The plant's operational authority sets the live boundary. NIST SP 800-82 Rev. 3, CA-8 warns that OT systems can be sensitive to timing and limited resources, points to replicated, virtualized or simulated systems, and says extra care is needed so tests of non-OT networks do not propagate into OT. That is a substantive scoping rule for this article. A penetration test proposal that merely says "exclude PLCs" leaves too much unresolved.
The written rules of engagement should identify the named public services, identity tenant, test accounts, jump hosts, DMZ subnets and owner-controlled listeners allowed for active work. It should state the permitted hours, rate limits, approvers, monitoring contacts and stop phrase. It should mark controller, HMI, safety-system and industrial-protocol addresses as out of active scope. It should also specify how a tester recognizes an unexpected OT response and stops. A configuration review can still evaluate whether those destinations are reachable according to policy, and an OT specialist can exercise representative behavior in a lab.
Use a staged handoff. First reconcile drawings, gateway policies and identity roles. Next prove that logs are being captured with one benign login. Then run only the approved negative cases at the external and DMZ layers. Pause if unexpected routing, operational alarms, unstable latency or an unlisted destination appears. The owner should see the scenario record in real time. A prearranged operational contact needs authority to halt activity without waiting for an engagement report.
A lab is not automatically representative. The owner should record which production policies, identity configuration and routing rules were copied into the lab and which were not. A tabletop is better for a decision path such as emergency disablement when it would be unsafe to cut a live vendor connection. The evidence should say exactly which mode was used, so a board or insurer does not mistake a tabletop outcome for a production control test.
Architecture choices change the evidence, not the objective
NIST SP 1800-45 demonstrates a traditional DMZ remote access architecture, a cloud-based architecture and a system-to-system architecture. These are representative designs, not an endorsement of one vendor or a requirement to copy a diagram. The buyer's objective remains control over the principal, route, destination and record.
For an on-site broker, ask for firewall policy on both sides of the DMZ, broker role mapping, authentication and session logs, and a trace from the supplied test identity to the approved host. NIST's example terminates an external session in the DMZ and initiates a separate connection inward. The test should distinguish these hops and show that a direct route is unavailable under the agreed negative case.
For a cloud control plane, ask who administers access decisions, where the activity log lives, whether the gateway enforces the decision locally, how emergency revocation works during an outage, and what the service agreement promises. NIST says cloud architectures can move authentication and authorization to the provider and notes that security measures belong in the contract or service-level agreement. The evidence packet should include the cloud decision and the on-site gateway outcome for the same scenario.
For a system-to-system link, use an asset and peer record instead of a human session. Verify through configuration review that authorized endpoints and expected flows are defined. Any active traffic to live process assets belongs to a separately approved OT test plan. A secure tunnel does not by itself prove that the two endpoints or the permitted process data are appropriate.
None of those designs replaces a maintained inventory. A forgotten cellular route, appliance support channel or contractor-managed account can invalidate a clean test of the main VPN. MITRE ATT&CK for ICS describes Internet Accessible Device as T0883 and recommends periodic comparison of exposed devices with the expected inventory. That comparison is a useful procurement deliverable when the organization has several sites and service partners.
Which ATT&CK paths should the buyer name?
Use ATT&CK labels as threat references, not as permission to reproduce an adversary's procedure. External Remote Services, T0822, describes initial access through outside services such as VPNs and other gateways; MITRE specifically notes vendor and engineering access. Valid Accounts, T0859, is relevant when the route is authenticated but its account ownership or permissions are wrong. Remote Services, T0886, describes movement between assets and segments after entry. Internet Accessible Device, T0883, gives an exposure inventory case.
Those labels should lead to measurable questions. Would an unapproved source be noticed at the gateway? Would the SOC correlate the vendor identity with the broker session? Is access to an unapproved IT-side destination denied? Can the owner disable the route and see the denial? MITRE's current T0822 detection analytic requires an identity or source-path policy violation corroborated by protected-asset access or another security-relevant follow-on event, and it suppresses approved vendor and support windows. The benign entry-layer alert suggested here is a buyer-defined gateway rule, not a claim to validate that MITRE analytic. The buyer can assess the local rule without conducting disruptive activity inside the plant.
The evidence packet a buyer should ask to keep
A final report is useful, but a control decision should remain reviewable after the report ages. Each matrix row should produce a short, redacted record with the approved scenario ID, owner, date, test mode, expected result, actual result, affected route, telemetry reference and disposition. Sensitive hostnames and account names can be moved to a controlled annex. The executive version should state whether the route met its agreed acceptance criteria and what remains untested.
Figure 2: Original evidence packet design linking an approved access decision to the test, telemetry, finding and retest record. Sources for the control categories: NIST SP 1800-45, table 3 and NIST SP 800-115.
The decision record states what the vendor was supposed to do and who approved it. The test record describes the bounded action and any stop condition. The telemetry record contains time-aligned identity, gateway, broker and firewall events. The finding record explains the business consequence of a gap without implying that production manipulation was attempted. The retest record repeats the same case after remediation and notes any changed assumptions. This follows NIST SP 800-115's general sequence of planning technical tests, analyzing findings and developing mitigation strategies.
Procurement can make this package contractual. Ask for a technical report that differentiates tested and reviewed controls, a route diagram with trust boundaries, redacted evidence for every acceptance row, prioritized remediation, and a retest statement that names what was repeated. Ask for the original event references and timestamps while they are available. A screen capture without the matching policy and log can be hard to interpret months later.
The same packet supports an audit or supplier review because it ties a claim to a repeatable observation. It should not be worded as a certification of the whole OT environment. A limited gateway test may provide strong evidence about the gateway and no evidence about a controller behind it. The tested asset list and exclusions belong beside the conclusion, not buried in a scope appendix.
How to evaluate a testing provider's proposal
A credible proposal should start with a route inventory and a joint scope workshop with security and operations. It should name the exact active surfaces and protected production classes, describe both positive and negative cases, identify who provides test identities and listeners, explain how logs are collected, and include a stop mechanism. It should budget for retesting. Broad phrases such as "full OT pentest" or "all devices scanned" do not tell the buyer whether the right path will be exercised safely.
Ask how the provider will distinguish a vendor access finding from a general segmentation finding. A vendor account that reaches an extra host is an authorization problem; an IT route that bypasses the DMZ may be an architecture problem. The mitigation owners differ. The provider should show the route, the policy that should have applied, the observed decision and the proposed correction. That level of detail lets procurement compare outcomes across sites and suppliers.
Ask who controls safety decisions. The OT operator should approve production contact, maintenance windows and excluded systems. A third-party lab can answer questions about controller behavior where a production test would be unsuitable. Do not accept a report that turns a lab simulation into an unstated claim about every installed asset. NIST's OT testing discussion is explicit about the care required.
Stingrai is a CREST-accredited penetration testing service provider founded in Toronto. Its human-led internal and external network testing covers perimeter, internal paths and segmentation under agreed scope, and its red teaming service can test an authorized human and network path when that is the buyer's objective. Human-led engagements use two named testers, post confirmed findings to the PTaaS portal as they are found, and include retesting. For this topic, Stingrai's fit is the external gateway, identity and IT/DMZ boundary; controller-level work belongs to the plant OT team or a qualified OT specialist. Buyers can scope a one-time annual engagement or a continuous program according to the access change rate.
Common mistakes in acceptance reviews
Equating MFA with safe access. MFA is essential for the interactive route but does not answer whether the account is shared, the permitted target is too broad or the entitlement remains after a contract ends. Make the identity, destination and expiry rows independent. A supplier can pass one and fail another.
Treating a drawing as an observed path. Architecture diagrams are hypotheses until gateway and firewall decisions match them. A narrow, authorized trace to a DMZ listener can reveal whether traffic uses the intended broker without sending traffic to a controller. If the path is not understood, stop and reconcile it before expanding the test.
Counting a log without an analyst. A vendor session might be recorded in several tools but never correlated. The acceptance criterion should include whether the owner can reconstruct the person, source, time and destination and whether a prearranged unusual case received a sensible disposition. Preserve both the event and the analyst note.
Using a single vendor as a proxy for all vendors. Integrators often have different support models. A gateway policy that is sound for one contract may leave a second supplier with a persistent shared account. Sample each distinct access pattern or state the coverage limit.
Closing a finding without repeating the scenario. A screenshot of a changed configuration is evidence of a change, not evidence of the control outcome. Use the same test identity, route, canary and expected decision in the retest where feasible. If the environment changed, state how that changes comparability.
FAQ
What should an OT vendor remote access penetration test include?
It should include the approved external entry point, vendor identity and MFA, role and destination limits, protected broker path, time-bound access, session logging, emergency disablement and a retest of any corrected gap. Active work should stay within written-authorized IT, identity and DMZ surfaces. Production OT behavior needs an OT-led lab, review or separately approved test plan.
Does NIST SP 1800-45 require a vendor remote access penetration test?
No. NIST SP 1800-45 is a voluntary practice guide for secure remote access in water and wastewater systems. This article's matrix is a buyer-designed way to verify selected considerations from that guide; it is not a NIST test requirement or a universal pass mark.
Can a tester scan PLCs or HMIs to validate the vendor path?
A gateway or boundary test does not require active scans of production PLCs or HMIs. NIST SP 800-82 Rev. 3 says penetration testing on OT networks requires care and gives replicated, virtualized or simulated systems as alternatives. The plant owner should set a separate OT-approved plan for any production contact.
What evidence proves that a supplier was blocked from an unapproved asset?
The strongest record combines the approved access policy, a bounded negative test to an owner-controlled canary or lab destination, the broker or firewall denial event, and a time-aligned identity record. It should also show a successful positive case to the approved destination so a broken test account is not mistaken for effective restriction.
How should a remote access finding be retested?
Repeat the original scenario ID with the same identity, source, route, destination class and expected result where practical. Keep the new policy version and the new authentication, broker and firewall events. Explain any changed assumptions or substituted lab component in the retest statement.
Where can Stingrai help with OT vendor access?
Stingrai can scope human-led testing of authorized external gateways, identity, internal network and IT/OT segmentation boundaries, with findings and retesting. The plant OT team or an OT specialist should own controller, HMI, safety-system and industrial-protocol work. The engagement can be a one-time annual test or part of a continuous program.
Related reading
Primary sources and method
This matrix was assembled from NIST SP 1800-45, final June 2026, NIST SP 800-82 Rev. 3, NIST SP 800-115, and the current MITRE ATT&CK for ICS technique pages linked above. The sources were read on 15 October 2026. The tests, pass criteria and evidence packet are the author's synthesis for procurement; they should be tailored to plant safety constraints and the signed rules of engagement. No client environment or observed client result is represented.
Talk to Stingrai
Stingrai can help scope a human-led assessment of the vendor entry path, identity controls and IT/DMZ boundary, with a report and retest plan tied to your approved access policy. Get a Quote or book a free discovery call.
