CSA-311

ISA Security Compliance Institute —

Component Security Assurance
Functional security assessment for components

Version 2.3
December 2022

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved
 CSA-311 Terms of Use
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

A. DISCLAIMER

ASCI and all related entities, including the International Society of Automation (collectively, “ASCI”) provide all materials, work products and,
information (‘SPECIFICATION’) AS IS, WITHOUT WARRANTY AND WITH ALL FAULTS, and hereby disclaim all warranties and conditions, whether
express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a
particular purpose, of reliability or availability, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack
of negligence, all with regard to the SPECIFICATION, and the provision of or failure to provide support or other services, information, software, and
related content through the SPECIFICATION or otherwise arising out of the use of the SPECIFICATION. Also, there is no warranty or condition of title,
quiet enjoyment, quiet possession, correspondence to description, or non-infringement with regard to the SPECIFICATION.

Without limiting the foregoing, ASCI disclaims all liability for harm to persons or property, and users of this SPECIFICATION assume all risks of such
harm.

In issuing and making the SPECIFICATION available, ASCI is not undertaking to render professional or other services for or on behalf of any person or
entity, nor is ASCI undertaking to perform any duty owed by any person or entity to someone else. Anyone using this SPECIFICATION should rely on
his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in
any given circumstances.

B. EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES

To the maximum extent permitted by applicable law, in no event shall ASCI or its suppliers be liable for any special, incidental, punitive, indirect, or
consequential damages whatsoever (including, but not limited to, damages for loss of profits or confidential or other information, for business
interruption, for personal injury, for loss of privacy, for failure to meet any duty including of good faith or of reasonable care, for negligence, and for any
other pecuniary or other loss whatsoever) arising out of or in any way related to the use of or inability to use the SPECIFICATION, the provision of or
failure to provide support or other services, information, software, and related content through the SPECIFICATION or otherwise arising out of the use
of the SPECIFICATION, or otherwise under or in connection with any provision of this SPECIFICATION, even in the event of the fault, tort (including
negligence), misrepresentation, strict liability, breach of contract of ASCI or any supplier, and even if ASCI or any supplier has been advised of the
possibility of such damages.

C. OTHER TERMS OF USE

Except as expressly authorized by prior written consent from the Automation Standards Compliance Institute, no material from this document owned,
licensed, or controlled by the Automation Standards Compliance Institute may be copied, reproduced, republished, uploaded, posted, transmitted, or
distributed in any way, except for non-commercial use only, provided that you keep intact all copyright and other proprietary notices. Modification of the
materials or use of the materials for any other purpose, such as creating derivative works for commercial use, is a violation of the Automation
Standards Compliance Institute’s copyright and other proprietary rights.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 2 of 53
 CSA-311 Revision history - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

version date changes

1.11 2019.08.03 initial version published to https://www.isasecure.org
incorporated errata from CSA-102 v2.2; add not relevant case where no essential functions in
FSA-CCSC 1A, CCSC 1B, CCSC 1C, CCSC 1F, FSA-CR 2.10A, FSA-CR 7.1; modify scope of
validation FSA-CR 2.12; add outcomes to FSA-HDR 3.2 RE(1); clarifications FSA-
2.3 2022.12.07 EDR|HDR|NDR 3.14, EDR|HDR|NDR 3.14 RE(1), FSA-CR 4.1B; add not relevant case to FSA-
CR 4.2 RE(1); refer to ICSA-500 in FSA-CR 4.3; correct SDLPA to SDA in FSA-CR 7.1 RE(1)
and FSA-CR 7.6; editorial changes in validation activities for FSA-CR 1.9B, FSA-NDR 1.13, FSA-
NDR 1.13 RE(1)

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 3 of 53
 CSA-311 Overview - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Summary of Worksheets:
Overview Overview - this worksheet providing summary information about each worksheet
Tree Tree Structure - hierarchical summary of all requirements organized by the 7 Foundational Requirements
CCSC Common component security constraints - detailed requirements for common component security constraints
FR 1 Identification & authentication control - detailed requirements for 1st Foundational Requirement
FR 2 Use control - detailed requirements for 2nd Foundational Requirement
FR 3 System integrity - detailed requirements for 3rd Foundational Requirement
FR 4 Data confidentiality - detailed requirements for 4th Foundational Requirement
FR 5 Restricted data flow - detailed requirements for 5th Foundational Requirement
FR 6 Timely response to events - detailed requirements for 6th Foundational Requirement
FR 7 Resource availability - detailed requirements for 7th Foundational Requirement

Common structure used for all requirement worksheets:

Software Application

Embedded Device

Network Device
Host Device

Validation by
Validation Source of Capability Security
Requirement ID Reference Name Requirement Description Independent Test Rationale and Supplemental Guidance
Activity Requirement Level
Required (Yes/No)

Software Application - indicates whether each requirement applies to a software application

Embedded Device - indicates whether each requirement applies to an embedded device
Host Device - indicates whether each requirement applies to a host device
Network Device - indicates whether each requirement applies to a network device
Requirement ID - unique ID number assigned to each requirement within this document
Reference Name - name for each requirement that provides an indication of the scope / content (using names from IEC 62443-4-2, with name extensions to designate parts of requirements)
Requirement Description - text of the requirement from IEC 62443-4-2
Validation Activity - defines activity that must be performed as part of the evaluation audit
Validation by Independent Test Required - indicates whether the auditor is required to perform independent testing as part of the validation activity
Source of Requirement - Reference in IEC 62443-4-2 for the requirement
Capability Security Level - specifies those capability security levels to which the requirement applies in IEC 62443-4-2
Rationale and Supplemental Guidance - additional information on the requirement from sub clause with this title in IEC 62443-4-2

Normative references - The following pairs of references provide the same technical standard, as published by the organizations ANSI/ISA and IEC.

ANSI/ISA-62443-4-2-2018 Security for industrial automation and control systems Part 4-2: Technical security requirements for IACS components
IEC 62443-4-2:2019 Security for industrial automation and control systems Part 4-2: Technical security requirements for IACS components

ANSI/ISA-62443-4-1-2018 Security for industrial automation and control systems Part 4-1: Secure product development lifecycle requirements
IEC 62443-4-1:2018 Security for industrial automation and control systems Part 4-1: Secure product development lifecycle requirements

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 4 of 53
 CSA-311 Tree - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

CCSC - Common Component Security Constraints

x x x x FSA-CCSC 1A Support of essential functions - account lock out 1, 2, 3, 4
x x x x FSA-CCSC 1B Support of essential functions - non-repudiation 1, 2, 3, 4
x x x x FSA-CCSC 1C Support of essential functions - failure of certificate authority 1, 2, 3, 4
x FSA-CCSC 1D Support of essential functions - I&A and SIF initiation 1, 2, 3, 4
x FSA-CCSC 1E Support of essential functions - authorization and SIF initiation 1, 2, 3, 4
x x x x FSA-CCSC 1F Support of essential functions - incorrect timestamps 1, 2, 3, 4
FSA-CCSC 1G Support of essential functions - zone isolation
x FSA-CCSC 1H Support of essential functions - DoS and SIF initiation 1, 2, 3, 4
x x x x FSA-CCSC 2 Compensating countermeasures 1, 2, 3, 4
x x x x FSA-CCSC 3 Least privilege 1, 2, 3, 4
x x x x FSA-CCSC 4 Software development process 1, 2, 3, 4
FR 1 - Identification & Authentication Control
x x x x FSA-CR 1.1 Human user identification and authentication 1, 2, 3, 4
x x x x FSA-CR 1.1 RE(1) Unique identification and authentication 2, 3, 4
x x x x FSA-CR 1.1 RE(2) Multifactor authentication for all interfaces 3, 4
x x x x FSA-CR 1.2 Software process and device identification and authentication 2, 3, 4
x x x x FSA-CR 1.2 RE(1) Unique identification and authentication 3, 4
x x x x FSA-CR 1.3 Account management 1, 2, 3, 4
x x x x FSA-CR 1.4 Identifier management 1, 2, 3, 4
x x x x FSA-CR 1.5A Authenticator management - initialize authenticator content 1, 2, 3, 4
x x x x FSA-CR 1.5B Authenticator management - change default authenticators 1, 2, 3, 4
x x x x FSA-CR 1.5C Authenticator management - change/refresh all authenticators periodically 1, 2, 3, 4
x x x x FSA-CR 1.5D Authenticator management - protect authenticators 1, 2, 3, 4
x x x x FSA-CR 1.5 RE(1) Hardware security for authenticators 3, 4
x FSA-NDR 1.6 Wireless access management 1, 2, 3, 4
x FSA-NDR 1.6 RE(1) Unique identification and authentication 2, 3, 4
x x x x FSA-CR 1.7 Strength of password-based authentication 1, 2, 3, 4
x x x x FSA-CR 1.7 RE(1) Password generation and lifetime restrictions for human users 3, 4
x x x x FSA-CR 1.7 RE(2) Password lifetime restrictions for all users (human, software process, or device) 4
x x x x FSA-CR 1.8 Public key infrastructure (PKI) certificates 2, 3, 4
x x x x FSA-CR 1.9A Strength of public key-based authentication - check validity of signature of a given certificate 2, 3, 4
x x x x FSA-CR 1.9B Strength of public key-based authenticationn -validate certificate chain 2, 3, 4
x x x x FSA-CR 1.9C Strength of public key-based authentication - check certificate's revocation status 2, 3, 4
x x x x 2, 3, 4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 5 of 53
 CSA-311 Tree - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x x x x FSA-CR 1.9E Strength of public key-based authentication - map authenticated identity to a user 2, 3, 4
x x x x FSA-CR 1.9F Strength of public key-based authentication - use of cryptography 2, 3, 4
x x x x FSA-CR 1.9 RE(1) Hardware security for public key-based authentication 3, 4
x x x x FSA-CR 1.10 Authenticator feedback 1, 2, 3, 4
x x x x FSA-CR 1.11A Unsuccessful login attempts - limit number 1, 2, 3, 4
x x x x FSA-CR 1.11B Unsuccessful login attempts - response 1, 2, 3, 4
x x x x FSA-CR 1.12 System use notification 1, 2, 3, 4
x FSA-NDR 1.13 Access via untrusted networks 1, 2, 3, 4
x FSA-NDR 1.13 RE(1) Explicit access request approval 3, 4
x x x x FSA-CR 1.14A Strength of symmetric key-based authentication - establish trust 2, 3, 4
x x x x FSA-CR 1.14B Strength of symmetric key-based authentication - secure storage for shared secret 2, 3, 4
x x x x FSA-CR 1.14C Strength of symmetric key-based authentication - restrict access to shared secret 2, 3, 4
x x x x FSA-CR 1.14D Strength of symmetric key-based authentication - use of cryptography 2, 3, 4
x x x x FSA-CR 1.14 RE(1) Hardware security for symmetric key-based authentication 3, 4
FR 2 - Use Control
x x x x FSA-CR 2.1 Authorization enforcement 1, 2, 3, 4
x x x x FSA-CR 2.1 RE(1) Authorization enforcement for all users (humans, software processes and devices) 2, 3, 4
x x x x FSA-CR 2.1 RE(2) Permission mapping to roles 2, 3, 4
x x x x FSA-CR 2.1 RE(3) Supervisor override 3, 4
x x x x FSA-CR 2.1 RE(4) Dual approval 4
x x x x FSA-CR 2.2 Wireless use control 1, 2, 3, 4
FSA-CR 2.3 Use control for portable and mobile devices NA
x FSA-SAR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-SAR 2.4B Mobile code - control transfer by user 1, 2, 3, 4
x FSA-SAR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-SAR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-EDR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-EDR 2.4B Mobile code - control upload by user 1, 2, 3, 4
x FSA-EDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-EDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-HDR 2.4A Mobile code - control execution 1, 2, 3, 4
x FSA-HDR 2.4B Mobile code - control upload by user 1, 2, 3, 4
x FSA-HDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-HDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x FSA-NDR 2.4A Mobile code - control execution 1, 2, 3, 4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 6 of 53
 CSA-311 Tree - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x FSA-NDR 2.4B Mobile code - control transfer by user 1, 2, 3, 4

x FSA-NDR 2.4C Mobile code - integrity check 1, 2, 3, 4
x FSA-NDR 2.4 RE(1) Mobile code authenticity check 2, 3, 4
x x x x FSA-CR 2.5A Session lock- initiation 1, 2, 3, 4
x x x x FSA-CR 2.5B Session lock- removal 1, 2, 3, 4
x x x x FSA-CR 2.6 Remote session termination 2, 3, 4
x x x x FSA-CR 2.7 Concurrent session control 3, 4
x x x x FSA-CR 2.8A Auditable events - categories 1, 2, 3, 4
x x x x FSA-CR 2.8B Auditable events - data fields 1, 2, 3, 4
x x x x FSA-CR 2.9A Audit storage capacity - allocation 1, 2, 3, 4
x x x x FSA-CR 2.9B Audit storage capacity - exceeded 1, 2, 3, 4
x x x x FSA-CR 2.9 RE(1) Warn when audit record storage capacity threshold reached 3, 4
x x x x FSA-CR 2.10A Response to audit processing failures - maintain essential functions 1, 2, 3, 4
x x x x FSA-CR 2.10B Response to audit processing failures - actions taken 1, 2, 3, 4
x x x x FSA-CR 2.11 Timestamps 1, 2, 3, 4
x x x x FSA-CR 2.11 RE(1) Time synchronization 2, 3, 4
x x x x FSA-CR 2.11 RE(2) Protection of time source integrity 4
x x x x FSA-CR 2.12 Non-repudiation 1, 2, 3, 4
x x x x FSA-CR 2.12 RE(1) Non-repudiation for all users 4
x FSA-EDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-EDR 2.13 RE(1) Active monitoring 3, 4
x FSA-HDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-HDR 2.13 RE(1) Active monitoring 3, 4
x FSA-NDR 2.13 Use of physical diagnostic and test interfaces 2, 3, 4
x FSA-NDR 2.13 RE(1) Active monitoring 3, 4
FR 3 - System Integrity
x x x x FSA-CR 3.1 Communication integrity 1, 2, 3, 4
x x x x FSA-CR 3.1 RE(1) Communication authentication 2, 3, 4
x FSA-SAR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-EDR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-HDR 3.2 Protection from malicious code 1, 2, 3, 4
x FSA-HDR 3.2 RE(1) Report version of code protection 2, 3, 4
x FSA-NDR 3.2 Protection from malicious code 1, 2, 3, 4
x x x x FSA-CR 3.3 Security functionality verification 1, 2, 3, 4
x x x x FSA-CR 3.3 RE(1) Security functionality verification during normal operation 4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 7 of 53
 CSA-311 Tree - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x x x x FSA-CR 3.4 Software and information integrity 1, 2, 3, 4

x x x x FSA-CR 3.4 RE(1) Authenticity of software and information 2, 3, 4
x x x x FSA-CR 3.4 RE(2) Automated notification of integrity violations 3, 4
x x x x FSA-CR 3.5 Input validation 1, 2, 3, 4
x x x x FSA-CR 3.6 Deterministic output 1, 2, 3, 4
x x x x FSA-CR 3.7 Error handling 1, 2, 3, 4
x x x x FSA-CR 3.8A Session integrity - invalidate session identifiers 2, 3, 4
x x x x FSA-CR 3.8B Session integrity - generate and recognize session identifiers 2, 3, 4
x x x x FSA-CR 3.8C Session integrity - random session identifiers 2, 3, 4
x x x x FSA-CR 3.9 Protection of audit information 2, 3, 4
x x x x FSA-CR 3.9 RE(1) Audit records on write-once media 4
x FSA-EDR 3.10 Support for updates 1, 2, 3, 4
x FSA-EDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-HDR 3.10 Support for updates 1, 2, 3, 4
x FSA-HDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-NDR 3.10 Support for updates 1, 2, 3, 4
x FSA-NDR 3.10 RE(1) Update authenticity and integrity 2, 3, 4
x FSA-EDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-EDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-HDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-HDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-NDR 3.11 Physical tamper resistance and detection 2, 3, 4
x FSA-NDR 3.11 RE(1) Notification of a tampering attempt 3, 4
x FSA-EDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-HDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-NDR 3.12 Provisioning product supplier roots of trust - protection 2, 3, 4
x FSA-EDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-EDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-HDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-HDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-NDR 3.13A Provisioning asset owner roots of trust - protection 2, 3, 4
x FSA-NDR 3.13B Provisioning asset owner roots of trust - inside zone 2, 3, 4
x FSA-EDR 3.14 Integrity of the boot process 1, 2, 3, 4
x FSA-EDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4
x FSA-HDR 3.14 Integrity of the boot process 1, 2, 3, 4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 8 of 53
 CSA-311 Tree - CSA
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3
Software Application

Embedded Device

Network Device
Host Device
Capability
Section Requirement ID and Reference Name
Security Level

x FSA-HDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4

x FSA-NDR 3.14 Integrity of the boot process 1, 2, 3, 4
x FSA-NDR 3.14 RE(1) Authenticity of the boot process 2, 3, 4
FR 4 - Data Confidentiality
x x x x FSA-CR 4.1A Information confidentiality - at rest 1, 2, 3, 4
x x x x FSA-CR 4.1B Information confidentiality - in transit 1, 2, 3, 4
x x x x FSA-CR 4.2 Information persistence 2, 3, 4
x x x x FSA-CR 4.2 RE(1) Erase of shared memory resources 3, 4
x x x x FSA-CR 4.2 RE(2) Erase verification 3, 4
x x x x FSA-CR 4.3 Use of cryptography 1, 2, 3, 4
FR 5 - Restricted Data Flow
x x x x FSA-CR 5.1 Network segmentation 1, 2, 3, 4
x FSA-NDR 5.2 Zone boundary protection 1, 2, 3, 4
x FSA-NDR 5.2 RE(1) Deny all, permit by exception 2, 3, 4
x FSA-NDR 5.2 RE(2) Island mode 3, 4
x FSA-NDR 5.2 RE(3) Fail close 3, 4
x FSA-NDR 5.3 General purpose person-to-person communication restrictions 1, 2, 3, 4
FSA-CR 5.4 Application partitioning
FR 6 - Timely Response to Event
x x x x FSA-CR 6.1 Audit log accessibility 1, 2, 3, 4
x x x x FSA-CR 6.1 RE(1) Programmatic access to audit logs 3, 4
x x x x FSA-CR 6.2 Continuous monitoring 2, 3, 4
FR 7 - Resource Availability
x x x x FSA-CR 7.1 Denial of service protection 1, 2, 3, 4
x x x x FSA-CR 7.1 RE(1) Manage communication load from component 2, 3, 4
x x x x FSA-CR 7.2 Resource management 1, 2, 3, 4
x x x x FSA-CR 7.3 Control system backup 1, 2, 3, 4
x x x x FSA-CR 7.3 RE(1) Backup integrity verification 2, 3, 4
x x x x FSA-CR 7.4 Control system recovery and reconstitution 1, 2, 3, 4
FSA-CR 7.5 Emergency power
x x x x FSA-CR 7.6 Network and security configuration settings 1, 2, 3, 4
x x x x FSA-CR 7.6 RE(1) Machine-readable reporting of current security settings 3, 4
x x x x FSA-CR 7.7 Least functionality 1, 2, 3, 4
x x x x FSA-CR 7.8 Control system component inventory 2, 3, 4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 9 of 53
 CSA-311 CCSC
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Embedded Device
Software Application

Network Device
Host Device Validation by
Rationale and
Independent Source of Capability
Requirement ID Reference Name Requirement Description Validation Activity Supplemental
Test Required Requirement Security Level
Guidance
(Yes/No)

The components of the system shall adhere to specific constraints as

described in clause 4 of IEC 62443‑3‑3 [11].
Note that as part of their submissions for certification, the supplier will have
identified the essential functions of the component in alignment with the
(For reference, the specific items from Clause 4 of IEC 62443-3-3
definition in IEC 62443-4-2. Verify in design documentation that accounts
are copied below in this column, for rows FSA-CCSC 1A through
used for essential functions shall not be locked out, even temporarily. Verify
1H, with the first item following, in this cell.)
by testing that accounts used for essential functions are not locked out due IEC 62443-4-2:
x x x x FSA-CCSC 1A Support of essential functions - account lock out Yes 1, 2, 3, 4
to account management actions and locking functions implemented to CCSC 1
Access Controls (IAC and UC) shall not prevent the operation of
meet FR 1. Record one of:
essential functions, specifically:
a. Met
- Accounts used for essential functions shall not be locked out, even
b. Not met
temporarily (see 5.5, SR 1.3 – Account management, 5.6, SR 1.4 –
c. Not relevant - no essential functions
Identifier management, 5.13, SR 1.11 – Unsuccessful login attempts
and 6.7, SR 2.5 – Session lock).

Verify that the supplier has performed and documented analysis and testing
Access Controls (IAC and UC) shall not prevent the operation of to confirm that verifying and recording operator actions to enforce non-
essential functions, specifically: repudiation does not add significant delay to system response time (see
IEC 62443-4-2:
x x x x FSA-CCSC 1B Support of essential functions - non-repudiation - Verifying and recording operator actions to enforce non-repudiation FSA-CR 2.12 – Non-repudiation). Record one of: No 1, 2, 3, 4
CCSC 1
shall not add significant delay to system response time (see 6.14, SR a. Met
2.12 – Non-repudiation). b. Not met
c. Not relevant - no essential functions

