reg-nr in the RIPE Database: One Attribute, and the Identity Trap It Doesn't Solve
A buyer on my desk last quarter read the RIPE announcement correctly and then drew the wrong conclusion from it. He saw "new identity attribute," and told me he could finally automate his pre-purchase checks against a single clean field. The headline was right. His takeaway was not, and it would have cost him a week of false alarms before he noticed.
Here is what he was actually up against. Two of his target organisations had the same legal name, the same string, registered in two different countries, both holding RIPE space, both showing up in WHOIS as a tidy `organisation:` line that says almost nothing about which one you are looking at. The new attribute does help with that narrow case. What it does not do is the broad, automated identity sweep he had already started designing around it. That gap, between what the field is and what people assume it is, is the small problem the RIPE NCC just put a tool against, and the larger one it quietly created.
As of 30 April 2026, the RIPE Database carries a new `reg-nr:` attribute. It holds the official company registration number of a resource holder, and it sits on `organisation` objects that the RIPE NCC co-maintains. The point is narrow and useful: when two organisations share a name, the registration number is the thing that doesn't collide. The work landed through NWI-21, was first floated at RIPE 91, chewed over in the Database Working Group, and shipped ahead of RIPE 92. The announcement reads like a quiet win, and on its own terms it is one.
My job is to push on it anyway, because in client work "we added an identity field" reliably curdles into "everyone assumes the field means more than it does." `reg-nr:` is a label on data the registry already held. It records no fresh verification event, it does not appear everywhere, and treating it as a clean identity signal across the whole database is exactly the mistake that will bite a due-diligence workflow.
What actually shipped, and what was already there
Start with what the launch was, because the framing decides how you should read every populated field. The RIPE NCC was not out collecting fresh company registration numbers when this shipped. By its own technical accounting, the registry already holds verified legal information for roughly 99% of the resource holders that are legal entities. The `reg-nr:` attribute publishes that existing verified data into a structured, queryable field. What is new is the surface. The underlying check was always there.
That distinction is the whole reason the rollout could happen on a single date rather than over a multi-year collection campaign. The path to 30 April ran through a Release-Candidate environment and a production update on 4 March 2026, both ordinary RIPE Database release steps, before the attribute became live. No new burden landed on members for the bulk of objects; the data was sitting in the registry's records already.
So when you query a populated `reg-nr:`, you are reading something the RIPE NCC vouched for as part of normal membership verification. When you query one that is empty or marked "Not applicable," you are not looking at a gap in someone's paperwork. You are looking at a category boundary, and confusing those two readings is where operators get into trouble.
"Not applicable" is a privacy decision the rule made on purpose
The attribute does not apply to every `organisation` object, and the exceptions are deliberate. For natural persons and for governmental organisations, the published value is the literal string "Not applicable." That string is a privacy choice the registry made on purpose. A natural person's company registration number is personal data with no business being broadcast in a public registry, and the sovereign status of a government body sits outside the commercial-entity logic the attribute was built for.
Here is the failure mode I keep flagging for clients who automate against WHOIS. A script that treats "Not applicable" as an error condition will generate a steady stream of false alarms. Worse, escalating those "incorrect" entries as discrepancies draws manual attention to exactly the objects the privacy rule was meant to leave alone. The correct handling is to parse "Not applicable" as a terminal, valid state and move on, never as a synchronisation failure to be chased.
| `organisation` object type | What `reg-nr:` shows | How to read it |
|---|---|---|
| Co-maintained commercial entity | Official company registration number | Verified identity signal, safe to cross-check |
| Natural person | "Not applicable" | Privacy exemption, not a gap |
| Governmental organisation | "Not applicable" | Deliberate exclusion, not an error |
| Object not co-maintained by RIPE NCC | Attribute absent | Out of scope, not a defect |
The fourth row is the one most people miss. The attribute lives on RIPE NCC co-maintained objects. Legacy and self-maintained `organisation` objects outside that scope simply will not carry it, and that absence says nothing about the holder's legitimacy. Any tool that scores "no `reg-nr:`" as a red flag is measuring the maintainer relationship and mistaking it for a judgment about the entity.
Why this is a RIPE thing and not an ARIN or APNIC thing
If you operate across regions, do not expect to write one identity-resolution routine that spans all five RIRs. The registries model entity identity differently, and `reg-nr:` is a RIPE-specific answer to a RIPE-specific data shape. ARIN keys organisations through its Org ID structure. APNIC leans on person, role, and IRT objects. Neither currently exposes a directly equivalent, standardised "registration number" field in the same way.
The practical consequence is that cross-RIR due diligence stays manual at the seams. A registration number you can pull cleanly from a RIPE `organisation` object has no one-to-one counterpart you can pull the same way from ARIN or APNIC. I would rather say that plainly than let a client build a pipeline on the assumption of symmetry that isn't there. The RIPE improvement is real; it is also local to RIPE.
Reading the database without tripping its guards
The other place I see automation go wrong is volume. The RIPEstat Data API caps you at 8 concurrent requests from a single IP. Push past that with a parallel verification sweep and you do not get throttled gracefully, you get refused, and a bulk job that assumed it could fan out wide stalls outright. The fix is dull and reliable: serialise, keep concurrency under the ceiling, and back off on rejection rather than hammering through it.
The database also actively "dummifies" certain outputs to stop bulk harvesting of personal data, and enforces limits on how many personal objects you can query in a rolling 24-hour window. For `reg-nr:` work this rarely bites, because the attribute you care about lives on commercial objects, but it is worth knowing the masking exists. If a personal-object query starts returning thinner data than you expected, you have hit a privacy guard, not a bug. Unfiltered access to maintainer-scoped detail goes through an authenticated API key tied to the relevant maintainer; unauthenticated requests over the RESTful API (which requires HTTPS) return the sanitised view by design.
Here is the field checklist I hand to clients standing up `reg-nr:` checks. Run it in order before you trust a single result:
- Treat "Not applicable" and an absent attribute as valid end states, and never escalate either one as an error.
- Confirm the object is RIPE NCC co-maintained before you expect the attribute to be present at all.
- Keep concurrency at or below 8 requests per source IP, with backoff on refusal.
- Send any genuine correction to [email protected], and keep it out of your own update tooling.
- Do not assume ARIN or APNIC objects carry an equivalent field.
When the number really is wrong
Sometimes a published registration number genuinely is incorrect or incomplete. The RIPE NCC's route for that is a single channel: email [email protected], and the Member Services team follows up. There is no self-service override on a co-maintained attribute, and that is the right design, because the value's worth comes from the registry standing behind it rather than from any holder being able to rewrite it at will.
If you find a real discrepancy, report it through that mailbox with the org handle and the supporting registry document, then let Member Services reconcile it against their records. For "Not applicable" entries there is nothing to report; the value is correct as published.
About
I am Vladislava Shadrina, a Customer Account Manager at InterLIR Marketplace, working remotely from Tbilisi. I trained in architecture and interior design before I moved into IP resources, and that older habit of mind still shows up in how I read a registry: a structure is only as sound as the joints you cannot see. My clients come to me to acquire and hold IPv4 space cleanly, so I live in WHOIS and `organisation` objects on their behalf, where transparency and a reputable block are the whole job.
That is why `reg-nr:` lands for me in concrete terms. When a buyer is checking who really holds a block, a verified registration number gives the answer one more place to stop being a guess. The other half of my week is reassurance, telling a worried client that an empty field is exactly as the rules intend, which is the part that pushed me to write this up with the boundaries spelled out plainly.
Conclusion
`reg-nr:` is a clean, well-scoped improvement. It surfaces registration numbers the RIPE NCC already verified, onto the co-maintained objects where name collisions actually hurt, and it shipped without dumping new work on the membership. The exposure sits entirely in how you read it. The attribute is partial by design, "Not applicable" is a valid answer rather than an error, and its reach stops at the edge of the RIPE region.
Here is your next move, concretely. Before your next due-diligence run, open your verification script and add three guards: accept "Not applicable" and an absent attribute as passing states, gate the `reg-nr:` lookup on the object being RIPE NCC co-maintained, and cap concurrency at 8 per source IP with backoff. Then route one test discrepancy through [email protected] to confirm your team knows the path. Ship that small patch first, and only then point the field at real buying decisions.
Frequently Asked Questions
It holds the official company registration number of a resource holder, attached to `organisation` objects that the RIPE NCC co-maintains. Its purpose is to tell apart organisations whose names are similar or identical, using a number that does not collide the way a name can.
That value is a deliberate privacy decision for natural persons and governmental organisations, not a missing or broken entry. Automation should treat "Not applicable" as a valid terminal state and never escalate it as a data discrepancy.
No. The registry already held verified legal information for roughly 99% of resource holders that are legal entities, and the attribute simply publishes that existing data in a structured, queryable field. That is why the rollout could land on a single date rather than over a long collection effort.
No. The attribute is specific to the RIPE Database; ARIN uses Org IDs and APNIC uses person, role, and IRT objects, with no directly equivalent standardised field. Cross-RIR identity checks still need manual handling at the seams rather than one shared lookup.
Email [email protected] with the organisation handle and your supporting document, and the Member Services team will follow up and reconcile it. There is no self-service edit on a co-maintained attribute, and an "Not applicable" entry is correct as published, so there is nothing to report for those.
