Cell Register
Standards ยท IEC 62443

IEC 62443

Rendered when the buyer ticks "IEC 62443 asset owner". The register cites 39 of its 81 clauses, behind 8 findings: adaptive controller with no human oversight noted, remote access into a cell or line zone, flat network: networked assets with no zone named, a wrong action reaches a person, no safety function noted, no change record on an adaptive or networked asset, end of support or unpatched, vendor share at or above a third, safety zone shares a conduit with a business asset, and on the obligation rows of every asset it reaches. 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.

Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim. Framework page. What it attaches on the register: the IEC 62443 regime page. Of the framework's 81 controls, 23 carry evidence shared across a thematic set and are excluded from this product by rule.

Clauses cited

39 of 81
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
IEC 62443 3-3 SR 3.3 Security Functionality Verification

The IACS shall provide the capability to verify intended operation of security functions and report when verification fails, including periodic self-tests, configuration baselines and integrity checks.

Evidence an auditor accepts: Baseline configuration register; Configuration drift detection report; Self-test or health-check logs
Common gap: No baseline captured at commissioning
Source framework: IEC 62443

See which clauses your list engages

Paste the list and every asset names the clauses behind it, filtered to the regimes that apply to you. Eight assets free, no account.

Build my cell register