Annex I (2)(i) minimizing network impact under the CRA

What Annex I (2)(i) asks manufacturers to prove about network impact

Point (2)(i) of Annex I, Part I requires manufacturers to minimize the negative impact that their product, or devices connected to it, has on the availability of services provided by other devices or networks. In plain terms, a product must not be able to degrade or knock out someone else's network or services, whether through its own traffic, its misbehavior, or the way it is wired into a larger environment. The obligation sits inside the manufacturer's documented cybersecurity risk assessment under Article 13(2), so the question is not whether a product could ever affect another network, but whether the manufacturer identified that risk, decided how far it needed to be reduced, and built the reduction into the design. The risk is concrete. Article 7 treats the ability to disrupt, control or cause damage to a large number of other products as a reason a product category is important, and the Annex III list names routers, modems and switches, along with network management systems such as software-defined networking controllers, as class I categories. A manufacturer of a product in one of these families, or of a product that ships with a management plane able to push configuration to many devices, should expect the assessment to ask what happens to neighboring systems when the product fails, floods, or is taken over. Confirm with your conformity route and the technical description in Commission Implementing Regulation (EU) 2025/2392 whether your product falls in one of these categories before you scope the work.

The hard part is evidence. Network behavior is often difficult to bound in advance, because traffic patterns depend on the customer's topology, the number of connected devices, retry logic under failure and the interaction of firmware versions. Manufacturers usually need to define the load and connection limits they designed for, show how rate limiting, connection caps, back-off and fail-safe defaults keep the product from amplifying a fault, and record how they tested behavior at those limits. For a self-hosted platform, that means reviewing the product's own network stack, its outbound and retry behavior and its management interfaces, then keeping the test results and the residual exposure in the assessment file, which the team should be able to hand to an assessor.

Which products and network functions Annex I (2)(i) reaches

Requirement (2)(i) applies to any product with digital elements that can degrade other networks or services, but the work is heavier for products the regulation already names as important. The cards below show which product types and behaviors deserve a scoping decision before the risk assessment is closed.

Routers, modems and switches

Article 7(2)(b) names the ability to disrupt, control or cause damage to a large number of other products as a basis for listing important categories, and Annex III class I includes routers, modems and switches. A device that forwards traffic for many downstream systems can therefore hit (2)(i) hard. Check whether your firmware can flood, amplify or misroute traffic beyond its own network segment, and record how that behavior was tested.

Network management systems and SDN controllers

Implementing Regulation (EU) 2025/2392 describes network management systems, including controllers for software-defined networking, as a class I important product category under Annex III point 6. A controller that pushes configuration to many devices can cause outages across a network if it pushes a faulty change. Confirm which managed devices it can affect and how changes are staged, rate limited and rolled back.

Connected devices that send traffic outward

Products such as cameras, gateways and sensors that open connections to external endpoints can overload upstream services when they retry aggressively or synchronize at the same moment. Compare what each device sends during normal operation and during failure recovery. Document the retry logic, backoff behavior and any mass reconnection that could follow a regional network event.

Cloud-backed products with third-party dependencies

A product whose behavior depends on a vendor cloud, a DNS service or a time server can shift load onto services it does not own when that dependency changes or fails. Your assessment should identify which external services the product calls, how often, and what happens to other networks when those calls fail or slow down. Treat these dependencies as part of the same risk analysis, not as a separate supply chain item.

Default settings that generate unbounded traffic

Factory defaults that enable broad discovery, frequent telemetry or unlimited polling can create sustained load on shared networks before any user changes a setting. Review each default for polling intervals, broadcast use, logging volume and connection limits. Where a default cannot be bounded, record the reason in the risk assessment and state how the user can reduce the load.

How category sets the conformity route

A product's category decides the conformity assessment route. Most products follow self-assessment under module A, while class I important products may need a notified body where harmonized standards, common specifications or certification schemes are not applied in full, and class II and critical products need a notified body. Ask your assessor or notified body early which category applies, because scoping a network device into class I can change the evidence and third-party involvement you need before placing it on the market.

