Annex I, Part I, Req 2f: Integrity of Data and Code in Software
Ensuring that the data and the code within your software are trustworthy and haven't been improperly altered is a core requirement of the EU Cyber Resilience Act (CRA). It specifies that products with digital elements shall, where applicable, "protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions" (Annex I, Part I, Point 2f).
What Data and Code Integrity Means
- Data Integrity: Stored or transmitted information (user data, game state, financial transactions, configurations) must be accurate and complete, and protected from unauthorized changes.
- Code/Program Integrity: The software executables, scripts, and libraries themselves should be protected from unauthorized modification to prevent malicious code injection or tampering that could alter functionality or compromise security.
- Command Integrity: Commands issued by or to your software should be protected to ensure they are legitimate and haven't been altered in transit or at rest.
- Configuration Integrity: Settings and configuration files must be protected from unauthorized changes that could lead to insecure states.
Mechanisms for Protection
- Hashing and Digital Signatures: To verify that data or code hasn't changed. Code signing for your application and its updates is a key example.
- Access Controls: Strict controls on who or what can modify data or configuration files.
- Input Validation: To prevent malicious inputs from corrupting data or tricking the software.
- Secure Boot / Trusted Execution Environments (for some software): To ensure only authorized code runs.
- Checksums or CRCs: For detecting accidental data corruption.
Reporting Corruptions
The requirement also includes the ability to "report on corruptions." This means your software should ideally be able to detect if its data, code, or configuration has been corrupted or illicitly modified and alert the user or an administrator.
Key Takeway
Under Annex I, Part I, Point 2f of the CRA, your software must actively protect the integrity of its data, its own code, commands, and configurations against unauthorized modification. It should also be able to report detected corruptions.