Cell Register
Regimes · IEC 62443

IEC 62443

Attaches to every automated asset the owner runs, in every zone class; the rows differ by zone, by connectivity and by behaviour.

Who it binds: Part 2-1 binds the asset owner; Part 3-2 is the owner's zoning and risk assessment; Part 3-3 is what the owner specifies for the system. Part 2-4 binds the service provider and Parts 4-1 and 4-2 the product supplier, so those rows are rendered as what to ask.

On the register, tick "IEC 62443 asset owner" and these rows appear on every asset the regime reaches. Source framework page on the compliance graph.

The rows, and when each attaches

Asset owner duty
on every asset
On every asset (Part 2-1)
IEC 62443 2-1 AC · 2-1 BCP · 2-1 CSMS · 2-1 IR · 2-1 MOC · 2-1 NSEG · 2-1 PHY · 2-1 PM · 2-1 RA · 2-1 TRN
Whatever the zone, these ten programme duties are the owner's for every asset in the system under consideration.
Asset owner duty
where the zone class is cell
System requirements to specify for a cell zone (Part 3-3)
IEC 62443 3-3 SR 1.1 · 3-3 SR 2.1 · 3-3 SR 3.4 · 3-3 SR 5.1 · 3-3 SR 7.6
The cell zone is the smallest a conduit is drawn at; the requirements the owner writes into the CRS for it are identification, use control, integrity of the controller program, restricted data flow and a maintained configuration.
Asset owner duty
where the zone class is line
System requirements to specify for a line zone (Part 3-3)
IEC 62443 3-3 SR 1.1 · 3-3 SR 1.2 · 3-3 SR 2.1 · 3-3 SR 2.8 · 3-3 SR 3.1 · 3-3 SR 3.4 · 3-3 SR 5.1 · 3-3 SR 5.2 · 3-3 SR 6.1 · 3-3 SR 7.3 · 3-3 SR 7.6
A line zone shares a network among controllers, drives and stations, so device authentication, auditable events, communication integrity, a protected zone boundary, accessible logs and backup join the cell requirements.
Asset owner duty
where the zone class is supervisory
System requirements to specify for the plant supervisory zone (Part 3-3)
IEC 62443 3-3 SR 1.1 · 3-3 SR 1.2 · 3-3 SR 2.1 · 3-3 SR 2.8 · 3-3 SR 3.1 · 3-3 SR 3.4 · 3-3 SR 5.1 · 3-3 SR 5.2 · 3-3 SR 6.1 · 3-3 SR 6.2 · 3-3 SR 7.3 · 3-3 SR 7.6
The supervisory zone sees and commands many lines and is the zone the office reaches first, so every requirement family applies and continuous monitoring is added.
Asset owner duty
where the zone class is business
System requirements to specify for the site business zone (Part 3-3)
IEC 62443 3-3 SR 1.1 · 3-3 SR 2.1 · 3-3 SR 5.2 · 3-3 SR 6.1
An asset on the business side of the boundary is inside the CRS for what it can reach across it: identification, use control, the zone boundary and accessible logs.
Asset owner duty
where the zone class is safety
System requirements to specify for the safety zone (Part 3-3)
IEC 62443 3-3 SR 1.2 · 3-3 SR 2.8 · 3-3 SR 3.1 · 3-3 SR 3.4 · 3-3 SR 5.1 · 3-3 SR 5.2
The safety zone accepts no command from the process side: device authentication, auditable events, communication and program integrity, and a boundary that only carries status out.
Asset owner duty
where the asset is networked
Added where the asset is on a network
IEC 62443 3-3 SR 3.1 · 3-3 SR 5.2 · 3-3 SR 6.2
Communication integrity, a monitored zone boundary and continuous monitoring attach the moment the asset is reachable.
Asset owner duty
where the asset is reached remotely
Added where the asset is reached remotely
IEC 62443 2-1 AC · 3-3 SR 1.1 · 3-3 SR 6.1
The remote account, its authentication and the record of its sessions are the owner's.
Asset owner duty
where the controller adapts
Added where the controller adapts at runtime
IEC 62443 3-3 SR 2.8 · 3-3 SR 3.4
A controller that changes its own behaviour needs the integrity of its model or program watched and its actions logged, so a change can be told from an attack.
Ask the integrator
on every asset
Part 2-4 binds the service provider, not the owner
IEC 62443 2-4 SP-01 · 2-4 SP-02 · 2-4 SP-03 · 2-4 SP-04 · 2-4 SP-05 · 2-4 SP-06
The owner owes none of these rows; the owner asks the integrator and the maintenance provider for the evidence of each before commissioning and at every substantial change.
Ask the supplier
on every asset
Part 4-1 binds the supplier, not the owner
IEC 62443 4-1 DM · 4-1 SG · 4-1 SUM
The owner asks the maker of the controller or the machine for the hardening guide, the vulnerability handling process and the signed update channel.
Ask the supplier
where the asset is networked
Part 4-2 binds the supplier: a networked component
IEC 62443 4-2 CR-1-1 · 4-2 EDR-3-10
For a networked controller the owner also asks for signed firmware with rollback protection and user authentication on the component.
On the register as a wholeIEC 62443 3-2 CRS · 3-2 ZCR-1 · 3-2 ZCR-2 · 3-2 ZCR-3 · 3-2 ZCR-4