How an assessor tests Annex I (2)(i)

This table walks through the assessor's test steps for network impact, from reviewing the risk assessment entry to checking how connected devices are limited. Read each row as a test step with the evidence it asks for and the findings assessors commonly raise. The main takeaway is that a documented rationale and observed behavior under failure matter as much as the default configuration.

Test step	Evidence requested	Common findings
Review the risk assessment entry for network availability	The Article 13(2) risk assessment entry covering network impact, the Annex I point (2)(i) decision, and the reasoning behind it	No documented rationale for judging the requirement not applicable to a networked product
Confirm the scope of connected devices and services	Architecture diagrams showing which network services, peers and dependent systems the product connects to, and in which direction	Connected devices or upstream services missing from the diagram, so their load on other networks was never assessed
Inspect traffic behavior under normal operation	Traffic captures or flow logs from representative test runs, with request rates per endpoint and per connected device	Chatty background traffic, polling intervals that were never justified, or traffic that scales with user count without limits
Inspect resource behavior under abnormal conditions	Test records from load and fault scenarios, showing connection counts, bandwidth and CPU use when peers misbehave or slow down	No test of behavior when a dependent service is unavailable or responds slowly
Review default traffic and retry settings	Configuration files and defaults for timeouts, retry counts, backoff, keep-alive and batch sizes, with the values the product ships with	Unbounded retry loops, retries without exponential backoff, or aggressive defaults that multiply load during an outage
Review broadcast, multicast and discovery behavior	Documented discovery protocols, broadcast rules and the switches that enable or limit them	Broadcast or discovery traffic enabled by default with no way to scope it to the local segment
Review how connected devices are limited	Rate limits, connection caps, quotas or allow lists applied to peers and clients, with the test results that show them working	Limits described in documentation but not enforced in the build, or no limit on the number of devices a single instance can serve
Check the evidence trail for the decision	Monitoring rules or alerts that detect excessive traffic or resource use, and the change records that show when defaults were last reviewed	Monitoring that measures the product but does not alert on network impact, and defaults changed with no record of the impact review

How to implement the network impact requirement step by step

This sequence turns point (2)(i) into documented design decisions, measured behavior under load and dependency failure, and a record of the exposure the product still carries onto other networks and services.

Inventory network interfaces and external dependencies
Start from the cybersecurity risk assessment and list every network interface the product exposes or uses: listening ports, outbound connections, discovery protocols, management channels, and the external services it depends on, such as update servers, time sources, DNS and cloud APIs. The product engineering lead owns this list, and the security team reviews it against the architecture diagrams. The step is done when every interface and dependency has an owner and a row in the inventory, and when no connection exists that the team cannot explain.
Characterize expected traffic for each interface
For each entry in the inventory, document the expected traffic pattern: who initiates the connection, how often, typical and peak message rates, payload sizes, protocols and the devices or networks that receive the traffic. Where the product connects to infrastructure such as routers, switches or network management systems, record that relationship explicitly, since those categories are named in the regulation's important product classes. The step is done when a baseline exists that a tester can compare against later, and the owners have signed off on it.
Set limits on connections, retries and broadcasts
Define enforceable bounds for each interface: maximum concurrent connections, connection attempt rates, retry intervals with backoff, limits on broadcast or multicast discovery, and thresholds that flag scan-like behavior such as rapid sequential port access. Implement these in product code, configuration defaults or network policy, and record the values and where they are set. The step is done when each limit appears in the design documentation with its rationale and a configuration reference that a reviewer can verify.
Harden the edge with filtering and rate control
Apply the limits at the network boundary where the deployment allows it. Packet filters and web application firewalls can restrict sources, ports and protocols and log rule matches, and monitoring systems can alert on traffic that departs from the baseline. Confirm each capability against the specific components selected, since features vary by platform and version. The step is done when the filtering and alert rules are versioned with the product configuration and tested for the behaviors defined in the previous step.
Test under load and dependency failure
Run the product against the baseline and beyond it: sustained and peak load, reconnect storms after an outage, slow or unavailable upstream services, and malformed or flooding traffic from neighboring devices. Measure how many connections, retries and broadcasts the product generates and whether it degrades gracefully instead of amplifying traffic onto other networks. A test harness can be built by an implementation partner, but the manufacturer decides the pass criteria. The step is done when results are recorded for each scenario, with failures linked to defects or accepted risks.
Monitor behavior in deployment
Connect the product's network metrics and logs to a monitoring stack so that deviations from the baseline are visible after release. Metrics for connection counts, retry rates and error rates can be collected and alerted on, and the alert thresholds should come from the baseline rather than from defaults. The manufacturer confirms which telemetry the product can export without exposing personal data. The step is done when dashboards and alert rules exist, have been triggered in a test, and have named responders.
Record design decisions and residual exposure
Document every decision made in the previous steps, the tests that support it, and the exposure that remains, such as traffic a product must send by design or interfaces a customer must keep open. Record which limits are configurable by the user or integrator and what defaults ship. The risk assessment should be updated so the residual exposure is explicit and reviewable across the support period. The step is done when the technical documentation references this record and the manufacturer has approved the residual risk in writing.

