Vendor and Contractor Risk in OT: Secure-by-Contract Requirements for Integrators, OEMs, and Managed Service Providers

40

Operational Technology (OT) keeps the physical world running—power generation, water treatment, manufacturing lines, pipelines, refineries, rail, mining, building automation, and everything in between. In these environments, the largest “attack surface” is often not a device or a protocol. It’s the ecosystem of vendors, contractors, integrators, Original Equipment Manufacturers (OEMs), and Managed Service Providers (MSPs) who design, deploy, maintain, and remotely support the systems that operate critical processes.

This is why “trust” is not a control. In OT, you need Secure-by-Contract: a clear set of requirements written into legal agreements, enforced through procurement gates, validated through evidence, and monitored continuously.

This article is written for OT owners and operators, CISOs, plant managers, OT engineers, procurement teams, and vendor managers who need practical contract language and enforceable requirements—without breaking uptime, safety, or production.

Why vendor and contractor risk is uniquely dangerous in OT

In IT, a vendor compromise can be catastrophic. In OT, it can be catastrophic and physical.

OT vendor/contractor relationships frequently include:

• Remote access into highly sensitive environments
• Privileged credentials and engineering-level permissions
• Portable media and laptops that move between customer sites
• Service accounts that never expire “because uptime”
• Proprietary protocols with limited monitoring visibility
• Safety and process constraints that limit patching and scanning
• Long lifecycles (10–30+ years) and unsupported equipment

The result: vendor pathways can bypass your perimeter, your segmentation, and sometimes your detection.

Secure-by-Contract addresses this by turning security expectations into measurable obligations:

• “You must do X”
• “You must provide evidence of X”
• “You must notify us within Y hours”
• “You must not do Z”
• “If you fail, consequences include A, B, and C”

---

What “Secure-by-Contract” means in OT (and what it is not)

Secure-by-Contract is a procurement and legal strategy that ensures every third party with OT access is bound to:

1. Defined controls (technical + procedural)
2. Defined evidence (what “proof” looks like)
3. Defined accountability (roles, timelines, liability, escalation)
4. Defined operational constraints (safety, maintenance windows, change control)
5. Defined enforcement (audit rights, termination, penalties, remediation requirements)

It is not:

• A one-time security questionnaire
• A generic IT vendor template copied into OT
• A checkbox that says “IEC 62443 compliant” without verification
• A waiver culture (“we’ll fix it next year”) that becomes permanent

---

The OT vendor ecosystem: integrators vs. OEMs vs. MSPs

Different vendor types create different risks. Secure-by-Contract must reflect those differences.

1) System Integrators (SIs)

Typical access and influence

• Design and deploy OT networks and control systems
• Configure PLCs, HMIs, historians, engineering workstations
• Maintain project documentation, backups, and logic
• Often act as a “super-user” during commissioning

Common SI risk patterns

• Reuse of “golden images” with shared credentials
• Engineering laptops used across multiple clients
• Poor change documentation after late-night fixes
• VPN “temporary access” that becomes permanent

2) OEMs (equipment and control vendors)

Typical access and influence

• Provide PLCs, drives, analyzers, RTUs, DCS components, and software
• Provide firmware/software updates, remote diagnostics tools
• Influence security features (or lack thereof) in products

Common OEM risk patterns

• Default accounts and hardcoded service credentials
• Long patch cycles or “patches break validation”
• Incomplete logging, limited security telemetry
• Remote support tools that bypass customer controls

3) Managed Service Providers (MSPs / MSSPs for OT)

Typical access and influence

• Continuous monitoring, patch orchestration, backups
• Managed remote access, identity services, endpoint tooling
• Often hold broad credentials across multiple sites

Common MSP risk patterns

• Over-privileged shared accounts across customers
• Insecure remote management tooling
• Weak segregation of customer environments
• Incident response confusion (who does what when)

---

The core principle: access is the product

