CIP IEC-62443-4-2 Foundational Requirement-1 Assessment details 

Revision History

Revision No	Date	Change description	Author	Reviewed by
001	2025-07-25	CIP IEC-62443-4-2 FR-1 assessment details	Dinesh Kumar	BV (Bureau Veritas)

1. Overview 

This document provides details of IEC-62443-4-2 FR-1 requirements for CIP assessment. The objective of the document is to share details with CIP users for requireements which are found Met and NA during CIP IEC-62443-4-2 assessment by BV.

This document can be used as reference by CIP users for IEC-62443-4-2 compliance for end products based on CIP.

2. CR-1.1 Human user identification and authentication [Met]

2.1 How CR-1.1 is met 

Users in CIP image

By default CIP image has root user. Additional users can be created by using adduser. Users are authenticated using mechanisms like password based authentication, public key based authentication.

2.2 Test and evidence for CR-1.1 

List of human user interfaces.
- RS422 (for serial communication).
List of human users capable of accessing the device using mentioned humar user interface.
- root (Default user, administrator).
- Other authenticated users can be created using adduser.

To meet this requirement test evidence logs of TC_CR1.1_1 & TC_CR1.1_2 are used IEC layer test.

2.3 CIP User action 

Review and make a list of users required for component operation
Identify details how users are authenticated, reuse CIP artefacts if default Linux method of user athnetication is used
Share test evidence for any additional user authenrication

3. CR-1.1 RE(1) Unique identification and authentication [Met]

3.1 How CR-1.1 RE(1) is met 

Users in CIP are created using adduser. adduser creates unique user IDs (UID) for each new user, hence all users are uniquely identified. Users are authenticated using standard PAM framework. In CIP libpam-modules package is installed for user authentication.

3.2 Test and evidence for CR-1.1 RE(1)

TC_CR1.1-RE1_1 test verifies that every user is authenticated and uniquely identified. Refer [1] for TC_CR1.1-RE1_1 test details.

3.3 CIP User action 

CIP users are recommended to use adduser for creating users on their component to ensure each user has unique ID. Additionally, CIP users can also use any other means of creating users which can ensure unique IDs.

4. CR-1.1 RE(2) Multifactor authentication for all interfaces [NA]

4.1 How CR-1.1 RE(2) is met 

Though CIP supports MFA by using Google authenticator package (libpam-google-authenticator). CIP produced evidence for the same. However, due to SL-3 and SL-4 requirements being out of scope for assessment. This requirement was considered as NA.

4.3 CIP User action 

MFA support should be added in the end product if SL-3 is the target for IEC-62443-4-2 compliance. CIP users can use libpam-google-authenticator or any other solutions based on the available options.

Selecting the right multi-factor authentication (MFA) methods depends on balancing security needs with user convenience and resource availability. Here are key considerations.

Risk assessment
User experience
Infrastructure and cost
Regulatory Compliance
Technology Integration

5. CR-1.2 Software process and device identification and authentication [NA]

5.1 Why CR-1.2 is NA for CIP 

Meeting this requirement requires application support for process and device identification and authentication. As CIP image is a minimal reference image hence there are no additional applications which can help to meet this requirement.

5.2 CIP User action 

CIP users should use their applications to meet this requirement. All components need to identify themselves. CIP recommends the usage of TPM generated ids or use certificates for device id, process pid. In some cases using combination of device id and process id will be useful to identify processed bound to specific device.

6. CR-1.3 Account Management [Met]

6.1 How CR-1.3 is met 

CIP provides all required commands and utilities for user account management. like useradd, usermod, userdel, passwd, groupadd. These tools can be used to add, modify, disable, enable and remove user accounts. In CIP, the user account management system is implemented directly and there are no tools like ldap-tools, samba which can help to integrate into higher level account management systems like LDAP, AD etc.

Following CIP IEC layer tests [1] are used to produce evidence for meeting this requirement.

TC_CR1.3_1: Verifies addition of user account
TC_CR1.3_2: Verifies modification of user account
TC_CR1.3_3: Verifies disabling & enabling of user account.

6.2 CIP User action 

If CIP user device is required to be part of large network or bigger system, additional tools installation would be required like LDAP etc. For local user account additional tools/packages are not required.

7. CR-1.4 Identifier management [Met]

7.1 How CR-1.4 is met 

This requirement is verified by showcasing that the account management in CIP support identifier management for users using identifiers like userid, username.etc which are unique.

TC_CR1.4_1 CIP IEC layer test [1] was used to produce evidence to meet this requirement.

7.2 CIP User action 

No further action required by CIP users as far as CIP supported method of user account management is used.

8. CR-1.5 Authenticator management [Met]

8.1 How CR-1.5 is met 

TC_CR1.5_2 CIP IEC layer test [1] verifies that authenticator change can be identified. TC_CR1.5_3 CIP IEC layer test [1] verifies that stored authenticator information (for ex: /etc/shadow) is protected and cannot be accessed by unprivileged users.

To enforce change of default authenticators for a specific user, the following command should be used.