The zone and conduit sheet

Part 3-2 asks the owner to define the system under consideration, assess it, partition it into zones and conduits and set a target security level per zone. Cell Register places every asset in one of five zone classes and exports one row per asset with the zone, the conduit, the SL-T and the reasoning:

safetySafety zone: safety controllers, safety scanners and instrumented systems, kept on their own conduit so nothing on the process side can command them. Conduit: safety to line: a safety conduit that carries status out and accepts no command in from the process network.
cellCell zone: one machine or one closely coupled group with its own controller, the lowest level a conduit can be drawn at. Conduit: cell to line: the controller talks up to the line supervisor over one documented conduit, nothing else in.
lineLine zone: the controllers, drives and stations of one production line, sharing a network and a supervisor. Conduit: line to plant supervisory: the line reports up and takes recipes down through a boundary device with a deny-by-default rule set.
supervisoryPlant supervisory zone: SCADA, historians, HMIs and engineering workstations that see and command many lines. Conduit: plant supervisory to site business: through the industrial DMZ only, no direct session from the office to a controller.
businessSite business zone: the IT side of the boundary, reached from the plant only through a controlled conduit. Conduit: site business to plant: brokered through the DMZ, jump host and recorded session for anything that reaches down.

SL-T is the register's default per class, raised one for remote access and never above 3; a pasted SL-T replaces it. The sheet is the input to the CRS, not the CRS.

The clauses, quoted

38 of 81 in the framework

Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.

IEC 62443 2-1 CSMS Cyber Security Management System (CSMS) for IACS

Asset owners establish, implement and maintain a documented Cyber Security Management System covering scope, policy, risk analysis, risk treatment, training, business continuity, physical security, network segmentation, access control, monitoring, incident response and management review specific to IACS environments.

Evidence an auditor accepts: CSMS manual covering IACS scope and OT specifics; Approved IACS security policy signed by asset owner executive; CSMS scope statement listing sites, plants, control systems in scope
Common gap: IT security policy reused for OT with no IACS-specific adaptations
Source framework: IEC 62443
IEC 62443 2-1 RA IACS Risk Identification, Classification and Assessment

Asset owner performs high-level and detailed cybersecurity risk assessments of IACS considering threats, vulnerabilities, consequences to safety, environment, production and reputation, and documents risk treatment decisions before commissioning and on significant change.

Evidence an auditor accepts: High-level risk assessment report per site or process; Detailed risk assessment per zone aligned to 62443-3-2; Threat catalogue covering ransomware, insider, nation-state, supply chain, safety bypass
Common gap: Safety consequences not considered alongside cyber consequences
Source framework: IEC 62443
IEC 62443 2-1 NSEG Network Segmentation and Zone/Conduit Implementation

