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)

002

2025-07-25

Added details for NDR-1.6, NDR-1.6 RE(1), NDR-1.13, NDR-1.13 RE(1), CR-1.8, CR-1.9 and removed NDR 5.1

Pasquale Nieddu

BV (Bureau Veritas)

003

2025-11-12

Update CR 1.9 and fix minor CI warnings

Adithya Balakumar

BV (Bureau Veritas)

004

2025-11-21

Update NDR1.13 for user action based on BV feedback.

Dinesh Kumar

TBR

005

2026-03-05

Update references of test evidences for CR 1.08 and 1.09.

Adithya Balakumar

TBR

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.2 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.

  1. Risk assessment

  2. User experience

  3. Infrastructure and cost

  4. Regulatory Compliance

  5. 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.

  1. TC_CR1.3_1: Verifies addition of user account

  2. TC_CR1.3_2: Verifies modification of user account

  3. 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>

Additionally, the component can be configured to not transmit the authenticators in plain text. TC_CR1.5 CIP IEC layer test demonstrates the same.

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, NDR-1.6 Wireless access management & NDR-1.6 RE(1) Unique identification and authentication [NA]

9.1 Why these requirements are NA for CIP

These requirements are marked as “Not Applicable” (NA) for the CIP platform itself. CIP is a minimal embedded Linux platform. It can provide client-side tools like wpa_supplicant, but it doesn’t offer a full solution for wireless access management or network user authentication.

A complete solution needs a multi-component system beyond the CIP platform. This includes server-side AAA solutions (e.g., RADIUS servers), the necessary network infrastructure, and product-specific user authorization. These requirements are mainly for complete network devices, not for a basic system platform.

9.2 CIP User action

If your end product needs wireless access management and authentication, CIP users should:

  • Implement Server-Side Solutions: Integrate external components like RADIUS servers for a full AAA solution.

  • Use Client-Side Tools: Use available client-side tools on CIP (e.g., wpa_supplicant) to start authentication.

  • Define Product-Specific Authorization: Set up user authorization at the product level based on your application and network design.

  • Provide Necessary Infrastructure: Ensure the required network (hardware) infrastructure is in place for secure wireless communication.

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

10.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.

10.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.

11. CR-1.8 Public key infrastructure certificates [Met]

11.1 How CR-1.8 is met

The CIP platform meets this requirement by providing the necessary components to support Public Key Infrastructure (PKI) for secure authentication.

  • Included Package: The openssh-server package is included in CIP, enabling secure SSH key-pair based authentication.

  • Verification: This functionality has been verified through a dedicated test case (TC_CR1.8_1). This test successfully demonstrated authentication using SSH key pairs by creating a key pair, copying the certificate to a remote user, and confirming successful login.

  • Performance: Performance tests have shown that the time for each PKI operation is less than 0.5 seconds, meaning the impact on operational performance is trivial.

  • Standard Compliance: When public key infrastructure (PKI) is utilized, this component provides the capability to interact and operate in accordance with IEC 62443-3-3 SR1.8.

Evidences for the assessment were provided with the use of gencmpclient installed in the CIP security image. This tool was chosen for its ease of use and high level API support on top of openssl which is useful for application developers. However, the tool is not available as a standard debian package yet.

Alternatively, the requirements set out by CR-1.8 can also be verified using openssl cmp which is openssl’s implementation for a CMP client. Refer to the linked document for test evidences with openssl cmp client.

11.2 CIP User action

CIP users can leverage the platform’s capabilities to implement PKI-based authentication in their products:

  • Implement PKI: Utilize CIP’s openssh-server, openssl and related tools for secure, PKI-based authentication (e.g., SSH key pairs). Although openssl is sufficient to prove compliance, CIP users can also include the gencmpclient in their image to implement PKI. When compared to openssl, it provides a high level API suitable for application developers and also makes automation of certificate management easier.

  • Configure for Compliance: Configure your product to leverage these capabilities to meet the requirements of IEC 62443-3-3 SR1.8.

