OEM equipment contracts should treat cybersecurity as an explicit, shared responsibility across the entire equipment lifecycle. In regulated and long-lifecycle manufacturing, relying on generic warranty language or informal expectations is usually insufficient and creates gaps at audits, during incidents, and when integrating with brownfield systems.
1. Scope and security baseline
Contracts should clearly define what cybersecurity responsibilities apply to the OEM versus the buyer and any integrators.
- Reference standards or frameworks where possible (for example, IEC 62443 families or your internal OT security baseline), while recognizing that conformance still needs to be verified, not assumed.
- Identify which components are in scope: controllers, HMIs, embedded PCs, network switches, remote I/O, engineering workstations, historians, vendor cloud services, and any installed third-party software.
- Require a documented security configuration guide for the delivered system (accounts, services, ports, protocols, certificates), suitable for your internal cybersecurity team to review and validate.
2. Secure configuration and hardening
OEM contracts should require a minimum level of secure-by-default configuration, recognizing that specific settings may be adjusted by your site engineers during commissioning.
- Default accounts and passwords:
- No hardcoded credentials that cannot be changed.
- All default passwords must be unique per customer or per device and changeable.
- Account and access model:
- Role-based access where technically feasible.
- Ability to integrate with your identity and access management where feasible (for example, Active Directory for Windows-based HMIs).
- Service and port exposure:
- Only essential services and ports enabled by default.
- Documented list of required ports/protocols and justification (for example, which ports must cross cell/zone boundaries).
- Malware protection and system integrity:
- For general-purpose OS devices (Windows, Linux), support for an approved anti-malware solution and OS-native protections (for example, secure boot where supported).
- Clear guidance on what security agents or endpoint controls are certified or known to interfere with real-time performance.
3. Patch management and vulnerability handling
In long-lifecycle OT, patching is constrained by validation, qualification, and downtime. The contract should define how the OEM will support secure operation under those constraints.
- Supported software and firmware:
- List of operating systems, firmware versions, and key software components that the OEM will support during the agreed lifecycle.
- End-of-support timelines and how notice will be given when products or versions approach end-of-life.
- Patch release and testing commitments:
- Expectations for how quickly security patches are evaluated and released after upstream vendors publish them.
- Statement of what the OEM tests (for example, regression-tested patch bundles for specific configurations) and what is left to the site to validate in their environment.
- Vulnerability disclosure and advisory process:
- Formal process for notifying you of discovered vulnerabilities affecting the equipment.
- Expected timelines for initial notice, technical details, and recommended mitigations or fixes.
- Contact channels and escalation paths for security issues, including incident coordination procedures.
4. Remote access and vendor support connectivity
Remote access is a common failure point in OT environments. Contracts should specify strict conditions under which OEMs can connect into regulated production systems.
- Remote access mechanisms:
- Approved remote access technologies (for example, VPN with multi-factor authentication, jump servers) and disallowed methods (for example, unmanaged consumer remote desktop tools).
- Requirement that all remote access be initiated, controlled, and logged by the site, not the vendor.
- Access control and approvals:
- Formal approval workflow (who at your site can authorize a remote session, how long access is valid).
- Named or role-based vendor accounts, not shared anonymous “OEM support” logins.
- Monitoring and logging:
- Ability to log remote sessions (time, user, activity summary) and to store logs in your environment.
- Right to record or shadow vendor sessions, where technically feasible, for traceability.
- Cloud and vendor-hosted services:
- Data flows and data types transmitted to OEM clouds documented (telemetry, machine recipes, production data, personally identifiable information if any).
- Authentication, encryption in transit, and data retention policies described in appendices or referenced documents.
5. Logging, monitoring, and asset identification
For regulated and audit-heavy environments, the OEM should provide sufficient capabilities to support your monitoring, evidence, and incident response processes.
- Event logging capabilities:
- Support for logging security-relevant events: logins, configuration changes, firmware upgrades, recipe or parameter changes.
- Time synchronization support (for example, NTP) for consistent event timelines across systems.
- Integration with monitoring tools:
- Documentation of log formats and interfaces (for example, syslog out, OPC UA eventing, file export) so your SIEM or OT monitoring tools can consume them.
- Statement of what the OEM does not provide (for example, “no native syslog on PLC X; only via gateway”), so you can plan compensating controls.
- Asset inventory and identification:
- Unique and visible asset identifiers (model, serial number, firmware/software versions) to support CMDB/asset inventory.
- Machine-readable asset data where possible (for example, exportable BOM of software components and firmware versions).
6. Software bill of materials (SBOM) and third-party components
Modern OEM systems embed many third-party components. Contracts should make that explicit and require basic transparency.
- SBOM provision:
- Commitment to provide an SBOM at delivery and updated SBOMs when major releases or security-relevant changes occur.
- Format and level of detail defined enough for your security team to map against vulnerability databases.
- Third-party dependencies:
- Identification of key third-party components that impact your risk posture (for example, databases, middleware, connectivity agents).
- Clarification of who is responsible for tracking vulnerabilities in those components and issuing mitigations.
7. Lifecycle support, change control, and upgrades
In long-lifecycle environments, unmanaged OEM changes can break validation, documentation, and cyber controls. Contracts should align OEM change practices with your change control and qualification processes.
- Lifecycle and support period:
- Minimum period during which security support (patches, mitigations) will be provided.
- Notification timelines for end-of-support and any planned discontinuation of security updates.
- Change notification:
- Advance notice for changes that can affect cybersecurity posture, including firmware revisions, OS updates, network protocol changes, or cloud API changes.
- Release notes that clearly flag security-relevant changes and potential compatibility impacts.
- Upgrade and migration support:
- OEM responsibilities for assisting with secure upgrades, including documentation of required validation or requalification activities from their perspective.
- Options when upstream vendors cease support (for example, replacement controllers, migration paths, or documented compensating controls for a limited period).
8. Security testing, validation, and site-specific constraints
Security features are only useful if they can be validated and operated in your environment.
- Factory acceptance and site acceptance testing:
- Right to execute defined cybersecurity checks at FAT and SAT (for example, account review, port scan, verification of remote access controls).
- Criteria for remediation or non-acceptance if security requirements are not met.
- Support for your validation/qualification process:
- Documentation necessary to support qualification and regulatory documentation (configuration manuals, hardening guides, change logs).
- Clarification that final validation and risk acceptance remain your responsibility, while the OEM provides technical details and test evidence as agreed.
- Performance and safety constraints:
- Acknowledgement that some security controls may be limited by real-time, safety, or availability requirements, which must be analyzed jointly.
- Process to document known limitations and compensating controls in your environment.
9. Incident response and responsibilities during a cyber event
Incident handling with OEM involvement should be defined before an event, not during it.
- Coordination and communication:
- OEM point of contact and escalation paths for suspected or confirmed security incidents affecting their equipment.
- Expectations for response times and participation in root cause analysis where their systems are implicated.
- Forensic support and data preservation:
- Agreement on what logs and artifacts the OEM systems can provide and under what conditions.
- Guidance on safe evidence collection that avoids compromising system integrity or voiding support, within reasonable bounds.
10. Limitations, tradeoffs, and brownfield coexistence
The exact clauses you include must reflect your site architecture, integration maturity, and regulatory posture.
- Legacy and mixed-vendor systems:
- Do not assume all OEMs can meet the same cybersecurity baseline, especially for older platforms. Contracts may need graded requirements and explicit exceptions for legacy devices.
- Where OEMs cannot modify existing products, document constraints and plan network-level or procedural compensating controls.
- Validation and downtime constraints:
- Frequent patching and major upgrades may be infeasible in validated, high-availability environments. Contracts should allow for coordinated patch windows and highlight where OEM security expectations conflict with your operational realities.
- Full replacement of installed OEM platforms purely for cybersecurity reasons is often impractical due to qualification burden, production interruption risk, and integration complexity. Well-defined contractual responsibilities help you prioritize mitigation instead of unplanned replacement.
- No implied compliance guarantees:
- Contract language can support your cybersecurity and regulatory objectives, but it cannot guarantee compliance or pass audits on its own. You still need internal governance, integration testing, and monitoring.
In practice, many organizations maintain a standard set of cybersecurity requirements and contractual clauses for OEMs, then negotiate deviations case by case. The more clearly roles, limits, and constraints are captured in the contract, the easier it is to manage security over the multi-decade lifecycle of critical equipment.
