CRA Exploit Mitigation Requirements: Reducing the Impact of a Successful Attack

The Cyber Resilience Act (CRA) requires manufacturers, where applicable and based on the cybersecurity risk assessment, to design products so that the impact of security incidents can be limited through appropriate exploitation-mitigation mechanisms and techniques. Annex I Part I point 2(k) therefore adds a second line of defence after prevention: assume that some vulnerabilities or attack paths may still be exploited and design the product so that one successful step does not automatically become full compromise.

For product teams, this means identifying realistic exploitation paths, limiting privilege and blast radius, protecting critical boundaries, defining safe failure behaviour, and testing whether the released product contains an incident when one control is bypassed.

Exploit mitigation is not the same as vulnerability prevention

Prevention tries to stop exploitation from happening. Exploit mitigation assumes prevention may fail and asks what happens next.

Examples of preventive controls include removing unnecessary interfaces, fixing known vulnerabilities, validating input and enforcing authentication. Mitigation controls reduce the consequence of a successful exploit by restricting what an attacker can do after crossing one boundary.

The distinction matters because no single preventive control is perfect. A memory-safety flaw, compromised credential, malicious component, logic error or exposed service can create an initial foothold. The product architecture should make that foothold difficult to expand into control of unrelated components, sensitive data or critical functions.

Use the cybersecurity risk assessment to scope mitigation

Annex I Part I applies detailed product requirements on the basis of the manufacturer's cybersecurity risk assessment and where applicable. There is therefore no single mandatory exploit-mitigation stack for every product.

A useful scoping exercise should identify:

• components that process untrusted input;
• privileged services and administrative functions;
• security-critical processes;
• code that crosses trust boundaries;
• remote-facing interfaces;
• parsers, protocol handlers and file-processing components;
• update and recovery functions;
• hardware interfaces that expose privileged access;
• third-party components with elevated privileges; and
• dependencies whose compromise could affect several product functions.

For each area, document the plausible exploitation path, the consequence of compromise, the containment objective and the selected mitigation.

Reduce privilege and blast radius

A central mitigation principle is to ensure that compromise of one component does not automatically grant authority over the whole product.

Depending on the architecture, useful techniques can include:

• least-privilege service accounts;
• separate processes for high-risk parsers or network services;
• operating-system sandboxing;
• mandatory access-control policies;
• capability-based restrictions;
• container or virtual-machine isolation where appropriate;
• separation between user-facing and administrative functions;
• hardware privilege separation;
• restricted access to security-sensitive files and devices; and
• narrowly scoped API permissions.

The objective is not isolation for its own sake. It is to define which resources a compromised component actually needs and prevent access to unrelated functions.

Protect critical security boundaries

Some boundaries deserve stronger protection because crossing them changes the security state of the product.

Examples include:

• normal user to administrator;
• application process to operating-system privilege;
• network service to local system control;
• normal boot path to recovery mode;
• unsigned or untrusted code to executable state;
• ordinary storage to secret or credential storage;
• application logic to update authority; and
• local product control to remote management functions.

For each critical boundary, define how the product authenticates, authorises and validates the transition. Exploit mitigation should make unintended transitions fail rather than silently broaden access.

Use memory and control-flow mitigations where relevant

Software products that execute native code may benefit from platform-level exploit mitigations such as address-space randomisation, non-executable memory, stack protection, control-flow protections or hardened allocation behaviour.

The CRA does not prescribe these specific mechanisms in Annex I. Their relevance depends on the technology stack and risk assessment.

The practical requirement is to avoid treating compiler and operating-system hardening as accidental defaults. Where such controls materially reduce exploitability or post-exploitation capability, record the required build and runtime settings and verify that production artefacts actually contain them.

Contain untrusted input handling

Components that parse complex or attacker-controlled input often deserve stronger containment.

Examples include:

• network protocol parsers;
• document or media parsers;
• archive extraction;
• firmware package parsing;
• configuration import;
• browser or rendering engines;
• plugin loaders; and
• file formats received through removable media.

Useful design options can include process isolation, restricted privileges, bounded resource consumption, strict schema validation and disabling unnecessary parser features.

The goal is to stop one malformed input from becoming unrestricted control of the product.

Design safe failure behaviour

Mitigation also includes deciding how the product behaves after a security-relevant failure.

A safe failure design may need to answer:

• Does a crashed security service restart with reduced protection?
• Does loss of an authentication dependency create an unintended bypass?
• Can an integrity-check failure be ignored?
• What happens when protected configuration cannot be read?
• Does recovery mode expose stronger privileges than normal operation?
• Can repeated failures leave the system in a permanently unsafe state?
• Is a partial update rolled back to a trusted version?
• Does failure of one component propagate unnecessarily to essential functions?

