CRA incident-impact reduction is a defence-in-depth requirement. Secure development should try to prevent vulnerabilities, but the product should also contain mechanisms that reduce damage if exploitation succeeds. Depending on the architecture, this can include least privilege, process isolation, sandboxing, memory protections, compartmentalisation, privilege separation and controls that make lateral movement or persistence more difficult.
Annex I Assumes That Incidents Can Still Occur
Annex I Part I point 2(k) requires products with digital elements to be designed, developed and produced to reduce the impact of an incident using appropriate exploitation-mitigation mechanisms and techniques. This requirement is important because it recognises that secure development cannot guarantee that exploitation will never occur. A product can pass security testing and still later encounter a newly discovered vulnerability, supply-chain weakness or unexpected attack technique. Manufacturers should therefore consider what happens after an attacker gains an initial foothold and whether the architecture limits the damage that foothold can cause.
- Assume some controls can fail.
- Identify consequences of successful exploitation.
- Limit privileges available after compromise.
- Limit reachable assets and components.
- Verify containment mechanisms.
Incident Prevention and Incident Impact Are Different Questions
Many security activities focus on preventing exploitation through secure coding, vulnerability remediation, authentication and attack-surface reduction. Point 2(k) asks a second question: if exploitation occurs anyway, how much can the attacker achieve? The product can therefore need both preventive and limiting controls. Input validation can prevent one vulnerability, while sandboxing can reduce the consequences if another vulnerability remains. Removing an unnecessary interface can prevent an attack path, while privilege separation can constrain an attacker who compromises a required interface. A strong Annex I mapping keeps these objectives distinct even where one technical measure contributes to several requirements.
- Prevent exploitation where possible.
- Assume preventive controls can fail.
- Design limits on post-exploitation capability.
- Map controls to their specific security outcomes.
Least Privilege Can Reduce the Blast Radius
A component that runs with more privilege than it needs gives an attacker those privileges if it is compromised. Least privilege can therefore reduce incident impact by limiting access to files, devices, network functions, credentials and administrative operations. Product teams should examine service accounts, operating-system permissions, cloud permissions, database roles and device privileges. The goal is not to create complexity for its own sake but to ensure that a compromised component cannot automatically control unrelated high-value assets. Privilege decisions should be documented at architecture level rather than left entirely to deployment defaults.
- Limit process privileges.
- Limit filesystem permissions.
- Limit network privileges.
- Limit cloud and service permissions.
- Review privileged paths during product changes.
Isolation and Sandboxing Can Contain Exploitation
Isolation mechanisms can separate components with different trust levels or risk profiles. Depending on the platform, this can include process isolation, containers, sandboxes, virtual machines, hardware security boundaries or language-level isolation. The objective is to make compromise of one component less likely to become compromise of the whole product. A parser that handles untrusted files, for example, can be a candidate for stronger isolation than a component that never processes attacker-controlled input. Manufacturers should assess whether the isolation boundary is meaningful and test whether an attacker can escape it through shared resources, excessive privileges or exposed management interfaces.
- Identify high-risk components.
- Separate trust domains where appropriate.
- Restrict communication across boundaries.
- Minimise shared privileged resources.
- Test containment and escape paths.
Memory and Execution Protections Can Increase Exploitation Difficulty
Software platforms can provide exploit-mitigation mechanisms that make certain classes of vulnerabilities harder to turn into reliable compromise. Depending on the product, these can include address-space randomisation, non-executable memory, stack protections, control-flow protections, memory-safe languages, hardened allocators or compiler security options. Annex I point 2(k) does not prescribe a universal list of technologies, so manufacturers should choose mechanisms appropriate to the product, platform and cybersecurity risks. Where a platform provides relevant protections, production builds should not accidentally disable them through development or compatibility settings.
- Review compiler and platform security protections.
- Use memory-safe approaches where appropriate.
- Verify production build settings.
- Document unavailable or disabled mitigations.
- Test realistic exploitation scenarios where justified.
Secrets and Credentials Should Not Automatically Fall With One Component
A compromised component can become much more powerful if it has direct access to long-lived administrative credentials, cryptographic keys or tokens for unrelated services. Product architecture can reduce incident impact by separating secrets, narrowing credential scope and avoiding unnecessary sharing between components. Hardware-backed or operating-system key protection can help in some architectures, while service-specific credentials and short-lived tokens can reduce lateral movement in others. The correct design depends on the product, but the risk assessment should consider what credentials an attacker would obtain after compromising each exposed component.
- Limit credential scope.
- Avoid unnecessary secret sharing.
- Separate high-value keys where appropriate.
- Use short-lived credentials where suitable.
- Model credential exposure after component compromise.
Compartmentalisation Can Limit Lateral Movement
Large products can contain many services, plugins or subsystems. If every component trusts every other component, compromise can spread quickly. Compartmentalisation establishes boundaries between product areas so that access from one part does not automatically grant access to another. This can involve network segmentation, service authentication, permission boundaries, separate data stores or explicit API authorisation. The architecture should focus on meaningful security boundaries rather than cosmetic separation. Manufacturers should test whether a compromised low-trust component can reach administrative functions or high-value data through undocumented internal paths.
- Define component trust levels.
- Restrict internal service access.
- Authenticate important service-to-service communication.
- Protect high-value data stores.
- Test lateral-movement paths.
Exploit Mitigation Should Work With Availability and Recovery
Containment mechanisms can affect availability. Terminating a compromised process may protect the rest of the system while temporarily removing one function. Isolation can also influence recovery architecture. Manufacturers should therefore coordinate point 2(k) incident-impact controls with the availability and resilience requirements in points 2(h) and 2(i). The objective is not necessarily to keep every compromised function running. In some cases, stopping or isolating a function can be the safer behaviour while preserving essential functions elsewhere. The cybersecurity risk assessment should document these trade-offs and the intended response when exploitation is detected or suspected.
- Define safe containment behaviour.
- Preserve essential functions where appropriate.
- Avoid uncontrolled cascading failure.
- Coordinate containment and recovery.
- Test incident-state transitions.
Exploit Mitigation Needs Security Testing
A mitigation mechanism should be verified rather than assumed from architecture diagrams. Testing can include attempting privilege escalation, sandbox escape, access to restricted resources, lateral movement, credential theft or execution outside intended boundaries. Where compiler or operating-system protections are relied on, build and deployment checks can confirm that they are enabled in production. Threat modelling can identify which component compromises deserve the deepest testing. Test evidence should identify the product version and security configuration because mitigation behaviour can change with build settings, platform versions and deployment permissions.
- Test privilege boundaries.
- Test isolation boundaries.
- Test access to restricted resources.
- Verify production mitigation settings.
- Record version-specific results.
Evidence for CRA Incident-Impact Reduction
Useful evidence can include architecture diagrams showing trust boundaries, privilege matrices, sandbox specifications, compiler-hardening configuration, threat models, credential-scope documentation, lateral-movement analysis and exploitation tests. The manufacturer should be able to connect each important compromise scenario to controls that limit the resulting impact. Evidence should also show that the controls exist in the production product rather than only in development plans. Where mitigation relies on operating-system or hardware capabilities, the dependency and required configuration should be explicit in the technical documentation.
- Trust-boundary architecture.
- Privilege and permission matrix.
- Isolation and sandbox design.
- Exploit-mitigation build configuration.
- Credential-containment evidence.
- Post-exploitation security testing.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.