If public key authentication is used by the component, determine by asking

the supplier, if this is a high availability component.
If public key authentication is used by the component and the supplier
asserts it is a high availability component, verify that the supplier has a test
case to confirm that the component maintains its essential functions upon
Access Controls (IAC and UC) shall not prevent the operation of failure of the certificate authority. Verify that this test has passed (See FSA-
essential functions, specifically: CR 1.8 – Public key infrastructure (PKI) certificates). Record one of:
Support of essential functions - failure of certificate IEC 62443-4-2:
x x x x FSA-CCSC 1C - For high availability control systems, the failure of the certificate a. Met No 1, 2, 3, 4
authority CCSC 1
authority shall not interrupt essential functions (see 5.10, SR 1.8 – b. Not met
Public key infrastructure (PKI) certificates). If public key authentication is not used by the component, record:
c. Not relevant - public key authentication not used
If public key authentication is used but the supplier does not assert this is a
high availability component, record:
d. Not relevant - not high availability component, or no essential functions

If the component has a safety instrumented function (SIF), verify in design

documentation that Identification and authentication does not prevent the
initiation of the SIF (see FSA-CR 1.1 – Human user identification and
Access Controls (IAC and UC) shall not prevent the operation of
authentication and FSA-CR 1.2 – Software process and device
essential functions, specifically:
identification and authentication). Verify by testing that initiation of SIF
- Identification and authentication shall not prevent the initiation of IEC 62443-4-2:
x FSA-CCSC 1D Support of essential functions - I&A and SIF initiation occurs as designed regardless of the authentication state of component Yes 1, 2, 3, 4
the SIF (see 5.3, SR 1.1 – Human user identification and CCSC 1
users. Record one of:
authentication and 5.4, SR 1.2 – Software process and device
a. Met
identification and authentication).
b. Not met
If the component does not have SIF, record:
c. Not relevant

If the component has a safety instrumented function (SIF), verify in design

documentation that authorization enforcement does not prevent the
Access Controls (IAC and UC) shall not prevent the operation of initiation of the SIF (see FSA-CR 2.1 – Authorization enforcement). Record
Support of essential functions - authorization and SIF essential functions, specifically: one of: IEC 62443-4-2:
x FSA-CCSC 1E No 1, 2, 3, 4
initiation Authorization enforcement shall not prevent the initiation of the SIF a. Met CCSC 1
(see 6.3, SR 2.1 – Authorization enforcement). b. Not met
If the component does not have SIF, record:
c. Not relevant

Verify using design documentation that incorrectly timestamped audit

records do not adversely affect essential functions. (See FSA-CR 2.8 -
Incorrectly timestamped audit records (see 6.10, SR 2.8 – Auditable
Auditable events and FSA-CR 2.11 Timestamps.) Record one of: IEC 62443-4-2:
x x x x FSA-CCSC 1F Support of essential functions - incorrect timestamps events and 6.13 SR 2.11 – Timestamps) shall not adversely affect No 1, 2, 3, 4
a. Met CCSC 1
essential functions.
b. Not met
c. Not relevant - no essential functions

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 10 of 53
 CSA-311 CCSC
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Embedded Device
Software Application

Network Device
Host Device Validation by
Rationale and
Independent Source of Capability
Requirement ID Reference Name Requirement Description Validation Activity Supplemental
Test Required Requirement Security Level
Guidance
(Yes/No)

Essential functions of an IACS shall be maintained if zone boundary There is no component level requirement associated with this requirement
IEC 62443-4-2:
FSA-CCSC 1G Support of essential functions - zone isolation protection goes into fail-close and/or island mode (see 9.4, SR 5.2 – in IEC 62443-3-3, therefore there is no validation activity. 1, 2, 3, 4
CCSC 1
Zone boundary protection).

If the component has a safety instrumented function (SIF), and requirement

FSA-CR 7.1 Denial of service protection has been met, record one of the
A denial of service (DoS) event on the control system or safety following as specified for that requirement, for the essential function SIF:
IEC 62443-4-2:
x FSA-CCSC 1H Support of essential functions - DoS and SIF initiation instrumented system (SIS) network shall not prevent the SIF from a. Met No 1, 2, 3, 4
CCSC 1
acting (see 11.3, SR 7.1 – Denial of service protection). b. Not met
If the component does not have SIF, record:
c. Not relevant

Identify any requirement derived from FR 1 - FR 7 such that:

- it is applicable to the certification level, and
- the result recorded for the validation activity in the present document is
"Met by integration into system."
There will be cases where one or more requirements specified in the
document cannot be met without the assistance of a compensating If there are such requirements, verify for each one that the component
countermeasure that is external to the component. When this is the documentation describes appropriate countermeasures applied by a
IEC 62443-4-2:
x x x x FSA-CCSC 2 Compensating countermeasures case the documentation for that component shall describe the system to allow the requirement to be met when the component is No 1, 2, 3, 4
CCSC 2
appropriate countermeasures applied by the system to allow the integrated into that system. Record one of:
requirement to be met when the component is integrated into a a. Met
system. b. Not met

If there are no requirements that meet these criteria, record:

c. Not relevant

The SDLPA certification element under requirement SDLA-SG-6 in

document SDLA-312, requires information about user account permissions
and privileges required to use the product. If the evaluation for SDLA-SG-6
has passed, verify that the supplier has performed and documented an
analysis of tasks related to the component. Verify that this analysis shows
the permissions provided and mapping capability of permissions to roles
support sufficient granularity and flexibility to enforce the concept of least
privilege assignment of tasks to users. If requirement CR 2.1 has been met
with dependence on external countermeasures, then permission
assignment and mapping for human users may take place external to the
component using compensating system or component countermeasures
When required and appropriate, one or more system components
and/or procedures documented in the supplier’s security guidelines for the
(software applications, embedded devices, host devices and network
component. Examples of external assignment of privileges are: provide a
devices) shall provide the capability for the system to enforce the
privileged account to use an external configuration tool, or provide an IEC 62443-4-2:
x x x x FSA-CCSC 3 Least privilege concept of least privilege. Individual system components shall No 1, 2, 3, 4
individual with a physical key to an enclosure protecting user access to such CCSC 3
provide the granularity of permissions and flexibility of mapping those
a tool. Reliance upon external countermeasures that are not integrated with
permissions to roles sufficient to support it. Individual accountability
the system, as in this last example, is permitted for SL-C = 1 only. Record
shall be available when required.
one of:

a. Met by component (without external countermeasures)

b. Met with dependence on external countermeasures (CR 2.1 must also
be met with dependence on external countermeasures for this option to be
chosen)
c. Not met

If the evaluation for SDLA-SG-6 has not passed, record:

c. Not met

The SDLPA and SDA elements of certification verify this requirement. If

those elements have passed per the criteria for those elements described
in the certification criteria document for this evaluation (specification
All of the components defined in this document shall be developed
numbered 300), record: IEC 62443-4-2:
x x x x FSA-CCSC 4 Software development process and supported following the secure product development processes No 1, 2, 3, 4
a. Met CCSC 4
described in IEC 62443‑4‑1 [12].
Otherwise, record:
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 11 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component has human users, verify

that the component can identify and
Components shall provide the capability
authenticate all users at all accessible
to identify and authenticate all human
interfaces, either locally or by integration All human users need to be identified and authenticated for all access to the component. Authentication of the identity of these users
users according to IEC 62443‑3‑3 [11]
into a system. Note that user identification should be accomplished by using methods such as passwords, tokens, biometrics or physically keyed lids etc., and in the case of
SR 1.1 on all interfaces capable of
and authentication may be role-based or multifactor authentication, some combination thereof. The geographic location of human users can also be used as part of the
human user access. This capability shall
group-based (such as, for some authentication process. This requirement should be applied to both local and remote access to the component. This requirement comes in
enforce such identification and
component interfaces, several users may addition to the requirement of having such an authentication and identification at the system level.
authentication on all interfaces that
Human user identification and share the same identity) Record one of: IEC 62443-4-2: Interfaces capable of human user access are local user interfaces such as touchscreens, push buttons, keyboards, etc. as well as
x x x x FSA-CR 1.1 provide human user access to the No 1, 2, 3, 4
authentication a. Met by component CR 1.1 network protocols designed for human user interactions such as hypertext transfer protocol (HTTP), HTTP secure (HTTPS), file transfer
component to support segregation of
b. Met by integration into system protocol (FTP), secure FTP (SFTP), protocols used for device configuration tools (which are sometimes proprietary and other times use
duties and least privilege in accordance
c. Not met open protocols). User identification and authentication may be role-based or group-based (such as, for some component interfaces,
with applicable security policies and
several users may share the same identity). User identification and authentication should not hamper fast, local emergency actions.
procedures. This capability may be
In order to support IAC policies, as defined according to IEC 62443‑2‑1 [5], the component should verify the identity of all human users as
provided locally by the component or by
If the component has no human users, a first step. In a second step, the permissions assigned to the identified human user should be enforced (see 6.3).
integration into a system level
record:
identification and authentication system.
d. Not relevant

If the component has human users, verify

that the component can uniquely identify
and authenticate all human users at all user
accessible interfaces, either locally or by
integration into a system. Record one of:
Components shall provide the capability
Unique identification and a. Met by component IEC 62443-4-2:
x x x x FSA-CR 1.1 RE(1) to uniquely identify and authenticate all No 2, 3, 4
authentication b. Met by integration into system CR 1.1 RE(1)
human users.
c. Not met

If the component has no human users,

record:
d. Not relevant

If the component has human users, verify

that the component can provide the
capability of multifactor authentication for
all human users, either locally or by
Components shall provide the capability integration into a system. Record one of:
Multifactor authentication for all to employ multifactor authentication for a. Met by component IEC 62443-4-2:
x x x x FSA-CR 1.1 RE(2) No 3, 4
interfaces all human user access to the b. Met by integration into system CR 1.1 RE(2)
component. c. Not met

If the component has no human users,

record:
d. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 12 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Vendor shall provide a list of all types of

software processes and devices with which Note this requirement has been interpreted as intending identification and authentication by the component of other devices, as well as
the component can connect. For all of the requiring identification and authentication of the component itself to other devices.
listed types of software processes and
devices, verify that evidence exists that the “Types” of software processes and devices are defined by the supplier, to distinguish entities with different functions, or that have
component under evaluation can identify different incoming or outgoing authentication capabilities that are required to interoperate with those of the component under evaluation.
and authenticate itself to an entity of this Various brands or models of connecting entities may fall under the same type, and do not need to be individually listed.
Components shall provide the capability
type, for outgoing connections from the
to identify itself and authenticate to any
component to such an entity. Further, verify The function of identification and authentication is to map a known identity to an unknown software process or device (henceforth referred
other component (software application,
that evidence exists that the component to as an entity in 5.4.2) so as to make it known before allowing any data exchange. Allowing rogue entities to send and receive control
embedded devices, host devices and
can identify and authenticate each instance system specific data can result in detrimental behavior of the control system.
network devices), according to IEC
of a software process and device of a listed All entities should be identified and authenticated for all access to the control system. Authentication of the identity of such entities should
62443‑3‑3 [11] SR1.2.
type, for incoming connections from such be accomplished by using methods such as passwords, tokens or location (physical or logical). This requirement should be applied to
If the component, as in the case of an
Software process and device an entity to the component under IEC 62443-4-2: both local and remote access to the control system. However, in some scenarios where individual entities are used to connect to different
x x x x FSA-CR 1.2 application, is running in the context of a No 2, 3, 4
identification and authentication evaluation. Identification and authentication CR 1.2 target systems (for example, remote vendor support), it may be technically infeasible for an entity to have multiple identities. In these
human user, in addition, the
of entities making incoming connections cases, compensating countermeasures would have to be applied.
identification and authentication of the
can be provided either locally or by Special attention needs to be made when identifying and authenticating portable and mobile devices. These types of devices are a known
human user according to IEC
integration into a system level identification method of introducing undesired network traffic, malware and/or information exposure to control systems, including otherwise isolated
62443‑3‑3 [11] SR1.1 may be part of
and authentication system. networks.
the component identification and
Record one of: Where entities function as a single group, identification and authentication may be role-based, group-based or entity-based. It is essential
authentication process towards the
a. Met that local emergency actions as well as control system essential functions not be hampered by identification or authentication
other components.
b. Met by integration into system (for requirements (see clause 4 for a more complete discussion). For example, in common protection and control schemes, a group of
incoming connections) devices jointly execute the protection functions and communicate with multicast messages among the devices in the group. In these
c. Not met cases, group authentication based on shared accounts or shared symmetric keys are commonly used.
d. Not relevant – component does not In order to support identification and authentication control policies as defined according to IEC 62443‑2‑1 [5], the control system verifies
exchange data with any other devices or the identity of all entities as a first step. In a second step, the permissions assigned to the identified entity are enforced (see 6.3, CR 2.1 –
software processes Authorization enforcement)

Vendor shall provide list of all software

processes and devices to which the
component can connect. Verify that
evidence exists that the component can
Components shall provide the capability
Unique identification and provide a unique identification to each IEC 62443-4-2:
x x x x FSA-CR 1.2 RE(1) to uniquely identify and authenticate No 3, 4
authentication process and device to which the CR 1.2 RE(1)
itself to any other component.
component can connect.
Record one of:
a. Met
b. Not met

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify component supports account
management functions by an administrator
Components shall provide the capability A component may provide this capability by integrating into a higher level account management system. If the capability is not integrated
type role to establish, activate, modify,
to support the management of all into a higher level account management system then the component is expected to provide the capability natively.
disable and remove accounts, either
accounts directly or integrated into a IEC 62443-4-2: A common approach meeting this requirement would be a component that delegates the valuation of authentication to a directory server
x x x x FSA-CR 1.3 Account management directly or by integration into a system. No 1, 2, 3, 4
system that manages accounts CR 1.3 (for example, LDAP or Active Directory) which provides the account management capabilities required by IEC 62443‑3‑3 [11] SR 1.3.
Record one of:
according to IEC 62443‑3‑3 [11] SR When a component integrates into a higher level system to provide the account management capabilities there needs to be consideration
a. Met by component
1.3. for the impact to the component in the event that the higher level system capability becomes unavailable.
b. Met by integration into system
c. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
d. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 13 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate that
Components shall provide the capability Accounts created under CR 1.3 – Account management require the use of one or more identifiers to distinctly identify each account.
component allows managing identifiers by
to integrate into a system that supports These identifiers must be unique and unambiguous as to the account with which they are associated. Some examples of identifiers in
user, group, role and / or interface, either
the management of identifiers and/or common use are account names, UNIX user ids, Microsoft Windows account globally unique identifiers (GUID), and bound X.509
directly or by integration into a system. IEC 62443-4-2:
x x x x FSA-CR 1.4 Identifier management provide the capability to support the No 1, 2, 3, 4 certificates. A component may provide a local capability to associate identifiers with accounts. If the component is integrated into a system
Record one of: CR 1.4
management of identifiers directly that enforces a system-wide security policy it is highly recommended that identifiers be associated with the same account across all
a. Met by component
according to IEC 62443‑3‑3 [11] SR components in the system. In order to accomplish this a component must be able to integrate into a system-wide identifier management
b. Met by integration into system
1.4. capability.
c. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
d. Not relevant

In addition to an identifier (see 5.6) an authenticator is required to prove identity. Control system authenticators include, but are not limited
to, tokens, symmetric keys, private keys (part of a public/private key pair), biometrics, passwords, physical keys and key cards. There
should be security policies in place instructing that human users must take reasonable measures to safeguard authenticators, including
maintaining possession of their individual authenticators, not loaning or sharing authenticators with others and reporting lost or
compromised authenticators immediately.
Authenticators have a lifecycle. When an account is created automatically a new authenticator needs to be created, in order for the
account owner to be able to authenticate. For example, in a password-based system, the account has a password associated with it.
Definition of the initial authenticator content could be interpreted as the administrator defining the initial password that the account
If component provides the capability to management system sets for all new accounts. Being able to configure these initial values makes it harder for an attacker to guess the
identify and authenticate users of any type password between account creation and first account use (which should involve the setting of a new password by the account owner).
(humans, software processes or devices), Some control systems are installed with unattended installers that create all necessary accounts with default passwords and some
either directly or by integration into a embedded devices are shipped with default passwords. Over time, these passwords often become general knowledge and are
system, verify user documents indicate documented on the Internet. Being able to change the default passwords protects the system against unauthorized users using default
ability to define initial authenticator content. passwords to gain access. Passwords can be obtained from storage or from transmission when used in network authentication. The
Components shall provide the capability
Authenticator management - Record one of: IEC 62443-4-2: complexity of this can be increased by cryptographic protections such as encryption or hashing or by handshake protocols that do not
x x x x FSA-CR 1.5A to support the use of initial authenticator No 1, 2, 3, 4
initialize authenticator content a. Met CR 1.5(a) require transmission of the password at all. Still, passwords might be subject to attacks, for example, brute force guessing or breaking the
content.
b. Not met cryptographic protection of passwords in transit or storage. The window of opportunity can be reduced by changing/refreshing the
If component does not provide the passwords periodically. Similar considerations apply to authentication systems based on cryptographic keys. Enhanced protection can be
capability to identify and authenticate users achieved by using hardware mechanisms such as hardware security modules like trusted platform modules (TPMs).
of any type as described above, record: The management of authenticators should be specified in applicable security policies and procedures, for example, constraints to change
c. Not relevant default authenticators, refresh periods, specification of the protection of authenticators or firewall procedures.
Besides the capabilities for authenticator management specified in this requirement, the strength of the authentication mechanism
depends on the strength of the chosen authenticator (for example, password complexity or key length in public key authentication) and the
policies for validating the authenticator in the authentication process (for example, how long a password is valid or which checks are
performed in public key certificate validation). For the most common authentication mechanisms, password-based and public key
authentication, 5.9, 5.10 and 5.11 provide further requirements.
Use of components for some operations may be restricted, requiring additional authentication (such as, tokens, keys and certificates) in
order to perform some functions.

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate
ability to change default authenticators
(such as default passwords) at installation
Components shall provide the capability
time. Verify by testing that the component
Authenticator management - to support the recognition of changes to IEC 62443-4-2:
x x x x FSA-CR 1.5B recognizes these changes after installation Yes 1, 2, 3, 4 See FSA-CR 1.5A
change default authenticators default authenticators made at CR 1.5(b)
as expected. Record one of:
installation time.
a. Met
b. Not met

If component does not provide the

capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 14 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify user documents indicate
ability to function properly with
Authenticator management - Components shall provide the capability
changed/refreshed authenticators. Record IEC 62443-4-2:
x x x x FSA-CR 1.5C change/refresh all authenticators to function properly with periodic No 1, 2, 3, 4 See FSA-CR 1.5A
one of: CR 1.5(c)
periodically authenticator change/refresh operation.
a. Met
b. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

If component provides the capability to

identify and authenticate users of any type
(humans, software processes or devices),
either directly or by integration into a
system, verify design or user documents
indicate ability to protect authenticators
Components shall provide the capability
from unauthorized disclosure and
to protect authenticators from
Authenticator management - modification when stored, used or IEC 62443-4-2:
x x x x FSA-CR 1.5D unauthorized disclosure and No 1, 2, 3, 4 See FSA-CR 1.5A
protect authenticators transmitted by the component. Record one CR 1.5(d)
modification when stored, used and
of:
transmitted.
a. Met
b. Not met
If component does not provide the
capability to identify and authenticate users
of any type as described above, record:
c. Not relevant

Verify user or design documents indicate

The authenticators on which the ability to protect relevant authenticators with
Hardware security for IEC 62443-4-2:
x x x x FSA-CR 1.5 RE(1) component rely shall be protected via hardware mechanisms. Record one of: No 3, 4
authenticators CR 1.5 RE(1)
hardware mechanisms. a. Met
b. Not met

If the network device supports wireless

access management, verify that the
network device can identify and
authenticate all users (humans, software
processes, or devices) engaged in wireless
A network device supporting wireless communication. Note that user identification
access management shall provide the and authentication may be role-based or Any wireless technology can, and in most cases should, be considered just another communication protocol option. Thus, it should be
capability to identify and authenticate all group-based (such as, for some IEC 62443-4-2: subject to the same IACS security requirements as any other communication type utilized by the IACS. However, from a security point of
x FSA-NDR 1.6 Wireless access management No 1, 2, 3, 4
users (humans, software processes or component interfaces, several users may NDR 1.6 view, there is at least one significant difference between wired and wireless communications. Physical security countermeasures are
devices) engaged in wireless share the same identity). Record one of: typically less effective when using wireless.
communication. a. Met
b. Not met

If the network device does not support

wireless access management, record:
c. Not relevant

If the network device supports wireless

communication, verify that the network
device can uniquely identify and
authenticate all users (humans, software
The network device shall provide the
processes, or devices) engaged in wireless
capability to uniquely identify and
Unique identification and communication. Record one of: IEC 62443-4-2:
x FSA-NDR 1.6 RE(1) authenticate all users (humans, No 2, 3, 4
authentication a. Met NDR 1.6 RE(1)
software processes or devices)
b. Not met
engaged in wireless communication.
If the network device does not support
wireless communication, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 15 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component utilizes password-based

