NRO Strategy 2026-28: The ROA Coverage Gap Operators Cannot Ignore
The same ticket keeps coming back across the leased prefixes my team manages: a customer with a freshly VALID Route Origin Validation status reports that a chunk of their traffic disappears for minutes at a time, and the ROA is correct every time we check. I have logged that pattern often enough to stop blaming the customer's config.
The cause sits on the other side. A relying party somewhere upstream stalls fetching the publication point, defaults the prefix into a NOT FOUND treatment, and a downstream filter drops it. Nothing is misconfigured. The signing is sound. What loses the race is the synchronization between the database and the live routing table. That recurring gap is the part of routing security I keep arguing about, and this strategy is the first registry document I have read that names it directly.
The Number Resource Organization put its name behind that argument on 11 June 2026. The RIPE Network Coordination Center published the NRO Strategy Document 2026-28, a three-year coordination plan for the five Regional Internet Registries built around governance, routing security, and IPv6. The headline reads like more inter-registry cooperation, and the trade press has covered it that way. I read it differently. Buried in the security pillar is an admission that the registries cannot keep pace with their own success: leased-prefix ROA coverage climbed from 29.9% in 2021 to 71.0% by the end of 2024, and the machinery that validates all those new objects is starting to strain.
My position is straightforward. The coverage numbers are good news, but coverage is not the same as protection, and the strategy is right to spend its security budget on reliability and threat-intelligence coordination rather than on chasing a higher percentage. For operators, that reframes the job. The work for the next three years is to make signing survive contact with real BGP, which is a harder problem than signing more prefixes.
Coverage rose fast, but it rose unevenly
The leased-market figure is the one that should make registry stakeholders sit up. Over the same window that leased prefixes went from 29.9% to 71.0%, the global routing table as a whole moved from 33.1% to 51.5%. Commercial leasing secured itself faster than the legacy Internet did, which tracks with what I see daily: a customer leasing a block has an SLA and a counterparty to answer to, and clean Route Origin Authorizations are part of that deal.
Aggregate coverage hides the real exposure. Against a global average near 50% for routed address space, adoption collapses in exactly the sectors that can least afford a hijack.
| Segment | RPKI / ROA coverage | Why it matters |
|---|---|---|
| Leased prefixes (2024) | 71.0% | Market pressure drives signing |
| Global routing table (2024) | 51.5% | The baseline everyone shares |
| Academia / education | ~28% | Research networks left exposed |
| Government / regulatory | ~15% | High-value targets, low coverage |
| South Korea (IPv4, under APNIC) | ~2% | A regional enforcement tail risk |
These gaps create asymmetric attack surfaces. An attacker pivots through a low-coverage zone to reach a high-value target, and because validation enforcement is uneven across regions, a route flagged invalid in one jurisdiction can stay invisible to filters in another during an active incident. That is the coordination problem the strategy names, and it is why the NRO is committing to shared threat-intelligence processes and metrics rather than leaving each registry to publish its own statistics in isolation.
What the strategy actually commits the registries to
The document sets three work areas. Governance puts the NRO, founded in 2003, forward as the single point of contact with ICANN, with all outputs published openly. IPv6 gets a coordinated push across regions, framed around a future where IPv4 is no longer dominant. The security pillar is the one with operational teeth.
On security the NRO names three concrete deliverables: a Trust Anchor Constraints document, deployment of Autonomous System Provider Authorization (ASPA), and ongoing reliability improvements across RIR systems. It also commits to strengthening how the registries share threat intelligence, including new coordination processes and metrics to measure whether that sharing actually works. The metrics line is the most important sentence in the document. Today an operator cannot easily tell whether a route rejected next door was a real hijack or a sync artifact, because the registries do not publish rejection data in a comparable form. Measuring effectiveness is the prerequisite for fixing it.
Two of these deliverables address gaps I hit in production. Trust Anchor Constraints let a relying party bound which certification paths it will accept rather than trusting an entire hierarchy implicitly. ASPA closes a hole that Route Origin Validation cannot: ROV confirms the origin ASN is authorized for a prefix, but it says nothing about whether the AS path between you and that origin is legitimate. ASPA lets each provider publish its authorized customer relationships so a validator can reject a path that traverses an unauthorized upstream.
The catch is real. ASPA needs every provider in a chain to publish, whereas a ROA needs only the prefix holder. That is the structural reason path validation lags origin validation: it depends on multi-party coordination, and one party acting alone cannot get there.
The reliability gap is the deployment lesson
Here is the failure mode the marketing version of this story skips. RPKI validation depends on relying parties fetching complete, current data from remote publication points. When object counts rise, that synchronization gets slower and less reliable. As the underlying research on relying-party delay notes, some implementations cope by using timeout mechanisms to skip unresponsive publication points rather than blocking all updates. That is a sensible engineering choice with an ugly side effect: skip a point and the prefixes it would have validated fall into a NOT FOUND state until the next successful fetch.
NOT FOUND is not benign once you are enforcing policy. A prefix with a valid ROA whose publication point was skipped looks, for that interval, identical to a prefix with no ROA at all. If a downstream applies an aggressive local policy to NOT FOUND routes, legitimate traffic drops, which is exactly the incident that opened this article. The cost is real and it is measured in availability: premature rejection of valid paths happens whenever the registry database lags behind live BGP announcements. Leased blocks feel this first because they update most frequently.
This is why I read the strategy's "reliability improvements across RIR systems" as the load-bearing phrase. The registries are not promising higher coverage; they are promising that the validation pipeline holds together as coverage grows. That is the right priority, and it should change how operators sequence their own rollout.
A deployment table that respects the sync problem
The instinct after reading a coverage milestone is to flip every router to hard-fail on invalid routes. For path validation in particular, that instinct will cost you uptime during the transition. Before you enforce anything, run each prefix and peer through the checks below. The middle column is the answer that lets you proceed; the right column is why a different answer should change your call.
| What to check | A good answer | Why it changes the call |
| Does your ROV setup classify the prefix-and-ASN pair correctly on its own? | ||
| Yes, origin status is clean before any path logic runs | If you layer ASPA on top of an unverified origin, a sync failure becomes indistinguishable from a real path violation | |
| Are your own ASPA objects published in the registry? | ||
| Yes, your provider authorizations are in place before you reject anyone | Path validation only works when the chain is populated, so validating others first while you are absent breaks legitimate paths | |
| Is a NOT FOUND on your leased prefix a real gap or a skipped publication point? | ||
| You have confirmed it is a genuine gap rather than a stalled fetch | A skipped point makes a valid prefix look unsigned, so dropping it on policy takes down traffic that was never at fault | |
| Has this peering set demonstrated stable, repeatable synchronization? | ||
| Yes, in a soft logging mode that flagged anomalies without dropping | Hard-drop before the peer is proven turns every transient sync hiccup into a customer-visible outage; move one peer at a time | |
| Which blocks update fastest and expose sync lag first? | ||
| Your leased prefixes, instrumented specifically | A global coverage average hides the lag on exactly the blocks that change most and feel it first |
I cannot hand you a single right timeout value. The source does not give one, and the correct number depends on your relying-party software and how far it sits from the publication points. The discipline is to measure your own synchronization latency before you choose a threshold. A figure copied from an article will not match your topology.
About
I am Evgeny Sevastyanov. I lead customer support at InterLIR, a Berlin-based IPv4 marketplace, and I work from Varna. Most of my hours go into creating and maintaining objects in the RIPE and APNIC databases for clients leasing and transferring address space, which seats me at the operational end of the validation problems this strategy describes.
My credentials sit on two sides of this work. I hold the RIPE Database Associate certification on the technical side and a Master's in International Commercial Law on the policy side, and I am finishing a PhD in public law. I stay on IPv4 because that is where most of the working Internet still lives and where my clients need clean, well-documented resources today. When a ROA breaks, the call lands with my team, so I read a document like this one for what it does to a database object once the press release is forgotten.
Conclusion
So let me restate the position I came in with. The NRO Strategy 2026-28 is being reported as a coverage milestone, and the 71.0% leased-prefix figure earns that attention. The more useful reading is in the security pillar, where the document admits that signing prefixes ran ahead of the registries' ability to validate them reliably, and commits its budget to fixing the pipeline instead of pushing the percentage higher. Trust Anchor Constraints, ASPA, reliability work, and measurable threat-intelligence sharing all aim at one target: validation that holds up under real BGP conditions.
That is the argument I have been making at the database object level for years, now written into a three-year plan. Coverage tells you a ROA exists. Reliability tells you it will do its job on a bad afternoon when a publication point stalls and a downstream filter is unforgiving. The registries have chosen to spend the next three years on the second one, and that is the right call for the people who actually answer the tickets.
Frequently Asked Questions
Not by itself. Coverage means a ROA exists, but protection depends on relying parties fetching that data reliably from publication points. When synchronization lags during high object volumes, a valid prefix can briefly fall into a NOT FOUND state and be dropped by downstream policy, so high coverage reduces risk without eliminating availability problems.
Route Origin Validation only confirms that the origin ASN is authorized to announce a prefix. ASPA validates the AS path itself by letting each provider publish its authorized customer relationships, which catches route leaks through unauthorized upstreams that origin validation alone cannot detect. The tradeoff is that ASPA needs every provider in the chain to publish, while a ROA needs only the prefix holder.
As the number of RPKI objects grows, relying-party synchronization becomes slower, and some implementations skip unresponsive publication points to avoid blocking all updates. A prefix whose publication point was skipped temporarily looks the same as an unsigned one, so if a downstream applies strict policy to NOT FOUND routes, legitimate traffic can be dropped until the next successful fetch.
I would not, especially for ASPA path validation. Phase it in with logging so you flag anomalies without dropping traffic, confirm your peering set synchronizes reliably, then move to hard-drop one peer at a time. Going straight to hard-fail across the board turns every transient sync failure into a customer-visible outage during the transition period.
Adoption tracks incentives and enforcement, not just availability. Leased prefixes hit 71% because the commercial market ties signing to SLAs, while academia sits near 28%, government near 15%, and South Korea around 2% for IPv4, where there is no comparable pressure. Those low-coverage zones create asymmetric attack surfaces that the NRO strategy aims to address through coordinated threat-intelligence sharing.
