Annex I Part I (2)(k) Exploitation mitigation: CRA evidence

What Annex I Part I (2)(k) exploitation mitigation requires in plain words

Point (2)(k) asks manufacturers to design, develop and produce products so that the impact of an incident is reduced through appropriate exploitation mitigation mechanisms and techniques. A product team or compliance lead reading this point should take away one idea: even when a flaw is exploited, the product must not hand the attacker everything. Isolation, privilege separation and runtime containment are examples of the mechanisms the point has in mind, but the regulation does not prescribe a fixed list. The choice is made from the manufacturer's cybersecurity risk assessment under Article 13(2), so the mitigations you ship should trace back to the risks that assessment identified for your product.

The risk this point addresses is the chain reaction. A single exploited flaw in a parser, a web component or a third-party library becomes full product or data compromise when that component shares memory, credentials, network reach or a process with the rest of the system. Mitigation aims to break that chain. The hard part is usually the first decision: deciding which components are critical enough to isolate, and what boundary each one must not cross. Ask engineering to list the components that handle untrusted input, hold secrets or control privileged functions, then record for each one which mechanism limits its blast radius and why that mechanism was chosen.

The second difficulty is proving that the isolation works at runtime, not only in the architecture diagram. An assessor will expect evidence that a compromised component cannot reach the data or functions it should not, such as tested container or sandbox configurations, enforced admission policies, and runtime detection of attempts to cross a boundary. Confirm with your own security engineers which of these you can demonstrate from the shipped build, and which depend on how the customer deploys the product. That split determines what you document as the manufacturer's responsibility and what you explain in user instructions.

Which products, components and third parties fall under the (2)(k) scope

Point (2)(k) applies to every product with digital elements, but the measures a manufacturer must adopt depend on which components are critical and which product category applies. The cards below are the scoping decisions that most change the work, and each one should be recorded in the cybersecurity risk assessment before design choices are made.

Hypervisors and container runtimes

Hypervisors and container runtime systems separate execution environments, so a flaw in one can affect every workload on the host. Annex III places them in class II important products, and Implementing Regulation (EU) 2025/2392 describes the category in technical detail. Check whether your product is one of these categories, because that classification changes the conformity route and the level of evidence you need to show for isolation.

Highly critical internal components

Identify which internal components, such as parsers, privileged services, key handling modules or components that run with elevated rights, would cause the most damage if compromised. The risk assessment should name these components and state how each one is isolated from the rest of the product. Components that cannot be isolated should be recorded with the reason and the compensating measure.

Third-party components you integrate

Third-party libraries, runtimes and open-source packages carry their own vulnerabilities into your product. Commission FAQ 4.4.2 lists sandboxing or isolating highly critical components among the actions manufacturers may take when integrating them. Inventory each integrated component, record its privileges and network access, and decide whether it runs in a separate process, container or sandbox.

Tailor-made products and business user agreements

A product built for one business user under a specific agreement may be treated differently from a standard product, and the boundaries of that exception must be written down. Confirm with the business user which isolation measures they accept, which they manage themselves, and where responsibility for the configuration sits. Record the agreement in the risk assessment so the scope is not decided later by default.

Exposure of isolation boundaries

Map the boundaries that separate components, such as process, container, virtual machine and kernel boundaries, and the interfaces that cross them. Any interface that lets a lower-trust component reach a higher-trust one is an isolation weakness to review. Check which boundaries the product itself enforces and which depend on the host, the operator or the cloud environment.

Risk assessment, not product size

The depth of (2)(k) measures follows from the documented cybersecurity risk assessment, not from how large the product or its codebase is. A small product with a privileged component may need stronger isolation than a large application with none. Keep the assessment current through the support period so that new components, integrations or changed privileges trigger a review of the isolation decisions.

How an assessor tests exploitation mitigation under (2)(k)

This table sets out what an independent assessor would check for Annex I Part I point (2)(k), what evidence they would ask for, and where products usually fall short. Read it as a preparation checklist: each row is a test the manufacturer should be able to pass with records already in place. The assessor, not DeployOpen or the manufacturer, reaches the conclusion on conformity.