Asset owner segments IACS networks into zones and conduits based on risk, separating IACS from corporate IT via DMZ, restricting traffic to documented purposes, and protecting safety systems from other control systems.

Evidence an auditor accepts: Network architecture diagram showing Purdue levels and zones; DMZ design between Level 3.5 and corporate; Firewall ruleset with business justification per rule
Common gap: Flat OT network with no segmentation between process areas
Source framework: IEC 62443
IEC 62443 2-1 MOC Management of Change for IACS Security

Asset owner integrates cybersecurity into management of change processes so that hardware, software, firmware, network, or logic changes to IACS are risk-assessed, approved, tested and documented including effect on security posture.

Evidence an auditor accepts: MOC procedure referencing cybersecurity review step; Change records showing security risk assessment outcome; Cybersecurity sign-off role identified in workflow
Common gap: MOC process exists for safety but cybersecurity not a required review
Source framework: IEC 62443
IEC 62443 2-1 PM Patch Management and System Update for IACS

Asset owner operates a documented IACS patch management process covering vulnerability monitoring, applicability analysis, vendor approval, test, deployment during outages, and risk acceptance for unpatchable systems.

Evidence an auditor accepts: IACS patch policy and procedure; Vendor patch approval matrix per product; Patch test environment description
Common gap: Patches deferred indefinitely with no compensating controls
Source framework: IEC 62443
IEC 62443 2-1 PHY Physical and Environmental Security of IACS Assets

Asset owner protects control rooms, marshalling cabinets, PLCs, RTUs, network equipment and engineering workstations from unauthorised physical access, tampering and environmental damage.

Evidence an auditor accepts: Cabinet lock and seal inventory; Control room badge access logs; CCTV coverage map of critical IACS areas
Common gap: PLC cabinets left unlocked on plant floor
Source framework: IEC 62443
IEC 62443 2-1 AC Account Management and Access Control for IACS

Asset owner manages IACS user and service accounts with least privilege, individual accountability where feasible, role-based access, periodic review and removal upon role change or departure.

Evidence an auditor accepts: IACS user account register with roles and last review date; Shared/operator account justification and compensating controls; Quarterly access review records
Common gap: Shared operator console account with no logging of individual operator
Source framework: IEC 62443
IEC 62443 2-1 IR Incident Planning and Response for IACS

Asset owner maintains an incident response capability tailored to IACS, including detection, triage, containment, eradication, recovery, lessons learned, communication with regulators, and exercises that include OT-specific scenarios such as ransomware on engineering workstation or malicious PLC logic change.

Evidence an auditor accepts: IACS incident response plan separate from or integrated with corporate IR; OT-specific playbooks (ransomware, PLC tamper, HMI lockout, SIS bypass); Tabletop exercise reports with OT operations attendance
Common gap: Corporate SOC has no visibility into OT and no OT runbooks
Source framework: IEC 62443
IEC 62443 2-1 BCP Business Continuity and Disaster Recovery for IACS

Asset owner plans, tests and maintains the ability to recover IACS function after a cybersecurity incident or other disruption, including configuration backups for controllers, HMI images, historian data and engineering workstations, with documented RTO and RPO.

Evidence an auditor accepts: IACS BCP/DRP document with RTO/RPO per system tier; PLC and HMI configuration backup procedure and storage; Offline backup evidence (immutable or air-gapped)
Common gap: PLC programs only on engineer laptop with no central backup
Source framework: IEC 62443
IEC 62443 2-1 TRN Personnel Security Awareness and Training for IACS

Asset owner provides role-based IACS cybersecurity training to operators, engineers, maintenance staff, contractors and managers, with content tailored to OT realities and refresher cadence defined.

Evidence an auditor accepts: Training matrix by role (operator, control engineer, network admin, integrator); Course content covering OT-specific risks (USB, vendor remote access, safe state); Attendance records with signatures
Common gap: IT phishing training only, nothing OT-specific
Source framework: IEC 62443
IEC 62443 3-3 SR 1.1 Human User Identification and Authentication (FR1)

The IACS shall provide the capability to identify and authenticate all human users and enforce the authentication on all interfaces providing access to the IACS, including operator HMI, engineering workstation and remote access.