Which self-hosted open-source tools support network impact evidence

OPNsense is a stateful packet filter, and its rules pass, block or reject traffic by source, destination, port and protocol. For point (2)(i), this matters when a product or its management network is placed behind OPNsense, because the rule set shows which connections the product is permitted to open and which it is not. Aliases let teams group addresses, so a rule can describe a class of devices rather than one hard-coded host.

Rule set as configuration evidence: The exported rules show the traffic the product may send to other networks and services, which is the starting point for judging impact on those services.
Aliases for address groups: Named groups of hosts or networks make it easier to show which devices are covered by a given rule and to keep that scope current.
Logged rule matches: When logging is enabled on a rule, matches appear in the live log view, which can show connection attempts the product makes against other networks.
Limits of the record: The firewall shows what crossed its boundary, not whether the product's traffic degraded another service.

Before relying on these records, confirm with your own deployment team which rules log, how long logs are retained, and whether exports can be kept with the technical documentation.

Evidence that passes an Annex I (2)(i) review

Point (2)(i) is tested through documents and test results, not through a single control. The cards below cover the risk assessment entry, the configured limits, load and failure tests, filter and alert evidence, and the disclosed residual exposure. Each artifact must be reviewed again whenever the product, its interfaces or its connected devices change during the support period.

Risk assessment entry for availability

Record how the product or its connected devices could degrade the availability of other devices or networks, for example through excessive connection attempts, broadcast storms or unbounded retry loops. Explain why the chosen measures are proportionate to that risk and which point (2) requirements they support. Review the entry at each release and whenever a new connected device type or network role is added, because the reasoning depends on the deployment context the manufacturer assumed.

Documented traffic and connection limits

List every external interface with its configured limits on connections, request rates, packet rates and message sizes, together with the default values and the ranges an integrator may change. Assessors check that the limits exist, that they are enforced by the product and that the documentation matches the shipped configuration. Store the list in version control with the release tag, so each change to a default is visible and traceable.

Load and dependency failure test reports

Keep reports showing how the product behaves under sustained high load, bursts of traffic and loss of an upstream service such as DNS, authentication or a time source. The reports should show that the product backs off, queues or drops traffic without flooding neighboring networks. Repeat the tests against each release candidate, and record the test environment, the product version and any deviation from the documented limits.

Filter rule exports with logging

Where the product includes packet filtering or rate limiting, export the active rule set with logging enabled for rules that block or throttle traffic. Assessors look for rules that restrict outbound floods as well as inbound attacks, and for log entries that show the rule that acted. Export the rules as part of each release build, and confirm that a rule change in a test environment appears in the export before shipping. The OPNsense documentation describes how rules and rule-match logging are configured in that platform.