Test area	Evidence requested	Common findings
Risk assessment link to chosen mitigations	The Article 13(2) cybersecurity risk assessment, the list of critical components and the mitigation chosen for each risk, with the reasoning linking them	Mitigations are listed generically with no tie to a specific identified risk or component
Architecture review of component boundaries	Architecture diagrams showing trust zones, process and container boundaries, privilege levels and the highly critical components isolated from the rest	Boundaries exist in diagrams but not in the deployed build, or critical components share a privilege domain with exposed services
Runtime verification that isolation holds	Test results from a test environment running the released build, such as attempts to cross a boundary, logs showing enforcement and the configuration that enforces it	Isolation is configured but never tested, or a default setting quietly disables the boundary in some deployment options
Review of third-party component handling	Records of how each third-party component is integrated, any sandboxing or isolation applied to highly critical components, as referenced in Commission FAQ 4.4.2, and the component inventory	Third-party components run with full privileges because the integration was never reviewed for exploitation impact
Review of the decision record for mitigations not applied	A documented rationale for each mitigation not applied, the residual risk accepted, the approver and the review date	Missing or undated rationales, or decisions that do not match the risk assessment's own severity ratings
Review of mitigation settings across the support period	Change records for isolation controls, configuration baselines and the process that re-checks mitigations when the risk assessment is updated	Mitigations weakened by later changes with no update to the risk assessment or the decision record

How to implement exploitation mitigation step by step

This sequence turns the risk assessment's view of critical components into isolation and hardening decisions that are built, tested at runtime and recorded, so the manufacturer can show that an incident's impact is contained under point (2)(k).

Identify critical components from the risk assessment
Start from the cybersecurity risk assessment required under Article 13(2) and list every component whose compromise would expose the most data, control the most functions or spread to other parts of the product. Include third-party libraries, agents, parsers, network-facing services and privileged processes, not only the components the team wrote. The product owner and security lead sign off the list. This step is done when each entry names the component, its version, the risk it carries and the reason it was rated critical.
Map trust boundaries and dependencies
For each critical component, draw where it receives input, what it can reach and which other components it depends on. Mark every point where a less trusted input or process meets a more privileged one, such as a network listener feeding a parser that runs as root. Engineers and architects do this together, using architecture diagrams and the component inventory from the SBOM work. The output is a dependency and trust-boundary diagram that shows which failures could cascade and where a break would stop them.
Choose mitigations for each component
Select a mitigation for each boundary, matched to the risk level in step one. Options include running a process with least privilege, separating it in its own container or virtual machine, isolating a host, restricting interfaces so it accepts only the calls it needs, and sandboxing highly critical third-party components as the Commission's FAQ describes. Record the choice and the reason for it in the risk assessment. The step is complete when every critical component has a named mitigation and a rationale that an assessor can follow.
Implement and configure the isolation controls
Engineers build the chosen controls into the product or its deployment: container and runtime settings, service accounts with minimal rights, network policies, file and system call restrictions, and admission rules that stop non-conforming workloads from starting. Policy engines such as Kyverno can enforce some of these rules at Kubernetes admission, and runtime tools such as Falco can alert on suspicious behavior. The configuration is kept in version control so each change has an author and a review. Done means the configuration matches the approved design and is reproducible from the repository.
Verify the mitigations at runtime
Test that each boundary holds when it is attacked. Testers attempt privilege escalation from the component, access to data outside its scope and lateral movement to neighboring services, then confirm that isolation stops the attempt and that monitoring records it. Security testing can be run by the manufacturer's own team or by an outside tester. The output is a test report listing each scenario, the expected result, the observed result and any gap that needs a fix before release.
Record decisions and residual risk
Write down the final mitigation for each component, the tests that proved it, the open gaps and the residual risk the manufacturer accepts. Link these records to the technical documentation and to the Annex I Part I (2)(j) attack surface record, so the reasoning sits in one place. The product owner approves the residual risk in writing and the record is re-opened whenever the risk assessment changes. This step closes when an independent reviewer can trace each isolation decision back to a component, a test and an accepted risk.

Open-source tools that produce runtime and pipeline evidence for (2)(k)

Exploitation mitigation is shown by how a product runs, how its isolation is enforced and how changes to that isolation are reviewed. The four tools below each produce a different kind of evidence for those points. None of them provides isolation on its own, so the isolation design itself must come from the manufacturer's risk assessment.

Runtime detection with Falco

Falco (Apache-2.0) watches Linux system calls at runtime, by default through an eBPF probe, and matches them against YAML rules. The rules can flag privilege escalation, unauthorized file modification, unexpected network connections and suspicious process execution, which are the signals that show a mitigation boundary is being tested. Check that the rule set covers the isolated components your risk assessment names, and confirm where alerts are sent and how long they are kept.

Admission policy enforcement with Kyverno

Kyverno (Apache-2.0) enforces policies when Kubernetes resources are created or changed, by validating, mutating, generating or removing them. It also verifies container images. Policies can require that workloads for isolated components run with restricted privileges and approved images. Its CLI can scan existing resources, which produces a repeatable record of what the cluster allowed. Confirm which policies your assessor will expect to see in version control.