Evidence an auditor accepts: Authentication mechanism documentation per interface; Identity store inventory (AD, local, application); MFA implementation evidence on engineering and remote
Common gap: HMI shared operator account with sticker password
Source framework: IEC 62443
IEC 62443 3-3 SR 2.1 Authorisation Enforcement (FR2 Use Control)

The IACS shall provide the capability to enforce authorisations assigned to all human users for controlling use of the IACS to support segregation of duties and least privilege.

Evidence an auditor accepts: Role definitions (operator, engineer, supervisor, admin, viewer); Permission matrix mapped to roles; Access control list export per system
Common gap: All users on HMI given administrator
Source framework: IEC 62443
IEC 62443 3-3 SR 3.4 Software and Information Integrity

The IACS shall provide the capability to detect, record, report and protect against unauthorised changes to software, firmware, configuration and information at rest within the control system.

Evidence an auditor accepts: File integrity monitoring on EWS and historian; Firmware version inventory and verification; PLC program checksum monitoring
Common gap: No detection of PLC program change outside change window
Source framework: IEC 62443
IEC 62443 3-3 SR 5.1 Network Segmentation (FR5 Restricted Data Flow)

The IACS shall provide the capability to logically segment networks and restrict data flow between zones based on the principle of least communication necessary.

Evidence an auditor accepts: Network segmentation design referencing zones from 62443-3-2; Firewall rule documentation per conduit; Annual rule review
Common gap: Logical segmentation absent within OT (single broadcast domain)
Source framework: IEC 62443
IEC 62443 3-3 SR 7.6 Network and Security Configurations

The IACS shall provide the capability to be configured according to recommended network and security configurations and maintain them across normal operation, restart and recovery.

Evidence an auditor accepts: Hardening standard per device family; Configuration baseline backup; Drift detection process
Common gap: Devices deployed with vendor defaults, no hardening applied
Source framework: IEC 62443
IEC 62443 3-3 SR 1.2 Software Process and Device Identification and Authentication

The IACS shall provide the capability to identify and authenticate software processes and devices communicating across conduits or to control system components.

Evidence an auditor accepts: Device certificate inventory (OPC UA, IEC 62351); Service account register with use case; Mutual authentication evidence between historian and PLC where supported
Common gap: OPC UA configured in anonymous mode
Source framework: IEC 62443
IEC 62443 3-3 SR 2.8 Auditable Events

The IACS shall provide the capability to generate audit records for security-relevant events including access control, configuration change, authentication, system events and operator actions on safety-critical commands.

Evidence an auditor accepts: Audit policy listing events; Sample audit log extract; Log aggregation architecture
Common gap: PLCs do not log set-point or program changes locally
Source framework: IEC 62443
IEC 62443 3-3 SR 3.1 Communication Integrity (FR3 System Integrity)

The IACS shall provide the capability to protect the integrity of transmitted information, especially for control commands and safety-relevant communications, using cryptographic or other appropriate mechanisms.

Evidence an auditor accepts: Protocol inventory with integrity mechanism (TLS, IPSec, IEC 62351); Cryptographic key management procedure; Justification where integrity protection is not feasible
Common gap: Plain Modbus or DNP3 in production without integrity protection
Source framework: IEC 62443
IEC 62443 3-3 SR 5.2 Zone Boundary Protection

The IACS shall provide the capability to monitor and control communications at zone boundaries, providing deny-by-default policy and alarming on attempted boundary violations.

Evidence an auditor accepts: Boundary device inventory (firewalls, data diodes); Default deny ruleset evidence; Boundary alarm escalation procedure
Common gap: Default allow rule at boundary
Source framework: IEC 62443
IEC 62443 3-3 SR 6.1 Audit Log Accessibility (FR6 Timely Response to Events)

The IACS shall provide the capability to make audit records accessible to authorised humans or automated tools for analysis in support of incident detection and response.