Alert rules and their test results

Keep the alert rules that detect abnormal connection counts, traffic volume or error rates from interfaces, with the thresholds and the queries that feed them. Test each rule against a simulated fault and record that the alert fired and reached the responsible team. Review thresholds after each release, because a new default or a new connected device can change what normal traffic looks like.

Residual exposure in technical documentation

Describe in the technical documentation the availability risks that remain after the measures, such as the traffic volume a device can still generate before a limit applies, and the conditions in which a connected device could affect a neighboring network. State what the integrator or operator must configure to keep that exposure acceptable. Update this section with every release, since each change to limits, interfaces or supported topologies alters the residual exposure.

What meeting Annex I (2)(i) costs in money and effort

This table breaks the cost of meeting point (2)(i) into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No supplied figures exist for these costs, so use the table to structure a written, scoped quote and to ask for the assumptions behind each line. The main takeaway is that open-source tooling removes license spend but not the engineering and evidence work.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Engineering time to design traffic limits and test behavior	Internal engineers or an implementation partner	One-time, then recurring for each release	Up: number of external interfaces and connected device types. Down: a narrow scope agreed in the risk assessment
Tooling for testing and monitoring	Open-source projects cost nothing in license fees; support contracts or hosting are paid where chosen	Recurring for hosting, storage and support	Up: retention periods and volume of metrics. Down: reuse of open-source monitoring already run by the organization
Evidence upkeep across releases	Internal product or compliance staff, or a partner on retainer	Recurring for every release and support period	Up: frequent releases and many network-facing components. Down: automated test results stored as versioned evidence
External testing or review of network behavior	Independent testing firm or consultant	One-time per assessment, plus periodic retests	Up: breadth of third-party dependencies and network topology. Down: a written test scope tied to the risk assessment
Assessor time for sampling	Notified body or independent assessor, where one is required	One-time per conformity assessment, plus re-assessment after substantial change	Up: class I or II or critical product status and number of product variants. Down: clear, versioned evidence packs
Internal coordination and governance	Product, security and legal staff	Recurring through the support period	Up: unclear ownership of network impact decisions. Down: named owners recorded in the technical documentation

Who does what for network impact: your team, a partner and the auditor

Your organization owns the Annex I point (2)(i) position. Under the regulation, the manufacturer must decide, on the basis of its cybersecurity risk assessment, how the product avoids degrading the availability of other devices or networks, and it must be able to explain that decision in its technical documentation. Those decisions cannot be delegated to a partner or an auditor.

Risk decisions: Decide which connected behaviors (broadcast traffic, retry loops, unbounded connection pools, discovery protocols) could affect other networks, and accept or treat each risk.
Product design: Set rate limits, backoff rules, default traffic profiles and the behavior of the product when a neighboring service fails.
Release decisions: Approve the product for release only when the test results match the documented risk acceptance.
Technical documentation: Record the rationale, the tested scenarios and the residual exposure in the documentation that supports conformity.
Ongoing ownership: Keep the analysis current through the support period as the product, its dependencies and its deployment context change.

Check that a named role in your organization signs each of these decisions and that the signature is traceable to a specific product version.

Questions buyers ask about Annex I (2)(i) before hiring help

Does a product outside network categories still need to meet Annex I (2)(i)?

Yes, if the product is in scope at all. Point (2)(i) applies to every product with digital elements placed on the EU market, not only routers or switches. It asks whether the product, or devices connected to it, can degrade the availability of services that other devices or networks depend on. A business application, IoT sensor or industrial controller can cause that harm through excessive traffic, broadcast storms, unthrottled retries or uncontrolled connection attempts. The manufacturer's cybersecurity risk assessment decides how much this matters for each product, and the reasoning should be recorded there. Network categories such as routers, modems and switches, and network management systems in Annex III class I, carry the highest expectation because their core function is to affect other networks.

How long does the work take, and what drives the duration?

