ISA IC34: Designing Secure Industrial Control Systems

ISA IC34 is the design and implementation specialist component of the ISA/IEC 62443 Cybersecurity Certificate Program. It takes the risk findings and target security expectations developed earlier in the lifecycle and turns them into an industrial control system architecture, countermeasures, implementation decisions, and verification activities. Candidates need to show that they can design protection that is effective, testable, and compatible with operational requirements.

The ISA IC34 page connects directly to ISA IC33 because design requirements should be driven by assessed risk rather than by a generic product checklist. The broader ISA certifications path also makes clear that the fundamentals certificate comes first and that operations and maintenance remain separate lifecycle responsibilities.

ISA IC34 preparation is strongest when candidates repeatedly move from requirement to architecture to verification. If a risk assessment says a critical zone needs stronger isolation, the designer must decide what communications are allowed, where enforcement occurs, how identities are handled, how remote access works, what happens during failure, and how the finished design will be tested. The answer must survive both cyber scrutiny and operational reality.

Turn risk findings into explicit security requirements

Design begins with requirements that describe the protection outcome rather than naming a favorite technology. A requirement may limit communication between zones, require authenticated remote access, preserve essential functions during a network disturbance, or create auditable records for security-relevant actions. ISA IC34 candidates should distinguish a requirement from an implementation choice so that the design remains traceable and alternatives can be evaluated.

Requirements also need context. Which asset or zone does the requirement apply to? What threat or consequence does it address? What operational constraint limits the solution? How will compliance be verified? These questions keep requirements from becoming vague statements such as “use strong security.” Traceability back to the risk assessment makes design review more defensible.

Requirements should also capture negative constraints: what the system must not permit. Examples include preventing direct internet access from a critical zone, blocking engineering changes from unmanaged devices, prohibiting shared administrative accounts, or ensuring that failure of a security appliance does not create an uncontrolled bypass. Negative requirements are useful because they make unacceptable states visible during design review and testing.

Design zones and conduits around process trust

Zone design should group assets with compatible security requirements and operational relationships. Conduits then define how information and control traffic moves between zones. The approved network segmentation resource reinforces the basic architectural value of reducing unnecessary reachability, but industrial design must also preserve deterministic communications, engineering workflows, safety dependencies, and recovery paths.

Candidates should avoid drawing boundaries that cannot be operated. Every conduit creates policy, monitoring, support, and failure-mode questions. If the architecture requires dozens of exceptions to keep production working, the zone model may not reflect the real process. Good ISA IC34 designs make required traffic explicit and unusual traffic easier to detect.

Designers should also consider manageability as a security property. A firewall architecture that requires constant manual exceptions, an identity model that operators cannot use during maintenance, or a monitoring platform that floods staff with alerts will eventually be bypassed. Candidates should evaluate whether administrators can operate controls accurately, whether changes are reviewable, and whether the organization has the skills and tools to maintain the design. Sustainable controls usually outperform theoretically stronger controls that the environment cannot operate consistently.

Choose layered controls that fail independently

Defense in depth means creating multiple opportunities to prevent, contain, detect, and recover from compromise. The approved security architecture material is useful supporting context, but ISA IC34 candidates should apply the principle to industrial constraints: physical controls, identity, network boundaries, hardening, allowlisting, secure configuration, monitoring, backups, and procedures all contribute differently.

Independent failure matters. Two controls that rely on the same credential store, management network, or administrator may fail together. A resilient design considers common dependencies and asks what remains if one layer is unavailable or compromised. This is particularly important in environments where emergency operation or degraded-mode control must continue even when normal security infrastructure is disrupted.

Architecture reviews should include data flows that are not obvious on network diagrams. Time synchronization, name resolution, authentication, software distribution, backup traffic, logging, licensing, and remote management can cross zone boundaries even when production protocols do not. Missing these supporting services can create either hidden trust or an implementation that fails when security controls are activated.

Engineer remote and vendor access deliberately

