What are the 7 foundational requirements for IEC 62443?

IEC 62443 defines seven high-level security Foundational Requirements (FRs) for industrial automation and control systems (IACS). They describe what must be protected, not a single technology stack. Implementation always depends on your specific assets, vendors, network design, and regulatory and validation constraints.

FR 1: Identification and Authentication Control

Ensure that all users, software processes, and devices are uniquely identifiable and authenticated before they can access system resources.

In practice this may include:

• Unique user accounts, role-based access, and avoiding shared logins on HMIs and engineering workstations
• Strong password policies and, where feasible, multi-factor authentication for remote and administrative access
• Device identity for controllers, servers, and gateways (certificates, secure keys)

In brownfield environments, FR1 is frequently limited by legacy controllers that do not support modern identity mechanisms, shared terminals on the shop floor, and incomplete integration with corporate identity providers. Workarounds (badges, physical controls, procedural controls) must be designed and documented carefully.

FR 2: Use Control

Limit what authenticated users or processes are allowed to do based on their roles and responsibilities.

Typical elements:

• Role-based access control (RBAC) on engineering tools, HMIs, historians, and MES
• Segregation of duties (e.g., engineering vs. operations vs. maintenance vs. IT admin)
• Least-privilege configuration for service accounts and API integrations

In regulated manufacturing, FR2 interacts directly with qualification and validation. Tightening roles can change system behavior and may require re-validation or documented impact assessment. Many plants implement FR2 incrementally to avoid large, disruptive requalification efforts.

FR 3: System Integrity

Protect system functions and data from unauthorized modification and detect attempts to tamper with them.

Examples include:

• Secure configuration of PLCs, drives, robots, and safety systems to prevent unauthorized logic changes
• Code signing, firmware integrity checks, and controlled patching
• Application whitelisting and anti-malware on servers and engineering workstations where feasible
• Change control with traceability for configuration and logic changes

In long-lifecycle environments, vendors may not support frequent patching or modern hardening on older operating systems. Many facilities rely on compensating controls (network segmentation, strict change control, offline backups) to fulfill the intent of FR3 without destabilizing validated systems.

FR 4: Data Confidentiality

Prevent unauthorized disclosure of sensitive information in transit and at rest.

Common measures:

• Encrypted remote access connections to OT networks
• Secure protocols (for example, where possible using encrypted variants instead of legacy cleartext protocols)
• Encryption and access control for engineering project files, batch records, and recipes
• Segregation of regulated or export-controlled technical data

In many industrial control systems, data confidentiality has historically been weaker than integrity and availability. Retrofitting encryption into legacy protocols can be difficult or impossible without gateways. Decisions usually require balancing confidentiality against performance, determinism, vendor support, and validation constraints.

FR 5: Restricted Data Flow

Control how data moves between zones and conduits to reduce exposure and limit the blast radius of incidents.

This typically includes:

• Network zoning and segmentation (e.g., separating safety, control, supervision, and business networks)
• Firewalls, data diodes, or controlled gateways between zones
• Strictly defined conduits for vendor remote support, historian replication, and MES/ERP integration
• Documented and reviewed firewall rules and port/protocol lists

In brownfield plants with many point-to-point connections and undocumented integrations, FR5 often requires gradual remediation: discovery, documentation, then staged tightening. Aggressive segmentation without deep understanding of dependencies can disrupt production or break validated data flows.

FR 6: Timely Response to Events

Detect security-relevant events and respond to them in a timeframe that limits impact.

Practical elements include:

• Logging and audit trails on key systems (controllers where supported, HMIs, engineering tools, servers, gateways)
• Integration of OT logs into monitoring systems, with clear runbooks for triage and escalation
• Incident response procedures tailored to production constraints and safety considerations
• Periodic testing of response processes, including communications between OT, IT, and plant leadership

Full SIEM integration and continuous monitoring are not always realistic for all OT assets, especially very old controllers. Many organizations start with a smaller set of critical systems and key conduits, then expand coverage as tooling, budget, and validation bandwidth allow.

FR 7: Resource Availability

Ensure that critical system resources remain available, even under fault or attack conditions, and that loss of availability is limited and recoverable.

Key aspects:

• Protection against denial-of-service (DoS) by limiting unnecessary services, connections, and broadcast traffic
• Redundancy for critical servers, networks, and controllers where justified by risk and cost
• Backup and restore procedures for configurations, logic, and key data, tested regularly
• Capacity planning so added security controls do not overload controllers, networks, or gateways

For validated and safety-critical systems, availability controls must be designed so that security failures do not create unacceptable process or safety risks. Any changes to redundancy, failover, or recovery behavior usually need formal impact assessment and, in many regulated plants, revalidation.

How these requirements apply in mixed, long-lifecycle environments

The seven Foundational Requirements are goals, not a fixed technology recipe. In most real plants:

• Legacy devices may not fully support all FRs, so you rely on compensating controls and documented risk acceptance.
• Integration with existing MES, ERP, PLM, and QMS stacks often constrains how far you can push identity, encryption, and segmentation without breaking validated workflows.
• Large, all-at-once replacement projects to “become IEC 62443 compliant” typically fail due to downtime risk, qualification and validation burden, and integration complexity across vendors.

Effective use of IEC 62443 usually means:

• Mapping the FRs to your actual zones, conduits, and assets.
• Prioritizing high-consequence areas and modernizable components first.
• Coordinating with change control, validation, and production scheduling so improvements are sustainable and auditable.

The standard provides a structured way to reason about security posture. The specific controls, technologies, and timelines are highly plant-specific and should be aligned with your risk appetite, regulatory environment, and operational realities.