Availability, and not becoming someone else's problem

Practical guidance, not legal advice. Annex references are drawn from Regulation (EU) 2024/2847. Check them against the official text before you rely on them.

Point (2)(h) requires products to protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks. Point (2)(i) requires them to minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks.

Read the second one again. Every other requirement in Annex I Part I protects the person who bought the product. This one protects everyone else, and it is in the Regulation because a generation of connected devices with weak credentials was assembled into attacks on people who had never heard of them. It is unusual in product law and it is the point most likely to be answered with a shrug.

Essential and basic functions is a phrase you have to define yourself

The Regulation uses the phrase and does not enumerate it for your product. That is not a loophole. It means the definition comes from your risk assessment, and once written it binds the rest of the answer, because everything you call essential has to keep working under conditions where the rest does not.

Writing the table is most of the work, and it produces a design consequence that is uncomfortable and correct: an essential function should not depend on the network path most likely to be attacked. A lock whose essential function is a cloud round trip has an availability requirement it cannot meet. Local fallback is the recurring answer, and it is a product decision more than a security one.

The words also after an incident

Availability in this point is not only uptime. It includes coming back, which puts recovery inside the requirement.

• A watchdog that actually resets the device, tested by deliberately hanging the main loop rather than assumed from the datasheet.
• Power-fail safety on writes, so an interruption mid-update or mid-write leaves a valid state rather than a corrupt one. This is where point (2)(f) and this point meet.
• A recovery or rescue image reachable when the main image will not boot, with a documented way in.
• A device that reboots into its working configuration rather than into setup mode, because a fleet that drops back to onboarding after a power cut is a support incident and, for a security product, an exposure.
• A written recovery procedure the customer can follow, in the Annex II information, rather than one that lives in a support engineer's head.

Test it the crude way. Pull the power during an update. Pull it during a write. Do it twenty times and see what fraction of units come back.

Denial of service, at your scale rather than a CDN's

Nobody expects a thermostat manufacturer to absorb a two-terabit attack, and a file that claims to would not be believed. What is expected is that the product does not fall over to trivial input, and that it does not do the attacker's work for them.

The controls are unglamorous. Bounded queues and bounded allocation driven by network input, so a malformed length field cannot ask for a gigabyte. Timeouts on every socket, including the ones in the library you did not write. Connection caps. Rate limits on anything reachable without authentication. Fuzzing for the parsers that face untrusted input, which is the cheapest high-yield testing available to an embedded team.

The denial of service you build yourself

A distinct and common class of finding, and the one worth looking for first because it does not need an attacker with resources.

• An account lockout any stranger can trigger. Ten wrong passwords from anywhere locks the legitimate user out of their own door. Prefer exponential backoff, and rate limit by source before you lock by account.
• A log that fills the filesystem, after which the product stops doing something important. Rotation with a hard cap, and a decision about what happens when the cap is reached.
• A reconnection storm. The backend has a ten-minute outage, and every unit in the fleet retries at the same instant when it returns, which extends the outage. Randomised jitter and exponential backoff, always.
• A memory leak that only shows up after six weeks of uptime, which is longer than any test ran.

That third one is where this point and the next become the same problem.

Point (2)(i): three ways a product hurts other people

It gets recruited

A device with a weak or shared credential and an exposed service joins a botnet and attacks somebody. The controls that prevent it are elsewhere in Annex I: secure defaults in (2)(b), access control in (2)(d), attack surface in (2)(j). What (2)(i) adds is the obligation to have considered the outcome and written it down. In an assessment this reads as a short paragraph connecting those controls to the harm they prevent to third parties, which is a different harm from the one they prevent to your customer.

It misbehaves by design

Services that answer unauthenticated requests with more bytes than they received are reflectors, and a fleet of them is an amplification network. NTP, DNS, SSDP, SNMP, CoAP and mDNS have all been used this way. The questions to answer: does the product run any of these, does it answer on an interface facing an untrusted network, is the response ever larger than the request, and is there a rate limit.

The default answer for most products is that these services should not be reachable from a wide-area interface at all. If yours must be, the response-size ratio and the rate limiting are the mitigation, and both belong in the file.

It is rude at scale

This is the one that catches well-intentioned teams, and it does not require any vulnerability. A firmware that checks for updates every sixty seconds, on the minute, is a reasonable design decision for one unit. Multiply it by the fleet and it is an attack on your own infrastructure, or on somebody else's.

The arithmetic is worth doing explicitly because the number surprises people. Four hundred thousand units, one request each per minute, synchronised to the top of the minute, is roughly six and a half thousand requests arriving inside one second. Spread the same traffic with randomised jitter across the minute and it is under seven per second.

The same applies to shared public infrastructure you do not pay for. Hardcoding a public NTP pool address, or a public DNS resolver, into a device that will ship in volume has caused real harm to volunteer-run services and has cost real manufacturers real money to fix in the field. Use the vendor pool if the project offers one, make the server configurable, and back off when you are refused.

Controls that answer this point directly: restrict outbound connections to known destinations where the deployment allows it, put randomised jitter on every periodic outbound activity, back off on failure rather than retrying harder, make every remote endpoint configurable rather than compiled in, and calculate your fleet's aggregate request rate before shipping rather than after.

What an assessor will expect

• The essential and basic function list, traceable to the risk assessment, with what each depends on.
• Resource limits and timeouts as configuration you can point at, not as an assurance.
• Results from load testing and from fuzzing the network-facing parsers.
• A recovery test with numbers: power cut during update, N attempts, N recoveries, what happened to the ones that did not.
• The egress policy, and for each outbound destination the purpose, the interval and the jitter.
• A short written analysis of how the product could be used against a third party, and what stops it. This is what point (2)(i) is asking for and it is almost always missing.

Points (2)(h) and (2)(i) are also where the reporting duty can find you later. A severe incident under Article 14 includes one that negatively affects the product's ability to protect availability. An availability design that was never tested tends to be discovered on a clock measured in hours.