If a vendor supports OT, they are not just selling a product or service—they are often receiving access. In Secure-by-Contract, treat access like a high-risk deliverable with explicit requirements:

• Who can access
• What they can access
• From where they can access
• When they can access
• How access is approved
• How actions are logged and reviewed
• How access is revoked and verified

---

A practical Secure-by-Contract framework for OT

Below is a contract-ready framework you can apply to most OT vendor relationships. You’ll tailor thresholds based on criticality (e.g., safety instrumented systems vs. packaging line).

1) Scope and system boundaries (make OT explicit)

Contract must define:

• What constitutes OT systems (including “shadow OT” like IoT gateways)
• Included sites, environments (prod vs lab), and network zones
• In-scope data types (recipes, batch records, control logic, safety documentation)
• What vendor actions are permitted (and prohibited)

Why this matters: ambiguity is the enemy of enforcement.

---

2) Identity, authentication, and privileged access (the #1 control area)

Secure-by-Contract requirements

• No shared accounts for interactive access (exceptions must be documented)
• Multi-factor authentication (MFA) for all remote access and privileged actions
• Role-based access control (RBAC) mapped to job function
• Privileged Access Management (PAM) or equivalent controls for elevated sessions:
  • credential vaulting
  • time-bound access
  • approval workflows
• Service accounts:
  • must be documented
  • must be least privilege
  • must have rotation and ownership
• Joiner/mover/leaver process:
  • access removed within a defined timeframe (e.g., 24–72 hours)
• No vendor “backdoors” or undisclosed access methods

Evidence to require

• Identity architecture diagram (high level)
• MFA enforcement screenshot/policy excerpt
• List of privileged roles and control mapping
• Sample access removal workflow audit trail

---

3) Remote access: design for safe operations, not convenience

OT remote access cannot be “just a VPN.” Secure-by-Contract should specify:

Minimum remote access architecture

• Access must terminate in a controlled entry point (jump server/bastion)
• Vendor access must be:
  • time-bound
  • approved
  • logged
• Strong preference for:
  • session recording for engineering actions
  • command logging where feasible
  • file transfer controls and malware scanning

Operational safety constraints

• Remote changes must follow Management of Change (MOC) rules
• Vendor must support maintenance windows and emergency procedures
• If remote access fails, vendor must have a defined “break-glass” process—still logged and reviewed

Evidence to require

• Remote access workflow diagram
• Jump host configuration standard (sanitized)
• Session recording capability description
• Example log records and retention settings

---

4) Endpoint and portable media hygiene (vendor laptops are a common bridge)

Secure-by-Contract endpoint requirements

• Vendor-owned endpoints used for OT access must have:
  • supported OS and patch levels
  • disk encryption
  • EDR/anti-malware
  • host firewall enabled
• Prohibit “unmanaged personal devices” for OT support
• Require controls for USB and portable media:
  • scanning station
  • approved media only
  • chain-of-custody for high criticality sites
• Require secure configuration for engineering tools and remote support clients

Evidence to require

• Endpoint security baseline (policy)
• Asset inventory class for “customer access devices”
• Sample EDR coverage report (aggregated)

---

5) Change control, backups, and recovery (OT reliability is security)

Secure-by-Contract requirements

• Vendor must comply with your MOC process, including:
  • risk assessment
  • rollback plan
  • pre-approval (except defined emergency)
  • post-change validation
• Vendor must support configuration backups and recovery:
  • PLC logic backups
  • HMI project backups
  • historian configs
  • network device configs (if in scope)
• Define RTO/RPO expectations for vendor-managed components (even if approximate)

Evidence to require

• Sample change ticket template used in OT projects
• Backup schedule and storage approach (high level)
• Restore test record frequency (e.g., quarterly/annually)

---

6) Vulnerability management and patching (OT realities, OT rigor)

Secure-by-Contract requirements