Vendor support is often essential for specialized industrial equipment, but permanent unmanaged remote access can defeat otherwise strong segmentation. ISA IC34 candidates should design clear entry points, strong authentication, approved accounts, controlled privileges, session logging, time limits, and pathways that terminate in a managed access zone before reaching critical assets. Direct inbound access to field devices should be difficult to justify.

The design should also account for outages and emergency support. If a plant cannot wait for a central identity service during a critical event, the architecture may need controlled break-glass procedures. Those mechanisms should be limited, monitored, tested, and reviewed after use. Designing resilience and security together prevents emergency exceptions from becoming undocumented permanent channels.

Match endpoint controls to industrial capability

Not every industrial asset can support the same endpoint control. Modern Windows-based engineering stations may support endpoint detection, application control, host firewalls, and frequent security updates, while embedded controllers may have limited resources and vendor restrictions. ISA IC34 candidates should compensate at other layers when endpoint capability is weak rather than pretending one control stack fits every device.

Secure configuration baselines, unnecessary-service reduction, protected engineering tools, removable-media controls, account management, and application allowlisting can be valuable depending on asset capability. The design should record why a control was selected, how it will be maintained, and what operational testing is required before deployment. Controls that cannot be sustained are weak design choices even if they look strong on paper.

Endpoint design should consider recoverability alongside prevention. If a hardened workstation is difficult to rebuild, teams may delay security changes or preserve unsafe configurations because recovery is uncertain. Standardized images, protected configurations, documented dependencies, and tested restoration procedures allow stronger hardening because operators know that the asset can be returned to a known state when a change goes wrong.

Design monitoring around meaningful industrial signals

Monitoring should capture events that help operators and security teams identify unauthorized change, suspicious access, abnormal communications, and control failures. Network sensors can be useful where endpoint agents are impractical, while authentication logs, firewall events, remote-access records, engineering changes, and asset inventories provide additional context. The goal is not maximum telemetry; it is enough reliable evidence to recognize and investigate meaningful deviation.

ISA IC34 candidates should think about placement, time synchronization, retention, bandwidth, and ownership of alerts. Monitoring that cannot distinguish maintenance activity from malicious behavior produces noise. A strong design connects telemetry to response procedures so that a useful signal has an owner, an escalation path, and enough context to support action.

Procurement can be part of secure design. Requirements for logging, authentication, signed updates, vulnerability disclosure, secure development, support periods, backup, and configuration export may need to be included before equipment is purchased. Once proprietary industrial assets are deployed, adding missing security capabilities can be expensive or impossible. ISA/IEC 62443 design thinking therefore reaches upstream into supplier selection and acceptance, ensuring that lifecycle security is not limited by avoidable procurement decisions.

Verify design objectives with testable acceptance criteria

Design work is incomplete until the organization can test whether the implemented solution satisfies its security requirements. Verification may include rule reviews, configuration inspection, access tests, failover tests, backup restoration, alarm generation, segmentation tests, and controlled attempts to cross trust boundaries. Acceptance criteria should be decided before testing so results are not interpreted opportunistically after implementation.

Testing in industrial systems must also protect safety and availability. Some activities require lab environments, simulations, maintenance windows, vendor involvement, or carefully constrained procedures. ISA IC34 candidates should balance assurance with operational risk and understand that a disruptive penetration test on a live control system can be a poor validation method even when aggressive testing is common elsewhere.

Implementation handover should include the rationale behind important controls, not only diagrams and configuration files. Operations teams need to know which flows are critical, which exceptions were temporary, which security assumptions must remain true, and what evidence indicates degradation. Without that context, later maintenance can unintentionally weaken a design while still appearing to follow ordinary change procedures.

Hand the design into operations with maintainability intact

The fourth specialist stage, ISA IC37, exists because security degrades if design assumptions are not maintained. ISA IC34 candidates should therefore think about ownership, documentation, backup, patching, certificate renewal, account lifecycle, monitoring, change control, and replacement parts while the architecture is still being designed.

For final review, take a risk scenario from ISA IC33 and develop a compact design response. State the requirement, draw the zone and conduit relationship, choose layered controls, explain operational constraints, and define how acceptance will be verified. That end-to-end reasoning is much closer to real industrial security engineering than memorizing isolated countermeasures.