Pipeline code scanning with Semgrep

Semgrep Community Edition scans code in languages including C/C++, Go, Java, Python, Rust and Terraform, using community or custom rules, and can run in CI/CD to scan repositories continuously. Custom rules can flag risky patterns such as disabled sandboxing flags or overly broad container settings in infrastructure code. The Community Edition is licensed LGPL-2.1-only, so confirm with your legal team that this license fits how you distribute or use the tool before you make it part of a compliance record.

Controlled isolation changes with GitLab

GitLab Community Edition (MIT) protected branches let maintainers restrict who can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Applied to the repository holding isolation configuration, these settings create an approval trail for each change to a boundary. Confirm that protected branch rules are set on the branches that deploy isolation settings, and that your review records are retained for the support period.

Which evidence shows that exploitation mitigation works

The evidence that matters for point (2)(k) is proof that a compromise stays contained, not a list of mitigation tools. Start with the risk assessment entries that select each mechanism and record why. For example, an entry might state that a parser handling untrusted input runs in its own container with a restricted seccomp profile because a memory-corruption flaw there could reach the signing key. Architecture and boundary diagrams should show the same components, their trust zones and every path between them, so an assessor can trace the decision to the design. Configuration baselines kept in version control show what was actually deployed, and their commit history shows who changed an isolation setting and when. Keep the Kubernetes admission policies enforced through Kyverno and the Falco rule sets in the same repository so they are reviewed with the code they protect.

Test results are the strongest proof. Run a contained-compromise exercise against each boundary you claim: from a compromised component, attempt lateral movement, privilege escalation, writes outside its volume and calls to restricted networks, then record what was blocked and what was not. Pair the results with runtime alert records from Falco showing that the attempts were detected, with timestamps, rule names and the container metadata that identifies the workload. Confirm with your own engineers which Falco events and output channels are retained and for how long, since the evidence is only as good as the logs that survive. Where a finding showed a boundary was weaker than the risk assessment assumed, the dated review record should show the change and the retest.

Keeping this evidence current between assessments is an operating task. Re-run the boundary tests after every release that changes a trust zone, a network path, a privilege or a dependency that runs inside a boundary. Treat a third-party component update as a trigger too: a new version of a library or base image may change its own privileges or syscall needs, and the risk assessment entry for it should be reviewed before the release ships. Assign a named owner for the review record and set a recurring review date that is not tied only to audits. Ask your implementation partner and your assessor to agree in writing which artifacts they expect in each period, so the evidence file grows with the product rather than being rebuilt before each assessment.

What meeting (2)(k) costs in money and effort

This table breaks the cost of meeting Annex I Part I (2)(k) into its components, showing who is paid, whether each cost is one-time or recurring, what moves it, and what to request in a written scope. No figures are given because none were supplied, so use the right-hand column to build a like-for-like comparison between quotes. The main takeaway is that open-source tooling removes license spend but not the engineering and evidence effort that the requirement creates.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Engineering time to redesign boundaries	One-time, with rework after major architecture changes	Number of critical components, how tightly they share memory, network or credentials, and whether isolation is retrofitted or designed in	A list of components to isolate, the boundary design for each, and the change that follows from the risk assessment
Tooling and licenses	Licenses are one-time or recurring; open-source tools carry no license fee	Choice between commercial and open-source runtime, policy and monitoring tools; open-source options still need hosting and tuning	Named tools, their license terms, and an explicit line for the hosting and operating effort they require
Operating effort for self-hosted tooling	Recurring	Cluster size, number of policy rules, alert volume, and how many teams own the platform	Who runs the tools, the on-call model, and which upgrades and rule updates are included in scope
Test and verification effort	Recurring per release, plus a one-time baseline	Number of isolation controls to test, whether tests are automated in CI/CD, and how often boundaries change	Test cases mapped to each isolated component, automation coverage, and the pass criteria used
Evidence upkeep per release	Recurring	Frequency of releases, how many components change, and whether evidence is generated automatically	The evidence set produced for each release, where it is stored, and who reviews it before shipment
External penetration or architecture review	One-time or periodic	Scope of isolation boundaries tested, product complexity, and whether the review covers AI or agent components	A written test scope naming the boundaries, the deliverables, and whether retests are included
Auditor or notified body sampling time	Recurring at each assessment	Depth of documentation, how traceable the risk assessment is to each isolation decision, and whether the route requires a notified body	Confirm with the assessor which samples they will request and the format they expect for test records
Internal product and compliance staff time	Recurring	Clarity of ownership between engineering, product and the security function, and how many decisions need sign-off	A named owner for each isolation decision and the review cadence agreed in writing