• Vendor must provide:
  • a vulnerability disclosure process
  • timelines for acknowledging reported issues
  • risk-based patch guidance (including compensating controls)
• For OEM products:
  • support firmware/software update paths
  • define what happens when product is end-of-support
• For MSP services:
  • define responsibility split for patching (OT owner vs vendor)
  • include test/validation requirements before production rollout

Evidence to require

• Vulnerability disclosure policy (VDP) or PSIRT process
• Patch advisory examples and severity scoring approach
• End-of-life policy documentation

---

7) Logging, monitoring, and incident notification (who calls whom, and when)

Secure-by-Contract requirements

• Vendor must generate and retain logs for:
  • remote access events
  • privileged actions
  • configuration changes (where feasible)
• Define log retention (e.g., 90–365 days depending on requirements)
• Incident notification timelines must be explicit:
  • e.g., notify within 24 hours of suspected compromise affecting your environment (adjust to your risk tolerance and regulations)
• Vendor must support incident investigations:
  • preserve evidence
  • provide access logs
  • provide timelines and scope
• Clarify whether vendor is allowed to run tools in your OT environment during IR (many are not)

Evidence to require

• Sample incident notification template
• Sample access log exports (redacted)
• Escalation runbook contacts and hours of coverage

---

8) Data handling and IP (OT data is sensitive—even when it’s “just telemetry”)

Secure-by-Contract requirements

• Data classification and permitted use:
  • no reuse for analytics or product training without explicit approval
• Encryption requirements:
  • in transit (TLS/secure tunnels)
  • at rest (vendor systems and backups)
• Data residency expectations (if applicable)
• Defined deletion/return requirements at contract end

Evidence to require

• Data flow diagram (who stores what)
• Data retention/deletion policy
• Encryption controls description

---

9) Subcontractors and supply chain (the fourth party problem)

Many OT vendors rely on subcontractors, offshore support desks, or specialized niche contractors.

Secure-by-Contract requirements

• Vendor must disclose subcontractors who will access OT systems or data
• Subcontractors must meet the same requirements (flow-down clauses)
• OT owner retains right to approve/reject subcontractors for critical systems
• Vendor remains accountable for subcontractor actions

Evidence to require

• Subcontractor list and roles
• Flow-down clause confirmation
• Access governance proof for subcontractor identities

---

10) Audit rights, assessments, and continuous verification

If you can’t verify it, you don’t control it.

Secure-by-Contract requirements

• Right to audit (reasonable notice, scope-limited, safety-aware)
• Requirement to provide independent assurance (where relevant):
  • ISO 27001 certification
  • SOC 2 Type II report
  • IEC 62443 product/system assurance artifacts
• Requirement to remediate findings within defined timeframes
• Right to restrict or suspend access for non-compliance

Evidence to require

• Latest audit report/executive summary
• Pen test summary (sanitized) or attestation
• Remediation plan status for open items

---

OT-specific “secure-by-contract” requirements by vendor type

For System Integrators: what to require (and why)

High-impact contract requirements for integrators

• Build standards:
  • naming conventions
  • account provisioning rules
  • firewall rule documentation requirements
• Golden image governance:
  • no reuse of credentials across customers
  • baseline hardening checklist for engineering workstations/HMIs
• Project documentation deliverables:
  • network diagrams
  • asset inventories
  • backup/restore procedures
  • “as-built” configurations
• Commissioning security checks:
  • default password removal verification
  • remote access disabled by default unless approved

Typical integrator contract deliverables

• “As-built” network and security architecture package
• Asset list (hardware + software versions)
• Credentials handoff procedure (with vaulting)
• Change log of all modifications

---

For OEMs: product security requirements you can enforce

Secure-by-Contract requirements for OEMs

• Secure defaults:
  • no default passwords
  • ability to disable unused services
• Identity and access controls:
  • unique accounts
  • RBAC capability where applicable
• Logging:
  • security-relevant events available for collection