Evidence an auditor accepts: Log forwarding configuration to SIEM or OT monitoring; Operator and analyst access procedure; Retention and protection policy
Common gap: Logs exist only on individual devices and aren't aggregated
Source framework: IEC 62443
IEC 62443 3-3 SR 7.3 Control System Backup

The IACS shall provide the capability to back up user-level information and system-level information without affecting the normal operation of the control system, and protect backup integrity and confidentiality.

Evidence an auditor accepts: Backup schedule per system; Backup integrity verification (hash, restore test); Offsite or immutable storage evidence
Common gap: Backups confirmed but never tested by restore
Source framework: IEC 62443
IEC 62443 3-3 SR 6.2 Continuous Monitoring

The IACS shall provide the capability to continuously monitor security-relevant events using mechanisms appropriate for control system environments such as passive network monitoring and asset inventory tools.

Evidence an auditor accepts: Asset inventory output; Anomaly detection alerts and triage process; Monitoring coverage map (which zones, which sensors)
Common gap: Monitoring deployed on corporate IT only, OT blind
Source framework: IEC 62443
IEC 62443 2-4 SP-01 Service Provider Security Program

IACS service providers (integrators, maintenance providers) establish a documented security program addressing personnel, processes and technical practices delivered to asset owners during integration, commissioning and ongoing maintenance.

Evidence an auditor accepts: Service provider security program document; Personnel competency records for delivery staff; Tools and methodology library list
Common gap: Integrator pitches 62443 capability with no documented program
Source framework: IEC 62443
IEC 62443 2-4 SP-02 Service Provider Solution Staffing and Assurance

Service provider ensures personnel deployed on IACS engagements are vetted, trained and supervised, with background checks proportionate to access level and competency verified for tasks performed.

Evidence an auditor accepts: Background check policy and records for project staff; Training records mapped to roles; Competency assessment per task type (PLC programming, network commissioning)
Common gap: Subcontractors deployed without same checks as employees
Source framework: IEC 62443
IEC 62443 2-4 SP-03 Service Provider Architecture and Design Practices

Service provider applies secure architecture practices when designing IACS solutions, including zones, conduits, defence in depth, secure remote access, least functionality and adherence to asset owner security requirements.

Evidence an auditor accepts: Reference architecture catalogue; Design review checklist with security items; Customer security requirement traceability matrix
Common gap: Designs reuse legacy patterns with flat networks
Source framework: IEC 62443
IEC 62443 2-4 SP-04 Service Provider Wireless and Remote Access Practices

Service provider implements secure wireless and remote access mechanisms when providing IACS services, including MFA, jump servers, session recording, time-limited access and explicit asset owner approval.

Evidence an auditor accepts: Remote access architecture with jump host and MFA; Session recording configuration evidence; Approval workflow before remote session
Common gap: No session recording, no audit trail of vendor actions
Source framework: IEC 62443
IEC 62443 2-4 SP-05 Service Provider Malware Protection Practices

Service provider applies malware protection on its own tools, removable media and delivery devices used at customer sites, and supports asset owner anti-malware controls during commissioning and maintenance.

Evidence an auditor accepts: Endpoint protection on all engineering laptops; Removable media scanning kiosk procedure; USB whitelist policy
Common gap: Engineering laptops without EDR or with outdated signatures
Source framework: IEC 62443
IEC 62443 2-4 SP-06 Service Provider Backup and Restore Practices

Service provider supports IACS backup and restore capability including controller program backups, system images, configuration archives and procedures handed over to asset owner with restore test evidence.

Evidence an auditor accepts: Backup design document part of project deliverables; Restore test report signed by asset owner; Configuration baseline archive on handover
Common gap: Backups taken at SAT but not handed to asset owner
Source framework: IEC 62443
IEC 62443 4-1 SG Security Guidelines for Asset Owner

Product supplier provides documentation to asset owners and integrators describing secure configuration, hardening, account management, removal/disposal and integration security considerations.

Evidence an auditor accepts: Security configuration guide per product; Hardening guide; Decommissioning guide
Common gap: No hardening guide
Source framework: IEC 62443
IEC 62443 4-1 DM Defect Management and Vulnerability Handling

