OT Integrator Access Needs An Expiry Date

A supplier finishes a commissioning project. The plant accepts the work. What expires?

The purchase order is not the security boundary. The useful questions are whether the support route still works, which assets it reaches, and what engineering material remains outside the plant.

Those are separate problems. A network rule can close a connection. It cannot recall a copied drawing.

The Evidence: Engineering Knowledge Outside The Plant

The September 23 FBI/CISA fact sheet on third-party ICS integrators describes a March-April 2025 intrusion into a U.S. industrial automation company. Attackers searched for customer and SCADA material and assembled archives containing device information and schematics for presumed exfiltration.

That wording matters. The document does not establish a subsequent customer outage. It identifies how information taken from an integrator could support later attacks.

The agencies also recommend assessing retained data, remote connections, and the operator’s ability to function without the supplier. They advocate monitored, on-demand remote access where possible.

My architectural takeaway: treat a supplier relationship as two inventories, not one VPN account.

Knowledge inventory: project files, drawings, configuration exports, and any embedded secrets.
Access inventory: identities, tunnels, support agents, jump systems, destination services, and the people authorized to use them.

Closing the second inventory does not erase the first. Cleaning up documents does not revoke a live tunnel.

Turn The Contract Boundary Into An Enforced Boundary

NIST SP 800-207 rejects implicit trust based solely on network location or ownership. Applied here, a supplier being connected to the maintenance network should not itself authorize access to every engineering system.

The following is a proposed implementation pattern, not a claim about the incident’s topology.

Start with one integrator, one plant, and one maintenance task. Define a policy record with:

named supplier and operator owner;
approved entry point and authenticated identity;
dedicated support execution environment;
exact destination assets and required services;
task or change reference;
activation and expiration conditions;
independent revocation procedure;
required process flows that must remain available.

Use the entry point to authenticate the person. Use segmentation behind it to limit the support environment’s reach. Use destination authorization to limit what that person or process can do after connecting.

These are different controls. Allowing a connection to an engineering service does not establish that every command carried over it is safe.

Do Not Put Every Supplier Behind One Broad Allow Rule

Consider a proposed design for a packaging line. An integrator needs a maintenance session on one engineering workstation. That workstation needs approved access to the line’s controllers.

The intended path is narrow:

Approved supplier session
  -> controlled support environment
  -> designated engineering workstation
  -> assigned line controllers

The support environment should have no default path to another production line, the plant identity infrastructure, or the systems that administer segmentation itself. Permit supporting services individually after validating the dependency.

If several suppliers share one jump host and one source address, a downstream IP-based rule cannot distinguish their sessions by source address alone. Either separate their execution environments or use enforcement that can preserve and evaluate the relevant identity context. Do not label a shared subnet “vendor access” and mistake the label for supplier isolation.

For legacy controllers, place network enforcement at a compatible boundary instead of assuming an endpoint agent can be installed. Keep command-level restrictions in the engineering application or protocol-aware control where available. Network microsegmentation limits reachable services; it is not a substitute for those restrictions.

This is the implementation objective: compromising one supplier session should not provide an equally usable path to every supplier’s destinations.

Make Project Closure A Policy Transition

My recommendation is to define commissioning, support, and emergency access as distinct states.

During commissioning, approve the temporary paths needed for acceptance work. At handover, remove those exceptions and retain only the documented support baseline. For emergency work, activate a separate, time-bounded path with an operator owner rather than restoring the entire commissioning policy.

Pair that transition with an artifact review. Decide which exports the supplier still needs, which copies should be removed under the agreed retention process, and which credentials require replacement. Treat a configuration backup containing a secret differently from a drawing containing no credentials.

Do not claim deletion evidence proves no copy ever escaped. Design the remaining access boundary to hold even if an attacker has learned the addressing and device layout.

The practical difference from a password-only response is that changing a credential does not replace the decision about which systems the support environment may reach.

Rehearse Supplier Revocation Without Rehearsing A Plant Outage

Define an acceptance exercise with operations before changing live policy. In a representative test environment, or an approved maintenance window, verify:

The approved support task works only against its assigned destinations.
The same session cannot reach an unrelated line or boundary-management interface.
Expiration prevents new access, and the revocation procedure terminates existing sessions where required.
Supplier isolation leaves the explicitly identified process-control and operator flows intact.
Local staff can execute the agreed fallback without depending on the disabled supplier path.

Record the expected result, observed result, evidence, and owner for each check. Where a production test is unsafe, document the untested condition and validate it through an appropriate offline setup. Do not substitute a successful login test for a containment test.

NIST’s final SP 800-82 Revision 3 frames OT security around performance, reliability, and safety as well as security. Those constraints belong in the acceptance criteria, not in an exception added after enforcement breaks an operational dependency.

There is also a timely reason to revisit the design: NIST published the initial public draft of Revision 4 on September 21, 2026. Its announced changes include security architecture guidance for management functions and Zero Trust. It is a draft, with comments due November 30, not a new final requirement.

The Useful Outcome

A completed supplier review should produce more than an approved vendor name.

It should produce a small, testable set of permitted paths, an explicit expiry decision, and a way to withdraw access without withdrawing control of the process.

Keep the retained engineering knowledge in view. But do not let uncertainty about old document copies become an excuse to leave current network access broad.

The integrator may need to understand the whole plant. Its maintenance session does not need to reach the whole plant.

Sources

Prepared with AI assistance.

microsegment.io