• Patchability and lifecycle:
  • defined update process
  • end-of-support timelines
• SBOM (Software Bill of Materials) availability for software/firmware where feasible
• PSIRT and vulnerability disclosure commitments

Practical note: You may not get everything. But you can require transparency: what controls exist, what don’t, and what compensating controls are recommended.

---

For MSPs: requirements that prevent “one compromise = all customers”

Secure-by-Contract requirements for MSPs

• Strong tenant separation and least privilege
• No shared admin credentials across customers
• Customer-specific logging and access visibility
• Mandatory MFA + conditional access policies
• Secure remote tooling configuration standards
• Defined “who owns the incident” model:
  • detection, containment, eradication, recovery responsibilities
• Right to review access logs and privileged session records
• Controlled use of automation scripts with change approval

---

A “Secure-by-Contract” requirements checklist (copy/paste for procurement)

Use this as a master checklist and tailor per vendor criticality.

Domain	Requirement	Evidence to Request
Identity	MFA for all remote & privileged access	Policy excerpt + enforcement proof
Privilege	No shared interactive accounts	Account model description
Access	Time-bound access approvals	Workflow screenshot or runbook
Remote Access	Jump host / controlled entry point	Architecture diagram
Logging	Access + admin actions logged & retained	Sample logs + retention config
Endpoint	Encrypted, managed vendor devices only	Endpoint baseline policy
Change	MOC compliance + rollback plans	Sample change ticket
Vulnerabilities	PSIRT/VDP + patch guidance	PSIRT/VDP doc + sample advisory
Incident	Notification within defined hours	IR clause + escalation list
Data	Encryption + deletion/return	Data flow + retention policy
Subcontractors	Disclosure + flow-down	Subcontractor list + clause
Assurance	Audit rights + independent reports	SOC2/ISO summary or attestations

---

Secure-by-Contract: sample contract clauses (practical language)

Important: The following is operationally-informed language, not legal advice. Have counsel adapt it to your jurisdiction, regulatory obligations, and risk tolerance.

Remote Access and Privileged Sessions

• Vendor remote access to Customer OT environments must occur only through Customer-approved access pathways (e.g., controlled entry point/jump host) and must not use any undisclosed method of access.
• All remote access must use MFA and uniquely assigned user identities. Shared interactive accounts are prohibited unless explicitly approved in writing for a defined purpose and duration.
• Privileged access must be time-bound and limited to the minimum permissions necessary to perform authorized work.
• Vendor must maintain access logs sufficient to identify user, source, time, target system, and actions performed, and must retain such logs for a minimum of X days.
• Upon request, Vendor must provide access logs and session records relevant to Customer systems within Y business days.

Incident Notification and Cooperation

• Vendor must notify Customer within X hours of discovering any suspected or confirmed security incident that could reasonably affect Customer OT systems, credentials, data, or availability.
• Vendor must preserve relevant evidence (including logs, access records, and system images where applicable) and cooperate with Customer’s investigation.
• Vendor must not materially alter Customer systems during an incident response effort without Customer authorization, except where necessary to prevent imminent harm to safety or to prevent ongoing compromise, in which case Vendor must notify Customer as soon as practicable.

Subcontractors and Offshore Support

• Vendor must not allow any subcontractor to access Customer OT systems or data without prior written disclosure and approval (for critical systems) or prior written notice (for non-critical systems), as defined by Customer.
• Vendor must ensure all subcontractors are bound by written obligations no less protective than those in this Agreement.
• Vendor remains fully responsible for subcontractor actions and omissions.

Secure Development and Vulnerability Management (OEM / Software Vendors)

• Vendor will maintain a documented vulnerability disclosure process and a security response capability (e.g., PSIRT) to receive, assess, and remediate reported vulnerabilities.
• Vendor will provide timely security advisories and risk mitigation guidance for vulnerabilities affecting products deployed in Customer environments.
• Vendor will provide end-of-support and end-of-life notices with at least X months’ advance notice where feasible, along with risk-based options (upgrade paths, compensating controls, extended support).