12. CR-1.9 Strength of public key-based authentication [Met]

12.1 How CR-1.9 is Met

The CIP platform meets this requirement by providing the necessary components to validate certificates by checking signatures, certificate chains, revocation status, private key control, identity mapping, and algorithm compliance.

  • Included Package: The openssl package is included in CIP, enabling validation of certificates.

  • Verification: This functionality has been verified through dedicated test cases (TC_CR1.9_1 to TC_CR1.9_6). These tests successfully demonstrate the capabilities of certificate validation.

Evidences for the the requirements set out by CR-1.9 were provided with the use of openssl. Refer to the linked document for test evidences with openssl.

12.2 CIP User action

CIP users can leverage the platform’s capabilities to ensure the strength of PKI-based authentication in their products:

  • Implement PKI: Utilize CIP’s openssh-server, openssl and related tools for secure, PKI-based authentication (e.g., SSH key pairs). CIP users can also include the gencmpclient in their image to implement PKI and benefit from the advantages of using gencmpclient over openssl as described in CR-1.08.

  • Configure for Compliance: Configure your product to leverage these capabilities to meet the requirements of IEC 62443-3-3 SR1.8.

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

13.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.

13.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.

14. CR-1.10 Authenticator feedback [Met]

14.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.

  1. showcasing that authentication process is obscured, by providing evidence (screenshot) that password is not visible while being entered by the user during authentication.

  2. Capturing the output while entering wrong username and user password and confirming that there is no time difference in feedback.

  3. Measured the time difference between a successful and failure login which was 1 to 3 ms on M-COM device.

  4. 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.

14.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.

15. CR-1.11 Unsuccessful login attempts [Met]

15.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.

15.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.

16. CR-1.12 System use notification [NA]

16.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.

  1. This system use is being monitored and recorded, any misuse may result in some penalty.

  2. The system is owned by someone etc.

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

16.2 CIP User action

CIP user can follow the suggestions as mentioned in the section for the reason being NA.

17. CR-1.13 Access via untrusted networks [NA]

17.1 Why CR-1.13 is NA

This is a network component specific requirement and is covered in each component specific section.

17.2 CIP User action

No action.

18. NDR-1.13 Access via untrusted networks [NA]

18.1 Why NDR-1.13 is NA for CIP

This requirement is “Not Applicable” (NA) for the CIP platform itself. CIP provides a basic embedded Linux operating system. CIP does not implement any features which can support monitoring of device access from untrusted networks. The platform offers tools for authentication, authorization, and logging, but it does not provide any mechanism to montor access via untrusted networks.

18.2 CIP User action

Access of networks should be monitored using network security software and tools, only used ports should be open and unused ports should be blocked to avoid unauthorized access.

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

19.1 Why NDR-1.13 RE(1) is NA for CIP

This requirement is “Not Applicable” (NA) for the CIP platform itself. CIP provides a basic embedded Linux operating system. “Explicit access request approval” is a feature that belongs to the application or product built on CIP, not the platform itself. The platform offers tools for authentication, authorization, and logging, but it does not define or manage specific approval workflows for access requests. These workflows are part of the end product’s business logic or security design.

19.2 CIP User action

CIP Users can take following measures to meet this requirement.

  • Identify workflows which require explicit approval

  • Define required roles which can be assigned required privileges for approval

  • Map roles in specific business application to specific privileges required for explicit approval

20. CR-1.14 Strength of symmetric key-based authentication [NA]

20.1 Why CR-1.14 is NA

CIP does not store or keep any permanent symmetric or assymetric keys. It’s simply because it’s a generic platform. For testing and development temporary keys are generated and discarded.

However, CIP has capabilities to use both types of keys via support of openssl and other cryptographic support.

20.2 CIP User action

CIP users should identify symmetric or assymetric keys installed in the system, review the requirement for CR-1.14 and share evidence

References

  1. CIP IEC layer test.

  2. IEC-62443-4-2 FR details.