Fail-safe behaviour should be defined explicitly rather than discovered during an incident.

Limit persistence after compromise

A successful attacker may try to survive reboot, update or recovery.

Mitigation controls can therefore include:

• authenticated boot chains;
• signed software or firmware;
• protected startup configuration;
• restricted persistence locations;
• integrity-protected update metadata;
• separation between runtime state and trusted recovery state;
• controlled factory-reset behaviour; and
• re-establishment of trusted configuration after recovery.

These controls are not universally required in the same form. They should be selected where persistence risk is relevant to the product.

Consider rollback and recovery as mitigation controls

Recovery is part of limiting incident impact.

A product may need a controlled path to:

• restart affected services;
• revert a failed update;
• restore trusted configuration;
• enter a restricted recovery mode;
• invalidate compromised credentials;
• replace trust anchors;
• reset exposed secrets; or
• recover essential functions without restoring an attacker-controlled state.

Recovery design should avoid creating a weaker security path than normal operation.

Test partial compromise rather than only normal operation

Happy-path tests do not demonstrate exploit mitigation.

Useful negative and resilience testing can include:

• compromise of a low-privilege process;
• malformed input reaching a parser;
• attempted access outside a sandbox;
• privilege-escalation attempts;
• failure of an authentication or policy service;
• repeated service crashes;
• tampered startup or recovery configuration;
• unauthorised persistence attempts;
• corrupted update state;
• loss of a security dependency; and
• recovery after deliberately induced faults.

The test objective is to verify that the product contains the failure and preserves defined security boundaries.

Verify mitigations on the production artefact

Exploit mitigations are often sensitive to build flags, packaging, deployment configuration and production defaults.

A release review should therefore verify the actual artefact rather than rely only on design intent.

Evidence can include:

• compiler and linker hardening configuration;
• sandbox or access-control policy;
• process privilege mapping;
• container or service permissions;
• secure boot and update verification configuration;
• production feature flags;
• recovery settings;
• negative-test results;
• fault-injection or containment-test results; and
• artefact-specific verification that required mitigations are enabled.

Keep mitigation decisions traceable to risks

Mitigation controls can become disconnected from the threat that originally justified them.

For each security-relevant mitigation, retain enough context to answer:

• Which threat or exploitation path does this control address?
• Which component or function does it protect?
• What consequence is it intended to reduce?
• Which product variants require it?
• Which releases contain it?
• How is it verified?
• What happens if the control fails?
• Which evidence demonstrates the current implementation?

This traceability becomes especially important when products have several variants or different hardware and software configurations.

Reassess when the architecture changes

Exploit-mitigation assumptions can become invalid when the product changes.

Reassessment is useful when teams introduce:

• new privileged services;
• new network interfaces;
• new parsers or file formats;
• additional third-party components;
• changes to process or container boundaries;
• new update mechanisms;
• remote management functionality;
• new recovery paths; or
• hardware revisions that change privilege or memory protections.

The mitigation model should evolve with the product instead of remaining tied to the original architecture.

Keeping risk decisions, mitigation controls, verification evidence and release scope connected is the operational challenge behind this requirement. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, which can help teams keep exploit-mitigation evidence attached to the release it supports. AA-sec does not determine CRA conformity for the manufacturer.

Practical release checklist

Before treating exploit mitigation as covered for a release, confirm that the team can answer:

• Which exploitation paths are credible for this product?
• Which components handle untrusted input?
• Which processes and services have elevated privileges?
• What limits the blast radius after one component is compromised?
• Which critical boundaries prevent privilege expansion?
• Are compiler, runtime or platform hardening controls enabled where relevant?
• Can failures create an authentication, recovery or configuration bypass?
• Can an attacker establish persistence after compromise?
• Does the product have a trusted recovery path?
• Have containment and failure cases been tested?
• Are mitigations verified on the actual production artefact?
• Can each mitigation be traced to the relevant risk, product and release?

Key takeaway

CRA exploit mitigation is about designing for the possibility that prevention fails. Manufacturers should identify credible exploitation paths, limit privilege and blast radius, protect critical boundaries, fail safely, support trusted recovery, test partial-compromise scenarios, and retain release-specific evidence that the selected mitigations are actually present.

Official sources

• Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
• Cyber Resilience Act - Manufacturers — European Commission
• ENISA Secure by Design and Default Playbook — ENISA