Cyber Resilience Act
Logical connection
Legal definition Art. 3(8) CRA
“a virtual representation of a data connection implemented through a software interface”
A logical connection is, under Article 3, point (8) of the Cyber Resilience Act (CRA), a virtual representation of a data connection implemented through a software interface. The term describes a connection at the level of software rather than at the level of the transmission path. Whether a cable sits underneath it, a radio link, or no physical medium at all, makes no difference to it.
It is one of three connection terms the CRA defines for itself and that Article 2(1) brings together to set the scope of the Regulation: logical in point (8), physical in point (9), indirect in point (10). That test as a whole is explained under data connection. This page deals with the variant that settles the question for pure software.
What the wording requires
Two elements sit inside the definition. There has to be a data connection, and it has to be implemented through a software interface. The real weight lies in the phrase “virtual representation”: what is described is not the transmission path itself but its representation in software. One physical line can therefore carry many logical connections, and a logical connection can exist where no dedicated transmission path is present at all.
Data is part of the definition itself. The physical connection is drafted differently: Article 3, point (9) describes only the physical means by which a connection is implemented and does not mention data. It is Article 2(1) that requires a data connection for both kinds. As a matter of definition, then, there is no such thing as a logical connection without an exchange of data.
Point (9) also names what is connected: electronic information systems or components. Point (8) names nothing of the sort. Where a logical connection has to lead follows only from Article 2(1), which says “to a device or network”.
What counts as a software interface
The CRA does not define the phrase “software interface”. Recital 9 does supply examples and makes the reach plain: network sockets, pipes, files and application programming interfaces, plus an express catch-all for “any other types of software interface”. The list is therefore open.
Two entries deserve particular attention, because neither needs a network. A pipe connects two processes on the same machine. A file connects them even across time: one program writes, another reads later. Treating the term as a synonym for network capability reads it far too narrowly.
Why this settles the question for software
Recital 9 draws the connection itself. The duty to design and develop products in line with the essential cybersecurity requirements is meant to cover both products that can be connected physically through hardware interfaces and products that are connected logically.
For a product with no hardware of its own, the logical connection is therefore the only route into scope, and it is a broad one. An application that reads a file, a library with a public interface, a service that opens a port: all three meet the criterion. Building the opposite case for a software product rarely succeeds.
What turns on the kind of connection
As far as the manufacturer’s obligations go, nothing. Article 2(1) asks for a direct or indirect, logical or physical data connection, and one variant is enough. Once a product is in scope, the Annex I requirements apply whichever variant it was. The conformity assessment procedure likewise follows Article 32 and the product category, not the kind of connection.
“Logical” and “indirect” also sit on different axes. The indirect connection says something about whether a connection is made immediately or through a larger system. A logical connection can be either. Keeping the four combinations properly apart saves a good deal of pointless argument.
Where the term appears in the Regulation
Exactly three times: in the definition in Article 3, point (8), in the scope condition in Article 2(1), and in recital 9. Nowhere does the CRA attach an obligation of its own to logical connections.
They still surface in the paperwork indirectly. Annex VII, point 2(a) requires the technical documentation to set out the necessary information on design and development, where applicable including a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing. That is a description of a product’s logical connections. Annex I, Part I, point 2(j) adds the requirement to limit attack surfaces, expressly including external interfaces.
A plain list of the interfaces through which the product takes in and gives out data is therefore worth the effort. It answers the entry question under Article 2(1) and then serves as the basis for the risk assessment and the architecture description.
A frequent confusion
Annex III, class I, point 10 lists “physical and virtual network interfaces” among the important products. That is a product category under Article 7, not a statement about kinds of connection. For a class I important product, Article 32(2) narrows the choice of conformity assessment procedure as soon as harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least “substantial” have not been applied, or have been applied only in part, or do not exist. A logical connection carries no such consequence.
Practical questions
-
Recital 9 names pipes and files expressly as examples, and neither needs a network. Article 2(1), however, asks for a data connection “to a device or network”, and the CRA does not say outright whether the machine itself is that device. The wording of the recital points that way. In practice the question rarely decides anything, because a product that talks locally to other programs almost always has further interfaces as well.
-
The public interface of a library is a software interface, and recital 9 names application programming interfaces expressly. A second route leads to the same result: a library is as a rule a Component, meaning software intended for integration into an electronic information system. Article 3, point (10) then makes it sufficient that the larger system is itself directly connectable to a device or network. Which of the two routes applies makes no difference to your obligations.
-
Nothing changes about scope if the product was already covered. Two other points need checking. Article 13(3) requires the cybersecurity risk assessment to be documented and updated as appropriate during the support period, and an additional interface enlarges the attack surface. Recital 39 adds that a substantial modification may arise where the nature of the hazard has changed or the level of cybersecurity risk has increased because of the update and the new version is made available on the market.
This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.