IEC 62443 Compliance

IEC 62443 is an international standard family for the security of Industrial Automation and Control Systems (IACS), jointly developed by the International Electrotechnical Commission (IEC) and the International Society of Automation (ISA). It covers the full lifecycle of product development, system integration, and operations and maintenance. For the power industry, grid dispatch automation, substation monitoring systems, and distribution automation systems are all typical IACS scenarios and the core applicable targets of IEC 62443.

EnerOS has been implemented according to IEC 62443-4-1 (Secure Development Lifecycle) and 4-2 (IACS Component Security Requirements) since v0.45, making it easy to deploy in industrial control environments and pass third-party certification.

Standard Family Overview

The IEC 62443 standard family is divided into four major categories, each targeting different roles:

As a product supplier, EnerOS must comply with 4-1 (Secure Development Process) and 4-2 (Component Technical Security Requirements); it also provides supporting deployment, operations, and audit tools for system integrators and asset owners.

Security Levels SL1-SL4

IEC 62443 defines four Security Levels (SL) that describe a system’s ability to resist threats, progressing from low to high:

For each SL, the standard further defines system-level targets (SL-T), zone-level targets (SL-Z), and component-level targets (SL-C), forming a hierarchical target chain.

SL Levels and Foundation Requirements Matrix

EnerOS implements all foundation requirements at SL3 by default and provides optional enhancements for SL4 (such as post-quantum cryptography hybrid, TPM measured boot, HSM key escrow).

Coverage Scope

The following table shows EnerOS’s corresponding implementations under 4-1 (Process) and 4-2 (Component):

EnerOS Compliance Implementation

1. Secure Development Lifecycle (4-1 SR1-SR5)

EnerOS implements a complete SDL process, with each version iteration including the following phases:

1. Requirements phase: Threat modeling based on STRIDE and LINDDUN, outputting threat lists and security requirement items
2. Design phase: Architecture review meetings examine the attack surface, outputting security design documents (including data flow diagrams, trust boundaries)
3. Implementation phase: Rust #![forbid(unsafe_code)], Clippy security ruleset, dependency audit cargo audit
4. Verification phase: Unit tests covering security paths, fuzzing starting from 2 million iterations, third-party penetration testing
5. Operations phase: Vulnerability response SLA, CVE monitoring, patch gray release

2. Component Security Requirements (4-2 CR)

Each CR maps to specific Rust crates and configuration items, forming a traceable matrix:

Configuration Example

IEC 62443 Configuration Block in eneros.toml

[security]
level = "sl3"                       # Security level SL1-SL4
standard = "iec-62443"              # Compliance framework
enforce_constraints = true          # Kernel-enforced constraints (CR 3.1)

[security.mtls]
required = true                     # Enforce mTLS (CR 1.1)
min_version = "TLS_1_3"             # Minimum TLS version (CR 2.1)
cipher_suites = ["post-quantum"]    # Post-quantum cryptography hybrid
cert_rotation_days = 90             # Certificate rotation period (CR 1.1)

[security.audit]
hmac_chain = true                   # HMAC chained audit (CR 1.2)
worm_store = "/var/eneros/audit"    # WORM storage (CR 1.9)
retention_days = 2555               # 7-year retention

[security.encryption]
field_algorithm = "AES-256-GCM"     # Field encryption (CR 4.1)
key_management = "kms"              # KMS-managed
rotate_keys_days = 365              # Key rotation

[security.dos_protection]
rate_limit_rps = 1000               # Rate limiting (CR 7.1)
quota_per_tenant = 1000000          # Quota
priority_queue = true               # Priority queue

Rust Code: Audit Chain Query

eneros-security provides AuditChain and WormStore for full traceability of any remote control command:

use eneros_security::audit::{AuditChain, QueryBuilder};

let chain = AuditChain::open("/var/eneros/audit.chain")?;

let entries = QueryBuilder::new()
    .actor("dispatch_agent")
    .action("remote_command")
    .range(t0, t1)
    .fetch(&chain)?;

for entry in entries {
    println!("{} {} {} {}", entry.timestamp, entry.actor,
             entry.action, entry.resource);
    println!("  hmac_chain_ok: {}", entry.verify_hmac(&chain)?);
}

Rust Code: select-before-operate

For critical commands, the select-before-operate flow is enforced, complying with CR 2.4 two-factor control:

use eneros_trust::sbo::{SboSession, SboConfirm};

let mut sbo = SboSession::new("breaker-123")
    .operation("open")
    .actor("dispatch_agent")
    .ttl_seconds(30);

// Step 1: select (operation preview)
sbo.select().await?;

// Step 2: confirm (operation confirmation, requires two factors)
let confirm = SboConfirm::builder()
    .totp_code("123456")
    .approver_id("operator-7")
    .build();
sbo.confirm(confirm).await?;

// Step 3: execute (actual dispatch)
sbo.execute().await?;

Security Requirements Matrix

The following table shows the complete technical requirements and verification evidence at SL3 level:

Certification Process

EnerOS assists users in completing IEC 62443-4-1 and 4-2 certification:

1. Preparation phase: Use eneros-cli compliance check --standard iec-62443 to generate a self-assessment report
2. Gap analysis: Compare against SL targets to output a gap list and remediation recommendations
3. Remediation implementation: Adjust eneros.toml and network configuration based on recommendations
4. On-site assessment: Third-party certification bodies (such as TÜV, exida) conduct on-site audits
5. Certification issuance: Upon passing, obtain IEC 62443-4-1 / 4-2 certification (valid for 3 years)
6. Continuous supervision: Annual surveillance audit, re-assessment before certificate expiration

# Generate self-assessment report
eneros-cli compliance check --standard iec-62443 --level sl3 \
  --output iec-62443-self-assessment.json

# Output gap list
eneros-cli compliance gap --standard iec-62443 --level sl3 \
  --input iec-62443-self-assessment.json \
  --output iec-62443-gap-list.csv

Compliance Checklist

Confirm each item before deployment:

• All internal inter-service communication has mTLS enabled (see Zero Trust & Security Enhancement)
• Certificates are uniformly issued by internal CA and auto-rotate (90 days)
• Audit logs are written to WORM storage, retained for ≥ 7 years
• IDS deployed with OT attack signature database configured
• Critical commands go through select-before-operate flow
• Least privilege RBAC + ABAC policies implemented
• Secure development lifecycle documented, including threat models and penetration test reports
• Vulnerability response SLA: Critical ≤ 7 days, High ≤ 30 days
• All configuration changes go through GitOps pipeline, direct login modifications prohibited
• Image signature verification failure refuses startup
• Port inventory exportable via eneros-cli audit ports
• Field-level encryption covers all PII data
• Rate limiting and quota policies effective per tenant dimension
• Network segmentation policies block unauthorized lateral access
• Annual simulated attack exercise conducted and report archived

Forensic Capability

eneros-security provides AuditChain and WormStore for full traceability of any remote control command:

let chain = AuditChain::open("/var/eneros/audit.chain")?;
let entries = chain.query().actor("dispatch_agent").range(t0, t1).fetch()?;

Related Documentation

• Zero Trust & Security Enhancement
• Safety Guard
• Zero Trust Architecture & mTLS
• NERC CIP Compliance