Summary

  • RIPE NCC's public member list includes Nebius B.V., and registry whois answers for that operator's footprint return five autonomous system objects, named NebiusMAD, NebiusPA10, CoreNebiusNet, NebiusCloud and NEBIUS-UK, with the shared organisation handle ORG-NB187-RIPE attached to three of them.
  • Announced-prefix data retrieved on 2026-10-21 shows four of the five originating address space, between five and twenty-seven prefixes each, while CoreNebiusNet returned an empty prefix list and an as-overview record saying announced: false.

A registry is not a marketing surface. It is where a network number becomes a name that other networks can act on, and where an upstream, a filtering service or an auditor looks when it has to decide whose traffic it is handling. For anyone whose workloads sit behind an AI cloud contract, the shape of the operator's registry entry is therefore a working document, not a footnote.

RIPE NCC's list of members records Nebius B.V. in the Netherlands (RIPE NCC member list). The directory record for the company treats that listing strictly as membership and number-resource context, and states that membership alone does not establish that the entity sells ISP, IP transit, cloud, registry or managed-network services (directory entry). The network numbers themselves come from the registry's own answers.

On 2026-10-21, whois responses returned through RIPEstat showed five autonomous system numbers whose as-names carry the Nebius token. AS203326 answers with the as-name NebiusMAD together with the organisation key ORG-NB187-RIPE (AS203326 whois). AS214415 answers NebiusPA10 with the same organisation key (AS214415 whois), and AS215169 answers CoreNebiusNet with that key a third time (AS215169 whois). The pattern stops there: AS213291 returned only the as-name NebiusCloud (AS213291 whois) and AS211318 only NEBIUS-UK (AS211318 whois), with no organisation key in the excerpts obtained.

Four numbers originate, one stays empty

The forwarding side of the record is uneven. In the same day's announced-prefix snapshots, AS203326 announced five prefixes (AS203326 prefixes), AS214415 thirteen (AS214415 prefixes), AS213291 twenty-seven (AS213291 prefixes) and AS211318 six (AS211318 prefixes). AS215169 returned an empty prefix array (AS215169 prefixes), and the as-overview record for the number reports its holder as "CoreNebiusNet Nebius B.V." with announced set to false (AS215169 overview).

A registered autonomous system that originates nothing is an ordinary object to find in a registry. It can be a reservation, a number held through a migration, a system used only internally, or an entry simply left standing after a change. The record cannot distinguish those cases, and it should not be asked to. What it does say is narrow and checkable: on that date no globally visible prefix was originated by that number, so any claim that CoreNebiusNet carries a customer's traffic needs evidence from somewhere other than the registry.

The tokens in the names are registrant choices. MAD, PA10, Cloud, Core and UK describe how someone inside the organisation decided to label a record. They are not registry fields, not locations, and not declarations of function.

The interconnection record does not follow the labels

The one interconnection record obtained does not support reading those tokens as geography. PeeringDB's entry for AS213291 names the organization as Nebius B.V., the network type as Content, and lists four facilities: Digita Helsinki Pasila Broadcasting Tower, Elisa Helsinki Lauttasaari, Equinix AM7 in Amsterdam and Equinix FR5 in Frankfurt (PeeringDB AS213291). There is no Madrid site and no Pennsylvania site on that list. If the MAD and PA10 labels describe places, the registry and the facility record do not show it.

What this record does not establish

The gaps are specific rather than vague. Nothing obtained for this review contains the rest of the aut-num objects: no description, origin, maintainer, creation or last-modified field was retrieved for any of the five numbers. The ORG-NB187-RIPE organisation object text was not obtained. PeeringDB records for AS203326, AS214415, AS215169 and AS211318 were not obtained either, and the failed lookups were access failures, not empty records, which is a different fact and should not be read as absence. No RIPE NCC database web-interface rendering was captured.

No Nebius Group filing, annual report or investor document naming an autonomous system was read.

On the company's own account, nebius.com presents Nebius as an artificial-intelligence cloud provider offering GPU clusters, high-speed networking, managed inference and training tools, and identifies Nebius B.V. as the legal entity operating the service (nebius.com). The documentation portal covers virtual machines, GPU clusters, Kubernetes and VPC networking, but contains no human-readable mapping from a RIPE-registered autonomous system number to an operational role, a site or a service (docs.nebius.com). Two documents, one number, no bridge.

The instrument that would settle the question is a specific class of document rather than more of the same data: a first-party network or peering page that names an AS number, an RIR object that cross-references the number to a role, or a filing that assigns one. Until a document of that kind exists in readable form, the strongest defensible statement is the observation itself, dated 2026-10-21.

For a buyer the consequence is concrete. A contract can name a legal entity and a service region without ever naming the autonomous system that carries the traffic, and the registry will not close the gap on its own. Asking which number originates the customer's prefixes, and who holds the credentials that change those announcements, is a question the public record can later confirm or contradict.