authentication, verify user documents
indicate that configurable password
For components that utilize password- strength can be enforced that meets
based authentication, those internationally recognized and proven
components shall provide or integrate guidelines, either directly or by integration The ability to enforce configurable password strength, whether it is based on minimum length, variety of characters, or duration of time
Strength of password-based into a system that provides the into a system. Record one of: IEC 62443-4-2: (the minimum being a one-time password) is necessary to assist in increasing the overall security of user chosen passwords. Generally
x x x x FSA-CR 1.7 No 1, 2, 3, 4
authentication capability to enforce configurable a. Met by component CR 1.7 accepted practices and recommendations can be found in documents such as NIST SP800-63-2, Electronic Authentication Guideline
password strength according to b. Met by integration into system [27].
internationally recognized and proven c. Not met
password guidelines.
If the component does not utilize password-
based authentication, record:
d. Not relevant

If the component utilizes password-based

authentication, verify user documents
indicate that password use for human users
Components shall provide, or integrate
can be limited to a specified lifetime, and re-
into a system that provides, the
use can be limited to a configurable
capability to protect against any given
number of generations, either directly or by
human user account from reusing a
integration into a system. Verify a source
password for a configurable number of
for the commonly accepted practices
Password generation and lifetime generations. In addition, the component IEC 62443-4-2:
x x x x FSA-CR 1.7 RE(1) followed. Record one of: No 3, 4
restrictions for human users shall provide the capability to enforce CR 1.7 RE(1)
a. Met by component
password minimum and maximum
b. Met by integration into system
lifetime restrictions for human users.
c. Not met
These capabilities shall conform to
commonly accepted security industry
If the component does not utilize password-
practices.
based authentication, record:
d. Not relevant

If the component utilizes password-based

authentication, verify user documents
indicate that the component supports the
capability to enforce password minimum
and maximum lifetime restrictions for all
types of users that support password
Components shall provide, or integrate
based authentication (humans, software
Password lifetime restrictions for into a system that provides, the
processes, devices), either directly or by IEC 62443-4-2:
x x x x FSA-CR 1.7 RE(2) all users (human, software capability to enforce password No 4
integration into a system. Record one of: CR 1.7 RE(2)
process, or device) minimum and maximum lifetime
a. Met by component
restrictions for all users.
b. Met by integration into system
c. Not met

If the component does not utilize password-

based authentication, record:
d. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 16 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if public key authentication is used by the
component. This includes use of X509
certificates or other trust models (e.g.
PGP).

For reference, IEC 62443-3-3 SR 1.8

states: "Where PKI is utilized, the control
system shall provide the capability to
operate a PKI according to commonly
accepted best practices or obtain public
key certificates from an existing PKI." SR
1.8 has accompanying rationale also
When public key infrastructure (PKI) is
included in IEC 62443-4-2 for CR 1.8, and The selection of an appropriate PKI should consider the organization’s certificate policy which should be based on the risk associated with
utilized, the component shall provide or shown in the present document in the
a breach of confidentiality of the protected information. Guidance on the policy definition can be found in commonly accepted standards
Public key infrastructure (PKI) integrate into a system that provides the IEC 62443-4-2:
x x x x FSA-CR 1.8 "Rationale and Supplemental Guidance" No 2, 3, 4 and guidelines, such as the Internet Engineering Task Force (IETF) Request for Comment (RFC) 3647 [31] for X.509-based PKI. For
certificates capability to interact and operate in CR 1.8
column to the right. example, the appropriate location of a certification authority (CA), whether within the control system versus on the Internet, and the list of
accordance with IEC 62443‑3‑3 [11]
trusted CAs should be considered in the policy and depends on the network architecture (see also IEC 62443‑2‑1 [5]).
SR1.8. If public key authentication is used, for
certificates not obtained from an existing
PKI, verify user documents indicate that the
required public key infrastructure practices
per SR 1.8 are supported, either directly or
by integration into a system. Record one of:
a. Met by component
b. Met by integration into system
c. Not met
If public key authentication is not used by
the component, record:
d. Not relevant

Review user documentation and determine To meet the requirements in 5.11.1 does not necessarily require a real time connection to a certificate authority. Alternative out-of-band
if public key authentication is used. methods may be used to meet the requirements in 5.11.1. For example, a disconnected system could install and update certifications
using manual out-of-band processes.
If public key authentication is used, verify in Public/private key cryptography strongly depends on the secrecy of a given subject’s private key and proper handling of the trust
user documentation that signature validity relationships. When verifying a trust between two entities based on public key authentication, it is essential to trace the public key
can be determined, either directly or by certificate to a trusted entity. A common implementation error in certificate validation is to only check the validity of a certificate’s signature,
integration into a system, without but not checking the trust in the signer. In a PKI setting, a signer is trusted if they are a trusted CA or have a certificate issued by a trusted
communicating outside the same IACS CA, thus all verifiers need to trace certificates presented to them back to a trusted CA. If such a chain of trusted CAs cannot be
environment, such as out to the Internet or established, the presented certificate should not be trusted.
For components that utilize public-key- to a less secure IACS zone. If self-signed certificates are used instead of a PKI, the certificate subject itself signed its certificate, thus there never is a trusted third-
based authentication, those party or CA. This should be compensated by deploying the self-signed public key certificates to all peers that need to validate them via an
components shall provide directly or If the component directly supports the otherwise secured mechanism (for example, configuration of all peers in a trusted environment). Trusted certificates need to be distributed
Strength of public key-based
integrate into a system that provides the capability, also verify with the following test IEC 62443-4-2: to peers through secure channels. During the validation process, a self-signed certificate should only be trusted if it is already present in
x x x x FSA-CR 1.9A authentication - check validity of 2, 3, 4
capability within the same IACS in an environment without an Internet Yes CR 1.9(a) the list of trusted certificates of the validating peer. The set of trusted certificates should be configured to the minimum necessary set.
signature of a given certificate
environment to validate certificates by connection. Provide a certificate with an In both cases, validation needs to also consider the possibility that a certificate is revoked. In a PKI setting this is typically done by
checking the validity of the signature of invalid signature to the component. Verify maintaining certificate revocation lists (CRLs) or running an online certificate status protocol (OCSP) server. When revocation checking is
a given certificate. that this problem is detected and reported not available due to control system constraints, mechanisms such as a short certificate lifetime can compensate for the lack of timely
to the user. Record one of: revocation information. Note that short lifetime certificates can sometimes create significant operational issues in a control system
a. Met by component environment.
b. Met by integration in system It is expected that most components will integrate into an IACS and leverage the key authentication mechanisms provided by the
c. Not met underlying IACS. When implementing public key authentication at the component-level of an IACS, protection of the key becomes a
primary concern and objective of key storage on that component. Care should be taken in the implementation to assure that any private
If public key authentication is not used, keys stored within the component cannot be retrieved or tampered with (See 5.7, CR 1.5 – Authenticator management).
record: NOTE Tamper resistant design methodologies and technologies are available to assist with designing a secure private key protection
d. Not relevant mechanism.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 17 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation and determine if the
component has the capability, either directly
or by integration into a system, to validate
For components that utilize public-key-
the certificate chain without communicating
based authentication, those
outside the same IACS environment or in
components shall provide directly or
the case of self-signed certificates, by
integrate into a system that provides the
deploying leaf certificates to all nodes which
Strength of public key-based capability within the same IACS
communicate with the subject to which the IEC 62443-4-2:
x x x x FSA-CR 1.9B authentication -validate certificate environment to validate the certificate No 2, 3, 4 See FSA-CR 1.9A
certificate is issued. Examples of CR 1.9(b)
chain chain or, in the case of self-signed
communication outside the same IACS
certificates, by deploying leaf
environment are communication to the
certificates to all hosts that
Internet or to a less secure IACS zone.
communicate with the subject to which
Record one of:
the certificate is issued.
a. Met by component
b. Met by integration with system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, verify in

user documentation that the component
has the capability, either directly or by
integration into a system, to check
certification revocation status without
communication outside the same IACS
For components that utilize public-key- environment, such as to the Internet or a
based authentication, those less secure IACS zone.
components shall provide directly or
Strength of public key-based
integrate into a system that provides the If the component directly supports the IEC 62443-4-2:
x x x x FSA-CR 1.9C authentication - check certificate's Yes 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS capability, also verify with the following test CR 1.9(c)
revocation status
environment to validate certificates by in an environment without an Internet
checking a given certificate’s revocation connection. Provide a certificate with a
status. revoked status. Verify that the problem is
detected and reported to the user.
Record one of:
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used,

examine user documents to verify that key
pairs may be generated either directly or by
integration into a system, without
For components that utilize public-key- communicating outside the same IACS
based authentication, those environment, such as to the Internet or a
components shall provide directly or less trusted IACS zone. Verify by review of
Strength of public key-based
integrate into a system that provides the user and design documents that IEC 62443-4-2:
x x x x FSA-CR 1.9D authentication - establish user No 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS corresponding private keys are only CR 1.9(d)
control of private key
environment to establish user (human, accessible by the owner of the key, whether
software process or device) control of human, software process, or device.
the corresponding private key. Record one of:
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 18 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine

if public key authentication is used.

If public key authentication is used,

examine user documents to verify that an
identity authenticated by public key
For components that utilize public-key- authentication is mapped to a component
based authentication, those user (human, software process, or device),
components shall provide directly or without communicating outside the same
Strength of public key-based
integrate into a system that provides the IACS environment, such as to the Internet IEC 62443-4-2:
x x x x FSA-CR 1.9E authentication - map No 2, 3, 4 See FSA-CR 1.9A
capability within the same IACS or a less trusted IACS zone. Record one CR 1.9(e)
authenticated identity to a user
environment to map the authenticated of:
identity to a user (human, software a. Met by component
process or device). b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation to verify that the
component provides the capability either
directly or by integration into a system, and
For components that utilize public-key-
without communication outside the same
based authentication, those
IACS environment, to ensure that
components shall provide directly or
algorithms and keys used for this comply
Strength of public key-based integrate into a system that provides the
with FSA-CR 4.3 - Use of cryptography. IEC 62443-4-2:
x x x x FSA-CR 1.9F authentication - use of capability within the same IACS No 2, 3, 4 See FSA-CR 1.9A
Examples of communication outside the CR 1.9(f)
cryptography environment to ensure that the
same IACS environment are
algorithms and keys used for the public
communication to the Internet or to a less
key authentication comply with CR 4.3 –
secure IACS zone. Record one of:
Use of cryptography.
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

Review user documentation and determine

if public key authentication is used.

If public key authentication is used, review

design documentation to verify that
hardware mechanisms are used to protect
critical long-lived private keys, either directly
Components shall provide the capability
Hardware security for public key- by the component or by integration into a IEC 62443-4-2:
x x x x FSA-CR 1.9 RE(1) to protect critical, long-lived private keys No 3, 4
based authentication system. Record one of: CR 1.9 RE(1)
via hardware mechanisms.
a. Met by component
b. Met by integration into system
c. Not met

If public key authentication is not used,

record:
d. Not relevant

If the component locally provides an

authentication capability, verify component
When a component provides an
is capable of obscuring feedback of Obscuring feedback protects the information from possible exploitation by unauthorized individuals, for example, displaying asterisks or
authentication capability, the component
authentication information. Record one of: IEC 62443-4-2: other random characters when a human user types in a username and/or password obscures feedback of authentication information.
x x x x FSA-CR 1.10 Authenticator feedback shall provide the capability to obscure No 1, 2, 3, 4
a. Met CR 1.10 Other examples include the entry of secure socket shell (SSH) token entry and one-time passwords. The authenticating entity should not
feedback of authenticator information
b. Not met provide any hint as to the reason for the authentication failure, such as “unknown user name.”
during the authentication process.
If the component does not locally provide
an authentication capability record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 19 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component locally provides an

authentication capability, verify component
is capable of enforcing a limit of a
When a component provides an Due to the potential for denial of service, the number of consecutive invalid access attempts may be limited. If enabled, the application or
configurable number of consecutive invalid
authentication capability the component device may automatically reset to zero the number of access attempts after a predetermined time period established by the applicable
access attempts by any user (human,
shall provide the capability to enforce a security policies and procedures. Resetting the access attempts to zero will allow users (human, software process or device) to gain
software process or device) during a
Unsuccessful login attempts - limit of a configurable number of IEC 62443-4-2: access if they have the correct login credentials. Automatic denial of access for control system operator workstations or nodes should not
x x x x FSA-CR 1.11A configurable time period. Record one of: No 1, 2, 3, 4
limit number consecutive invalid access attempts by CR 1.11(a) be used when immediate operator responses are required in emergency situations. All lockout mechanisms should consider functional
a. Met
any user (human, software process or requirements for continuous operations so as to mitigate adverse denial of service operating conditions which could result in system
b. Not met
device) during a configurable time failures or compromising the safety of the system. Allowing interactive logins to an account used for critical services could provide a
period. potential for denial of service or other abuse.
If the component does not locally provide
an authentication capability, record:
c. Not relevant

If the component locally provides an

authentication capability, verify component
is capable of denying access for a
specified period of time or until unlocked by
When a component provides an
an administrator when a configured limit for
authentication capability the component
unsuccessful login attempts has been
Unsuccessful login attempts - shall provide the capability to deny IEC 62443-4-2:
x x x x FSA-CR 1.11B reached. Record one of: No 1, 2, 3, 4 See FSA-CR 1.11A
response access for a specified period of time or CR 1.11(b)
a. Met
until unlocked by an administrator when
b. Not met
this limit has been reached.
If the component does not locally provide
an authentication capability, record:
c. Not relevant

If component provides local human use

access/HMI, verify component is capable of Privacy and security policies and procedures need to be consistent with applicable laws, directives, policies, regulations, standards and
displaying user configurable system use guidance. Often, the main justification for this requirement is legal prosecution of violators and proving intentional breach. This capability is
When a component provides local
notifications before authenticating. Record thus necessary to support policy requirements, and might improve IACS security because it can be used as a deterrent. System use
human user access/HMI, it shall provide
one of: notification messages can be implemented in the form of warning banners displayed when individuals log in to the control system. A
the capability to display a system use
a. Met IEC 62443-4-2: warning banner implemented as a posted physical notice in the control system facility does not protect against remote login issues.
x x x x FSA-CR 1.12 System use notification notification message before No 1, 2, 3, 4
b. Not met CR 1.12 Examples of elements for inclusion in the system use notification message are:
authenticating. The system use
a) that the individual is accessing a system owned by the asset owner;
notification message shall be
If the component does not provide local b) that system usage may be monitored, recorded and subject to audit;
configurable by authorized personnel.
human use access/HMI, record: c) that unauthorized use of the system is prohibited and subject to criminal and/or civil penalties; and
c. Not relevant d) that use of the system indicates consent to monitoring and recording.

Unless the supplier has documented that a

network device is not intended to support
access into a network via an untrusted
network, verify that the network device has
the capability to inspect all network traffic
The network device should protect against unauthorized connections or subversion of authorized connections.
that accesses the device, where that
Examples of access to the network device via untrusted networks typically include remote access methods (such as, dial-up, broadband
inspection determines whether the network
and wireless) as well as connections from a company’s office (non-control system) network. The network device may provide ACL
device takes action to control the traffic.
The network device supporting device (Access Control List) functionality to restrict access by:
Examples of control actions supported may
access into a network shall provide the Layer 2 forwarding devices such as Ethernet switches:
include rerouting the traffic or dropping it. IEC 62443-4-2:
x FSA-NDR 1.13 Access via untrusted networks capability to monitor and control all No 1, 2, 3, 4 a) MAC address
Methods of access to the network device NDR 1.13
methods of access to the network b) VLAN
subject to this requirement shall include but
device via untrusted networks. Layer 3 forwarding devices such as routers, gateways and firewalls:
are not limited to, dial-up, broadband, and
a) IP address
wireless.
b) Port and protocol
Record one of:
c) Virtual Private Networks
a. Met
b. Not met
If the supplier has documented that a
network device may not be used to support
access into a network, record:
c. Not relevant

Verify by test that: the network device may

The network device shall provide the assign a user to a role approving untrusted
capability to deny access requests via networks for access to the network device, IEC 62443-4-2:
x FSA-NDR 1.13 RE(1) Explicit access request approval Yes 3, 4
untrusted networks unless explicitly and that networks so approved are NDR 1.13 RE(1)
approved by an assigned role. permitted access, and other networks are
not.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 20 of 53
 CSA-311 FR 1
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Means should be defined for installing the keys into the component. This may include installing and managing the component key using
Review user documentation and determine out-of-band methods. This is necessary since a compromise of any symmetric keys that are stored within the component could lead to a
if symmetric key authentication is used. full compromise of the system using those keys.
In practice, there are two basic ways to perform the secure authentication of a device to another: either using asymmetric cryptography
If symmetric key authentication is used, (see 5.11) or by using symmetric cryptography. The choice between asymmetric and symmetric is dictated by several criteria, like key
For components that utilize symmetric verify user documents indicate ability for the management, trust provisioning, legacy support and efficiency. Examples of symmetric key authentication schemes are Needham-
keys, the component shall provide the component to establish mutual trust using Schröder or Kerberos. When symmetric key authentication is used, the party uses a secret key they have learned in the past (for
Strength of symmetric key-based IEC 62443-4-2:
x x x x FSA-CR 1.14A capability to establish the mutual trust the symmetric key. Record one of: No 2, 3, 4 example, through trust provisioning). The party proves their claimed identity by proving knowledge of the secret key (for example, by
authentication - establish trust CR 1.14(a)
using the symmetric key. a. Met answering a challenge submitted by the other party, the examiner). The examiner has the knowledge of the same secret (also learned in
b. Not met the past through trust provisioning) and is able to compute the answer to the challenge performing the same cryptographic operations as
the prover. The examiner can then compare the answer of the prover with its own computation. If they match, the examiner is convinced
If symmetric key authentication is not used, that the prover is the one they claim to be and the process can be conducted the other way around, switching roles, to achieve mutual-
record: authentication. This mechanism is secure only if the shared secret is only known by the prover and the examiner and if the secret is
c. Not relevant diversified per prover. One instance of such a mechanism is the proper use of cipher-based message authentication code (CMAC)
computations or alternatively the Galois counter mode (GCM)/Galois message authentication code (GMAC) operation modes.

Review user documentation and determine

if symmetric key authentication is used.
If symmetric key authentication is used,
verify user and design documents indicate
For components that utilize symmetric
ability to protect the shared secret from
Strength of symmetric key-based keys, the component shall provide the
unauthorized disclosure. Record one of: IEC 62443-4-2:
x x x x FSA-CR 1.14B authentication - secure storage capability to store securely the shared No 2, 3, 4 See FSA-CR 1.14A
a. Met CR 1.14(b)
for shared secret secret (the authentication is valid as
b. Not met
long as the shared secret remains
If symmetric key authentication is not used,
secret).
record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

verify design and user documents indicate
For components that utilize symmetric ability to protect the shared secret from
Strength of symmetric key-based
keys, the component shall provide the unauthorized use or modification Record IEC 62443-4-2:
x x x x FSA-CR 1.14C authentication - restrict access to No 2, 3, 4 See FSA-CR 1.14A
capability to restrict access to the one of: CR 1.14(c)
shared secret
shared secret. a. Met
b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

review design documentation to verify that
For components that utilize symmetric the component provides the capability to
keys, the component shall provide the ensure that algorithms and keys used for
capability to ensure that the algorithms this comply with FSA-CR 4.3 - Use of IEC 62443-4-2:
x x x x FSA-CR 1.14D No 2, 3, 4 See FSA-CR 1.14A
and keys used for the symmetric key cryptography. Record one of: CR 1.14(d)
authentication comply with CR 4.3 – a. Met
Use of cryptography Subclause 8.5. b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Review user documentation and determine

if symmetric key authentication is used.

If symmetric key authentication is used,

review design documentation to verify that
hardware mechanisms are used to protect
Components shall provide the capability
Hardware security for symmetric critical long-lived symmetric keys. Record IEC 62443-4-2:
x x x x FSA-CR 1.14 RE(1) to protect critical, long lived symmetric No 3, 4
key-based authentication one of: CR 1.14 RE(1)
keys via hardware mechanisms.
a. Met
b. Not met

If symmetric key authentication is not used,

