Attack surface

The attack surface of a product is the sum of all the points at which an attacker can interact with it: open ports and network services, programming interfaces, user-facing controls, removable media, connectors, radio interfaces, and every function that accepts input from outside. The Cyber Resilience Act (CRA) does not define the term, but it does make limiting it a binding product requirement.

The provision is Annex I, Part I, point 2(j). Products with digital elements must be designed, developed and produced to limit attack surfaces, expressly including external interfaces.

A requirement about the product, not the process

The wording attaches to design, development and production. What it demands is a property of the shipped product, not a description of a procedure. That is why it sits in Part I of Annex I, compliance with which the manufacturer must ensure when placing the product on the market under Article 13(1). The vulnerability handling requirements in Part II are a separate matter.

What counts as an interface

The CRA works with a broad notion of connection, and every connection is a possible way in. A physical connection between electronic information systems or components is made by physical means, such as electrical, optical or mechanical interfaces, wires or radio waves. A logical connection is the virtual representation of a data connection implemented through a software interface. An indirect connection does not happen directly but as part of a larger system that is itself directly connectable.

Recital 9 gives network sockets, pipes, files and application programming interfaces as examples of logical connections. It also explains why the requirement is not confined to obviously exposed products. Hardware and software considered less critical can still facilitate the initial compromise of a device or network, and cyber threats can propagate across several products before reaching their actual target.

The “where applicable” qualifier

Point 2 of Annex I, Part I applies only “where applicable”, and it refers expressly to the cybersecurity risk assessment under Article 13(2). Article 13(3) then requires that assessment to state whether and, if so, in what manner the point 2 security requirements apply to the product and how they are implemented. For point 2(j) the consequence is that your own documented assessment sets the reasonable level in the first instance, not an authority.

Where your assessment concludes that a requirement does not apply, Article 13(4) requires a clear justification in the Technical documentation. The assessment itself belongs there too under Article 13(4) and Annex VII, point 3, and under Article 13(3) it must be documented and updated as appropriate during the support period.

Telling it apart from its neighbours

Point 2(j) sits alongside three requirements it is easily confused with:

• Point (a) requires the product to be made available without known exploitable vulnerabilities. That concerns the known defects on the attack surface, not its size.
• Point (b) requires a secure by default configuration. It determines how much of the existing surface is actually open as shipped.
• Point (j) requires the surface itself to be kept small.
• Point (k) requires the impact of an incident to be reduced using appropriate exploitation mitigation mechanisms and techniques. It only bites once an attacker has already reached the surface.

The four points read as a sequence: as few ways in as possible, as few of those open as possible, no known exploitable vulnerabilities among them, and contained damage when something gets through anyway.

New features enlarge the surface

The attack surface is the reason the CRA looks hard at new functionality. Recital 39 records that adding new features typically leads to a broader attack surface and thereby increases the cybersecurity risk. A feature update that modifies the originally intended functions or the type or performance of the product and meets the other criteria named there can therefore amount to a Substantial modification and trigger a fresh conformity assessment.

The same recital offers a concrete example: a new input element added to an application, for which the manufacturer then has to ensure adequate input validation. A pure security update does not qualify as long as it leaves the intended purpose untouched.

What the CRA leaves open

There is no metric. The CRA names neither a method for measuring an attack surface nor a threshold above which it counts as sufficiently limited. The standard “limit attack surfaces” is tied to the risk, not to an absolute number.

The requirement only becomes tractable at the evidence level. The CRA does not prescribe an inventory of the product’s interfaces, but one is the usual way to show, for each interface, why it exists, in what state it ships, and how the risk assessment treats it. Harmonised standards may put firmer criteria around this later; until then your own reasoning carries the case.