OT Cybersecurity: From the Purdue Model to IEC 62443

An OT assessment should produce decisions and evidence, not a colored diagram. Use Purdue as a communication model to locate business, operations, supervisory control, basic control, and process assets. Do not treat it as a universal architecture, a compliance framework, or proof that a design is secure. Plants contain cloud links, package units, safety systems, wireless networks, and vendor connections outside one stack.

This checklist is defensive and non-invasive. Review approved records, configurations, diagrams, and logs with operations and safety owners. Do not scan controllers, probe services, or change production equipment. Record unknowns as findings rather than testing them on a running process.

1. Define scope and collect the inventory

• Name the process, site boundary, accountable owner, assessment date, and operating constraints.
• Reconcile an inventory of PLCs, HMIs, engineering workstations, historians, safety systems, network equipment, servers, remote-access appliances, and external services.
• For each asset, record owner, location, function, vendor/model, firmware or OS, criticality, support status, network identifiers, dependencies, and an authoritative source.
• Identify temporary, portable, contractor-owned, and intermittently connected equipment. Mark every unknown field for follow-up.

Evidence can include an approved asset register, switch configuration export, support record, and owner sign-off. Passive observations may supplement these records when already deployed and authorized; absence from a monitoring tool is not evidence that an asset does not exist.

2. Map zones and conduits

Place assets on a current data-flow diagram, then group them by process function, consequence, trust, and operational requirement. Label Purdue levels only where they help teams communicate. Define each conduit as an approved flow with source, destination, protocol, port or service, direction, business purpose, owner, and review date.

• Separate enterprise, site operations, supervisory, control, safety, and package-system trust boundaries where risk requires it.
• Confirm enforcement exists at the boundary; a VLAN label alone is not a security control.
• Remove or deny undocumented cross-zone paths through change control, after assessing process impact.
• Give legacy, broadcast, vendor-specific, or safety-related traffic explicit exceptions with compensating controls and expiry dates.

3. Assess the industrial DMZ

An IDMZ can mediate necessary exchanges between enterprise and OT networks. It is not mandatory in every topology and does not make unsafe flows safe by itself.

• Terminate cross-boundary services in the IDMZ where feasible: jump hosts, proxies, update staging, replicated historian services, or managed file transfer.
• Check that enterprise sessions do not pass transparently into control zones and that control assets do not initiate unrestricted Internet access.
• Review firewall rules against the conduit register; capture rule owner, justification, last review, and expiry.
• Verify administration uses a separate managed path and IDMZ systems receive hardening, backup, monitoring, and patch governance.

4. Control remote access

• Inventory every human and machine remote path, including vendor appliances and cellular links.
• Require named accounts, MFA where technically supported, approval, least privilege, and time-bounded access.
• Route interactive sessions through managed jump hosts; prevent direct exposure of PLC, HMI, RDP, SSH, or industrial protocol services to the public Internet.
• Log authentication and session activity, disable dormant accounts, and define emergency revocation.
• Where MFA or modern authentication is unsupported, document the exception and use isolation, supervised access, short activation windows, or other risk-based compensating controls.

5. Verify backups and restoration

Back up controller logic, HMI/SCADA projects, recipes, historian and server configurations, certificates, network configurations, and required licenses. Protect at least one copy from routine administrative compromise. Record encryption and key custody where used.

• Define recovery priority, responsible people, dependencies, and acceptable objectives with process owners.
• Test restoration in a safe environment or approved outage; verify integrity, version compatibility, and rebuild prerequisites.
• Keep evidence of the latest restore exercise, result, defects, and remediation owner. A successful backup job is not a successful restore test.

6. Review logging and time synchronization

Identify events needed for operations and investigation: authentication, privilege changes, engineering downloads, controller mode changes, configuration changes, remote sessions, firewall decisions, endpoint alerts, and safety-relevant actions where available.

• Forward supported logs to a protected collection point without impairing deterministic control.
• Use approved, resilient time sources and document devices that cannot synchronize.
• Preserve source, timestamp, timezone, clock offset, retention, access controls, and chain-of-custody procedure.
• Map available telemetry to relevant MITRE ATT&CK for ICS behaviors to expose detection gaps. ATT&CK describes observed adversary behavior; it is not a control checklist or prediction.

7. Govern vulnerabilities and patch exceptions

• Correlate vendor advisories and supported versions with the inventory; do not actively scan fragile OT assets without specific authorization and a tested method.
• Evaluate exploitability, exposure, process consequence, safety, vendor support, outage needs, and rollback before remediation.
• Test patches or configuration changes on representative equipment where feasible, approve them through OT change control, and retain rollback evidence.
• For deferred patches, record rationale, owner, compensating controls, review date, and exception expiry. Reassess when exposure or threat information changes.

8. Prepare incident response and evidence handling

Create OT-specific playbooks with operations, engineering, safety, legal, and communications roles. Define who can isolate a zone, stop remote access, collect evidence, contact vendors, or alter a process. Safety and process stability govern containment; automatically disconnecting equipment can worsen consequences.

• Maintain offline contacts, current diagrams, system priorities, clean recovery resources, and decision authority.
• Practice compromised credentials, ransomware in the IDMZ, unauthorized logic change, and loss-of-visibility scenarios.
• Document evidence sources, collection authority, hashing, custody, secure storage, and clock discrepancies. Preserve volatile evidence only when operationally safe and approved.
• Convert exercise findings into assigned corrective actions and update recovery documentation.

9. Use a deterministic evidence decision fixture

Apply one review rule: ALLOW only when all required evidence fields are present and current; otherwise DENY the assessment item and open a finding. These are assessment outcomes, not live firewall commands.

[
  {
    "id": "C-01",
    "flow": "Historian replica to enterprise reporting",
    "owner": "OT Operations",
    "evidence": "approved rule CR-1842; reviewed 2026-07-24",
    "decision": "ALLOW"
  },
  {
    "id": "C-02",
    "flow": "Vendor laptop directly to PLC",
    "owner": "",
    "evidence": "verbal request only",
    "decision": "DENY"
  }
]

The first record has a purpose, owner, approved record, and review date. The second lacks accountable ownership and approved evidence, so the review cannot accept it. Actual network changes still require site risk assessment and change control.

Official references

• NIST, SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security, especially its OT risk, architecture, controls, incident response, backup, remote-access, and monitoring guidance.
• CISA, Principles of Operational Technology Cyber Security and ICS Cybersecurity Best Practices.
• MITRE, ATT&CK for ICS, used here to inform defensive visibility and exercise scenarios.

Sources accessed 2026-07-24. Passing this checklist does not certify compliance, eliminate risk, prove an air gap, or guarantee availability or security. The useful output is a reviewed evidence pack: inventory, zone/conduit map, exceptions, restore results, logging gaps, incident actions, owners, and due dates.