record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 21 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Use control policies (for example, identity-based policies, role-based policies

For capability security levels 3 and 4, or if the component
and rule-based policies) and associated read/write access enforcement
provides the capability to directly identify and authenticate
mechanisms (for example, access control lists, access control matrices and
human users, verify the component directly enforces
cryptography) are employed to control usage between users (humans, software
authorizations for these users to control use of the
processes and devices) and assets (for example, devices, files, records,
component as configured. For capability security levels 1
software processes, programs and domains).
and 2, if the component provides the capability to identify
After the control system has verified the identity of a user (human, software
and authenticate human users by integration into a
process or device) (see 5.3, CR 1.1 – Human user identification and
system, then verify that authorizations to access the
authentication and 5.4, CR 1.2 – Software process and device identification and
component are enforced by either the component and/or
authentication), it also has to verify that a requested operation is actually
external countermeasures that are documented in the
Components shall provide an authorization permitted according to the defined security policies and procedures. For
supplier’s security guidelines. These external
enforcement mechanism for all identified and IEC 62443-4-2: example, in a role-based access control policy, the control system would check
x x x x FSA-CR 2.1 Authorization enforcement countermeasures may include mechanisms that may or No 1, 2, 3, 4
authenticated users based on their assigned CR 2.1 which roles are assigned to a verified user or asset and which privileges are
may not be integrated with the system, and
responsibilities. assigned to these roles – if the requested operation is covered by the
policies/procedures that restrict how human users may
permissions, it is executed, otherwise rejected. This allows the enforcement of
connect to the component. Reliance upon external
segregation of duties and least privileges. Usage enforcement mechanisms
countermeasures not integrated with the system, or
should not be allowed to adversely affect the operational performance of the
reliance upon adherence to policies/procedures that are
control system.
carried out by non-administrators, is permitted for SL-C=1
Planned or unplanned changes to control system components can have
only. Record one of:
significant effects on the overall security of the control system. Accordingly, only
qualified and authorized individuals should obtain the use of control system
a. Met by component (without external countermeasures)
components for purposes of initiating changes, including upgrades and
b. Met with dependence on external countermeasures
modifications.
c. Not met
If the component has no human users, record:
d. Not relevant

Further notes on above validation activity:

NOTE 1 Any mechanism via which a human may
influence a deployed component, involves a human “user”
(per definitions in 62443-1-1-2007 for “user” and
“access”). A common scenario is human user access to a
component via an intermediate program such as a
configuration tool.
NOTE 2 The following are example countermeasures
related to the case of an external configuration tool that
has a network connection to the component. These
countermeasures might be used in various combinations
to enforce restriction of component configuration access
to authorized individuals for capability security levels 1
and 2. IEC 62443-4-2:
x x x x FSA_CR 2.1 Authorization enforcement NA 1,2,3,4
Examples of external countermeasures integrated with the CR 2.1
system:
• Human user identification/authorization capability of
external configuration tool
• Device-level network restriction that only the intended
configuration tool workstation can connect to the
component configuration port
• Application-level restriction that only configuration tool
software can connect to the component configuration
interface
• Configuration tool and component are placed in same
domain, with domain enforcement of permitted network
connections to the component

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 22 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Further notes on above validation activity, continued:

•Mechanism that detects and/or prevents a second copy
of configuration tool software from communicating on the
IACS network
• Physical key required to power up the configuration tool
workstation
Examples of external countermeasures not integrated with
the system:
• Physical key required to gain physical access to IEC 62443-4-2:
x x x x FSA_CR 2.1 Authorization enforcement NA 1, 2, 3, 4
enclosure that houses the configuration tool workstation CR 2.1
Examples of policies/procedures for administrators:
• Only one engineering workstation may be placed in
domain with component
Examples of policies/procedures for non-administrators:
• Only one instance of engineering workstation software
may be connected to IACS (in the case where no
mechanisms detect/prevent a non-administrator from
setting up such a connection)

Review user documentation and determine if software

processes or devices are supported with user accounts on
the component.
If software processes or devices are supported with user
accounts, verify component enforces authorizations for
processes and device users to control use of the
Authorization enforcement for all Components shall provide an authorization
component as configured by account management. IEC 62443-4-2:
x x x x FSA-CR 2.1 RE(1) users (humans, software processes enforcement mechanism for all users based on No 2, 3, 4
Record one of: CR 2.1 RE(1)
and devices) their assigned responsibilities and least privilege.
a. Met
b. Not met
If software processes or devices are not supported with
user accounts on the component, record:
c. Not relevant

If the component provides the capability to identify and

authenticate users of any type (humans, software
processes or devices), either directly or by integration into
a system, verify component provides the capability to map
Components shall, directly or through a permissions to roles for these users by an authorized
compensating security mechanism, provide for supervisory level account, either directly or through a
IEC 62443-4-2:
x x x x FSA-CR 2.1 RE(2) Permission mapping to roles an authorized role to define and modify the compensating security mechanism. Record one of: No 2, 3, 4
CR 2.1 RE(2)
mapping of permissions to roles for all human a. Met by component
users. b. Met by a compensating security mechanism
c. Not met
If the component does not provide the capability to identify
and authenticate users of any type as described, record:
d. Not relevant

If the component has an operator interface, verify that the

component can support supervisor override of role
permissions for actions on this interface. Verify that the
override can be configured to be in effect for a
configurable time or sequence of events. Record one of:
Components shall support a supervisor manual a. Met
IEC 62443-4-2:
x x x x FSA-CR 2.1 RE(3) Supervisor override override for a configurable time or sequence of b. Not met No 3, 4
CR 2.1 RE(3)
events. Note if the component has an operator interface but roles
are not supported for this interface, both this requirement
and FSA-CR 2.1 are to be recorded as not met.
If the component does not have an operator interface,
record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 23 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component has an operator interface, verify that the

component supports dual approval for actions on this
interface that could impact the industrial process. Record
Components shall support dual approval when one of:
IEC 62443-4-2:
x x x x FSA-CR 2.1 RE(4) Dual approval action can result in serious impact on the a. Met No 4
CR 2.1 RE(4)
industrial process. b. Not met
If the component does not have an operator interface,
record:
c. Not relevant

If the component supports usage through wireless Wireless use control may be implemented in different devices that make up the
interfaces, verify with user documentation that the system. Network devices may be one of the devices that assist with use control
component can integrate into a system to authorize through controls such as network admission control. For devices and
usage, monitor, and enforce usage restrictions for applications that utilize wireless networks those devices should be able to
If a component supports usage through wireless
wireless connectivity to the component per commonly properly utilize wireless network protection such as network admission control.
interfaces it shall provide the capability to
accepted security practices. Record one of: Components may also implement different limitations on access based on
integrate into the system that supports usage IEC 62443-4-2:
x x x x FSA-CR 2.2 Wireless use control a. Met No 1, 2, 3, 4 whether the access is from wireless devices or wired devices. This does place a
authorization, monitoring and restrictions CR 2.2
b. Not met need that the component be able to distinguish whether the interface is through
according to commonly accepted industry
wireless or not. Some network devices provide the capability to scan for
practices.
If the component does not support usage through wireless unauthorized wireless network activity in the wireless spectrum. In order to
interfaces, record: prevent a negative impact on the performance of the control system
c. Not relevant functionality, it is a good practice to deploy dedicated devices to perform checks
for unauthorized network activity.

Use control for portable and mobile There is no component level requirement IEC 62443-4-2:
FSA-CR 2.3 No validation activity
devices associated with IEC 62443‑3‑3 SR 2.3. CR 2.3

Review user documentation and determine if the software

application uses mobile code technologies.

If the software application uses mobile code technologies,

review user documentation and verify that the application Mobile code technologies include, but are not limited to, Java, JavaScript,
In the event that a software application utilizes
provides the capability to enforce a security policy for the ActiveX, portable document format (PDF), Postscript, Shockwave movies, Flash
mobile code technologies, that application shall
usage of mobile code technologies. Verify that a policy is animations and VBScript. Usage restrictions apply to both the selection and use
provide the capability to enforce a security policy
supported at a minimum, that prevents each mobile code of mobile code installed on servers and mobile code downloaded and executed
for the usage of mobile code technologies. The IEC 62443-4-2:
x FSA-SAR 2.4A Mobile code - control execution technology used, from being executed, when initiated by No 1, 2, 3, 4 on individual workstations. Control procedures should prevent the development,
security policy shall allow, at a minimum, for SAR 2.4(a)
the software application, on the hosting device. Record acquisition or introduction of unacceptable mobile code within the control
each mobile code technology used on the
one of: system in which the component resides. For example, mobile code exchanges
software application, action to control execution
a. Met may be disallowed directly within the control system, but may be allowed in a
of mobile code.
b. Not met controlled adjacent environment maintained by IACS personnel.

If the software application does not use mobile code

technologies, record:
c. Not relevant

Review user documentation and determine if the software

application uses mobile code technologies.
In the event that a software application utilizes
If the software application uses mobile code technologies,
mobile code technologies, that application shall
review component documentation and verify that there is
provide the capability to enforce a security policy
a mechanism to control, for each mobile code technology,
for the usage of mobile code technologies. The
which users (human, software process, or device) are
security policy shall allow, at a minimum, for IEC 62443-4-2:
x FSA-SAR 2.4B Mobile code - control transfer by user allowed to transfer mobile code to/from the application. No 1, 2, 3, 4 See FSA-SAR 2.4A
each mobile code technology used on the SAR 2.4(b)
Record one of:
software application, action to control which
a. Met
users (human, software process, or device) are
b. Not met
allowed to transfer mobile code to/from the
application.
If the software application does not use mobile code
technologies, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 24 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the software

application uses mobile code technologies.
In the event that a software application utilizes
mobile code technologies, that application shall If the software application uses mobile code technologies,
provide the capability to enforce a security policy review component documentation and verify that there is
for the usage of mobile code technologies. The a policy mechanism to require that an integrity check
security policy shall allow, at a minimum, for must run and pass prior to mobile code execution, for IEC 62443-4-2:
x FSA-SAR 2.4C Mobile code - integrity check No 1, 2, 3, 4 See FSA-SAR 2.4A
each mobile code technology used on the each mobile technology used. Record one of: SAR 2.4(c)
software application, action to control the a. Met
execution of mobile code based on the results of b. Not met
an integrity check prior to the code being
executed. If the software application does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the software

application uses mobile code technologies.

If the software application uses mobile code technologies,

review component documentation and verify that there is
that there is a policy mechanism to require that an
The application shall provide the capability to
authenticity check must run and pass prior to mobile code
enforce a security policy that allows the device to
execution. IEC 62443-4-2:
x FSA-SAR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the No 2, 3, 4
Record one of: SAR 2.4 RE(1)
results of an authenticity check prior to the code
a. Met
being executed.
b. Not met

If the software application does not use mobile code

technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.

If the embedded device uses mobile code technologies,

Mobile code technologies include, but are not limited to, Java, JavaScript,
In the event that an embedded device utilizes review user documentation and verify that the embedded
ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
mobile code technologies, the embedded device device provides the capability to enforce a security policy
Usage restrictions apply to both the selection and use of mobile code installed
shall provide the capability to enforce a security for the usage of mobile code technologies. Verify that a
on servers and mobile code downloaded and executed on individual
policy for the usage of mobile code technologies. policy is supported at a minimum, that prevents each IEC 62443-4-2:
x FSA-EDR 2.4A Mobile code - control execution No 1, 2, 3, 4 workstations. Control procedures should prevent the development, acquisition
The security policy shall allow, at a minimum, for mobile code technology used from being executed on the EDR 2.4(a)
or introduction of unacceptable mobile code within the control system in which
each mobile code technology used on the device. Record one of:
the component resides. For example, mobile code exchanges may be
embedded device, action to control execution of a. Met
disallowed directly within the control system, but may be allowed in a controlled
mobile code. b. Not met
adjacent environment maintained by IACS personnel.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.

In the event that an embedded device utilizes If the embedded device uses mobile code technologies,
mobile code technologies, the embedded device review component documentation and verify that there is
shall provide the capability to enforce a security a mechanism to control, for each mobile code technology,
policy for the usage of mobile code technologies. which users (human, software process, or device) are
IEC 62443-4-2:
x FSA-EDR 2.4B Mobile code - control upload by user The security policy shall allow, at a minimum, for allowed to upload mobile code to the device. Record one No 1, 2, 3, 4 See FSA-EDR 2.4A
EDR 2.4(b)
each mobile code technology used on the of:
embedded device, action to control which users a. Met
(human, software process, or device) are b. Not met
allowed to upload mobile code to the device.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 25 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the

embedded device uses mobile code technologies.
In the event that an embedded device utilizes
If the embedded device uses mobile code technologies,
mobile code technologies, the embedded device
review component documentation and verify that there is
shall provide the capability to enforce a security
a policy mechanism to require that an integrity check
policy for the usage of mobile code technologies.
must run and pass prior to mobile code execution, for IEC 62443-4-2:
x FSA-EDR 2.4C Mobile code - integrity check The security policy shall allow, at a minimum, for No 1, 2, 3, 4 See FSA-EDR 2.4A
each mobile technology used. Record one of: EDR 2.4(c)
each mobile code technology used on the
a. Met
embedded device, action to control the execution
b. Not met
of mobile code based on the results of an
integrity check prior to the code being executed.
If the embedded device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the

embedded device uses mobile code technologies.

If the embedded devices uses mobile code technologies,

review component documentation and verify that there is
The embedded device shall provide the that there is a policy mechanism to require that an
capability to enforce a security policy that allows authenticity check must run and pass prior to mobile code
IEC 62443-4-2:
x FSA-EDR 2.4 RE(1) Mobile code authenticity check the device to control execution of mobile code execution. No 2, 3, 4
EDR 2.4 RE(1)
based on the results of an authenticity check Record one of:
prior to the code being executed. a. Met
b. Not met

If the embedded device does not use mobile code

technologies, record:
c. Not relevant

Review user documentation and determine if the host

device uses mobile code technologies.

If the host device uses mobile code technologies, review

Mobile code technologies include, but are not limited to, Java, JavaScript,
user documentation and verify that the host device
In the event that a host device utilizes mobile ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
provides the capability to enforce a security policy for the
code technologies, the host device shall provide Usage restrictions apply to both the selection and use of mobile code installed
usage of mobile code technologies. Verify that a policy is
the capability to enforce a security policy for the on servers and mobile code downloaded and executed on individual
supported at a minimum, that prevents each mobile code IEC 62443-4-2:
x FSA-HDR 2.4A Mobile code - control execution usage of mobile code technologies. The security No 1, 2, 3, 4 workstations. Control procedures should prevent the development, acquisition
technology used from being executed on the host device. HDR 2.4(a)
policy shall allow, at a minimum, for each mobile or introduction of unacceptable mobile code within the control system in which
Record one of:
code technology used on the host device, action the host device resides. For example, mobile code exchanges may be
a. Met
to control execution of mobile code. disallowed directly with the control system, but may be allowed in a controlled
b. Not met
adjacent environment maintained by IACS personnel.
If the host device does not use mobile code technologies,
record:
c. Not relevant

Review user documentation and determine if the host

device uses mobile code technologies.

In the event that a host device utilizes mobile If the host device uses mobile code technologies, review
code technologies, the host device shall provide component documentation and verify that there is a
the capability to enforce a security policy for the mechanism to control, for each mobile code technology,
usage of mobile code technologies. The security which users (human, software process, or device) are
IEC 62443-4-2:
x FSA-HDR 2.4B Mobile code - control upload by user policy shall allow, at a minimum, for each mobile allowed to upload mobile code to the host device. Record No 1, 2, 3, 4 See FSA-HDR 2.4A
HDR 2.4(b)
code technology used on the host device, action one of:
to control which users (human, software process, a. Met
or device) are allowed to upload mobile code to b. Not met
the host device.
If the host device does not use mobile code technologies,
record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 26 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the host

device uses mobile code technologies.
In the event that a host device utilizes mobile
If the host device uses mobile code technologies, review
code technologies, the host device shall provide
component documentation and verify that there is a policy
the capability to enforce a security policy for the
mechanism to require that an integrity check must run and
usage of mobile code technologies. The security
pass prior to mobile code execution, for each mobile IEC 62443-4-2:
x FSA-HDR 2.4C Mobile code - integrity check policy shall allow, at a minimum, for each mobile No 1, 2, 3, 4 See FSA-HDR 2.4A
technology used. Record one of: HDR 2.4(c)
code technology used on the host device, action
a. Met
to control the execution of mobile code based on
b. Not met
the results of an integrity check prior to the code
being executed.
If the host device does not use mobile code technologies,
record:
c. Not relevant

Review user documentation and determine if the host

device uses mobile code technologies.

If the host devices uses mobile code technologies, review

component documentation and verify that there is that
The host device shall provide the capability to there is a policy mechanism to require that an authenticity
enforce a security policy that allows the device to check must run and pass prior to mobile code execution.
IEC 62443-4-2:
x FSA-HDR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the Record one of: No 2, 3, 4
HDR 2.4 RE(1)
results of an authenticity check prior to the code a. Met
being executed. b. Not met

If the host device does not use mobile code technologies,

record:
c. Not relevant

Review user documentation and determine if the network

device uses mobile code technologies. Mobile code technologies include, but are not limited to, Java, JavaScript,
ActiveX, PDF, Postscript, Shockwave movies, Flash animations and VBScript.
If the network device uses mobile code technologies, Usage restrictions apply to both the selection and use of mobile code installed
In the event that a network device utilizes mobile review user documentation and verify that the network on servers and mobile code downloaded and executed on individual
code technologies, the network device shall device provides the capability to enforce a security policy workstations. Control procedures should prevent the development, acquisition
provide the capability to enforce a security policy for the usage of mobile code technologies. Verify that a or introduction of unacceptable mobile code within the control system in which
for the usage of mobile code technologies. The policy is supported at a minimum, that prevents each IEC 62443-4-2: the component resides. For example, mobile code exchanges may be
x FSA-NDR 2.4A Mobile code - control execution No 1, 2, 3, 4
security policy shall allow, at a minimum, for mobile code technology used from being executed on the NDR 2.4(a) disallowed directly within the control system, but may be allowed in a controlled
each mobile code technology used on the network device. Record one of: adjacent environment maintained by IACS personnel.
network device, action to control execution of a. Met Mobile code could be secured by adding integrity, authenticity, and
mobile code. b. Not met authorization checks to the code itself (application layer), or for “just-in-time”
code execution through transmitting the mobile code via a secure
If the network device does not use mobile code communications tunnel which provides these attributes, or any mechanism
technologies, record: equivalent to these options.
c. Not relevant

Review user documentation and determine if the network

device uses mobile code technologies.
In the event that a network device utilizes mobile
If the network device uses mobile code technologies,
code technologies, the network device shall
review component documentation and verify that there is
provide the capability to enforce a security policy
a mechanism to control, for each mobile code technology,
for the usage of mobile code technologies. The
which users (human, software process, or device) are
security policy shall allow, at a minimum, for IEC 62443-4-2:
x FSA-NDR 2.4B Mobile code - control transfer by user allowed to transfer mobile code to/from the network No 1, 2, 3, 4 See FSA-NDR 2.4A
each mobile code technology used on the NDR 2.4(b)
device. Record one of:
network device, action to control which users
a. Met
(human, software process, or device) are
b. Not met
allowed to transfer mobile code to/from the
network device.
If the network device does not use mobile code
technologies, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 27 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the network

device uses mobile code technologies.
In the event that a network device utilizes mobile
If the network device uses mobile code technologies,
code technologies, the network device shall
review component documentation and verify that there is
provide the capability to enforce a security policy
a policy mechanism to require that an integrity check must
for the usage of mobile code technologies. The
run and pass prior to mobile code execution, for each IEC 62443-4-2:
x FSA-NDR 2.4C Mobile code - integrity check security policy shall allow, at a minimum, for No 1, 2, 3, 4 See FSA-NDR 2.4A
mobile technology used. Record one of: NDR 2.4(c)
each mobile code technology used on the
a. Met
network device, action to control the execution of
b. Not met
mobile code based on the results of an integrity
check prior to the code being executed.
If the network device does not use mobile code
technologies, record:
c. Not relevant

Review user documentation and determine if the network

device uses mobile code technologies.

If the network devices uses mobile code technologies,

review component documentation and verify that there is
that there is a policy mechanism to require that an
The network device shall provide the capability to
authenticity check must run and pass prior to mobile code
enforce a security policy that allows the device to
execution. IEC 62443-4-2:
x FSA-NDR 2.4 RE(1) Mobile code authenticity check control execution of mobile code based on the No 2, 3, 4
Record one of: NDR 2.4 RE(1)
results of an authenticity check prior to the code
a. Met
being executed.
b. Not met

If the network device does not use mobile code

technologies, record:
c. Not relevant

Review user documentation and determine if the

component provides a human user interface, which may
be accessed locally or via a network.

If the component provides a user interface, verify user

If a component provides a human user interface,
documents include evidence that the component provides Session locks are used to prevent access to specified workstations or nodes.
whether accessed locally or via a network, the
the capability to initiate a session lock for a human user Components should activate session lock mechanisms automatically after a
component shall provide the capability to protect
triggered by one of: session inactivity longer than a IEC 62443-4-2: configurable time period. In most cases, the session locks are configured at the
x x x x FSA-CR 2.5A Session lock - initiation against further access by initiating a session lock No 1, 2, 3, 4
configurable time period or manual initiation by the human CR 2.5(a) system level. Session locks implemented as part of this requirement may be
after a configurable time period of inactivity or by
user owning the session. Record one of: pre-empted or limited by remote session termination, as defined in CR 2.6 –
manual initiation by the user (human, software
a. Met Remote session termination.
process or device).
b. Not met

If the component does not provide a human user

interface, record:
c. Not relevant

Review user documentation and determine if the

component provides a human user interface, which may
be accessed locally or via a network.

If the component provides a human user interface, verify

