Before a third-party industrial control system (ICS) integrator receives access, the owner or operator should document five things: the data the integrator can reach or retain, every remote-access path, the people and components authorized to use those paths, the security and incident obligations in the agreement, and how the organization will recover or operate if the integrator is unavailable or compromised.
This is a contract, architecture, and continuity question—not only a firewall question. An integrator may hold network diagrams, controller details, engineering files, credentials, logs, or other information that would be valuable to an attacker even when the attacker never reaches the operator's environment directly.
On September 23, 2026, the FBI and CISA published considerations for critical-infrastructure operators working with third-party ICS integrators. The fact sheet recommends risk assessments, security requirements in contracts, reduced public exposure, monitored on-demand remote access, supplied-component inventories, and the ability to operate independently. The checklist below turns those recommendations into evidence an operator can request before access begins and review throughout the relationship.
What the new advisory confirms
The agencies describe FBI technical analysis of an incident from March and April 2025. Foreign cyber actors gained access to a U.S. industrial-automation solutions company's network, searched for terms including “customers” and “SCADA,” and created nine compressed archives containing approximately 800 files for presumed exfiltration. The files included customer SCADA information, ICS device details, and schematics, according to the fact sheet.
The advisory does not publicly identify the company or say that a customer's operational environment was disrupted. Its practical lesson is narrower: information and access concentrated at an integrator can create a pathway to multiple customer environments. Owners should therefore evaluate both the controls in their own network and the information, access, and dependencies placed with the integrator.
Build an integrator evidence matrix
| Area | Questions to answer | Evidence to retain |
|---|---|---|
| Data custody | What diagrams, device data, logs, credentials, backups, or engineering files can the integrator access or store, and where? | Approved data inventory, storage locations, retention periods, protection requirements, and deletion or return terms |
| Remote access | Which people, systems, routes, destinations, protocols, and time windows are authorized? | Named-user list, access diagram, approval record, multifactor-authentication requirement, session logs, and access-expiration date |
| Supplied components | What hardware and software enters the environment, how is it configured, and who maintains it? | Component inventory, versions, ownership, connection map, hardening record, update process, and change history |
| Incident duties | When must the integrator notify the operator, what evidence must be preserved, and who coordinates containment? | Notification threshold, contact roster, escalation timeline, evidence requirements, and tested response procedure |
| Continuity and exit | Can the operator run and recover critical processes without the integrator? | Offline software and configuration backups, local support plan, knowledge-transfer records, credential return or revocation steps, and an exit test |
1. Map data before granting access
Start with the information the integrator can see, copy, create, or retain. Include more than production data. Network diagrams, controller models, project files, device configurations, remote-access records, credentials, customer names, facility locations, and maintenance schedules can reveal how an operational environment is built and where it may be vulnerable.
- Identify the business owner and operational owner for each data category.
- Record whether the integrator merely views the data or stores a copy.
- Document the storage system, country or jurisdiction, retention period, encryption expectations, and approved recipients.
- Define what must be returned or securely deleted when the work or contract ends.
- Ask whether subcontractors or hosted platforms can access the same information.
NIST's SP 1326 due-diligence guide describes supplier assessment in terms that include foreign ownership, control or influence; provenance; resilience; foundational cyber practices; and supply-chain tiers. It is scoped to information and communications technology suppliers rather than ICS integrators specifically, so organizations should adapt those factors to their operational, safety, legal, and procurement requirements.
2. Make remote access explicit and temporary
A contract statement allowing “remote support” is not an access design. Create a named access matrix that identifies the approved user, source, gateway, destination, protocol, purpose, approver, maintenance window, and expiration. Separate routine monitoring from engineering or programming access; a support user who only needs to view status should not automatically have permission to alter controller logic.
The FBI-CISA fact sheet recommends access through routes the operator can monitor and on-demand access where possible. The operator should be able to enable access for approved work, observe the session, and disable it afterward. Shared accounts, persistent tunnels, undocumented cellular links, and integrator-managed appliances outside the owner's inventory should be treated as gaps to resolve.
Technical implementation must respect safety and availability requirements. The broader Network Box USA PLC security checklist covers public exposure, gateways, segmentation, engineering workstations, project-file backups, and response in more depth. This checklist focuses on the separate buyer and governance question: what must be agreed with the integrator before those controls can be operated consistently.
3. Put operational security requirements in the agreement
Security questionnaires are useful only when the resulting obligations have owners and enforceable follow-up. The agreement or service schedule should address:
- Data-location, protection, retention, return, and deletion requirements
- Authorized personnel, subcontractors, background or training requirements where applicable, and access-review frequency
- Remote-access methods, approval, logging, session termination, and credential revocation
- Hardening of deployed components, including changing defaults and disabling unused services or ports
- Patch, vulnerability, and change-management responsibilities
- Security-incident notification triggers, timing, contacts, evidence preservation, and cooperation
- Inventory delivery, update documentation, and configuration or engineering-file ownership
- Knowledge transfer, local support, transition assistance, and exit obligations
NIST SP 800-161 Rev. 1 provides a broader framework for identifying, assessing, and mitigating cybersecurity supply-chain risk. It is not a model contract and does not decide which clauses are legally appropriate for a particular organization. Procurement, operations, security, safety, and legal stakeholders should review the final requirements together.
4. Inventory what the integrator supplies and changes
Request an inventory of hardware and software supplied or administered by the integrator, plus a diagram showing how each component connects. At minimum, record the component owner, manufacturer, model or product, version, network location, exposed services, update method, configuration authority, support status, and dependency on an integrator-hosted system.
Then connect that inventory to change management. An approved change should identify what will change, who authorized it, the maintenance window, the expected communications or process behavior, the rollback plan, and the evidence showing completion. This helps security monitoring distinguish expected engineering work from activity that needs investigation.
5. Test whether the organization can operate independently
The fact sheet asks whether the operator can continue if the integrator is compromised and recommends secure offline copies of software needed to operate equipment. Translate that question into a controlled exercise:
- Select one critical process and assume the integrator's network and remote-support service are unavailable.
- Confirm that internal personnel can find current diagrams, approved configurations, software, licenses, credentials, contacts, and recovery instructions.
- Demonstrate how integrator access would be disabled without interrupting safe operations.
- Restore or validate a non-production copy of an essential configuration or project file using the documented procedure.
- Identify decisions that still depend on an unreachable individual or system, then assign an owner and target date.
Do not perform a live failover or disable production access without operational approval, safety review, and a rollback plan. The goal is to prove that the organization owns the knowledge and recovery capability it depends on, not to create avoidable production risk.
Fit network controls to the governance decision
The Network Box USA manufacturing security approach treats remote and vendor access as part of the connected IT and OT environment. Managed Secure SD-WAN can support encrypted connectivity and centrally managed network policy across approved sites and connections, while SIEM included with qualifying Network Box USA services can centralize agreed logs for investigation and reporting. Exact sources, routes, retention, alert logic, responsibilities, and response actions depend on the designed and contracted scope.
These controls do not replace integrator due diligence, contract requirements, safe operating procedures, or an exit plan. If you are reviewing how third-party access fits into your manufacturing or critical-infrastructure environment, contact our team through the Network Box USA form to discuss the network pathways, monitoring coverage, and responsibilities that apply to your environment.