Product supplier maintains a process to receive, triage, remediate and disclose security defects including coordinated disclosure with researchers and customers, advisories, and CVE assignment.

Evidence an auditor accepts: PSIRT charter and contact; Vulnerability disclosure policy; Sample security advisory
Common gap: No PSIRT, researchers ignored
Source framework: IEC 62443
IEC 62443 4-1 SUM Security Update Management

Product supplier provides security updates for products including evaluation of compatibility, controlled distribution, signing, and clear documentation of remediated vulnerabilities for asset owners.

Evidence an auditor accepts: Update release process; Code signing implementation; Update distribution channel
Common gap: No signed updates, asset owner cannot trust file authenticity
Source framework: IEC 62443
IEC 62443 4-2 EDR-3-10 Embedded Device Support for Updates

Embedded devices (PLCs, RTUs, IEDs) shall support the capability to be updated with security patches in a manner consistent with availability requirements, including signed firmware and rollback protection.

Evidence an auditor accepts: Signed firmware documentation; Rollback protection mechanism description; Update procedure tested during outage
Common gap: Firmware updates unsigned
Source framework: IEC 62443
IEC 62443 4-2 CR-1-1 Component Identification and Authentication of Users

Components (embedded devices, host devices, network devices, software applications) shall provide the capability to identify and authenticate all human users seeking access to the component.

Evidence an auditor accepts: Component authentication mechanism documentation; Vendor declaration of conformance to CR 1.1
Common gap: Embedded device without authentication on local interfaces
Source framework: IEC 62443
IEC 62443 3-2 ZCR-1 Identify System Under Consideration

Define the System Under Consideration including boundary, components, functions, supporting infrastructure and external interfaces as the basis for risk assessment and zone/conduit definition.

Evidence an auditor accepts: SUC boundary document with diagram; Asset inventory within SUC; Interface register (network, physical, human, supply)
Common gap: SUC boundary fuzzy, missing safety system or historian
Source framework: IEC 62443
IEC 62443 3-2 ZCR-2 High-Level Risk Assessment

Perform an initial high-level cybersecurity risk assessment on the SUC to identify worst-case unmitigated consequences and prioritise areas needing detailed analysis and zoning.

Evidence an auditor accepts: HLRA report with consequence categories (HSE, production, financial, reputation); Worst-case scenario register; Initial security level target SL-T proposal
Common gap: HLRA done by IT without process safety SME participation
Source framework: IEC 62443
IEC 62443 3-2 ZCR-3 Partition the SUC into Zones and Conduits

Partition the SUC into zones (groupings with common security requirements) and conduits (communications between zones), based on function, risk, criticality, ownership and physical or logical boundaries.

Evidence an auditor accepts: Zone and conduit diagram; Zone descriptor (function, assets, criticality, SL-T); Conduit descriptor (protocols, endpoints, controls)
Common gap: Entire plant treated as one zone
Source framework: IEC 62443
IEC 62443 3-2 ZCR-4 Detailed Cybersecurity Risk Assessment per Zone and Conduit

For each zone and conduit perform detailed risk assessment identifying threats, vulnerabilities, existing countermeasures, likelihood, consequence and resulting risk against tolerable risk, leading to target Security Level SL-T.

Evidence an auditor accepts: Per-zone risk assessment report; Threat catalogue applied to zone; Vulnerability inventory (CVEs, configuration, design)
Common gap: SL-T assigned by gut feel with no risk math
Source framework: IEC 62443
IEC 62443 3-2 CRS Document Cybersecurity Requirements Specification (CRS)

Document the Cybersecurity Requirements Specification capturing per-zone and per-conduit security requirements, SL-T, assumptions and constraints used as input to design, procurement and acceptance.

Evidence an auditor accepts: CRS document approved by asset owner; Mapping of CRS to FR1 to FR7 requirements; Procurement specs referencing CRS
Common gap: No CRS produced, requirements communicated verbally to integrator
Source framework: IEC 62443

See what it attaches to your list

Paste the equipment list, tick the regime, and every asset it reaches carries these rows. Eight assets free, no account.

Build my cell register