CIP IEC-62443-4-2 Foundational Requirement-4 & 5 Assessment details 

Revision History

Revision No	Date	Change description	Author	Reviewed by
001	2025-08-12	CIP IEC-62443-4-2 FR-4 & FR-5 assessment details	Dinesh Kumar	BV (Bureau Veritas)
002	2025-09-08	Added details for CR-4.1	Dinesh Kumar	BV (Bureau Veritas)
003	2025-09-10	Added details for CR-5.2	Adithya Balakumar	BV (Bureau Veritas)
004	2025-09-10	Added details for CR-5.1, CR-5.3, NDR-5.3, CR-5.4	Pasquale Nieddu	BV (Bureau Veritas)
005	2025-11-12	Fix minor formatting issues to resolve CI warnings	Adithya Balakumar	BV (Bureau Veritas)
006	2025-12-29	Additional information for CR 4.1	Adithya Balakumar	BV (Bureau Veritas)

1. Overview 

This document provides details of IEC-62443-4-2 FR-4 & FR-5 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-4.1 Information confidentiality [Met]

2.1 How CR-4.1 is Met

CIP provides required capabilities through various mechanisms

Data in Transit Protection:

OpenSSL (/usr/bin/openssl)

SSH (/usr/bin/ssh)

SSL libraries:

/usr/lib/x86_64-linux-gnu/libssl.so.3

/lib/x86_64-linux-gnu/libcrypto.so.3

Data at Rest Protection:

Kernel crypto support (via /proc/crypto) Base cryptographic libraries present

The image fulfills the basic requirements for IEC 62443-4-2 confidentiality through built-in encryption capabilities and secure communication protocols.

In CIP the tpm2 device is used for encryption and decryption of data partitions (/home and /var). The encrypted partitions in the CIP Security image is a LUKS partition and uses a TPM to secure the passphrase on the device. CIP has documentation that explains the implementation.

During CIP IEC-62443-4-2 assessment, it was pointed out by Certification Body that port 68 on M-COM remains open which can be exploited by malicious users. However, CIP members clarified as CIP and M-COM is a reference base platform hence DHCP information is considered as non-confidential.

2.2 CIP User action

CIP users shall use mechanisms to either disable port 68 or block it by using available security mechanisms like nftable or similar ones.

3. CR-4.2 Information persistence [Met]

3.1 How CR-4.2 is Met

When a device or component is decommissioned from active services. It may have crirical information in it’s persistent memory. To meet this requirement, evidence needs to be produced so all critical information is removed from the device so it’s not recoverables by anyone later.

The requirement is fullfilled with following tools

shred: It securely overwrites files multiple times; data recovery practically impossible;
dd: Built-in Linux command low-level block device operations; can overwrite entire storage devices Standard utility

These two tools provide the capability to erase information from components. These standard tools ensures that users (root/sudo) can permanently remove data if needed.

CIP also supports factory-reset feature starting from isar-cip-core V1.9 release. Refer details at factory-reset document.

3.2 CIP User action

Following mechanisms are available for CIP users to meet this requirement.

Use tools shred and dd
Support factory-reset document

4. CR-4.2 RE(1), CR-4.2 RE(2) Erase of shared memory resources, Erase verification [NA]

4.1 Why CR-4.2 RE(1), CR-4.2 RE(2) are NA

These requirements are not evaluated due to SL-3 security level.

4.2 CIP User action

Investigate and support required tools which supports erasing shared memory resources on the device. Once any shared memory resource is deleted, verification of erasure should be supported as well.

5. CR-4.3 Use of cryptography [Met]

5.1 How CR-4.3 is Met

CIP uses openssl package as primary tool to meet cryptographic requirements. In addition, there are NIST standard which recommend various cryptographic practices. There is a summary of practices in NIST standards in CIP use of Cryptography document.

5.2 CIP User action

CIP users are recommended to follow NIST standards for more detailed undertanding.

Use Secure Cipher document. for more detailed information for using secure ciphers and TLS usage.

6. CR 5.1, NDR-5.1 Network segmentation [NA]

6.1 Why CR 5.1, NDR-5.1 is NA

This requirement is application-specific. Network segmentation is typically implemented by the application using networking protocols supported by switches and routers, rather than being a direct feature of the CIP base platform itself.

6.2 CIP User action

CIP users are responsible for implementing network segmentation within their applications. This involves utilizing appropriate networking protocols and configuring switches and routers to achieve the desired segmentation for their specific use case.

7. CR 5.2 Zone boundary protection [NA]

7.1 Why CR 5.2 is NA

This requirement is component specific hence does not need any evidence. Component specific requirements are addressed in respective sections.

8. NDR 5.2, NDR 5.2 RE(1), NDR 5.2 RE(2), NDR 5.2 RE(3) Zone boundary protection, Deny all and permit by exception, Island mode, Fail close [NA]

8.1 Why NDR 5.2 Zone boundary protection is NA

This requirement targets devices like Routers, Security gateways, Switches with capabilities like routing between zones, traffic inspection etc. which are application specific and require network device hardware. At a platform level CIP cannot support these requirements.

8.2 Why NDR 5.2 RE(1) Deny all and permit by exception is NA

This requirement can be met using nftables. But since the parent requirement (NDR 5.2) is NA, this requirement is also declared NA

8.3 Why NDR 5.2 RE(2) Island mode, NDR 5.2 RE(3) Fail close are NA

These requirements are not evaluated due to SL-3 security level.

8.4 CIP User action

CIP as a platform provides the OS level features that are needed to meet the requirements, but CIP users shall investigate their end device for the required hardware capabilities and the supporting software to meet these requirements.

9. CR 5.3, NDR 5.3 General-purpose person-to-person communication restrictions [NA]

9.1 Why CR 5.3, NDR 5.3 is NA

This is an application-specific requirement. CIP, as a platform, does not enforce restrictions on general-purpose, person-to-person communication.

9.2 CIP User action

CIP users can meet this requirement by blocking specific ports that are used by applications supporting the exchange of general-purpose, person-to-person messages. This can be achieved using available security mechanisms like nftables or similar tools.

10. CR 5.4 Application partiontiong [NA]

10.1 Why CR 5.4 is NA

This requirement is application-specific. The implementation of application partitioning depends on the unique architecture and security needs of the end product’s applications and is not directly handled by the CIP base platform.

10.2 CIP User action

CIP users are responsible for assessing and implementing application partitioning strategies based on their specific application design and security requirements.