The Automation Solution Security Lifecycle describes the technical and organisational security work that runs through the life of an IACS Automation Solution — that is, how Control Systems and Components are realised and kept secure at a particular facility.
Teaching notes usually describe seven engineering phases from specification through decommissioning, with shared responsibilities among the Asset Owner, Integration Service Provider, Maintenance Service Provider, and Product Supplier.
Related: Security Protection Scheme (SPS) | Product Security Lifecycle (Part 4-1)
An Automation Solution is the configured reality of one or more Control Systems at a facility — essential functions such as control and safety, plus supporting functions such as historisation and engineering. Risk assessment typically partitions the System Under Consideration into Zones and Conduits.
The IACS is that Automation Solution plus the organisational security measures used to operate and maintain it. The Asset Owner stays accountable for cybersecurity risk of the IACS and the Equipment Under Control, even when suppliers and service providers take on day-to-day responsibilities.
The lifecycle follows systems engineering practice (ISAGCA material references ISO/IEC/IEEE 24748-1 for context) and treats cybersecurity as part of operational reliability and long-term asset management — not a bolt-on after commissioning.
Industrial automation projects often run for decades and see many modifications along the way.
Without a structured engineering lifecycle:
The Automation Solution Security Lifecycle is a repeatable way to weave cybersecurity into each engineering stage so the facility stays protectable for its whole operational life.
Before facility projects lean on this lifecycle, the Asset Owner normally has an IACS Security Program in place (Part 2-1). That program takes organisation-wide security policy and adds IACS-specific shape, for example:
These expectations usually show up in organisational standards and practices, project specifications, and contracts with product suppliers and service providers.
Refer to: IEC 62443 Security Program · IEC 62443-2-1 Cybersecurity Awareness Training
In practice the lifecycle is often taught in two broad bands:
Products developed under the Product Security Lifecycle enter this facility lifecycle with declared security capabilities and guidelines that are then selected and configured against Target Security Levels.
Each phase draws on more than one part of the series. Tags below highlight common anchors — Parts 2-1, 2-2, 2-3, 2-4, 3-2, and 3-3 — rather than a full clause catalogue.
Primary parts: ISA/IEC 62443-3-2 (early Zone / Conduit / risk steps)
Specification sets the cybersecurity scene before detailed design. The Asset Owner frames the System Under Consideration (SUC), runs an initial cybersecurity risk assessment, and partitions the system into Zones and Conduits. Design later uses Target Security Levels (SL-T) for each Zone and Conduit that come out of this work.
In teaching terms, this phase usually covers:
Roles: Asset Owner leads and stays accountable; Integration Service Provider is typically consulted.
Key deliverables:
Refer to: IEC 62443-1-1 Models (Zones & Conduits) · Security Levels
Primary parts: ISA/IEC 62443-3-2 (detailed risk and requirements); technical measures from Part 3-3
Design turns the Specification picture into a workable cybersecurity architecture per Zone and Conduit: technical measures sized to SL-T, related organisational measures, and compensating measures where pure technical capability falls short. The central artefact is the Cybersecurity Requirements Specification (CRS), which the Asset Owner approves before Implementation starts.
In teaching terms, this phase usually covers:
If the early risk picture already sits within tolerable risk, Part 3-2 allows a lighter detailed-design path; otherwise the full detailed assessment continues.
Roles: Asset Owner accountable; Integration Service Provider typically leads design work; Product Supplier consulted on product capabilities.
Key deliverables:
Primary parts: ISA/IEC 62443-2-4 (service provider security program); product updates from suppliers
Implementation installs and configures the technical measures in the CRS. Organisational measures for Operations and Maintenance are prepared in parallel so they can be checked in Verification & Validation. While integration is underway, physical and logical access, update hygiene, confidentiality and malware protection still need to be maintained.
In teaching terms, this phase usually covers:
Roles: Asset Owner accountable. Integration Service Provider typically owns technical build work; Maintenance Service Provider helps shape organisational maintenance measures; Asset Owner owns organisational operations measures. Product Supplier supplies updates and advice on capabilities.
Key deliverables:
Primary parts: CRS checks; optional Security Program Rating – Capability (SPR-C) concepts in Part 2-2; Part 2-4 for service provider validation activities
Verification & Validation asks whether technical and organisational security measures actually meet the CRS. In many sectors this appears as Factory Acceptance Tests (FAT) and Site Acceptance Tests (SAT). Typical techniques include vulnerability scans, penetration tests, intrusion detection checks and access-control tests.
Focuses on ensuring implementation matches design:
Roles: Integration Service Provider typically leads verification of technical measures.
Confirms the Automation Solution satisfies operational security needs:
Roles: Maintenance Service Provider typically validates organisational maintenance measures; Asset Owner validates organisational operations measures.
Formal handover returns the Automation Solution to the Asset Owner. Before the system goes live, change access credentials (accounts, passwords, encryption keys) that were used by the Integration Service Provider or Product Supplier during build. For some essential-function credentials this may be the last convenient chance to rotate them before operation.
Accountable: Asset Owner throughout V&V and handover.
Primary parts: Organisational / operational measures under the Part 2-1 Security Program
After commissioning, the Automation Solution is in service. Organisational and technical security measures run continuously, and both the measures and the underlying risk assessment need periodic review.
In teaching terms, this phase usually covers:
Roles: Asset Owner accountable and responsible for Operations.
Primary parts: ISA/IEC 62443-2-3 (patch management); Part 2-4 (maintenance service provider expectations); Management of Change with risk review
Maintenance is driven by Operations requests or by monitoring for threats and vulnerabilities. Changes to organisational or technical measures should follow a Management of Change process that includes risk review. Product security updates involve Asset Owner, Product Supplier and Maintenance Service Provider roles working together.
Maintenance may also be driven by:
In teaching terms, this phase usually covers:
Roles: Asset Owner accountable and approves Management of Change. Maintenance Service Provider typically owns organisational maintenance execution; Product Supplier supports products and security updates.
Refer to: IEC 62443 Patch Management
Decommissioning may start from a maintenance task (for example replacing storage) or from a major upgrade. The goal is to protect ongoing operations and stop retired equipment from becoming a future cybersecurity liability — including destruction or purging of sensitive data.
In teaching terms, this phase usually covers:
Roles: Asset Owner approves decommissioning through Management of Change; Maintenance Service Provider typically performs the asset work.
A role is not the same as an organisation. One organisation can hold several roles, and a single role’s work can be split across organisations. Accountability for the IACS still sits with the Asset Owner.
Cybersecurity belongs in every engineering phase — not only during Implementation. Changes to the Automation Solution should follow a documented Management of Change (MoC) process so residual risk stays acceptable.
Part 2-2 also discusses Security Program Ratings (SPR) as a way of pairing Security Level (technical) with Maturity Level (organisational), using Capability (SPR-C), Target (SPR-T) and Achieved (SPR-A) flavours. Capability and Target SPRs can inform Integration; Achieved SPR is judged during Operation and Maintenance. The full SPR method is outside this lifecycle overview.
A joint ISA84 / ISA99 effort is aligning the IEC 61511 Functional Safety Lifecycle with ISA/IEC 62443 security lifecycles. Results are expected in future updates to ISA-TR84.00.09 (Cybersecurity Related to the Functional Safety Lifecycle).
Primary Standards