Termination, Access Revocation, Transition

• Upon termination or expiration, Vendor must promptly return or securely destroy Customer data and certify destruction upon request.
• Vendor must revoke all access (including credentials, certificates, API keys, and remote tooling authorizations) within X hours and provide written confirmation.
• Vendor will provide reasonable transition support to a successor vendor, including transfer of documentation, configurations, and backup artifacts, subject to agreed scope.

The evidence-driven approach: stop accepting “we comply”

One of the biggest failures in third-party risk management is accepting statements like:

• “We follow best practices.”
• “We are secure.”
• “We comply with industry standards.”

Secure-by-Contract replaces these with evidence.

Examples: turn vague statements into measurable requirements

Vague: “Vendor uses strong authentication.”
Contractual: “Vendor must enforce MFA for all remote access to Customer OT environments and must provide evidence of enforcement upon request.”

Vague: “Vendor monitors for incidents.”
Contractual: “Vendor must maintain logs for remote access and privileged actions affecting Customer systems and must notify Customer within X hours of a suspected or confirmed incident that could affect Customer environments.”

Vague: “Vendor provides secure updates.”
Contractual: “Vendor must provide security advisories and patch guidance for vulnerabilities affecting deployed products and must disclose end-of-support timelines.”

---

Building a tiered vendor model (criticality-based requirements)

Not every vendor should face the same burden. Use tiers.

Suggested vendor tiers for OT

• Tier 1 (Critical Access / High Impact): direct access to control networks, PLC/DCS changes, safety-adjacent systems
• Tier 2 (Operational Support): access to DMZ services, historians, patch servers, monitoring tools
• Tier 3 (Low Risk): no OT access, limited business data access

Policy: Tier 1 vendors must meet the strongest Secure-by-Contract requirements, including session logging, strict identity controls, and the shortest incident notification timelines.

---

Secure-by-Contract + OT operations: how to avoid breaking uptime

Security that halts production will be bypassed. The best contracts encode operational reality.

Make the contract OT-friendly

• Define maintenance windows and emergency change procedures
• Include pre-approved playbooks (e.g., “critical alarm storm” response)
• Require rollback plans for changes that could impact safety or availability
• Require vendors to maintain site-specific runbooks (not generic ones)

Establish joint governance

• Monthly/quarterly access reviews
• Change review boards for high-risk systems
• Joint tabletop exercises for incident scenarios

---

A vendor security questionnaire that OT teams actually use

Below is a short, high-signal question set to include in RFPs and onboarding.

OT Vendor Security Questionnarie

1. Remote Access: Describe your remote access method(s). Do you support customer-controlled jump hosts and time-bound approvals?
2. MFA: Is MFA enforced for all remote access and privileged actions? Which methods?
3. Identity: Do you use unique accounts per technician? Any shared accounts? If yes, why and how controlled?
4. Logging: What events do you log for customer access? How long are logs retained?
5. Endpoint Hygiene: Are devices used to access customer OT environments managed, encrypted, and protected by EDR?
6. Portable Media: What is your process for USB/media scanning and control when onsite?
7. Change Control: How do you document, approve, and roll back changes in OT environments?
8. Vulnerability Handling: Do you have a PSIRT/VDP? Provide an example advisory and response timelines.
9. Subcontractors: Who might access customer systems? How do you govern subcontractor access and training?
10. Incident Response: Notification timeline, escalation path, and cooperation commitments—provide your standard language.
11. Segregation: For MSPs, explain customer separation controls and credential segregation.
12. Assurance: Provide current certifications/reports or explain alternatives.

Scoring vendor security maturity (simple and defensible)

To choose between vendors (or to drive remediation plans), use a scoring rubric.

Example scoring bands

