The International Society of Automation published ISA-TR62443-2-2-2025 in December 2025, completing a long-awaited piece of the ISA/IEC 62443 series and giving industrial operators their first standards-body guidance on building a Security Protection Scheme (SPS) for industrial automation and control systems. The technical report sits alongside the broader 62443 family — 2-1 for security programs, 3-2 for risk and zone/conduit definition, 3-3 for system requirements, 4-1 for product development — and addresses the practical "how do I assemble all of these into a defensible operational scheme?" question that operators kept asking working group authors. For OT defenders, 2-2-2025 is significant because it formalizes the protection-scheme concept that vendors had been describing inconsistently across product lines, and it gives audits a structured artifact to evaluate.
What is a Security Protection Scheme?
A Security Protection Scheme is the engineered set of technical, administrative, and physical controls that, taken together, protect an IACS at its intended security level (SL-T, per IEC 62443-3-3) under the operating conditions of a defined zone and conduit topology. The SPS is a tangible deliverable — typically a document with a control inventory, zone diagram, control-to-zone mapping, validation procedure, and operational playbooks. Before 2-2-2025, asset owners and integrators worked from informal templates derived from 3-2 risk assessments. The new TR provides a normative structure for what an SPS contains and how to validate it against a target SL.
How does 2-2-2025 fit the rest of the 62443 family?
It bridges design-time and operate-time. IEC 62443-3-2 tells you how to identify zones, conduits, and target security levels via risk assessment. IEC 62443-3-3 tells you what foundational requirements (FRs) and system requirements (SRs) those zones must meet. ANSI/ISA-62443-2-1-2024 tells you what an asset owner's overall security program looks like. ISA-TR62443-2-2-2025 fills the gap between "we have zones with target SLs" and "we have a maintained, documented, validated set of controls in operation that achieve those SLs." It explicitly references the 7 Foundational Requirements (Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability) and shows how a protection scheme is decomposed against them.
# Skeleton Security Protection Scheme excerpt
scheme:
iacs_name: "Plant-A Distillation Control"
zones:
- id: Z-DCS-CRIT
target_sl: SL-T-3
assets:
- emerson-deltav-controller-bay-1
- emerson-deltav-controller-bay-2
conduits_in:
- C-EWS-DCS # engineering workstation to DCS
- C-HMI-DCS
protection_measures:
FR1_IAC:
- active_directory_with_smartcard_for_engineer_role
- rbac_in_deltav_with_privileged_access_workstation
FR3_SI:
- signed_firmware_only
- rate_limited_logic_download
- whitelisted_engineering_workstations
FR5_RDF:
- unidirectional_gateway_to_historian
- dnp3_secure_authentication_v5
FR6_TRE:
- syslog_to_ot_siem_with_24x7_soc
- quarterly_ir_tabletop
validation:
method: structured_walkdown_plus_atomic_testing
cadence: annual_and_after_change
last_evidence: 2026-01-15
What does validation look like under the TR?
Validation of an SPS is no longer a one-time commissioning artifact. The TR calls for a lifecycle of design validation (proof at deployment), operational validation (recurring evidence that the scheme remains effective), and change validation (evidence after material change). The recommended approach combines structured walkdowns (compare design to physical/logical reality), atomic tests (verify individual controls — for example, that engineering-workstation network access is blocked from a non-authorized host), and end-to-end attack simulations against the zone boundary. The TR is explicit that operational validation must catch drift: if a vendor adds a new remote-access path in a maintenance window without updating the SPS, the validation cycle is intended to surface it.
How does 2-2-2025 relate to the broader 62443-1-6 IIoT update?
The IEC PAS 62443-1-6:2025 publication, which preceded 2-2 by several months, addressed industrial IoT use cases by introducing new communication channels, a new organization of functions, and new cybersecurity concerns relevant to cloud-connected IACS deployments. 2-2 builds on that work by giving asset owners a way to incorporate IIoT-driven protection requirements into a Security Protection Scheme. The combination matters because modern industrial operators rarely deploy purely on-premises IACS: they consume cloud telemetry services, allow OEM remote-support tunnels, and run hybrid OT/IT analytics platforms. A 2-2-aligned SPS must accommodate these patterns explicitly, declaring which zones extend off-premises, which conduits cross the OT/IT or OT/cloud boundary, and what compensating controls apply when the operator does not control the entire data path. For organizations whose 3-2 risk assessment was performed before IIoT topologies became common, the SPS exercise is the right time to revisit the assessment under updated 1-6 assumptions.
How does the SPS interact with software supply chain?
Indirectly but importantly. The SPS documents which products are present in each zone; those products carry their own ISA-62443-4-1 development practices and ISA-62443-4-2 component requirements, and modern asset owners are expected to consume vendor SBOMs to maintain the SPS as components are updated. The 2-2-2025 TR does not require SBOMs as part of the protection scheme, but it requires "evidence that vulnerability state of components in the zone is known and managed." In practice, that evidence is most efficiently produced via SBOM ingestion plus continuous CVE matching against the inventory.
What should asset owners do in the next two quarters?
Three actions. First, inventory which IACS in your portfolio have a current SPS-equivalent document and which do not — most operators have something, but few have a structured SPS aligned to 2-2-2025. Second, pick one high-criticality zone and produce a TR-compliant SPS as a pilot; the exercise reveals gaps in zone definition, control documentation, and validation evidence. Third, establish the operational validation cadence — annual plus post-change — and codify who owns evidence collection, because the TR's value is largely in the cadence, not the document. For integrators selling to asset owners under ISA/IEC 62443 expectations, SPS readiness will be a competitive differentiator within the next 12 months.
What about regulator and insurer expectations?
Beyond the standards themselves, regulators in critical-infrastructure sectors and cyber-insurance underwriters are beginning to reference ISA/IEC 62443 alignment as a baseline expectation. The US TSA Security Directives for pipeline and rail operators reference 62443-aligned controls. The EU NIS2 Directive and the Critical Entities Resilience Directive both push affected operators toward demonstrable industrial cybersecurity practice. Cyber insurers underwriting industrial operators routinely ask about 62443 alignment as part of risk evaluation, and operators with documented SPS-aligned programs typically receive better terms than operators relying on ad-hoc OT security claims. The 2-2-2025 publication gives those audiences a structured artifact to evaluate, replacing the historic situation where each regulator and insurer had to construct their own evaluation criteria. For asset owners, this is largely good news: the same SPS work satisfies multiple external audiences rather than requiring parallel evidence preparation for each.
How does the TR change supplier and integrator expectations?
Integrators and product suppliers who build IACS for asset owners face new evidence expectations under 2-2-2025. Where a vendor previously delivered a product certified to ISA/IEC 62443-4-2 component requirements and stopped there, the TR-2-2 lifecycle puts the integrator and supplier on a longer engagement curve: contributing to SPS design, participating in validation, supporting recurring change validation, and responding to vulnerability state in components inside the zone. Several large OT vendors have begun publishing SPS-aligned integration guides for their product lines as a result. For asset owners, the practical effect is improved leverage in supplier contracts — they can demand SPS-aligned support as a contractual term and reference 2-2-2025 as the basis. For integrators, it changes the engagement model from project-bounded to lifecycle-bounded. For pure product suppliers, the change is less direct but still real: their products are now evaluated not just as standalone components but as parts of a documented protection scheme, and the products that come with better SPS integration documentation are easier to recommend.
How Safeguard Helps
Safeguard's OT-extended SBOM module maps IACS components into the platform's component graph, with PLC firmware, HMI software, engineering-workstation packages, and embedded library inventories normalized alongside enterprise software. For each zone defined in a Security Protection Scheme, Safeguard provides the "vulnerability state of components in the zone is known and managed" evidence the TR expects: continuous CVE matching, ICS-CERT advisory ingestion, and CISA KEV tracking, scoped per zone. Griffin AI generates the FR-aligned control narrative skeleton for an SPS, populated from connected asset data, so engineers spend their time validating reality rather than authoring boilerplate. TPRM workflows score IACS vendors against ISA/IEC 62443-4-1 development practice claims, and policy gates can require that any component entering an SL-T-3 zone carries a vendor attestation aligned to 4-1. The result is an SPS that is auditable, current, and traceable rather than a static binder on a control-room shelf.