CRA integrity is concerned with whether data, commands, software and configuration remain trustworthy and protected from unauthorised change. Manufacturers should identify which product elements could create cybersecurity risk if modified, select appropriate access-control and cryptographic protections, detect relevant corruption and retain evidence showing that integrity protections work across storage, transmission, execution and update paths.
Annex I Protects More Than Data Integrity
Annex I Part I point 2(f) covers the integrity of stored, transmitted or otherwise processed personal or other data, but it also expressly reaches commands, programs and configuration. The requirement therefore concerns the trustworthiness of important product state and behaviour, not only whether database records remain unchanged. An unauthorised change to an executable, firmware image, security policy, administrative configuration or control command can create serious cybersecurity consequences even where no confidential information is disclosed. The manufacturer should identify which elements require protection and how an attacker, compromised component or unintended process could modify them.
- Identify security-relevant data.
- Identify executable software and firmware.
- Identify security-sensitive commands.
- Identify configuration that affects cybersecurity.
- Assess consequences of unauthorised modification.
Integrity and Confidentiality Are Different Security Outcomes
Confidentiality protects information from unauthorised disclosure. Integrity protects information and product state from unauthorised modification. The two can be related but they are not interchangeable. Encrypting information can prevent disclosure while providing no protection against certain forms of undetected modification if the cryptographic construction does not authenticate the data. A digital signature can prove authenticity and integrity without making the signed information confidential. Manufacturers should therefore avoid using a single statement such as data is encrypted as evidence for both Annex I points. The integrity analysis should identify how unauthorised modification is prevented, detected or rejected.
- Confidentiality addresses disclosure.
- Integrity addresses unauthorised change.
- Some cryptographic mechanisms support both outcomes.
- Maintain separate Annex I mappings and tests.
Software and Firmware Integrity Can Be Critical
Products can become compromised when an attacker substitutes, modifies or injects code. Depending on the architecture and risk assessment, manufacturers can use signed software packages, verified boot processes, package signatures, protected update channels, integrity measurements or other mechanisms to help ensure that only authorised software executes. The appropriate control depends on the product. A system that can execute privileged remote updates can require different assurance from a local application installed through a trusted platform. Integrity design should also consider rollback because installation of an authentic but vulnerable older version can undermine the intended security state even if the package itself carries a valid signature.
- Protect software distribution.
- Verify software before installation or execution where appropriate.
- Protect firmware and boot chains where relevant.
- Consider downgrade and rollback risks.
- Retain evidence for update and release verification.
Configuration Integrity Protects the Security Baseline
Configuration often controls authentication, privileges, network exposure, logging, cryptography and update behaviour. Unauthorised changes can therefore weaken multiple security properties at once. Manufacturers should identify security-sensitive configuration values and control who or what can alter them. Depending on the product, useful controls can include authorisation, signed configuration, protected storage, change auditing, integrity checks or policy validation. The design should also distinguish an authorised administrator making a permitted change from an attacker modifying the configuration outside the intended management path. Where configuration can be imported or synchronised from another system, the integrity of that path should be considered as well.
- Identify security-sensitive configuration.
- Restrict modification to authorised actors.
- Validate imported configuration.
- Detect unexpected changes.
- Preserve evidence of important administrative changes.
Command Integrity Matters for Connected Products
Connected products can receive commands through APIs, messaging protocols, local interfaces, management channels or remote services. An attacker who can alter a command in transit, replay a previous command or inject an unauthorised instruction can change product behaviour without modifying stored data. Product teams should therefore consider command authenticity, integrity, sequencing and replay resistance where those threats are relevant. Authentication of the sender is important, but authentication alone does not necessarily prove that the command remained unchanged after creation. Protocol design should connect identity, authorisation and integrity so that the receiving product can determine whether a security-relevant instruction should be trusted.
- Authenticate security-relevant command sources.
- Protect commands against modification.
- Consider replay protection.
- Validate command structure and authorisation.
- Test tampered and duplicated command scenarios.
The Product Should Report Relevant Corruptions
Annex I point 2(f) also requires reporting on corruptions. The appropriate mechanism depends on the product and its cybersecurity risk assessment. Reporting can involve local diagnostics, administrative events, alarms, logs or another mechanism that provides useful information when protected data, software or configuration fails an integrity check. The product should avoid producing so much low-value information that meaningful corruption events become unusable. Corruption reporting should also avoid exposing sensitive data unnecessarily. Teams should identify which integrity failures have cybersecurity relevance, what information is needed to investigate them and who should receive or access that information.
- Identify security-relevant integrity failures.
- Surface meaningful corruption events.
- Protect corruption records from unauthorised modification.
- Avoid leaking sensitive information.
- Verify that reporting works when integrity checks fail.
Backups and Recovery Also Need Integrity Protection
A product can protect its live data while remaining vulnerable through corrupted backups, recovery images or configuration archives. If recovery restores attacker-modified content, the compromise can survive a reset or incident response process. Manufacturers should therefore consider the integrity of recovery assets where they form part of the product or its normal support process. Controls can include authenticated backups, protected recovery images, version validation and verification before restoration. The exact design depends on the product boundary and deployment model, but recovery should not bypass security checks applied during normal operation.
- Protect recovery images and backups.
- Validate content before restoration.
- Control access to backup modification.
- Test recovery from tampered artefacts.
- Document external recovery dependencies.
Evidence for CRA Integrity Requirements
Evidence should show which data, programs, commands and configuration require integrity protection, which threats were considered, which controls were selected and how they were verified. Useful material can include architecture diagrams, trust-boundary documentation, software signing design, update verification records, access-control specifications, command protocol analysis, configuration-protection tests, corruption-detection tests and release evidence. The record should identify the relevant product version and configuration. Where integrity depends on an external platform or service, the dependency and security assumption should be explicit in the product risk assessment.
- Integrity threat analysis.
- Software and firmware verification design.
- Configuration protection evidence.
- Command integrity controls.
- Corruption-reporting tests.
- Version-specific verification results.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.