• 0 — Not supported: vendor cannot meet requirement
• 1 — Partially supported: ad hoc, not provable
• 2 — Supported: defined process + basic evidence
• 3 — Strong: automated enforcement + strong evidence + monitoring

Score across domains (Identity, Remote Access, Endpoint, Logging, Incident, Vulnerability, Subcontractors). Require minimum scores for Tier 1 vendors.

---

Common pitfalls (and how to fix them)

Pitfall 1: “Perpetual temporary access”

Fix: Contractually require time-bound access and periodic recertification (e.g., every 30/90 days).

Pitfall 2: Contracts that require controls you can’t operationalize

Fix: Align requirements with OT constraints (maintenance windows, safety rules), and define exceptions with approvals and compensating controls.

Pitfall 3: No ownership between OT, IT, and procurement

Fix: Establish a shared vendor intake workflow with clear RACI (Responsible/Accountable/Consulted/Informed).

Pitfall 4: OEMs refuse requirements

Fix: Require transparency and compensating controls. Where you can’t force product changes, enforce network segmentation, strict remote access, and monitoring.

---

Implementation playbook: how to roll this out in 60–120 days

Phase 1 (Weeks 1–3): Define your baseline

• Build OT vendor tiers and criticality definitions
• Standardize your Secure-by-Contract controls library
• Create a “Tier 1 contract addendum” and “Tier 2 addendum”

Phase 2 (Weeks 4–8): Apply to new and renewing vendors

• Gate procurement: no PO without security addendum acceptance
• Require evidence for Tier 1 vendors before access is granted
• Implement access pathways (jump hosts, MFA, approvals)

Phase 3 (Weeks 9–16): Remediate legacy vendors

• Identify vendors with persistent access
• Replace shared accounts and rotate credentials
• Add session logging for high-risk remote support
• Run a tabletop exercise involving at least one key vendor

---

What good looks like: a Secure-by-Contract “minimum viable” standard

If you do only five things, do these:

1. MFA + unique accounts for all vendor remote access
2. Time-bound approvals and least privilege for privileged work
3. Centralized logging of access and admin actions (with retention)
4. Incident notification SLAs with clear escalation paths
5. Subcontractor disclosure + flow-down clauses

This set alone eliminates a large portion of the most common OT vendor pathways.

---

FAQ: Vendor & contractor risk in OT (quick answers)

What’s the difference between IT vendor risk and OT vendor risk?

OT vendor risk often includes direct control over physical processes and high-privilege engineering access, with additional constraints that limit patching, scanning, and downtime.

Do I need IEC 62443 language in contracts?

It helps, especially for OEM and integrator requirements—but the key is translating any standard into specific, testable obligations and requesting evidence.

How do we handle vendors who “must” use their own remote support tool?

Require that their tool:

• uses MFA
• supports time-bound access
• is logged/recorded (or integrated with your logging)
• is approved through change and risk review
  If they cannot meet baseline controls, treat it as a risk exception with compensating controls (segmentation, monitoring, limited access windows).

Should vendors have access to Level 0/1 networks remotely?

In most environments, remote access to the most sensitive zones should be exception-based, tightly controlled, and heavily monitored. Many organizations require remote access to terminate in a controlled zone and then pivot under supervision.

What is the best way to enforce these requirements?

Enforce through:

• procurement gates (no contract, no access)
• technical controls (MFA, jump hosts, logging)
• periodic access reviews
• audit rights and remediation timelines

Conclusion: secure-by-contract is the fastest way to reduce OT third-party risk

Vendor and contractor risk is not an edge case in OT—it’s a primary pathway. The organizations that handle it well don’t rely on trust, emails, or tribal knowledge. They implement Secure-by-Contract requirements that are:

• OT-realistic
• evidence-based
• tiered by criticality
• enforced through access design and governance

If you want a single sentence to guide your program, use this:

If a vendor can’t meet your access, logging, and incident obligations in writing—and prove it—they shouldn’t have privileged touchpoints into your OT environment.