user documents include evidence that the component
If a component provides a human user interface, provides the capability for a session lock, once initiated
whether accessed locally or via a network, the for any type of user session (human, software process, or
component shall provide the capability for the device), to remain in effect until either a human user who
session lock to remain in effect until the human owns the session, or another authorized human user, re- IEC 62443-4-2:
x x x x FSA-CR 2.5B Session lock - removal No 1, 2, 3, 4 See FSA-CR 2.5A
user who owns the session, or another establishes access using appropriate identification and CR 2.5(b)
authorized human user, re-establishes access authentication procedures. Record one of:
using appropriate identification and a. Met
authentication procedures. b. Not met

If the component does not provide a human user

interface, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 28 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the

component supports remote sessions.

If the component supports remote sessions, verify the

If a component supports remote sessions, the component has at least one of these capabilities: it is able A remote session is initiated whenever a component is accessed across the
component shall provide the capability to to be configured to automatically terminate a remote boundary of a zone defined by the asset owner based on their risk assessment.
terminate a remote session either automatically session after a configurable time period of inactivity, or a This requirement may be limited to sessions that are used for component
IEC 62443-4-2:
x x x x FSA-CR 2.6 Remote session termination after a configurable time period of inactivity, local authority may terminate a remote session. Record No 2, 3, 4 monitoring and maintenance activities (not critical operations) based on the risk
CR 2.6
manually by a local authority, or manually by the one of: assessment of the control system and security policies and procedures. Some
user (human, software process or device) who a. Met components may not allow sessions to be terminated as the session might be
initiated the session. b. Not met part of an essential function of the component.

If the component does not support remote sessions,

record:
c. Not relevant

Verify the component is able to be configured to limit the

number of concurrent user (login )sessions per interface,
for any given user (human, software process, or device).
A resource starvation DoS might occur if a limit is not imposed. There is a trade-
Components shall provide the capability to limit For all interfaces, verify that the supplier has executed
off between potentially locking out a specific user versus locking out all users
the number of concurrent sessions per interface and passed a test to verify this limit is enforced, by IEC 62443-4-2:
x x x x FSA-CR 2.7 Concurrent session control Yes 3, 4 and services due to a lack of resources. Product supplier and/or system
for any given user (human, software process or attempting to create more than the maximum number of CR 2.7
integrator guidance is likely required to provide sufficient information as to how
device). user sessions allowed and verifying denial of connection
the number of concurrent sessions value should be assigned.
once the threshold is reached. Record one of:
a. Met
b. Not met

Verify via user documentation that the component

Components shall provide the capability to supports capability to generate audit records relevant to
Devices may contain either embedded firmware or run an OS. While the intent
generate audit records relevant to security for the security for the following categories: access control,
of the requirement is to cover categories of events, at least all events from the
following categories: access control, request request errors, control system events, backup and restore IEC 62443-4-2:
above categories that can be generated by the firmware or OS are to be
x x x x FSA-CR 2.8A Auditable events - categories errors, control system events, backup and events, configuration changes, and audit log events. Yes CR 2.8(a)-(f) first 1, 2, 3, 4
included.
restore event, configuration changes, and audit Verify via sample logs that some records from each of sentence
NOTE Security event categories are only applicable if functionality itself is
log events. these categories are generated. Record one of:
provided by the component.
a. Met
b. Not met

Verify via user documentation that all audit records in the

categories listed in FSA-CR 2.8A include timestamp,
Individual audit records shall include timestamp,
source (originating device, software process or human
source (originating device, software process or IEC 62443-4-2:
user account), category, type, event ID, and event result.
x x x x FSA-CR 2.8B Auditable events - data fields human user account), category, type, event ID, Yes CR 2.8(a)-(f) 1, 2, 3, 4 See FSA-CR 2.8A
Verify via sample logs that all of these fields have values
and event result. second sentence
present for all categories of records. Record one of:
a. Met
b. Not met

Components should provide sufficient audit storage capacity, taking into

Verify that the capacity for audit record storage on the
account retention policy, the auditing to be performed and the online audit
device is documented, and that the device provides this
processing requirements. Components may rely on the system into which they
Components shall provide the capability to capacity. Verify that evidence exists that the supplier
are integrated to provide the majority of audit storage capacity. However, the
allocate audit record storage capacity according performed analysis to confirm that the capacity will meet IEC 62443-4-2:
x x x x FSA-CR 2.9A Audit storage capacity - allocation No 1, 2, 3, 4 components should provide enough local storage to buffer audit data until it can
to commonly recognized recommendations for business and regulatory requirements of users. Record CR 2.9(a)
be sent to the system.
log management. one of:
Guidelines to be considered may include NIST Special Publication (SP) 800-92
a. Met
[26]. The audit storage capacity should be sufficient to retain logs for a period of
b. Not met
time required by applicable policies and regulations or business requirements.

Review design documentation or perform testing to verify

Components shall provide mechanisms to that all functions of the component are maintained when it
IEC 62443-4-2:
x x x x FSA-CR 2.9B Audit storage capacity - exceeded protect against a failure of the component when reaches or exceeds audit storage capacity. Record one of: No 1, 2, 3, 4 See FSA-CR 2.9A
CR 2.9(b)
it reaches or exceeds the audit storage capacity. a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 29 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documents and confirm that the component

has the capability to issue a warning when allocated audit
Components shall provide the capability to issue
Warn when audit record storage record storage volume on the component reaches a fixed IEC 62443-4-2:
x x x x FSA-CR 2.9 RE(1) a warning when the allocated audit record No 3, 4
capacity threshold reached or configurable threshold. Record one of: CR 2.9 RE(1)
storage reaches a configurable threshold.
a. Met
b. Not met

Audit generation typically occurs at the source of the event. Audit processing
involves transmission, possible augmentation (such as, the addition of a
Verify via design documentation that software or hardware
timestamp) and persistent storage of the audit records. Audit processing failures
errors related to audit processing, or failures in the audit
include, for example, software or hardware errors, failures in the audit capturing
capturing mechanisms, do not cause loss of essential
Components shall provide the capability to mechanisms and audit storage capacity being reached or exceeded. Guidelines
functions of the component. Record:
Response to audit processing protect against the loss of essential services and IEC 62443-4-2: to be considered when designing appropriate response actions may include the
x x x x FSA-CR 2.10A a. Met No 1, 2, 3, 4
failures - maintain essential functions functions in the event of an audit processing CR 2.10(a) NIST SP 800-92, Guide to Computer Security Log Management [26]. It should
b. Not met
failure. be noted that either overwriting the oldest audit records or halting audit log
c. Not relevant - no essential functions
generation are possible responses to audit storage capacity being exceeded but
Note that validation for FSA-CR 2.9B separately validates
imply the loss of potentially essential forensic information. Also alerting
another aspect this requirement.
personnel could be an appropriate supporting action in response to an audit
processing failure.

Verify user documents include evidence that the audit

function supports one or more common accepted industry
practices and recommendations upon lack of storage
space to record new events, for example overwrite oldest
audit records or stop generating audit records. Verify via
testing that the device takes the action under these
Components shall provide the capability to conditions as described in the user documentation.
support appropriate actions in response to an
Response to audit processing IEC 62443-4-2:
x x x x FSA-CR 2.10B audit processing failure according to commonly Verify in design documentation that in the event of Yes 1, 2, 3, 4 See FSA-CR 2.10A
failures - actions taken CR 2.10(b)
accepted industry practices and software or hardware errors related to audit processing,
recommendations. one or more actions are taken in accordance with
common accepted industry practices and
recommendations, for example logging the event or
generating a notification. Record one of:
a. Met
b. Not met

A good reference for the format of timestamps is ISO/IEC 8601:2004, Data

Components shall provide the capability to Verify by reviewing sample audit records in each category, elements and interchange formats – Information interchange – Representation
IEC 62443-4-2:
x x x x FSA-CR 2.11 Timestamps create timestamps (including date and time) for that audit records include timestamps. Record one of: Yes 1, 2, 3, 4 of dates and times [15]. Care should be taken when designing a system that
CR 2.11
use in audit records. a. Met periodic time-shift events, such as daylight savings time in some locations, are
b. Not met taken into account.

Verify using user documentation that the component can

Components shall provide the capability to be configured to synchronize time stamps with a system
IEC 62443-4-2:
x x x x FSA-CR 2.11 RE(1) Time synchronization create timestamps that are synchronized with a wide time source. Record one of: No 2, 3, 4
CR 2.11 RE(1)
system wide time source. a. Met
b. Not met

Verify user documents include evidence that unauthorized

The time synchronization mechanism shall alteration of time synchronization is detected and creates
provide the capability to detect unauthorized an audit event record. Record one of: IEC 62443-4-2:
x x x x FSA-CR 2.11 RE(2) Protection of time source integrity No 4
alteration and cause an audit event upon a. Met CR 2.11 RE(2)
alteration. b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 30 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review user documentation and determine if the

component provides a human user interface that permits
actions by human users.

If the component provides such a human user interface,

verify component requirements documentation states that
actions taken by human users, and the human user Examples of particular actions taken by a user include performing operator
responsible for those actions, are logged in the audit actions, changing control system configurations, creating information, sending a
records. At a minimum, this applies to actions related to message, approving information (such as, indicating concurrence) and receiving
If a component provides a human user interface, security functions required by this standard and to a message. Non-repudiation protects against later false claims by a user of not
the component shall provide the capability to example actions shown under Rationale and having taken a specific action, by an author of not having authored a particular
determine whether a given human user took a Supplemental Guidance." Further verify that supplier test document, by a sender of not having transmitted a message, by a receiver of
IEC 62443-4-2:
x x x x FSA-CR 2.12 Non-repudiation particular action. cases are mapped to this requirement and have passed. No 1, 2, 3, 4 not having received a message or by a signatory of not having signed a
CR 2.12
Control elements that are not able to support Record one of: document. Non-repudiation services can be used to determine if information
such capability shall be listed in component a. Met originated from a user, if a user took specific actions (for example, sending an
documents. b. Not met email and approving a work order) or received specific information. Non-
repudiation services are obtained by employing various techniques or
If a component does not provide a such a human user mechanisms (for example, user identification and authorization, digital
interface, verify that the user manual for the component signatures, digital message receipts and timestamps).
documents that the component does not have the ability
to log user actions. If this can be verified, record:
a. Not relevant

If this cannot be verified, record:

b. Not met

Review user and design documentation and determine if

the component permits actions by other than human
users (software processes or devices).

If the component permits such actions, verify

requirements for the component state that all actions
taken by a given user (software process or device), and
the user responsible for those actions, are logged in the
Components shall provide the capability to audit records. Further verify that supplier test cases are
determine whether a given user (human, mapped to this requirement and have passed. Record one IEC 62443-4-2:
x x x x FSA-CR 2.12 RE(1) Non-repudiation for all users No 4
software process or device) took a particular of: CR 2.12 RE(1)
action. a. Met
b. Not met

If a component does not permit such actions, record:

c. Not relevant

(Note that the case for human users is covered by FSA-

CR 2.12.)

Examine the embedded device hardware, and design

Factory diagnostic and test interface(s) are created at various locations within
documentation for all device models in scope for the
the embedded device to assist the embedded device’s developers and factory
certification, and the threat model, to identify any
personnel as they test the functional implementation, and when errors are
diagnostic and test interfaces that provide an ability to
discovered to subsequently remove them from the embedded device . However,
control the embedded device or to access non-public
these same interfaces must be carefully protected from access by unauthorized
information. If there are such interfaces, review user or
entities to protect the essential functionality provided by the embedded device
design documents to verify that authorization of an
to the IACS.
Embedded devices shall protect against authenticated user assigned to a role authorized to use
If a diagnostic and test interface does not provide an ability to control the
Use of physical diagnostic and test unauthorized use of the physical factory them, is required to access them (in which case they IEC 62443-4-2:
x FSA-EDR 2.13 No 2, 3, 4 embedded device or to access non-public information, then it will not need an
interfaces diagnostic and test interface(s) (e.g. JTAG would be subject for FR 1 requirements), or that they are EDR 2.13
authentication mechanism. This shall be determined via a threat and risk
Debugging). otherwise protected against unauthorized access.
assessment. An example of this would be JTAG debugging, in which JTAG is
Record one of:
used to take control of the processor and execute arbitrary commands, versus a
a. Met
JTAG boundary scan where JTAG is used to simply read information (which
b. Not met
may be publicly available information).
There may be cases where the factory diagnostic and test interface(s) use
If there are no such interfaces, record:
network communications with the device. When this is the case those
c. Not relevant
interfaces are to be subjected to all of the requirements of this document.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 31 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If diagnostic or test interfaces that provide the ability to

control the device or access to non-public information are
found in validation of FSA-EDR 2.13, verify by testing that
Embedded devices shall provide active an audit log entry is generated when an attempt is made
monitoring of the device’s diagnostic and test to access any of these interfaces. Record one of:
IEC 62443-4-2:
x FSA-EDR 2.13 RE(1) Active monitoring interface(s) and generate an audit log entry a. Met Yes 3, 4
EDR 2.13 RE(1)
when attempts to access these interface(s) are b. Not met
detected.
If such interfaces are not found in validation of FSA-EDR
2.13, then record:
c. Not relevant

Examine the host device hardware, and design

Factory diagnostic and test interface(s) are created at various locations within
documentation for all device models in scope for the
the host device to assist the component’s developers and factory personnel as
certification, and the threat model, to identify any
they test the functional implementation, and when errors are discovered to
diagnostic and test interfaces that provide an ability to
subsequently remove them from the component. However, these same
control the host device or to access non-public
interfaces must be carefully protected from access by unauthorized entities to
information. If there are such interfaces, review user or
protect the essential functionality provided by the component to the IACS.
design documents to verify that authorization of an
There may be cases where the factory diagnostic and test interface(s) use
Host devices shall protect against unauthorized authenticated user assigned to a role authorized to use
Use of physical diagnostic and test IEC 62443-4-2: network communications with the device. When this is the case those
x FSA-HDR 2.13 use of the physical factory diagnostic and test them, is required to access them (in which case they No 2, 3, 4
interfaces HDR 2.13 interfaces are to be subjected to all of the requirements of this document.
interface(s) (e.g. JTAG debugging). would be subject to FR 1 requirements), or that they are
If a diagnostic and test interface does not provide an ability to control the host
otherwise protected against unauthorized access.
device or to access non-public information, then it will not need an
Record one of:
authentication mechanism. This shall be determined via a threat and risk
a. Met
assessment. An example of this would be JTAG debugging, in which JTAG is
b. Not met
used to take control of the processor and execute arbitrary commands, versus a
JTAG boundary scan where JTAG is used to simply read information (which
If there are no such interfaces, record:
may be publicly available information).
c. Not relevant

If diagnostic or test interfaces that provide the ability to

control the device or access to non-public information are
found in validation of FSA-HDR 2.13, verify by testing that
an audit log entry is generated when an attempt is made
Host devices shall provide active monitoring of
to access any of these interfaces. Record one of:
the device’s diagnostic and test interface(s) and IEC 62443-4-2:
x FSA-HDR 2.13 RE(1) Active monitoring a. Met Yes 3, 4
generate an audit log entry when attempts to HDR 2.13 RE(1)
b. Not met
access these interface(s) are detected.
If such interfaces are not found in validation of FSA-HDR
2.13, then record:
c. Not relevant

Examine the network device hardware, and design

Factory diagnostic and test interface(s) are created at various locations within
documentation for all device models in scope for the
the component to assist the component’s developers and factory personnel as
certification, and the threat model, to identify any
they test the functional implementation, and when errors are discovered to
diagnostic and test interfaces that provide an ability to
subsequently remove them from the component. However, these same
control the network device or to access non-public
interfaces must be carefully protected from access by unauthorized entities to
information. If there are such interfaces, review user or
protect the essential functionality provided by the component to the IACS.
design documents to verify that authorization of an
Network devices shall protect against There may be cases where the factory diagnostic and test interface(s) use
authenticated user assigned to a role authorized to use
Use of physical diagnostic and test unauthorized use of the physical factory IEC 62443-4-2: network communications with the device. When this is the case those
x FSA-NDR 2.13 them, is required to access them (in which case they No 2, 3, 4
interfaces diagnostic and test interface(s) (e.g. JTAG NDR 2.13 interfaces are to be subjected to all of the requirements of this document.
would be subject to FR 1 requirements), or that they are
debugging). Note that if a diagnostic and test interface does not provide the ability to control
otherwise protected against unauthorized access.
the product, or to access non-public information, then it will not need an
Record one of:
authentication mechanism. This should be determined via a threat assessment.
a. Met
An example of this would be JTAG debugging, in which JTAG is used to take
b. Not met
control of the processor and execute arbitrary commands, versus a JTAG
boundary scan where JTAG is used to simply read information (which may be
If there are no such interfaces, record:
publicly available information).
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 32 of 53
 CSA-311 FR 2
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If diagnostic or test interfaces that provide the ability to

control the device or access to non-public information are
found in validation of FSA-NDR 2.13, verify by testing that
an audit log entry is generated when an attempt is made
Network devices shall provide active monitoring
to access any of these interfaces. Record one of:
of the device’s diagnostic and test interface(s) IEC 62443-4-2:
x FSA-NDR 2.13 RE(1) Active monitoring a. Met Yes 3, 4
and generate an audit log entry when attempts to NDR 2.13 RE(1)
b. Not met
access these interface(s) are detected.
If such interfaces are not found in validation of FSA-NDR
2.13, then record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 33 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Many common network attacks are based on the manipulation of data in transmission, for example manipulation of
network packets. Switched or routed networks provide a greater opportunity for attackers to manipulate packets as
undetected access to these networks is generally easier and the switching and routing mechanisms themselves can also
be manipulated in order to get more access to transmitted information. Manipulation in the context of a control system
could include the change of measurement values communicated from a sensor to a receiver or the alteration of
command parameters sent from a control application to an actuator.
Depending on the context (for example transmission within a local network segment versus transmission via untrusted
networks) and the network type used in the transmission (for example transmission control protocol (TCP) / internet
protocol (IP) versus local serial links), feasible and appropriate mechanisms will vary. On a small network with direct
Examine design and user documents and
links (point-to-point), physical access protection to all nodes may be sufficient on lower SLs if the endpoints’ integrity is
determine if the component provides the
protected as well (see 7.6, CR 3.4 – Software and information integrity), while on a network distributed in areas with
capability to protect the data it transmits against
regular physical presence of staff or on a wide area network physical access is likely not enforceable. If a commercial
changes to message content. Protection
service is used to provide communication services as a commodity item rather than a fully dedicated service (for
provided shall be beyond that provided by the
Components shall provide the example a leased line versus a T1 link), it may be more difficult to obtain the necessary assurances regarding the
transport layer. An example is the use of IEC 62443-4-2:
x x x x FSA-CR 3.1 Communication integrity capability to protect integrity of No 1, 2, 3, 4 implementation of needed security controls for communication integrity (for example because of legal restrictions). When
cryptographic hashes. Record one of: CR 3.1
transmitted information. it is infeasible or impractical to meet the necessary security requirements it may be appropriate to implement either
a. Met
appropriate compensating countermeasures or explicitly accept the additional risk.
b. Not met
Industrial equipment is often subject to environmental conditions that can lead to integrity issues and/or false positive
incidents. Many times the environment contains particulates, liquids, vibration, gases, radiation, and electromagnetic
interference (EMI) that can cause conditions that affect the integrity of the communication wiring and signals. The
network infrastructure should be designed to minimize these physical/environmental effects on communication integrity.
For example, when particulate, liquids, and/or gases are an issue, it may be necessary to use a sealed registered jack 45
(RJ-45) or M12 connector instead of a commercial-grade RJ-45 connector on the wire. The cable itself may need to use
a different jacket instead to handle the particulate, liquid, and/or gas as well. In cases where vibration is an issue, M12
connectors may be necessary to prevent the spring pins on an RJ-45 connector from disconnecting during use. In cases
where radiation and/or EMI are an issue, it may be necessary to use shielded twisted pair or fiber cables to prevent any
effect on the communication signals. It may also be necessary to perform a wireless spectrum analysis in these areas if
wireless networking is planned to verify that it is a viable solution.

Many common network attacks are based on the manipulation of data in transmission, for example manipulation of
network packets. Switched or routed networks provide a greater opportunity for attackers to manipulate packets as
undetected access to these networks is generally easier and the switching and routing mechanisms themselves can also
be manipulated in order to get more access to transmitted information. Manipulation in the context of a control system
could include the change of measurement values communicated from a sensor to a receiver or the alteration of
command parameters sent from a control application to an actuator.
Depending on the context (for example transmission within a local network segment versus transmission via untrusted
networks) and the network type used in the transmission (for example transmission control protocol (TCP) / internet
protocol (IP) versus local serial links), feasible and appropriate mechanisms will vary. On a small network with direct
Examine design and user documents and
links (point-to-point), physical access protection to all nodes may be sufficient on lower SLs if the endpoints’ integrity is
determine if the component provides the
protected as well (see 7.6, CR 3.4 – Software and information integrity), while on a network distributed in areas with
capability to protect the data it transmits against
regular physical presence of staff or on a wide area network physical access is likely not enforceable. If a commercial
changes to message content. Protection
service is used to provide communication services as a commodity item rather than a fully dedicated service (for
provided shall be beyond that provided by the
Components shall provide the example a leased line versus a T1 link), it may be more difficult to obtain the necessary assurances regarding the
transport layer. An example is the use of IEC 62443-4-2:
x x x x FSA-CR 3.1 (ADV) Communication integrity capability to protect integrity of No 1, 2, 3, 4 implementation of needed security controls for communication integrity (for example because of legal restrictions). When
cryptographic hashes. Record one of: CR 3.1
transmitted information. it is infeasible or impractical to meet the necessary security requirements it may be appropriate to implement either
a. Met
appropriate compensating countermeasures or explicitly accept the additional risk.
b. Not met
Industrial equipment is often subject to environmental conditions that can lead to integrity issues and/or false positive
incidents. Many times the environment contains particulates, liquids, vibration, gases, radiation, and electromagnetic
interference (EMI) that can cause conditions that affect the integrity of the communication wiring and signals. The
network infrastructure should be designed to minimize these physical/environmental effects on communication integrity.
For example, when particulate, liquids, and/or gases are an issue, it may be necessary to use a sealed registered jack 45
(RJ-45) or M12 connector instead of a commercial-grade RJ-45 connector on the wire. The cable itself may need to use
a different jacket instead to handle the particulate, liquid, and/or gas as well. In cases where vibration is an issue, M12
connectors may be necessary to prevent the spring pins on an RJ-45 connector from disconnecting during use. In cases
where radiation and/or EMI are an issue, it may be necessary to use shielded twisted pair or fiber cables to prevent any
effect on the communication signals. It may also be necessary to perform a wireless spectrum analysis in these areas if
wireless networking is planned to verify that it is a viable solution.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 34 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Examine design and user documents and