The duration depends on the product's architecture, not on a fixed template, so ask for a timeline only after a written scope exists. The main drivers are the number of external interfaces and protocols, whether the product connects to shared networks by default, how many connected device types it supports, and how much existing traffic and load testing data the team already has. Work also grows when the product has no baseline for normal behavior, because the team must first define what normal traffic looks like before it can set limits. Products that already log connection and request rates need less preparation than products that do not. A fixed-scope agreement should state the systems in scope, the test environments used and the evidence delivered.

What does the work need from our engineers?

It needs protocol, network and platform engineers who know how the product behaves under load and failure. They must document expected traffic patterns, connection behavior, retry logic and dependencies on other services. They also need to decide which limits apply, such as rate limits, connection caps, backoff settings and queue bounds, and to verify that the product fails in a controlled way when those limits are reached. Security and product owners should review the decisions and link them to the risk assessment. Expect the engineers to spend time on test setup and on explaining why a given limit is safe for the product's intended use, because that reasoning is what an assessor will read.

Can our own team meet this requirement without outside help?

Many teams can, provided they have engineers who can test their product under load and the authority to change its defaults. Outside help is most useful when the team lacks load or network test capability, when the product connects to many third-party networks, or when the manufacturer needs an independent view before a notified body review. The organization owns its controls and the final decision. An implementation partner can prepare test environments, monitoring, rate-limiting configuration and evidence packs, but it does not issue reports or certificates. Only an independent auditor, assessor or certification body does that. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and runs security testing, so its work can cover those parts when the scope is agreed in writing.

What evidence would a notified body or market surveillance authority ask for?

They will ask to see how the requirement was identified, decided and tested. Expect to provide the section of the cybersecurity risk assessment that explains why point (2)(i) applies or does not apply, the technical documentation describing traffic behavior and limits, test records showing how the product behaves under overload and failure, and configuration evidence for rate limits, connection caps and retry settings. Monitoring evidence matters too, such as dashboards and alert rules showing that abnormal outbound volume is detected. For a notified body route, the documentation must be complete before the review starts. Confirm the exact form of evidence with the notified body or authority you engage, because their expectations and the harmonized standards in progress may shape the detail.

What should we request in a written quote?

Ask for a scope that names each product, interface and environment covered, and a list of deliverables tied to the requirement. A useful quote states the test approach, the load and failure scenarios, the monitoring and alerting components, the configuration changes to the product or its open-source dependencies, and the documentation handed over. It should say who runs tests, who owns the results, and what happens if the product design changes during the work. Ask which costs are one-time, such as initial analysis and test setup, and which recur, such as retesting after updates or ongoing monitoring under a retainer. Confirm what the partner will not do, including issuing any audit report, attestation or certificate, because that role belongs to an independent assessor.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the network impact of each product is scoped, built and evidenced where it runs. For point (2)(i), that means tracing which services a product or its connected devices can affect, and handing over the configuration and monitoring evidence that shows how that impact is controlled.

How we scope

The written scope names each product, connected device and network segment whose availability could be affected.
It records which Annex III class I categories apply, such as network management systems, and why.
Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.

How we build

Configure edge controls such as OPNsense packet filter rules limiting which sources and ports can reach each service.
Set up traffic limits and service isolation for components named in the risk assessment, confirmed against platform documentation.
Deploy Prometheus and Grafana Alerting to watch request volume and service health, so abnormal load on shared networks is visible.

How we hand over

Configuration baselines for firewall rules, aliases, rate limits and alert rules, with the reasons each one exists.
Test records showing which traffic was blocked, allowed and alerted during acceptance testing.
Evidence prepared for your technical documentation, which you own and submit to your assessor.

How we support

Retainers for ongoing support, upgrades and continuous testing of the network controls as the product changes.
Review of firewall rules and alert rules after each release or change to connected devices.
Support for questions from your independent assessor about the evidence, while the assessor makes the decision.

Annex I Part I (2)(i) Minimizing impact on other networks