Who does what for exploitation mitigation: your team, a partner and the auditor

Your organization owns the decisions that make point (2)(k) meaningful. Exploitation mitigation is chosen according to the cybersecurity risk assessment, so the people accountable for the product must decide which components are critical, which must be isolated from each other, and which residual exposure is acceptable. Those decisions belong in the risk assessment and the technical documentation under your name, not in a partner's notes.

Risk-based scope: Identify the components whose compromise would have the greatest impact on the product's essential functions and record why each one needs mitigation.
Architecture decisions: Choose the isolation boundaries, such as separate execution environments, privilege separation and restricted network paths, and document the rationale.
Third-party components: Decide how components you did not write are sandboxed or isolated, as the Commission's FAQ on integrating third-party components contemplates.
Sign-off and ownership: Approve the design, name an owner for each mitigation control, and set the review trigger for changes.
Residual risk: Accept, in writing, the risks that remain after mitigation.

Before engaging a partner, confirm that your own team can explain every isolation decision without reference to the vendor or consultant.

Where organizations fall short on exploitation mitigation and how to close each gap

Most shortfalls against point (2)(k) are not missing technology. They are gaps between what the risk assessment says, what is actually isolated, and what can be shown to an assessor. The cards below cover six gaps and the closing action for each.

No link between risk and mitigation

The risk assessment identifies threats, but the chosen isolation or containment measures are not traced back to them. An assessor will ask why a given component is isolated and why another is not. Record each exploitation mitigation decision next to the threat it addresses, the component it protects and the residual risk accepted. Check that every high-risk finding has either a mitigation or a documented acceptance.

Critical components not identified

Teams often isolate the obvious services but never list which components would cause the largest impact if compromised, such as authentication services, key stores, update mechanisms or data pipelines. Build an inventory of critical components from the architecture and the risk assessment, then assign each one an owner and a mitigation. Review the list whenever the architecture changes.

Isolation never tested under attack

Sandboxes, network segments and container boundaries are often configured once and assumed to work. Without testing, nobody knows whether a compromised process can reach its neighbors. Schedule breakout and lateral movement tests against each isolation boundary, including privilege escalation attempts, and keep the results with the technical documentation. Retest after every change to the boundary.

Third-party components integrated unreviewed

Libraries, agents and runtimes brought into a product often run with the product's full privileges. Commission FAQ 4.4.2 lists sandboxing or isolating highly critical components among the actions manufacturers may take when integrating third-party components. For each component, decide whether it needs isolation, document that decision, and confirm the isolation survives the component's update cycle.

Detection coverage not recorded

Runtime detection that flags privilege escalation, unauthorized file changes or unexpected network connections is only useful if its rules match the isolation design. Falco evaluates Linux syscalls against YAML rules, and its default rule set may not cover every boundary you built. Write down which rules cover which mitigations, which events are not covered, and who reviews the alerts.

Configuration changes without review history

Isolation policies change over time through pull requests, admission rules and cluster settings. If a policy was weakened without review, the mitigation no longer matches the risk assessment. Protect the branches that hold these definitions so changes need approval, and enforce mitigation policies at admission with Kyverno. Keep the commit and review history as evidence that controls stayed in place during the support period.

Questions buyers ask about meeting the (2)(k) exploitation mitigation requirement

How much effort does meeting the (2)(k) exploitation mitigation requirement take?

The effort depends mostly on how many components in the product are highly critical and how far they can be separated from each other. Point (2)(k) asks for mitigation mechanisms and techniques chosen according to the manufacturer's risk assessment, so the work starts with identifying which components would cause the greatest damage if compromised. Effort rises with the number of such components, the number of trust boundaries between them, and the amount of legacy code that cannot easily be isolated. Each isolation measure also needs testing, documentation and maintenance across the support period. Ask any provider to break the estimate into architecture review, implementation, verification and evidence capture, and to state which of these recur with each release.

Can our own engineering team meet the (2)(k) requirement in-house?

Many teams can, provided they have engineers who understand the product architecture, the operating environment and the isolation options available to them. The Commission's FAQ 4.4.2 lists sandboxing or isolating highly critical components among the actions manufacturers may take when integrating third-party components, so isolation is a recognized route. The harder part is usually independent verification and evidence: showing that the chosen mechanisms work under attack conditions and are documented in the technical file. An in-house team can build the controls while an outside specialist tests them, or the reverse. Decide early which person signs off the risk decision, because the manufacturer keeps responsibility for conformity either way.