$ sudo chage –mindays <minimum number of days between password change> –maxdays <maximum number of days between password change> –warndays <number of days before warning password expiration> <test_user>

TODO: Add reference for additional test steps shared with BV for verifying password is not transmitted in plaintext.

8.2 CIP User action 

CIP users need to identify policies for authenticator changes and implement them. If the authenticator is password then password policies should be defined. if authenticator is something else like certificate based authenticator, OTP based etc, accordingly policies must be defined.

9. CR-1.6 Wireless access management [NA]

9.1 Why CR-1.6 is NA 

The wireless access management requirements are network-component specific and can be found as requirements for network components. It’s like a parent requirement for network components and no action or supporting evidence required.

9.2 CIP User action 

None.

10. NDR-1.6 Wireless access management [NA]

10.1 Why NDR-1.6 is NA 

10.2 CIP User action 

11. NDR-1.6 RE(1) Unique identification and authentication [NA]

11.1 Why NDR-1.6 RE(1) is NA 

11.2 CIP User action 

12. NDR-1.13 Access via untrusted networks [NA]

12.1 Why NDR-1.13 is NA 

12.2 CIP User action 

13. NDR-1.13 RE(1) Explicit access request approval [NA]

13.1 Why NDR-1.13 RE(1) is NA 

13.2 CIP User action 

14. NDR-5.1 Network segmentation [NA]

14.1 Why NDR-5.1 is NA 

14.2 CIP User action 

15. NDR-5.1 Network segmentation [NA]

15.1 Why NDR-5.1 is NA 

15.2 CIP User action 

16. CR-1.7 Strength of password-based authentication [Met]

16.1 How CR-1.7 is Met 

Showcasing the password strength configuration capabilities provided by CIP through the configuration file as evidence and documenting the password strength policy followed in CIP in user manual.

Testing whether the configured password strength setting is activated by changing the existing password of a user to strings with different character classes and confirming the test passes only if the new password meets the configured password strength settings.

TC_CR1.7_1 CIP IEC layer test [1] is used to produce evidence for this requirement.

CIP user manual. provides additional details about password policy configuration.

16.2 CIP User action 

CIP password policy configuration file. provides various options to create password policies. users can configure password policies based on their requirement for business uses cases as well as compliance.

17. CR-1.8 Public key infrastructure certificates [TBD]

17.1 How CR-1.7 is TBD 

To be updated once BV confirms it.

17.2 CIP User action 

18. CR-1.9 Strength of public key-based authentication [TBD]

18.1 How CR-1.9 is TBD 

To be updated once BV confirms it.

18.2 CIP User action 

19. CR-1.9 RE(1) Hardware security for public key-based authentication [NA]

19.1 Why CR-1.9 RE(1) is NA 

This requirement expects critical keys to be stored securely in secure storage. CIP on M-COM used TPM as secure storage. Similarly all Secure boot keys are stored in UEFI storage. The evidence for the same can be produced.

However, due to this requirement being SL-3, it was out of scope for the assessment hence declared as NA.

19.2 CIP User action 

If CIP users end product targets to comply for SL-3. evidence for secure storage for critical keys shall be produced.

20. CR-1.10 Authenticator feedback [Met]

20.1 How CR-1.10 is Met 

This requirement expects any feedback for authenticator used for authentication should be obscured. e.g. when user enters password, it’s shown as obscured by default.

In CIP, following evidence were produced during audit.

showcasing that authentication process is obscured, by providing evidence (screenshot) that password is not visible while being entered by the user during authentication.
Capturing the output while entering wrong username and user password and confirming that there is no time difference in feedback.
Measured the time difference between a successful and failure login which was 1 to 3 ms on M-COM device.
Confirmed that WEP is disabled by showcasing that wireless is disabled at /sys/class/net/$dev/

TC_CR1.10 CIP IEC layer test [1] is used to produce evidence for this requirement.

20.2 CIP User action 

Based on the authentication method used, provide similar evidences where authentication feedback is obscured and in case of successful and failed login there is no significant time difference.

21. CR-1.11 Unsuccessful login attempts [Met]

21.1 How CR-1.11 is Met 

In CIP, following methods are used to meet this requirement.

Attempting configured number of unsuccessful logins which locks the account and confirming that the account is locked.
Attempting configured number of unsuccessful logins, confirmed that the account is locked. After waiting till the configured limit, re-checking if the account has been unlocked.

TC_CR1.11_1 & TC_CR1.11_2 CIP IEC Layer tests [1] are used to produce evidence to meet this requirement.

21.2 CIP User action 

CIP users can reuse security configuration from CIP to meet this requirement. However, in case of different authenticator other than password, different configuration would be required.

22. CR-1.12 System use notification [NA]

22.1 Why CR-1.12 is NA 

System use notification can not be supported by CIP platform. System use notification involves displaying various types of messages in order to inform user about the intended use of the product as well as any consequences arising due to illegal use of the system e.g.

This system use is being monitored and recorded, any misuse may result in some penalty.
The system is owned by someone etc.

These notifications or banners also may vary based on use cases, industries and regions.

Network component requirement details to be updated in future.
PKI related requirement details to be updated later