Components shall provide the
determine whether the origin of data received
capability to verify the
Communication by the component can be validated by the IEC 62443-4-2:
x x x x FSA-CR 3.1 RE(1) authenticity of received No 2, 3, 4
authentication component. Record one of: CR 3.1 RE(1)
information during
a. Met
communication.
b. Not met

Verify that design or user documents contain

evidence that the software application is
compatible with at least one mechanism for
protection from installation and execution of
The application product supplier
malicious code on its hosting device. Verify that
shall qualify and document Protection from malicious code (for example, viruses, worms, Trojan horses and spyware) may be provided by the
these documents note any special configuration
which protection from malicious control system application or by an external service or application. Control system applications need to be compatible
Protection from malicious requirements applicable for that mechanism. IEC 62443-4-2:
x FSA-SAR 3.2 code mechanisms are No 1, 2, 3, 4 with mechanisms designed to protect them from malicious code. This requirement does not imply that the product
code Verify that the supplier can provide evidence SAR 3.2
compatible with the application supplier is to qualify and document all malicious code protection mechanisms which are compatible with the application
that the mechanism was qualified by testing or
and note any special but implies that the product supplier is to qualify and document at least one mechanism.
other means.
configuration requirements.
Record one of:
a. Met
b. Not met

Unauthorized software may contain malicious code and thus be harmful to the component. If an embedded device is
able to utilize a compensating control, it need not directly support protection from malicious code. It is assumed that the
Verify that design or user documents contain IACS will be responsible for providing the required safeguards. However, for scenarios such as having a local universal
The embedded device shall evidence that the embedded device supports serial bus (USB) host access, the need for protection from malicious code should be determined by a risk assessment.
Protection from malicious provide the capability to protect protections from installation and execution of IEC 62443-4-2: Detection mechanisms should be able to detect integrity violations of application binaries and data files. Techniques may
x FSA-EDR 3.2 No 1, 2, 3, 4
code from installation and execution unauthorized software. Record one of: EDR 3.2 include, but are not limited to, binary integrity and attributes monitoring, hashing and signature techniques.
of unauthorized software. a. Met Prevention techniques may include, but are not limited to, removable media control, sandbox techniques and specific
b. Not met computing platforms mechanisms such as restricted firmware update capabilities, No Execute (NX) bit, data execution
prevention (DEP), address space layout randomization (ASLR), stack corruption detection and mandatory access
controls. See 10.4 for an associated requirement involving control system monitoring tools and techniques.

Verify that design or user documents contain

evidence that the host device supports use of at
one or more mechanisms for protection from
There shall be mechanisms on
installation and execution of malicious code,
host devices that are qualified
covering all interfaces via which code may be
by the IACS product supplier to
introduced. Verify that these documents note
provide protection from Host devices need to support the use of malicious code protection (against, for example, viruses, worms, Trojan horses
Protection from malicious any special configuration requirements related IEC 62443-4-2:
x FSA-HDR 3.2 malicious code. The IACS No 1, 2, 3, 4 and spyware) . The product supplier should qualify and document the configuration of protection from malicious code
code to the mechanism(s). Verify that the supplier HDR 3.2
product supplier shall document mechanisms so that the primary mission of the control system is maintained.
can provide evidence that the mechanism(s)
any special configuration
was qualified by testing or other means.
requirements related to
protection from malicious code.
Record one of:
a. Met
b. Not met

The host device shall

Verify by test that the host device reports the
automatically report the
software and file versions of protection from
Report version of code software and file versions of IEC 62443-4-2:
x FSA-HDR 3.2 RE(1) malicious code in use. Record one of: Yes 2, 3, 4
protection protection from malicious code HDR 3.2 RE(1)
a. Met
in use (as part of overall logging
b. Not met
function).

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 35 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify that design or user documents contain

evidence that the network device provides,
directly or using one or more compensating
mechanisms, protection from installation and
execution of malicious code. The mechanisms If a network device is able to utilize a compensating control, it need not directly support protection from malicious code.
The network device shall shall cover all interfaces via which code may be One such possible compensating control would be the use of network packet filtering devices to identify and remove
Protection from malicious IEC 62443-4-2:
x FSA-NDR 3.2 provide for protection from introduced. Verify that these documents note No 1, 2, 3, 4 malicious code while in transit. It is assumed that the IACS will be responsible for providing the required safeguards.
code NDR 3.2
malicious code. any special configuration requirements related However, for scenarios such as having a local USB host access, the need for protection from malicious code should be
to the protection mechanisms. evaluated.

Record one of:

a. Met
b. Not met

The product supplier and/or system integrator should provide guidance on how to test the designed security controls.
Asset owners need to be aware of the possible ramifications of running these verification tests during normal operations.
Details of the execution of these verifications need to be specified with careful consideration of the requirements for
Verify component provides methods to test continuous operations (for example, scheduling or prior notification).
security functions during FAT, SAT and Examples of security verification functions include:
Components shall provide the scheduled maintenance. These security • Verification of antivirus countermeasures by European Institute for Computer Antivirus Research (EICAR) testing of the
capability to support verification functions shall include all those necessary to control system file system. Antivirus software should detect the EICAR test samples and appropriate incident handling
Security functionality IEC 62443-4-2:
x x x x FSA-CR 3.3 of the intended operation of support the security requirements specified in No 1, 2, 3, 4 procedures should be triggered.
verification CR 3.3
security functions according to the IEC 62443-4-2 standard. • Verification of the identification, authentication and use control countermeasures by attempting access with an
IEC 62443‑3‑3 [11] SR3.3. Record one of: unauthorized account (for some functionality this could be automated).
a. Met • Verification of intrusion detection systems (IDSs) as a security control by including a rule in the IDS that triggers on
b. Not met irregular, but known non-malicious traffic. The test could then be performed by introducing traffic that triggers this rule
and the appropriate IDS monitoring and incident handling procedures.
• Confirmation that audit logging is occurring as required by security policies and procedures and has not been disabled
by an internal or external entity.

Components shall provide the Verify component provides methods to test

Security functionality capability to support verification security functions during normal operation.
IEC 62443-4-2:
x x x x FSA-CR 3.3 RE(1) verification during normal of the intended operation of Record one of: No 4
CR 3.3 RE(1)
operation security functions during normal a. Met
operations. b. Not met

Verify that user documentation describes

Components shall provide the
manual or automated integrity mechanisms
capability to perform or support
(such as cryptographic hashes) to verify the
integrity checks on software,
integrity of component software and Integrity verification methods are employed to detect, record, report and protect against software and information
configuration and other
configuration information as well as the tampering that may occur if other protection mechanisms (such as authorization enforcement) have been circumvented.
Software and information information as well as the IEC 62443-4-2:
x x x x FSA-CR 3.4 recording and reporting of the results of these No 1, 2, 3, 4 Components should employ formal or recommended integrity mechanisms (such as cryptographic hashes). For example,
integrity recording and reporting of the CR 3.4
checks, either directly or by integration into a such mechanisms could be used to monitor field devices for their latest configuration information to detect security
results of these checks or be
system. Record one of: breaches (including unauthorized changes).
integrated into a system that
a. Met by component
can perform or support integrity
b. Met by integration into system
checks.
c. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 36 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Components shall provide the Verify that user documentation describes

capability to perform or support manual or automated authenticity mechanisms
authenticity checks on software, (such as digital signatures) to authenticate the
configuration and other origin of component software and configuration
Authenticity of software and information as well as the information as well as the recording and IEC 62443-4-2:
x x x x FSA-CR 3.4 RE(1) No 2, 3, 4
information recording and reporting of the reporting of the results of these checks. Record CR 3.4 RE(1)
results of these checks or be one of:
integrated into a system that a. Met by component
can perform or support b. Met by integration into system
authenticity checks. c. Not met

If component directly supports the capability

under FSA-CR 3.4, verify component provides
automated methods to verify software and
If the component is performing
configuration integrity and to provide automated
the integrity check, it shall be
notification to a configurable entity. Record one
capable of automatically
Automated notification of of: IEC 62443-4-2:
x x x x FSA-CR 3.4 RE(2) providing notification to a No 3, 4
integrity violations a. Met CR 3.4 RE(2)
configurable entity upon
b. Not met
discovery of an attempt to make
an unauthorized change.
If the component does not directly support the
capability under FSA-CR 3.4, record:
c. Not relevant

Rules for checking the valid syntax of input data such as set points should be in place to verify that this information has
No validation activity for the FSA element of
Components shall validate the not been tampered with and is compliant with the specification. Inputs passed to interpreters should be pre-screened to
certification.
syntax, length and content of prevent the content from being unintentionally interpreted as commands. Note that this is a security CR, thus it does not
any input data that is used as an address human error, for example supplying a legitimate integer number which is outside the expected range.
This requirement is covered in the SDA element IEC 62443-4-2:
x x x x FSA-CR 3.5 Input validation industrial process control input No 1, 2, 3, 4 Generally accepted industry practices for input data validation include out-of-range values for a defined field type, invalid
of certification, by the validations for IEC 62443- CR 3.5
or input via external interfaces characters in data fields, missing or incomplete data and buffer overflow. Additional examples where invalid inputs lead
4-1 requirements SVV-1 and SI-2, defined in the
that directly impacts the action to system security issues include SQL injection attacks, cross-site scripting or malformed packets (as commonly
ISASecure document SDLA-312 as
of the component. generated by protocol fuzzers). Guidelines to be considered should include well-known guidelines such as the Open
requirements SDLA-SVV-1C and SDLA-SI-2E.
Web Application Security Project (OWASP) Code Review Guide [28].

Review user documentation and determine if

the component can physically or logically
connect to an automation process.
The deterministic behavior of control system outputs as a result of threat actions against the control system devices and
Components that physically or If the component can physically or logically
software is an important characteristic to ensure the integrity of normal operations. Ideally, the device continues to
logically connect to an connect to an automation process, review user
operate normally while under attack, but if the control system cannot maintain normal operation, then the control system
automation process shall documentation and verify that the component
outputs need to fail to a predetermined state. The appropriate predetermined state of control system outputs is device
provide the capability to set will set outputs of an automation process to a IEC 62443-4-2:
x x x x FSA-CR 3.6 Deterministic output No 1, 2, 3, 4 dependent and could be one of the following user configurable options:
outputs to a predetermined predetermined state if normal operation can not CR 3.6
• Unpowered – the outputs fail to the unpowered state;
state if normal operation as be maintained. Record one of:
• Hold – the outputs fail to the last-known good value; or
defined by the component a. Met
• Fixed – the outputs fail to a fixed value that is determined by the asset owner or an application; or
supplier cannot be maintained. b. Not met
• Dynamic – the outputs fail to one of the above options based on the current state.
If the component can not physically or logically
connect to an automation process, record:
c. Not relevant

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 37 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Supplier provides a list of all error messages

returned to a non administrative user. Verify for The product supplier and/or system integrator should carefully consider the structure and content of error messages.
Components shall identify and samples from this list that component error Error messages generated by the component should provide timely and useful information without revealing potentially
handle error conditions in a messages do not reveal sensitive information harmful information that could be used by adversaries to exploit the IACS. Disclosure of this information should be
manner that does not provide that could be exploited to attack the component. IEC 62443-4-2: justified by the necessity for timely resolution of error conditions. Guidelines to be considered could include well-known
x x x x FSA-CR 3.7 Error handling No 1, 2, 3, 4
information that could be Verify that the supplier has performed a security CR 3.7 guidelines such as the OWASP Code Review Guide.
exploited by adversaries to expert review of all error messages for such NOTE: A good example of an error message that could help adversaries attack an IACS would be to provide details of
attack the IACS. exploitable information. Record one of: why authentication with the system failed. For example stating invalid user or invalid password in the feedback would
a. Met help an adversary attack the IACS and thus should not be provided.
b. Not met

Review user documentation and determine if

communication sessions are used. This control focuses on communications protection at the session, versus packet, level. The intent of this control is to
establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and
Components shall provide
If communication sessions are used, verify that in the validity of the information being transmitted. For example, this control addresses man-in-the-middle attacks
mechanisms to protect the
design documentation confirms that session including session hijacking, insertion of false information into a session or replay attacks. Use of session integrity
integrity of communications
identifiers for communication sessions initiated mechanisms can have a significant overhead and therefore their use should be considered in light of requirements for
Session integrity - invalidate sessions including the capability IEC 62443-4-2:
x x x x FSA-CR 3.8A by a user are invalidated upon user logout or No 2, 3, 4 real-time communications.
session identifiers to invalidate session identifiers CR 3.8(a)
other session termination. Record one of: Session hijacking and other man-in-the-middle attacks or injections of false information often take advantage of easy-to-
upon user logout or other
a. Met guess session IDs (keys or other shared secrets) or use of session IDs that were not properly invalidated after session
session termination (including
b. Not met termination. Therefore the validity of a session authenticator should be tightly connected to the lifetime of a session.
browser sessions).
Employing randomness in the generation of unique session IDs helps to protect against brute-force attacks to determine
If communication sessions are not used, record: future session IDs.
c. Not relevant

Review user documentation and determine if

communication sessions are used.
Components shall provide
If communication sessions are used, verify that
mechanisms to protect the
design documents indicate that the component
integrity of communications
can generate communication session identifiers
Session integrity - generate sessions including the capability
for each session that are unique and that IEC 62443-4-2:
x x x x FSA-CR 3.8B and recognize session to generate a unique session No 2, 3, 4 See FSA-CR 3.8A
session IDs not generated by the system are CR 3.8(b)
identifiers identifier for each session and
rejected. Record one of:
recognize only session
a. Met
identifiers that are system-
b. Not met
generated.
If communication sessions are not used, record:
c. Not relevant

Review user documentation and determine if

communication sessions are used.
Components shall provide
mechanisms to protect the If communication sessions are used, verify that
integrity of communications communication session identifiers are
Session integrity - random sessions including the capability generated by the system with an accepted level IEC 62443-4-2:
x x x x FSA-CR 3.8C No 2, 3, 4 See FSA-CR 3.8A
session identifiers to generate unique session of randomness. Record one of: CR 3.8(c)
identifiers with commonly a. Met
accepted sources of b. Not met
randomness.
If communication sessions are not used, record:
c. Not relevant

Review component documentation and verify

that audit information and audit tools (if present)
Components shall protect audit require authorization in order to access, modify
Audit information includes all information (for example, audit records, audit settings and audit reports) needed to
information, audit logs, and or delete, for any interface through which these
Protection of audit IEC 62443-4-2: successfully audit control system activity. The audit information is important for error correction, security breach
x x x x FSA-CR 3.9 audit tools (if present) from are accessible. Attempt to delete an audit log Yes 2, 3, 4
information CR 3.9 recovery, investigations and related efforts. Mechanisms for enhanced protection against modification and deletion
unauthorized access, as an unauthorized user and verify that access
include the storage of audit information to hardware-enforced write-once media.
modification and deletion. is denied. Record one of:
a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 38 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Review component documentation and verify

Components shall provide the that the component has the capability to
Audit records on write-once capability to store audit records produce audit records on hardware-enforced IEC 62443-4-2:
x x x x FSA-CR 3.9 RE(1) No 4
media on hardware-enforced write- write-once media. Record one of: CR 3.9 RE(1)
once media. a. Met
b. Not met

Verify by examining design documentation and

user documentation, that elements of the
Embedded devices over their installed lifetime may have the need for installation of updates and upgrades. There will
embedded device can be updated and
The embedded device shall be cases where embedded devices are supporting or executing essential functions as well. When this is the case the
upgraded. Typical elements are software and IEC 62443-4-2:
x FSA-EDR 3.10 Support for updates support the ability to be updated No 1, 2, 3, 4 embedded device needs to have mechanisms in place to support patching and updating without impacting the essential
firmware. Update and upgrade are defined in EDR 3.10
and upgraded. functions of high availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this
IEC 62443-4-2 sub clause 3.1. Record one of:
capability would be to support redundancy within the embedded device.
a. Met
b. Not met

Verify that the component provides measures to

verify prior to installation, that software updates
and upgrades originate from the supplier.

Verify in design and user documentation and by

testing that the component provides measures
The embedded device shall to detect changes to software that have
Update authenticity and validate the authenticity and occurred after creation by the supplier and prior IEC 62443-4-2:
x FSA-EDR 3.10 RE(1) Yes 2, 3, 4
integrity integrity of any software update to installation. EDR 3.10 RE(1)
or upgrade prior to installation.
One possible method to meet this requirement
is to validate digital signatures and
cryptographic hashes.
Record one of:
a. Met
b. Not met

Verify by examining design documentation and

user documentation, that elements of the host
Host devices over their installed lifetime may have the need for installation of updates and upgrades. There will be
device can be updated and upgraded. Typical
Host devices shall support the cases where host devices are supporting or executing essential functions as well. When this is the case the host device
elements are software and firmware. Update IEC 62443-4-2:
x FSA-HDR 3.10 Support for updates ability to be updated and No 1, 2, 3, 4 should have mechanisms in place to support patching and updating without impacting the essential functions of high
and upgrade are defined in IEC 62443-4-2 sub HDR 3.10
upgraded. availability systems (see 4.2 CSSC 1 Support of essential functions). One example for providing this capability would be
clause 3.1. Record one of:
to support redundancy within the host device.
a. Met
b. Not met

Verify that the component provides measures to

verify prior to installation, that software updates
and upgrades originate from the supplier.

Verify in design and user documentation and by

testing that the component provides measures
Host devices shall validate the to detect changes to software that have
Update authenticity and authenticity and integrity of any occurred after creation by the supplier and prior IEC 62443-4-2:
x FSA-HDR 3.10 RE(1) Yes 2, 3, 4
integrity software update or upgrade to installation. HDR 3.10 RE(1)
prior to installation.
One possible method to meet this requirement
is to validate digital signatures and
cryptographic hashes.
Record one of:
a. Met
b. Not met

Verify by examining design documentation and

user documentation, that elements of the
Network devices over their installed lifetime may require installation of updates and upgrades. There will be cases
network device can be updated and upgraded.
Network devices shall support where network devices are supporting or executing essential functions as well. When this is the case the network device
Typical elements are software and firmware. IEC 62443-4-2:
x FSA-NDR 3.10 Support for updates the ability to be updated and No 1, 2, 3, 4 should have mechanisms in place to support patching and updating without impacting the essential functions of high
Update and upgrade are defined in IEC 62443-4- NDR 3.10
upgraded. availability systems (see 4.2 CCSC 1 Support of essential functions). One example for providing this capability would be
2 sub clause 3.1. Record one of:
to support redundancy within the network device.
a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 39 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify that the component provides measures to

verify prior to installation, that software updates
and upgrades originate from the supplier.

Verify in design and user documentation and by

testing that the component provides measures
Network devices shall validate to detect changes to software that have
Update authenticity and the authenticity and integrity of occurred after creation by the supplier and prior IEC 62443-4-2:
x FSA-NDR 3.10 RE(1) Yes 2, 3, 4
integrity any software update or upgrade to installation. NDR 3.10 RE(1)
prior to installation.
One possible method to meet this requirement
is to validate digital signatures and
cryptographic hashes.
Record one of:
a. Met
b. Not met

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
Examine the threat model for the component to
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
verify that it enumerates possible integrity and
tampering event occur.
The embedded device shall confidentiality threats to the component due to
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
provide tamper resistance and physical access. Verify for each of these
Physical tamper resistance IEC 62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-EDR 3.11 detection mechanisms to threats, that they are deterred by physical No 2, 3, 4
and detection EDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
protect against unauthorized mechanisms and that carrying out the threat
paths will increase the difficulty of probing the product internals.
physical access into the device. creates tamper evidence. Record one of:
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
a. Met
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
b. Not met
tampering. More sophisticated techniques include switches.

Verify in the threat model that high risk events