What does the team need to provide for an exploitation mitigation project?

The work needs three things from the client: architecture access, test environments and named decision owners. Architecture access means current diagrams, data flows, component inventories and the list of third-party dependencies, so that highly critical components can be identified accurately. Test environments should resemble production closely enough to show whether isolation holds when a component is compromised, including container or virtualization layers where they apply. Decision owners must approve which mitigation is accepted for each component and record the reasoning in the risk assessment. Without a named approver, findings tend to stall, and the rationale for leaving a component unisolated may be missing when an assessor asks for it.

How long does a (2)(k) mitigation project take, and what sets the pace?

The pace is set by scope, the number of release trains that must carry the change, and how much third-party software needs to be reworked or wrapped. No fixed duration applies to every product, so ask for a timeline built from the written scope rather than a generic figure. Projects move faster when the product has a clear component boundary and a stable release cadence, and slower when isolation requires redesign of shared services or coordination with suppliers. Regulatory timing also matters: the reporting obligations under Article 14 apply from 11 September 2026, while the main regulation applies from 11 December 2027, so plan the mitigation work against the product's own release schedule and support period.

Are open-source tools enough to show exploitation mitigation?

Open-source tools can supply important parts of the evidence, but they do not decide on their own whether the requirement is met. Falco, which is licensed under Apache-2.0, parses Linux syscalls at runtime, by default through an eBPF probe, and flags events such as privilege escalation or unexpected network connections, which helps show that a compromise is detected and contained. Kyverno, also Apache-2.0, enforces policies at Kubernetes admission, which can limit what workloads are allowed to run with. Semgrep Community Edition can scan code in CI/CD pipelines for weaknesses that would widen an incident. Confirm each tool's fit with your architecture, and document how the tooling connects to the risk assessment rather than treating installation as the evidence.

Does a class II product that uses hypervisors or container runtimes need a notified body?

Yes, a notified body is generally needed for class II important products, according to Article 32 and the Commission's CRA FAQ 6.1 and 6.2. Hypervisors and container runtime systems, which separate execution environments, are listed as a class II important product category in Annex III and detailed by Commission Implementing Regulation (EU) 2025/2392. Where a product in that category applies harmonized standards in full, the route may differ, so check that point against the Commission's FAQ and your product's classification before deciding. A notified body assesses conformity but does not design the isolation for you. Ask a prospective body what evidence it will require for the (2)(k) mechanisms specifically.

How DeployOpen scopes, implements and prepares evidence for (2)(k)

DeployOpen works on Annex I Part I (2)(k) Exploitation mitigation as part of a written, fixed-scope engagement that starts from the manufacturer's own risk assessment. We plan, implement and document the mitigation measures inside your build and runtime environment, and we prepare the evidence your organization and its assessor need to review.

How we scope

Agree in writing which products, components and runtime environments the (2)(k) work covers, based on your documented risk assessment.
List the critical components that need isolation or other mitigation, and record which of them your risk assessment has flagged.
Confirm which third-party components your team integrates and which ones the written scope treats as highly critical.
Define deliverables, timelines and responsibilities before work starts. Ongoing support and continuous testing are available as a retainer.

How we build

Configure isolation boundaries for critical components, such as separate execution environments, network segmentation and restricted privileges, in your own infrastructure.
Enforce admission policies on Kubernetes workloads with Kyverno, so non-compliant resources are blocked or flagged before they run.
Deploy Falco for runtime detection of privilege escalation, unauthorized file changes and unexpected network connections in your environments.
Protect the release pipeline with GitLab protected branches and Semgrep scans in CI/CD, so code changes that weaken mitigations are caught early.

How we hand over

Document each mitigation mechanism, the component it protects, the risk it addresses and the configuration that sets it.
Provide configuration files, policy definitions and rule sets under version control so your team can review and reproduce them.
Package test results and runtime alert samples as evidence for technical documentation and for the independent assessor's review.
Confirm with your assessor which artifacts they expect for conformity assessment, since the organization owns its controls and the assessor decides what suffices.

How we support

Review mitigation settings when the risk assessment changes, a component is upgraded or a new third-party dependency is added.
Support your team through the support period with updates to isolation policies, detection rules and admission controls.
Run resilience and security testing against the mitigations on request, so you can see whether an incident would stay contained.
Keep documentation current with each release. Confirm the support terms and retainer scope in writing before the engagement starts.

Annex I Part I (2)(k) Exploitation mitigation