Summary

  • COM(2026) 13 would expand ENISA’s registry to essential and important entities and domain-name registration service providers.
  • The same proposed paragraph lets competent authorities request access to information about a named list of service-provider categories and air carriers. It does not name essential and important entities as a class.

A registry can grow in one sentence. The right to read it gets its own sentence. In the Commission’s NIS2 simplification proposal, those sentences describe different groups.

Under today’s NIS2, Article 27 gives ENISA a registry built around specified digital-service providers: DNS services, top-level-domain registries, cloud and data-centre providers, content-delivery networks, managed services and several online platforms. National single points of contact forward the information under that article. On request, ENISA gives competent authorities access to information about the categories named in the access clause, with confidentiality protected where applicable.

Essential and important entities sit in a different part of the current system. Article 3(4) requires Member States to maintain national lists and collect information about those entities, including their IP address ranges. That information stays on the national route under the current Article 27 forwarding rule. The directive’s current text explicitly leaves the provider IP-range field in Article 27(2)(f) out of the information sent to ENISA.

The Commission’s proposal redraws the map. Its replacement Article 27(1) says ENISA will maintain a registry of essential and important entities as well as entities providing domain-name registration services, using information received from national single points of contact. The proposal deletes the old separate provider list in Article 27(2) and routes Article 3(4) information into the registry. The current carve-out for IP ranges disappears from that forwarding path.

That is an intake change. The access sentence is a separate control.

Question Current directive Commission proposal
Who is in ENISA’s Article 27 registry? Named service-provider categories Essential and important entities, domain-name registration services and the other categories named in the access sentence
Which records can competent authorities request through Article 27(1)? Information about the named provider categories The sentence still names provider categories and air carriers; it does not name essential and important entities as a group
Where do entity IP ranges go? National lists; the current forwarding rule excludes Article 27(2)(f) Article 3(4) data would feed the ENISA registry, with no matching IP-range exception in the proposed forwarding clause

The gap is visible in the proposal’s own grammar. The first sentence broadens the registry to essential and important entities. The next sentence says that, on request, ENISA shall give competent authorities access to information “concerning” a long list: DNS providers, TLD registries, domain-name registration services, cloud and data-centre providers, content-delivery networks, managed services, online marketplaces, search engines, social-networking platforms and air carriers. Essential and important entities are not separately named in that list.

The proposal leaves one precise point open: whether this access right includes records for essential and important entities. Elsewhere, it assigns ENISA cross-border support and risk analysis involving those entities. The draft therefore answers one question cleanly—what the registry will contain—and leaves another to interpretation: which authorities can query which records. ENISA’s own analysis, a national authority’s access request and an entity’s national supervision are different acts. The text should make their boundaries legible instead of leaving readers to infer that one sentence silently does the work of the next.

IP ranges make the distinction concrete. A range attached to an entity is useful only in relation to a task: matching network evidence to the responsible organisation, coordinating across borders, or supporting a supervisory inquiry. RIPE NCC’s response to the Commission, filed on 12 May, asks what security purpose requires those ranges, which information entities should report, how to avoid duplicate reporting and what cost-benefit case supports the collection. Those questions concerned the data field. The access clause adds another: after the field enters ENISA’s registry, who may retrieve it, for which entities, and under what rule?

There is a respectable case for a broad registry and a narrow access gate. ENISA may need a cross-border view while competent authorities should see only records tied to their duties. But if that is the design, Article 27 should say so. It should distinguish ENISA’s analytic use from authority queries, identify whether the new essential-entity records are accessible on request, and define the purpose attached to a query. A list that expands quietly while access remains partly implicit is an invitation to divergent national readings.

An October 21 RIPE Labs update reports that the rapporteur’s draft favors data minimisation and national oversight of IP ranges. The European Parliament’s procedure page still lists the file as awaiting committee decision; it records a draft report from 24 September and amendments tabled on 13 October. The committee can still align the two clauses before the proposal becomes law. The useful test is simple: take one essential entity’s registry record and ask whether a competent authority can request it under Article 27(1), which authority can do so, and why. Article 27 should answer those questions in its operative text.

A recital, side letter or reader’s guess cannot set the access boundary.

Sources: NIS2 Directive · Commission proposal COM(2026) 13 · RIPE NCC response, 12 May 2026 · RIPE Labs, October 2026 update · European Parliament procedure 2026/0012(COD)