of unauthorized physical access are mitigated
by automatic notification.
The embedded device shall be
capable of automatically
Verify that the component provides the
providing notification to a
capability to automatically provide notification to
configurable set of recipients
a configurable set of recipients when such an
Notification of a tampering upon discovery of an attempt to IEC 62443-4-2:
x FSA-EDR 3.11 RE(1) access is detected, and to create an audit No 3, 4
attempt make an unauthorized physical EDR 3.11 RE(1)
record for this notification. Methods that require
access. All notifications of
human intervention for detection or notification
tampering shall be logged as
(such as a person noticing disturbed tamper
part of the overall audit logging
tape) do not meet this requirement. Record one
function.
of:
a. Met
b. Not met

Examine the threat model for the component to

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
verify that it enumerates possible integrity and
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
confidentiality threats to the component due to
Host devices shall provide the tampering event occur.
physical access. Verify for each of these
capability to support tamper Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
threats, that they are deterred by physical
Physical tamper resistance resistance and detection IEC 62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-HDR 3.11 mechanisms supported by the component, and No 2, 3, 4
and detection mechanisms to protect against HDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
that the component supports a mechanism such
unauthorized physical access paths will increase the difficulty of probing the product internals.
that carrying out the threat creates tamper
into the device. The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
evidence. Record one of:
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
a. Met
tampering. More sophisticated techniques include switches.
b. Not met

Verify in the threat model that high risk events

of unauthorized physical access are mitigated
by automatic notification.
Host devices shall be capable of
automatically providing
Verify that the component provides the
notification to a configurable set
capability to automatically provide notification to
of recipients upon discovery of
Notification of a tampering a configurable set of recipients when such an IEC 62443-4-2:
x FSA-HDR 3.11 RE(1) an attempt to make an No 3, 4
attempt access is detected, and to create an audit HDR 3.11 RE(1)
unauthorized physical access.
record for this notification. Methods that require
All notifications of tampering
human intervention for detection or notification
shall be logged as part of the
(such as a person noticing disturbed tamper
overall audit logging function.
tape) do not meet this requirement. Record one
of:
a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 40 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

The purpose of tamper resistance mechanisms is to prevent an attempt by an attacker to execute an unauthorized
Examine the threat model for the component to
physical action against an IACS device. Secondary to prevention, detection and response are essential should a
verify that it enumerates possible integrity and
tampering event occur.
Network devices shall provide confidentiality threats to the component due to
Tamper resistance mechanisms are most effectively used in combinations to prevent access to any critical components.
tamper resistance and detection physical access. Verify for each of these
Physical tamper resistance IEC 62443-4-2: Tamper resistance consists of using specialized materials to make tampering of a device or module difficult. This can
x FSA-NDR 3.11 mechanisms to protect against threats, that they are deterred by physical No 2, 3, 4
and detection NDR 3.11 include such features as hardened enclosures, locks, encapsulation, or security screws. Putting in place tight airflow
unauthorized physical access mechanisms, and that carrying out the threat
paths will increase the difficulty of probing the product internals.
into the device. creates tamper evidence. Record one of:
The purpose of tamper evidence is to ensure that visible or electronic evidence remains when a tampering event occurs.
a. Met
Many simple evidence techniques are comprised of seals and tapes to make it obvious that there has been physical
b. Not met
tampering. More sophisticated techniques include switches.

Verify in the threat model that high risk events

of unauthorized physical access are mitigated
by automatic notification.
Network devices shall be
capable of automatically Verify that the component provides the
providing notification to a capability to automatically provide notification to
configurable set of recipients a configurable set of recipients when such an
Notification of a tampering upon discovery of an attempt to access is detected, and to create an audit IEC 62443-4-2:
x FSA-NDR 3.11 RE(1) No 3, 4
attempt make an unauthorized physical record for this notification. Methods that require NDR 3.11 RE(1)
access. All notifications of human intervention for detection or notification
tampering shall be logged as (such as a person noticing disturbed tamper
part of the overall audit logging tape) do not meet this requirement. Record one
function. of:
a. Met
b. Not met

Examine supplier documentation of the

component design and manufacturing process
to verify that during the process for creating any
roots of trust for the device, and thereafter, the In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
product supplier keys and data to be used as provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
Embedded devices shall provide roots of trust, are handled within the device source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
the capability to provision and such that they cannot be accessed in any cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
protect the confidentiality, manner other than by the functions in the device to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
Provisioning product
integrity, and authenticity of that require the usage of this information. Verify IEC 62443-4-2: firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
x FSA-EDR 3.12 supplier roots of trust - No 2, 3, 4
product supplier keys and data that the threat model analyzes threats to the EDR 3.12 component will boot into a “known good” state in which all security mechanisms are known to be operational and
protection
to be used as one or more confidentiality, integrity and authenticity of the uncompromised. “Root of trust” data is often protected via hardware mechanisms, preventing any modification of the
“roots of trust” at the time of roots of trust at the time of device manufacture data during normal operations of the component. Modification of product supplier root of trust data is typically limited to
manufacture of the device. and as used thereafter, and that these threats the product supplier’s provisioning process, where the product supplier has a trusted process to perform the provisioning
have been mitigated. Use of a trusted store or a of the data. Instead, information to be validated against the root of trust is submitted to the validation process through a
trusted zone are examples of methods to meet hardware or software API which performs the validation and returns the results without exposing the protected data.
this requirement. Record one of:
a. Met
b. Not met

Examine supplier documentation of the

component design and manufacturing process
to verify that during the process for creating any
In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
roots of trust for the device, and thereafter, the
provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
product supplier keys and data to be used as
source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
Host devices shall provide the roots of trust, are handled within the device
cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
capability to provision and such that they cannot be accessed in any
to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
protect the confidentiality, manner other than by the functions in the device
Provisioning product firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
integrity, and authenticity of that require the usage of this information. Verify IEC 62443-4-2:
x FSA-HDR 3.12 supplier roots of trust - No 2, 3, 4 component will boot into a “known good” state in which all security mechanisms are known to be operational and
product supplier keys and data that the threat model analyzes threats to the HDR 3.12
protection uncompromised. “Root of trust” data can be protected by software or hardware implemented mechanisms to prevent
to be used as one or more confidentiality, integrity and authenticity of the
any modification of the data during normal operations of the component. Modification of product supplier root of trust
“roots of trust” at the time of roots of trust at the time of device manufacture
data is typically limited to the product supplier’s provisioning process, where the product supplier has a trusted process
manufacture of the device. and as used thereafter, and that these threats
to perform the provisioning of the data. Instead, information to be validated against the root of trust is submitted to the
have been mitigated. Use of a trusted store or a
validation process through a hardware or software API which performs the validation and returns the results without
trusted zone are examples of methods to meet
exposing the protected data.
this requirement. Record one of:
a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 41 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Examine supplier documentation of the

component design and manufacturing process
to verify that during the process for creating any
In order for a component to be able to validate the authenticity and integrity of the hardware, software, and data
roots of trust for the device, and thereafter, the
provided by the product supplier, it must possess a trusted source of data to perform the validation process. This trusted
product supplier keys and data to be used as
source of data is referred to as the “root of trust” for the system. This trusted source of data may be a set of
Network devices shall provide roots of trust, are handled within the device
cryptographic hashes of “known good” software, or it may be the public portion of an asymmetric cryptographic key pair
the capability to provision and such that they cannot be accessed in any
to be used in the validation of cryptographic signatures. This trusted data is often used to validate critical software,
protect the confidentiality, manner other than by the functions in the device
Provisioning product firmware, and data prior to booting the firmware or operating system of a component, in order to validate that the
integrity, and authenticity of that require the usage of this information. Verify IEC 62443-4-2:
x FSA-NDR 3.12 supplier roots of trust - No 2, 3, 4 component will boot into a “known good” state in which all security mechanisms are known to be operational and
product supplier keys and data that the threat model analyzes threats to the NDR 3.12
protection uncompromised. “Root of trust” data is often protected by software or hardware implemented mechanisms to prevent
to be used as one or more confidentiality, integrity and authenticity of the
any modification of the data during normal operations of the component. Modification of product supplier root of trust
“roots of trust” at the time of roots of trust at the time of device manufacture
data is typically limited to the product supplier’s provisioning process, where the product supplier has a trusted process
manufacture of the device. and as used thereafter, and that these threats
to perform the provisioning of the data. Instead, information to be validated against the root of trust is submitted to the
have been mitigated. Use of a trusted store or a
validation process through a hardware or software API which performs the validation and returns the results without
trusted zone are examples of methods to meet
exposing the protected data.
this requirement. Record one of:
a. Met
b. Not met

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
Examine user documentation to verify that after authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
an asset owner has assumed responsibility for a provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
device, a process exists for the asset owner to provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
create and use roots of trust for the device. programs, or other such means. In order to protect the security of the component, it is important that these extensions to
Verify in design documentation that the asset the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
owner keys and data to be used as roots of approved of their origins.
Embedded devices shall provide trust, are handled within the device such that In order to perform these validations the component must contain data that provides a way to differentiate between valid
the capability to provision and they cannot be accessed in any manner other and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
Provisioning asset owner protect the confidentiality, than by the functions in the device that require IEC 62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-EDR 3.13A No 2, 3, 4
roots of trust - protection integrity, and authenticity of the usage of this information. Verify that the EDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
asset owner keys and data to be threat model analyzes threats to the the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
used as “roots of trust”. confidentiality, integrity, and authenticity of the authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
asset owner roots of trust and that these threats of trust that grant them the ability to operate on the component.
have been mitigated. Use of a trusted store or a A root of trust can also be used as a basis communications security, such as communications integrity required by CR
trusted zone are examples of methods to meet 3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.
this requirement. Record one of: Requirements such as EDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code
a. Met prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
b. Not met validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
allowed to execute.

Examine user and design documents for

Embedded devices shall
evidence to verify that the component process
support the capability to
for provisioning asset owner roots of trust can
Provisioning asset owner provision without reliance on IEC 62443-4-2:
x FSA-EDR 3.13B be performed within the component's security No 2, 3, 4 See FSA-EDR 3.13A
roots of trust - inside zone components that may be EDR 3.13(b)
zone. Record one of:
outside of the device’s security
a. Met
zone.
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 42 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
Examine user documentation to verify that after
provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
an asset owner has assumed responsibility for a
provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
device, a process exists for the asset owner to
programs, or other such means. In order to protect the security of the component, it is important that these extensions to
create and use roots of trust for the device.
the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
Verify in design documentation that the asset
approved of their origins.
owner keys and data to be used as roots of
Host devices shall provide the In order to perform these validations the component must contain data that provides a way to differentiate between valid
trust, are handled within the device such that
capability to provision and and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
they cannot be accessed in any manner other
Provisioning asset owner protect the confidentiality, IEC 62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-HDR 3.13A than by the functions in the device that require No 2, 3, 4
roots of trust - protection integrity, and authenticity of HDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
the usage of this information. Verify that the
asset owner keys and data to be the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
threat model analyzes threats to the
used as “roots of trust”. authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
confidentiality, integrity, and authenticity of the
of trust that grant them the ability to operate on the component.
asset owner roots of trust and that these threats
Requirements such as HDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code
have been mitigated. Use of a trusted store or a
prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
trusted zone are examples of methods to meet
validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
this requirement. Record one of:
allowed to execute.
a. Met
A root of trust can also be used as a basis communications security, such as communications integrity required by CR
b. Not met
3.1 – Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Examine user and design documents for

evidence to verify that the component process
Host devices shall support the
for provisioning asset owner roots of trust can
capability to provision without
Provisioning asset owner be performed within the component's security IEC 62443-4-2:
x FSA-HDR 3.13B reliance on components that No 2, 3, 4 See FSA-HDR 3.13A
roots of trust - inside zone zone. Record one of: HDR 3.13(b)
may be outside of the device’s
a. Met
security zone.
b. Not met

Product suppliers have established mechanisms to ensure that the software and firmware on their components is
authentic, and the integrity of that software and firmware has not been compromised. This allows the product supplier to
Examine user documentation to verify that after
provide the asset owner with a “known good” state from which to operate. However, many product suppliers also
an asset owner has assumed responsibility for a
provide mechanisms for asset owners to extend the functionality of their devices through the use of mobile code, user
device, a process exists for the asset owner to
programs, or other such means. In order to protect the security of the component, it is important that these extensions to
create and use roots of trust for the device.
the component’s functionality also be validated to ensure that they are authorized, and that the asset owner has
Verify in design documentation that the asset
approved of their origins.
owner keys and data to be used as roots of
Network devices shall provide In order to perform these validations the component must contain data that provides a way to differentiate between valid
trust, are handled within the device such that
the capability to provision and and invalid origins. The list of valid and invalid origins will differ from asset owner to asset owner, and it is unlikely that a
they cannot be accessed in any manner other
Provisioning asset owner protect the confidentiality, IEC 62443-4-2: product supplier will have a complete list of every possible valid origin at time of manufacture. Therefore it is important
x FSA-NDR 3.13A than by the functions in the device that require No 2, 3, 4
roots of trust - protection integrity, and authenticity of NDR 3.13(a) that the product supplier provide a way for the asset owner to securely provision their own “roots of trust” which provide
the usage of this information. Verify that the
asset owner keys and data to be the ability to distinguish between origins allowed by the asset owner’s security policy, and those that are not. The
threat model analyzes threats to the
used as “roots of trust”. authenticity and integrity of these “roots of trust” must be protected so that malicious actors cannot add additional roots
confidentiality, integrity, and authenticity of the
of trust that grant them the ability to operate on the component.
asset owner roots of trust and that these threats
Requirements such as NDR 2.4 – Mobile code require the component to complete authenticity checks on mobile code
have been mitigated. Use of a trusted store or a
prior to the execution of mobile code. The roots of trust provided by this requirement provide the data necessary to
trusted zone are examples of methods to meet
validate the origin and integrity of mobile code, allowing the component to independently determine if the code is
this requirement. Record one of:
allowed to execute.
a. Met
A root of trust is used to provide communications security, such as communications integrity required by CR 3.1 –
b. Not met
Communication integrity or communications confidentiality required by CR 4.1 – Information confidentiality.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 43 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Examine user and design documents for

evidence to verify that the component process
Network devices shall support
for provisioning asset owner roots of trust can
the capability to provision
Provisioning asset owner be performed within the component's security IEC 62443-4-2:
x FSA-NDR 3.13B without reliance on components No 2, 3, 4 See FSA-NDR 3.13A
roots of trust - inside zone zone. Record one of: NDR 3.13(b)
that may be outside of the
a. Met
device’s security zone.
b. Not met

Verify in design documentation, and by testing

that the component provides measures to verify In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
Embedded devices shall verify during the boot process that all firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
the integrity of the firmware, software and configuration data needed for the firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
software, and configuration data boot or runtime process have not been modified IEC 62443-4-2: of the component’s firmware and/or software prior to use during the boot process, to ensure that the component does
x FSA-EDR 3.14 Integrity of the boot process Yes 1, 2, 3, 4
needed for component’s boot between a prior point in time when they were EDR 3.14 not boot into an insecure or invalid operating state that could damage the component or provide a path for a malicious
and runtime processes prior to assumed trustworthy, and each time of use for actor to gain access to additional components, assets, or data.
use. the boot or runtime process. Record one of:
a. Met
b. Not met

Verify in design and user documentation, and by

Embedded devices shall use the testing that the component uses supplier roots
component’s product supplier of trust to verify during the boot process that all
roots of trust to verify the firmware, software and configuration data
Authenticity of the boot authenticity of the firmware, needed for the boot process originate from the IEC 62443-4-2:
x FSA-EDR 3.14 RE(1) Yes 2, 3, 4
process software, and configuration data supplier. One possible method is validation of EDR 3.14 RE(1)
needed for the component’s digital signatures and cryptographic hashes.
boot process prior to it being Record one of:
used in the boot process. a. Met
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 44 of 53
 CSA-311 FR 3
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify in design documentation, and by testing

that the component provides measures to verify In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
Host devices shall verify the during the boot process that all firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
integrity of the firmware, software and configuration data needed for the firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
software, and configuration data boot process have not been modified between a IEC 62443-4-2: and authenticity of the component’s firmware and/or software prior to the boot process, to ensure that the component
x FSA-HDR 3.14 Integrity of the boot process Yes 1, 2, 3, 4
needed for component’s boot prior point in time when they were assumed HDR 3.14 does not boot into an insecure or invalid operating state that could damage the component or provide a path for a
process prior to it being used in trustworthy, and each time of use for the boot malicious actor to gain access to additional components, assets, or data.
the boot process. process. Record one of:
a. Met
b. Not met

Verify in design and user documentation, and by

testing that the component uses supplier roots
Host devices shall use the
of trust to verify during the boot process that all
component’s product supplier
firmware, software and configuration data
roots of trust to verify the
needed for the boot process originate from the
Authenticity of the boot authenticity of the firmware, IEC 62443-4-2:
x FSA-HDR 3.14 RE(1) supplier. One possible method is validation of Yes 2, 3, 4
process software, and configuration data HDR 3.14 RE(1)
digital signatures and cryptographic hashes.
needed for component’s boot
Record one of:
process prior to it being used in
a. Met
the boot process.
b. Not met

Verify in design documentation, and by testing

that the component provides measures to verify In order to make assurances to an asset owner that a component’s security functionality has not been compromised, it is
Network devices shall verify the during the boot process that all firmware, necessary to ensure that the component’s software and firmware has not been tampered with, and that the software and
integrity of the firmware, software and configuration data needed for the firmware is valid to execute on the component. Therefore the component must perform checks to validate the integrity
software, and configuration data boot process have not been modified between a IEC 62443-4-2: and authenticity of the component’s firmware and/or software prior to the boot process, to ensure that the component
x FSA-NDR 3.14 Integrity of the boot process Yes 1, 2, 3, 4
needed for component’s boot prior point in time when they were assumed NDR 3.14 does not boot into an insecure or invalid operating state that could damage the component or provide a path for a
process prior to it being used in trustworthy and each time of use for the boot malicious actor to gain access to additional components, assets, or data.
the boot process. process. Record one of:
a. Met
b. Not met

Verify in design and user documentation, and by

testing that the component uses supplier roots
Network devices shall use the
of trust to verify during the boot process that all
component’s product supplier
firmware, software and configuration data
roots of trust to verity the
needed for the boot process originate from the
Authenticity of the boot authenticity of the firmware, IEC 62443-4-2:
x FSA-NDR 3.14 RE(1) supplier. One possible method is validation of Yes 2, 3, 4
process software, and configuration data NDR 3.14 RE(1)
digital signatures and cryptographic hashes.
needed for component’s boot
Record one of:
process prior to it being used in
a. Met
the boot process.
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 45 of 53
 CSA-311 FR 4
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

The decision whether a given information should be protected or not

Identify all information at rest for which explicit read authorization is
depends on the context and cannot be made at product design.
supported. Review design documentation and verify that all such
However, the fact that an organization limits access to information by
information includes methods to protect the confidentiality such as
configuring explicit read authorizations in the control system is an
encrypting the data or limiting user access to the location where the
indicator that this information should be protected by the organization.
Components shall provide the capability data is stored. If the user must configure or set up the component in
Thus, all information for which the component supports the capability
Information confidentiality - at to protect the confidentiality of a certain manner to meet this requirement, verify that this is clearly IEC 62443-4-2:
x x x x FSA-CR 4.1A Yes 1, 2, 3, 4 to assign explicit read authorizations should be considered potentially
rest information at rest for which explicit read documented in a user manual. Attempt to access a sampling of CR 4.1(a)
sensitive and thus the component should also provide the capability to
authorization is supported. confidential information to verify that it cannot be accessed by users
protect its confidentiality.
without the proper authorization.
Confidentiality of information in transit requires system level
Record one of:
capabilities which the component should be able to support.
a. Met
For confidentiality protection, 8.5 CR 4.3 – Use of cryptography
b. Not Met
provides further requirements.

Identify all information in transit over external boundaries of the

component for which explicit read authorization is supported. Review
design documentation and verify that all such information includes
methods to protect the confidentiality such as encrypting the data or
limiting user access to the physical medium data used for
transmission. If the user must configure or set up the component in
Components shall support the protection
a certain manner to meet this requirement, verify that this is clearly
Information confidentiality - in of the confidentiality of information in IEC 62443-4-2:
x x x x FSA-CR 4.1B documented in a user manual. If a user can access a physical Yes 1, 2, 3, 4 See FSA-CR 4.1A
transit transit as defined in IEC 62443‑3‑3 [11] CR 4.1(b)
medium used for transmission, verify by test that no confidential
SR 4.1.
information can be seen on the transmission medium by using an
eavesdropping tool such as Wireshark to view a sampling of
communications while the system is performing its normal
operations. Record one of:
a. Met
b. Not Met

Removal of a control system component from active service should

not provide the opportunity for unintentional release of information for
which explicit read authorization is supported. An example of such
information can include authentication information and network
Review component documentation and verify that the component
Components shall provide the capability configuration information stored in non-volatile storage or other
has the ability to purge all information for which explicit read
to erase all information, for which explicit cryptographic information that would facilitate unauthorized or
authorization is supported. Verify that the data is purged from the IEC 62443-4-2:
x x x x FSA-CR 4.2 Information persistence read authorization is supported, from No 2, 3, 4 malicious activity.
component such that it can not be recreated. Record one of: CR 4.2
components to be released from active Information produced by the actions of a user or role (or the actions of
a. Met
service and/or decommissioned. a software process acting on behalf of a user or role) should not be
b. Not Met
disclosed to a different user or role in an uncontrolled fashion. Control
of control system information or data persistence prevents information
stored on a shared resource from being unintentionally disclosed after
that resource has been released back to the control system.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 46 of 53
 CSA-311 FR 4
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

Determine from component documention if the component may

have more than one user, and if confidential information may be
placed in volatile memory. If both of these statements are true, then
review component design documentation and verify that confidential
information is purged from RAM before that memory is released
back to the component for use by a different user. Review
component design documentation and verify that confidential
information is not stored in memory that can be accessed by
Components shall provide the capability
unauthorized users of any type (human, device, software
Erase of shared memory to protect against unauthorized and IEC 62443-4-2:
x x x x FSA-CR 4.2 RE(1) application). Record one of: No 3, 4
resources unintended information transfer via CR 4.2 RE(1)
a. Met
volatile shared memory resources.
b. Not Met
c. Not relevant, if the component has only one user or if no
confidential information is placed in volatile memory

Confidential information is information such that the security of the

component depends upon confidentiality protection of this data from
some or all users, or for which explicit read authorization may be
configured/customized by the user.

Review the component documentation and verify that the component

has the cabability to verify that information has been purged from the
component as defined in the CR-4.2 base requirement. Carry out a
test to follow the recommended practice to purge information from
the component and perform the documented verification method to
Components shall provide the capability
verify that the information has been purged from the component. IEC 62443-4-2:
x x x x FSA-CR 4.2 RE(2) Erase verification to verify that the erasure of information Yes 3, 4
Carry out an additional test to perform the documented verification CR 4.2 RE(2)
occurred.
method on a system that has not had its information purged to
ensure that the method will detect a failure of the purge.
Record one of:
a. Met
b. Not Met

The selection of cryptographic protection should be based on a threat

and risk analysis which covers the value of the information being
protected, the consequences of the confidentiality and integrity of the
information being breached, the time period during which the
information is confidential and control system operating constraints.
This can involve either information at rest, in transit, or both. Note that
backups are an example of information at rest, and should be
considered as part of a data confidentiality and integrity assessment
process. The control system product supplier should document the
practices and procedures relating to cryptographic key establishment
and management. The control system should utilize established and
Verify through design documentation that if the component uses
tested encryption and hash algorithms, such as the advanced
cryptography then algorithms, key sizes and mechanisms for key
If cryptography is required, the encryption standard (AES) and the secure hash algorithm (SHA)
establishment are done according to commonly accepted industry
component shall use cryptographic series, and key sizes based on an assigned standard. Key generation
best practices and recommendations as defined in ICSA-500, or in IEC 62443-4-2:
x x x x FSA-CR 4.3 Use of cryptography security mechanisms according to No 1, 2, 3, 4 needs to be performed using an effective random number generator.
NIST SP 800-57 or similar publication. CR 4.3
internationally recognized and proven The security policies and procedures for key management need to
a. Met by the component
security practices and recommendations. address periodic key changes, key destruction, key distribution and
b. Not Met
encryption key backup in accordance with defined standards.
Generally accepted practices and recommendations can be found in
documents such as NIST SP 800-57, Recommendation for Key
Management, Part 1: General [25]. Implementation requirements can
be found for example in FIPS 140-2, Security Requirements for
Cryptographic Modules [24] or ISO/IEC 19790, Information
technology – Security techniques – Security requirements for
cryptographic modules [17].
This CR, along with 5.10, CR 1.8 – Public key infrastructure
certificates may be applicable when meeting many other requirements
defined within this document.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 47 of 53
 CSA-311 FR 5
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

Network segmentation is used by organizations for a variety of purposes, including cyber

security. The main reasons for segmenting networks are to reduce the exposure, or
ingress, of network traffic into a control system and reduce the spread, or egress, of
network traffic from a control system. This improves overall system response and
reliability as well as provides a measure of cyber security protection. It also allows
different network segments within the control system, including critical control systems
and safety-related systems, to be segmented from other systems for an additional level
of protection.
Access from the control system to the World Wide Web should be clearly justified based
on control system operational requirements.
Network segmentation and the level of protection it provides will vary greatly depending
Components shall support a segmented Verify that the device supports a networking technology that on the overall network architecture used by an asset owner in their facility and even
network to support zones and conduits, is capable of being segmented. Record one of: system integrators within their control systems. Logically segmenting networks based on
IEC 62443-4-2: CR
x x x x FSA-CR 5.1 Network segmentation as needed, to support the broader a. Met No 1, 2, 3, 4 their functionality provides some measure of protection, but may still lead to single-points-
5.1
network architecture based on logical b. Not met of-failure if a network device is compromised. Physically segmenting networks provides
segmentation and criticality. another level of protection by removing that single-point-of-failure case, but will lead to a
more complex and costly network design. These trade-offs will need to be evaluated
during the network design process (see IEC 62443 2-1).
In response to an incident, it may be necessary to break the connections between
different network segments. In that event, the services necessary to support essential
operations should be maintained in such a way that the devices can continue to operate
properly and/or shutdown in an orderly manner. This may require that some servers may
need to be duplicated on the control system network to support normal network features,
for example dynamic host configuration protocol (DHCP), domain name service (DNS)
or local CAs. It may also mean that some critical control systems and safety-related
systems be designed from the beginning to be completely isolated from other networks.

Unless the supplier has documented that a network device is

not intended to be used at a zone boundary, verify that the
network device has the capability to inspect network traffic
passing through the device, that determines whether the
network device takes action to control the traffic. Examples
of control actions supported may include rerouting the traffic
or dropping it. For example, a firewall or router would satisfy
A network device at a zone boundary Any connections to outside each security zone should occur through managed interfaces
this aspect of the requirement. Also verify that the
shall provide the capability to monitor and consisting of appropriate boundary protection devices (for example, proxies, gateways,
occurrence of control actions taken on network traffic is
control communications at zone IEC 62443-4-2: routers, firewalls, unidirectional gateways, guards and encrypted tunnels) arranged in an
x FSA-NDR 5.2 Zone boundary protection recorded in a log. No 1, 2, 3, 4
boundaries to enforce the NDR 5.2 effective architecture (for example, firewalls protecting application gateways residing in a
Record one of:
compartmentalization defined in the risk- DMZ). Control system boundary protections at any designated alternate processing sites
a. Met
based zones and conduits model. should provide the same levels of protection as that of the primary site.
b. Not met
If the supplier has documented that a network device is not
intended to be used at a zone boundary, record:
c. Not relevant

The network component shall provide the Verify that user documents indicate the capability to deny all
capability to deny network traffic by network traffic through the network device by default and
IEC 62443-4-2:
x FSA-NDR 5.2 RE(1) Deny all, permit by exception default and allow network traffic by allow network traffic by exception. Record one of: No 2, 3, 4
NDR 5.2 RE(1)
exception (also termed deny all, permit by a. Met
exception). b. Not met

The network component shall provide the Verify in user documentation and by testing that the network
capability to protect against any device has the capability to be placed in a mode to block all NOTE Examples of when this capability may be used include where a security violation
IEC 62443-4-2:
x FSA-NDR 5.2 RE(2) Island mode communication through the control traffic passing through the device. Record one of: Yes 3, 4 and/or breach has been detected within the control system, or an attack is occurring at
NDR 5.2 RE(2)
system boundary (also termed island a. Met the enterprise level.
mode). b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 48 of 53
 CSA-311 FR 5
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Test Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Required Requirement
Level
(Yes/No)

Verify in user documentation and by testing that the network

The network component shall provide the
device has the capability to block all traffic passing through
capability to protect against any
the device, when there is any operational failure of boundary
communication through the control NOTE Examples of when this capability may be used include scenarios where a
protection mechanisms. Examples of operational failures for IEC 62443-4-2:
x FSA-NDR 5.2 RE(3) Fail close system boundary when there is an Yes 3, 4 hardware failure or power failure causes boundary protection devices to function in a
which this capability may be provided are power failure, NDR 5.2 RE(3)
operational failure of the boundary degraded mode or fail entirely.
software failures, and hardware failures.
protection mechanisms (also termed fail
a. Met
close).
b. Not met

General purpose, person-to-person communications systems include but are not limited
to: email systems, forms of social media (Twitter, Facebook, picture galleries, etc.) or
any message systems that permit the transmission of any type of executable file. These
systems are usually utilized for private purposes that are not related to control system
A network device at a zone boundary Verify in user documentation that the network device has the operations, and therefore the risks imposed by these systems normally outweigh any
shall provide the capability to protect capability to block all types of general purpose, person-to- perceived benefit.
General purpose, person-to- against general purpose, person-to- person messages. Record one of: IEC 62443-4-2: These types of general purpose communications systems are commonly used as attack
x FSA-NDR 5.3 No 1, 2, 3, 4
person communication restrictions person messages from being received a. Met NDR 5.3 vectors to introduce malware to the control system, pass information for which read
from users or systems external to the b. Not met authorization exists to locations external to the control system and introduce excessive
control system. network loading that can be used to create security problems or launch attacks on the
control system.
Network devices could realize such restrictions, for example, by blocking specific
communications based on port numbers and source and/or target address as well as
more in depth checks by application layer firewalls.

There is no component level requirement

IEC 62443-4-2: CR
FSA-CR 5.4 Application partitioning associated with IEC 62443‑3‑3 SR 5.4. No validation activity
5.4

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 49 of 53
 CSA-311 FR 6
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

The applications and devices may generate audit records about events
occurring in that application or device (see 6.10). Access to these audit
logs is necessary to support filtering audit logs, identifying and removing
information that is redundant, reviewing and reporting activity during after-
Verify that the component provides a means for the-fact investigations of security incidents. In general, audit reduction
Components shall provide the
authorized humans and/or authorized external tools to and report generation should be performed on a separate information
capability for authorized humans IEC 62443-4-2:
x x x x FSA-CR 6.1 Audit log accessibility access audit logs on a read-only basis. Record one of: No 1, 2, 3, 4 system. Manual access to the audit records (such as, screen views or
and/or tools to access audit logs on a CR 6.1
a. Met printouts) is sufficient for meeting the base requirement, but is
read-only basis.
b. Not met insufficient for higher SLs. Programmatic access is commonly used to
provide the audit log information to analysis mechanisms such as
security information and event management (SIEM). See relevant SRs in
Clauses 5, 6 and 9 regarding the creation of, protection of and access to
audit logs.

Verify in user or design documentation that the

Components shall provide
component provides programmatic access to audit
programmatic access to audit records
records by either using an application programming
Programmatic access to by either using an application IEC 62443-4-2:
x x x x FSA-CR 6.1 RE(1) interface (API) or sending the audit records to a No 3, 4
audit logs programming interface (API) or CR 6.1 RE(1)
centralized system. Record one of:
sending the audit records to a
a. Met
centralized system
b. Not met

Control system monitoring capability can be achieved through a variety

Verify that the supplier chose an industry resource that
of tools and techniques (for example, IDS, intrusion prevention system
provides recommendations for events to be monitored to
(IPS), protection from malicious code mechanisms and network
identify security breaches for the component. Verify that
monitoring mechanisms). As attacks become more sophisticated, these
the component is capable of being monitored for those
monitoring tools and techniques will need to become more sophisticated
events. For example failed authorization and access
Components shall provide the as well, including for example behavior-based IDS/IPS.
control attempts, failed input validation, and high value
capability to be continuously Monitoring devices should be strategically deployed within the control
transactions are identified in the OWASP Top 10
monitored using commonly accepted system (for example, at selected perimeter locations and near server
resource. Verify that monitoring can be done in a IEC 62443-4-2:
x x x x FSA-CR 6.2 Continuous monitoring security industry practices and No 2, 3, 4 farms supporting critical applications) to collect essential information.
continuous manner, and that the component is capable of CR 6.2
recommendations to detect, Monitoring mechanisms may also be deployed at ad hoc locations within
reporting of events in a time frame to permit mitigation of
characterize and report security the control system to track specific transactions.
a possible associated security breach associated with the
breaches in a timely manner. Monitoring should include appropriate reporting mechanisms to allow for
event. Verify that events are reported with content and
a timely response to events. To keep the reporting focused and the
format usable by a centralized analysis solution. Record
amount of reported information to a level that can be processed by the
one of:
recipients, mechanisms such as SIEM are commonly applied to correlate
a. Met
individual events into aggregate reports that establish a larger context in
b. Not met
which the raw events occurred.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 50 of 53
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

If the component has essential functions, verify that the threat

model for the component identifies DoS threats and their
mitigations using a systematic analysis method. Verify that the
Components shall provide the capability Components may be subjected to different forms of DoS situations.
supplier has test cases to show that the component maintains
to maintain essential functions when IEC 62443-4-2: When these occur the component should be designed in such a
x x x x FSA-CR 7.1 Denial of service protection essential functions when subjected to DoS attack. Verify that No 1, 2, 3, 4
operating in a degraded mode as the CR 7.1 manner that it maintains essential functions necessary for continued
those tests have passed. Record one of:
result of a DoS event. safe operations while in a degraded mode.
a. Met
b. Not met
c. Not relevant, if component has no essential functions

Verify that the threat model for the component identifies

information and/or message flooding types of DoS events.
Verify that the threat model indicates the capability to mitigate
the effects of these threats. Verify that the supplier has test
cases that have passed for these mitigations as required by
IEC 62443-4-1 requirement SVV-2. (This examination of test
cases can be done as part of validation activity in the SDA-C
Components shall provide the capability element of certification, for requirement SDLA-SVV-2-1 in
Manage communication load to mitigate the effects of information SDLA-312.) IEC 62443-4-2:
x x x x FSA-CR 7.1 RE(1) No 2, 3, 4
from component and/or message flooding types of DoS CR 7.1 RE(1)
events. Verify that the requirement SDLA-SVV-3A4 from SDLA-312 in
the SDA-C element of the certification has passed. This
requirement includes audit of testing under network traffic load
events.

Record one of:

a. Met
b. Not met

Verify using design documentation that usage of security

functions provided by the component to meet the IEC 62443-4-
2 standard are limited in such a way that high usage of these
Resource management (for example, network segmentation or priority
functions does not interfere with other component functions.
schemes) prevents a lower-priority software process from delaying or
Components shall provide the capability Examples include but are not limited to: high rates of user
interfering with the control system servicing any higher-priority
to limit the use of resources by security authentication attempts (possibly failed attempts), high audit IEC 62443-4-2:
x x x x FSA-CR 7.2 Resource management No 1, 2, 3, 4 software process. For example, initiating network scans, patching
functions to protect against resource logging rates, high rates of incoming data requiring CR 7.2
and/or antivirus checks on an operating system can cause severe
exhaustion. authenticity checking or outgoing data requiring integrity
disruption to normal operations. Traffic rate limiting schemes should
protections, series of physical attacks triggering a series of
be considered as a mitigation technique.
automated notifications. Record one of:
a. Met
b. Not met

The availability of up-to-date backups is essential for recovery from a

control system failure and/or mis-configuration. Automating this
function ensures that all required files are captured, reducing operator
overhead.
When designing to support a backup capability, consideration should
Verify that the supplier has test cases to show that the be given to information that will be stored in backups. Some of this
Components shall provide the capability
component provides the capability to provide component user information may contain cryptographic keys and other information that
to participate in system level backup
and component state information as part of a system level is protected through security controls while part of the system. Once
operations in order to safeguard the
backup operation, with no effect on the normal component IEC 62443-4-2: the information is placed into a backup it most likely will not have the
x x x x FSA-CR 7.3 Control system backup component state (user- and system- No 1, 2, 3, 4
operations. Verify this capability in user documentation. CR 7.3 same controls in place to protect it. Thus the component backup
level information). The backup process
Record one of: ability needs to include the mechanisms to support the necessary
shall not affect the normal component
a. Met protection of the information that is contained in the backup. This may
operations.
b. Not met include encryption of the backup, encryption of the sensitive data as
part of the backup procedure or not including the sensitive information
as part of the backup. If the backup is encrypted it is important not to
include the cryptographic keys as part of the backup but to backup the
cryptographic keys as part of a separate more secure backup
procedure.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 51 of 53
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify in user documentation that the component provides the

capability to validate the integrity of backed up information
prior to the initiation of a restore of that information. Verify via
Components shall provide the capability
testing by both deleting and modifying the data in the backed
to validate the integrity of backed up IEC 62443-4-2:
x x x x FSA-CR 7.3 RE(1) Backup integrity verification up information associated with some event. Attempt to restore Yes 2, 3, 4
information prior to the initiation of a CR 7.3 RE(1)
and verify that a problem is reported to the user before the
restore of that information.
restore to the component is initiated. Record one of:
a. Met
b. Not met

Component recovery and reconstitution to a known secure state

Verify in user documentation that a process is described for
means that all system parameters (either default or configurable) are
restoring a failed or suspected defective component to a
Components shall provide the capability set to secure values, security-critical patches are reinstalled, security-
known secure state. Verify that the expected state is described
Control system recovery and to be recovered and reconstituted to a IEC 62443-4-2: related configuration settings are reestablished, system
x x x x FSA-CR 7.4 in the user documentation. Perform the process and verify that Yes 1, 2, 3, 4
reconstitution known secure state after a disruption or CR 7.4 documentation and operating procedures are available, components
it achieves the documented state. Record one of:
failure. are reinstalled and configured with established settings, information
a. Met
from the most recent, known secure backups is loaded and the
b. Not met
system is fully tested and functional.

There is no component level

IEC 62443-4-2:
FSA-CR 7.5 Emergency power requirement associated with IEC No validation activity
CR 7.5
62443‑3‑3 SR 7.5.
The SDA-C certification element under requirements SDLA-
SG-3A and SDLA-SG-3D in document SDLA-312, requires
guidelines for security hardening and security configuration,
respectively.

If the evaluation for SDLA-SG-3A has passed, verify by test

that the user may view currently deployed network
configuration settings through a component interface. Verify
that the component may be configured through a component
interface to modify these settings, and in particular to meet
Components shall provide the capability any network configuration guidance found in the guidelines
to be configured according to that have met SDLA-SG-3A. These configuration settings are the adjustable parameters of the
recommended network and security control system components. By default the component should be
configurations as described in If the evaluation for SDLA-SG-3D has passed, verify by test configured to the recommended settings. In order for a component to
Network and security IEC 62443-4-2:
x x x x FSA-CR 7.6 guidelines provided by the control that the user may view the settings described in the guidelines Yes 1, 2, 3, 4 detect and correct any deviations from the approved and/or
configuration settings CR 7.6
system supplier. The component shall that have met that requirement, through a component recommended configuration settings, the component needs to support
provide an interface to the currently interface. Modify any settings that do not conform to the monitoring and control of changes to the configuration settings in
deployed network and security recommended settings. View and verify any changes in the accordance with security policies and procedures.
configuration settings. resulting configuration through the interface provided. Record
one of:
a. Met
b. Not met

If evaluations for either of the requirements SDLA-SG-3A and

SDLA-SG-3D in the SDA-C element of certification have not
passed, Record:
b. Not met

Verify that a report can be generated listing the currently

Components shall provide the capability
deployed security settings in a machine-readable format, by
Machine-readable reporting of to generate a report listing the currently IEC 62443-4-2:
x x x x FSA-CR 7.6 RE(1) generating and reading this report. Record one of: Yes 3, 4
current security settings deployed security settings in a machine- CR 7.6 RE(1)
a. Met
readable format.
b. Not met

Components are capable of providing a wide variety of functions and

Verify the user documentation specifies required ports and services. Some of the functions and services provided may not be
Components shall provide the capability protocols, and provides guidance for how to prohibit and/or necessary to support IACS functionality. Therefore, by default,
to specifically restrict the use of restrict the use of unnecessary functions, ports, protocols IEC 62443-4-2: functions beyond a baseline configuration should be disabled.
x x x x FSA-CR 7.7 Least functionality No 1, 2, 3, 4
unnecessary functions, ports, protocols and/or other services. Record one of: CR 7.7 Additionally, it is sometimes convenient to provide multiple services
and/or services. a. Met from a single component of a control system, but doing so increases
b. Not met the risk compared to limiting the services provided by any one
component.

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 52 of 53
 CSA-311 FR 7
ISA Security Compliance Institute
CSA-311 Component Security Assurance - Functional security assessment for components, Version 2.3

Software Application

Embedded Device

Network Device
Host Device Validation by
Capability
Independent Source of
Requirement ID Reference Name Requirement Description Validation Activity Security Rationale and Supplemental Guidance
Test Required Requirement
Level
(Yes/No)

Verify that the component provides the capability to identify its

Components shall provide the capability Components may bring their own set of components into the overall
presence and its associated properties for a control system
Control system component to support a control system component IEC 62443-4-2: control system. When this is the case then those components need to
x x x x FSA-CR 7.8 component inventory. Record one of: No 2, 3, 4
inventory inventory according to IEC 62443‑3‑3 CR 7.8 provide a mechanism to augment the overall component inventory
a. Met
[11] SR 7.8. which is compatible with IEC 62443‑2‑4 [8] SP.06.02.
b. Not met

Copyright © 2018-2022 ASCI - Automation Standards Compliance Institute, All rights reserved. Page 53 of 53