ROA Coverage vs ROV Adoption in 2026: Why the Routing Security Gap Matters

ROA Coverage vs ROV Adoption in 2026: The Short Answer

RPKI deployment is growing quickly, but publishing Route Origin Authorizations and actually enforcing Route Origin Validation are not the same thing.

APNIC’s February 2026 global routing-security analysis found that approximately:

• 60.3% of observed IPv4 routes were RPKI Valid

• 37.7% were Not Found

• 2.0% were Invalid

For IPv6:

• 60.9% were Valid

• 36.1% were Not Found

• 3.0% were Invalid

At the same time, APNIC’s measurement of Route Origin Validation found only about 26.6% of measured vantage points globally supporting ROV.

By late July 2026, APNIC Labs data cited in its analysis of India placed the global ROV figure at approximately 26.92%.

The conclusion is important:

The Internet is making faster progress in publishing routing authorization data than in consistently enforcing that data in live routing decisions.

For network operators, this means creating a ROA is an important step—but it is not the end of the routing-security process.

What Is ROA Coverage?

A Route Origin Authorization, or ROA, is a digitally signed RPKI object that states which Autonomous System is authorized to originate routes for one or more IP prefixes.

For example:

Prefix:     203.0.113.0/24
Origin ASN: AS64500

A ROA can authorize AS64500 to originate that prefix.

Under the current IETF specification, RFC 9582, a ROA provides a cryptographically verifiable way to determine whether an IP address block holder has authorized an AS to originate specified prefixes.

When analysts talk about ROA coverage, they are broadly asking:

How much of the visible routing table is covered by RPKI authorization information?

A route can then typically fall into one of three origin-validation states:

Valid
A covering ROA exists and the observed origin ASN and prefix length are permitted.

Invalid
A covering ROA exists, but the observed origin or prefix length does not match the authorization.

Not Found
No relevant validated ROA information covers the route.

These states describe the relationship between routing announcements and available RPKI data.

They do not automatically describe what an individual network does with that information.

That is where ROV comes in.

What Is Route Origin Validation?

Route Origin Validation (ROV) is the process of comparing BGP routes against validated RPKI information and using the resulting state as part of routing policy.

The basic idea is straightforward.

Suppose a network receives:

203.0.113.0/24 → AS64500

and RPKI data authorizes:

203.0.113.0/24 → AS64500

The route can be considered RPKI Valid.

But suppose the network instead receives:

203.0.113.0/24 → AS64501

while the ROA only authorizes AS64500.

That route may be classified as Invalid.

A network performing ROV can then apply policy to that result—for example, rejecting or otherwise de-preferencing Invalid routes.

RFC 6811 describes the origin-validation mechanism used to determine whether the AS claiming to originate a prefix is authorized to do so.

The distinction is therefore:

ROA = published authorization

ROV = operational use of that authorization

Both matter.

Global ROA Coverage Passed 60% in 2026

APNIC’s February 2026 routing-security snapshot showed an important milestone.

IPv4

IPv6

Source: APNIC — Routing security in APAC: Trends from the APNIC region

APNIC reported that IPv4 Valid coverage had increased by roughly six percentage points from February 2025.

IPv6 Valid coverage had increased by approximately seven percentage points.

That represents meaningful progress.

More resource holders are publishing cryptographically verifiable routing authorizations.

But the global ROV figure tells a different story.

ROV Adoption Is Still Far Behind ROA Coverage

In the same 2026 analysis, APNIC estimated that only 26.6% of measured vantage points globally supported ROV.

Regional results varied substantially:

Source: APNIC, February 2026.

By late July 2026, APNIC Labs data cited in a separate analysis placed measured global ROV adoption at approximately 26.92%.

The precise percentage should be interpreted carefully because ROV measurement is methodology-dependent.

ROA coverage and ROV deployment are also not directly equivalent metrics.

ROA coverage measures authorization information associated with routes.

ROV measurements attempt to infer network behavior from observed routing outcomes and measurement vantage points.

Therefore, it would be misleading to simply subtract one percentage from the other and call the result an exact “security gap.”

What the data does show clearly is a broader pattern:

Publishing ROAs has progressed substantially faster than operational deployment of validation policies.

Why ROA Coverage and ROV Adoption Are Different

Creating a ROA and deploying ROV involve different operational decisions.

For a resource holder, creating a ROA is largely an authorization task.

The operator identifies:

• the prefix;

• authorized origin ASN;

• permitted prefix length.

The ROA can then be published through the RPKI system.

ROV is different.

A network performing validation has to integrate RPKI-derived information into production routing policy.

That can affect routes received from:

• customers;

• peers;

• transit providers;

• route servers.

Operators therefore have to consider what happens when a route is classified Invalid.

Will it be:

• rejected?

• de-preferenced?

• monitored first?

• accepted temporarily while an exception is investigated?

This operational impact helps explain why validation deployment often progresses more slowly than ROA creation.

Why Operators May Be Cautious About ROV

APNIC’s 2026 analysis identified several recurring concerns.

These include:

• fear of accidentally dropping legitimate traffic;

• incomplete validation across customer networks;

• legacy provisioning systems;

• concern about stale or incorrect ROAs;

• operational complexity;

• inconsistent automation;

• uncertainty around exceptions.

These are not arguments against ROV.

They show why routing-security deployment needs good operational processes.

A network can create a valid ROA today and accidentally make legitimate routes Invalid tomorrow if its production routing changes but the authorization does not.

For example:

Original routing:
203.0.113.0/24 → AS64500

ROA:
203.0.113.0/24 → AS64500

Everything aligns.

Then the organization migrates to:

203.0.113.0/24 → AS64501

but leaves the ROA unchanged.

The production route is legitimate operationally.

The authorization is stale.

Networks enforcing ROV may now treat the announcement as Invalid.

NRS discusses this wider operational problem in What Happens When Internet Routing Goes Wrong?.

Routing Authorization Must Track Routing Reality

This is one of the most important lessons from the ROA–ROV gap.

RPKI works best when its authorization data accurately reflects intended routing.

That requires coordination between:

Registry and resource administration

Who administers the IP resource?

RPKI authorization

Which ASN is authorized to originate it?

BGP configuration

Which ASN is actually originating the route?

Operational change management

Has the network changed provider, ASN, prefix length or routing architecture?

These systems are connected.

But they are not the same system.

A ROA is not a BGP announcement.

A BGP announcement is not a registry record.

A registry record is not proof of current route authorization.

Good network operations keep the layers aligned.

South East Asia Shows How Fast ROA Coverage Can Grow

Regional RPKI statistics also show that adoption can change quickly when operators coordinate.

APNIC’s February 2026 IPv4 figures showed:

Source: APNIC.

The difference between South East Asia and East Asia is striking.

South East Asia had more than 92% Valid IPv4 ROA coverage, while East Asia remained at approximately 31%.

This demonstrates that RPKI adoption is not simply a function of technology availability.

Regional operator communities, incentives, training, large network participation and infrastructure policies can all influence adoption.

IPv6 Shows the Same Uneven Pattern

APNIC’s IPv6 data shows similarly significant regional variation.

These figures are particularly interesting because they show that IPv6 deployment does not automatically produce uniform RPKI deployment.

Some regions have near-complete authorization coverage.

Others remain far behind.

This matters because IPv6 is not inherently protected from route-origin mistakes simply because it is newer than IPv4.

Routing-security processes still need to be implemented.

Indonesia Shows What Coordinated Deployment Can Achieve

Indonesia provides one of the clearest recent examples of rapid RPKI progress.

APNIC reported that Indonesia moved from a little over 60% IPv4 ROA coverage to approximately 90.6% by late 2025.

By early 2026, around 22% of Indonesian networks were measured as performing ROV and dropping Invalid routes.

APNIC also highlighted the role of the Indonesian Internet Exchange.

The IIX adopted a drop-invalid policy in its route-reflector environment, creating a stronger incentive for participating networks to maintain correct ROAs.

Indonesia’s experience demonstrates something important:

ROA adoption can move quickly when technical tooling, operational incentives and community coordination reinforce one another.

But it also demonstrates that authorization coverage and enforcement still progress at different speeds.

India Shows the Gap Even More Clearly

India offers an even stronger example.

According to APNIC Labs data cited in August 2026, by late July:

• 88.04% of IPv4 routes were covered by valid ROAs;

• 97.91% of IPv6 routes were covered by valid ROAs.

Yet measured ROV deployment was only:

0.99%

That compared with:

• 3.14% for South Asia; and

• 26.92% globally under the same APNIC Labs measurement.

The point is not that India’s routing infrastructure is uniquely insecure.

ROV measurement has limitations, and individual networks may deploy routing controls that are not fully visible through every external measurement technique.

But the contrast is still useful.

It demonstrates that:

High authorization coverage does not automatically mean widespread enforcement.

A region can make substantial progress publishing ROAs while still having significant work remaining on validation.

Why a Valid ROA Is Only Half of the Operational Story

Consider a prefix protected by a correct ROA.

That improves the routing-security environment because networks can determine which origin ASN has been authorized.

But if another network never performs validation, the authorization may not affect its route-selection policy.

Conceptually:

Resource holder
     ↓
Publishes ROA
     ↓
RPKI repository
     ↓
ROV-capable network
     ↓
Validate route
     ↓
Apply routing policy

Publishing the ROA creates the security signal.

Validation turns that signal into operational action.

The Internet needs both.

What Does RPKI Valid Mean?

A Valid route broadly means that available RPKI information authorizes the observed origin relationship.

For example:

ROA:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64500

The authorization and observed origin align.

However, Valid does not mean:

• the route is necessarily optimal;

• the AS path is trustworthy;

• no route leak exists elsewhere in the path;

• the prefix has good reputation;

• the underlying network is secure.

RPKI origin validation addresses a specific routing-security problem.

It does not solve every BGP security problem.

What Does RPKI Invalid Mean?

A route can be classified Invalid when a covering authorization exists but the observed BGP announcement does not match it.

Common causes can include:

• incorrect origin ASN;

• stale ROA after migration;

• overly restrictive maxLength;

• unauthorized announcement;

• configuration error.

An Invalid route is therefore a strong signal that something needs investigation.

But operators should avoid assuming every Invalid route is malicious.

Many Invalids arise from operational mistakes.

This is why NRS emphasizes maintaining authorization data alongside operational change processes.

What Does RPKI Not Found Mean?

Not Found means there is no relevant validated ROA covering the announcement.

It does not automatically mean the route is malicious.

In 2026, a substantial portion of the global routing table still falls into this category.

APNIC’s February data showed:

• 37.7% of IPv4 routes

• 36.1% of IPv6 routes

as Not Found.

This illustrates why incomplete ROA coverage still matters even as adoption passes 60%.

Networks cannot validate an authorization that has never been published.

Why Incorrect ROAs Can Create Their Own Operational Risk

RPKI improves routing security only if the authorization data remains accurate.

An incorrect ROA can create problems during:

• provider changes;

• ASN migrations;

• IP transfers;

• network mergers;

• prefix deaggregation;

• disaster recovery;

• infrastructure restructuring.

For example, an organization may transfer an IPv4 block and begin announcing it from a new ASN.

If the old authorization remains in place, the new route may become Invalid.

NRS has highlighted this issue in its analysis of 2026 IPv4 transfer data: the registry transfer and routing-security transition should be treated as related but separate operational tasks.

maxLength Requires Particular Care

ROAs can include a maximum prefix length.

For example:

Prefix:    203.0.113.0/24
Origin:    AS64500
maxLength: /24

This permits the /24.

But suppose the network later announces:

203.0.113.0/25

The origin ASN may still be correct.

Yet if the authorization permits only /24, the more-specific announcement may be Invalid.

Operators sometimes respond by configuring very broad maxLength values.

That can reduce accidental Invalid states—but it can also authorize more-specific announcements that were never operationally intended.

The better approach is:

Authorize what the network actually needs, and update the authorization when the network architecture changes.

ROA Coverage Does Not Mean the Whole BGP Path Is Secure

Another important limitation is scope.

Route Origin Validation answers a narrow question:

Is this ASN authorized to originate this prefix?

It does not verify the complete AS path.

Consider:

AS64510 → AS64520 → AS64530 → AS64500

A ROA may validate AS64500 as the correct origin.

That does not cryptographically verify every relationship earlier in the path.

This is why routing security remains layered.

RPKI origin validation is highly valuable.

But it is not a universal solution to:

• route leaks;

• path manipulation;

• malformed BGP attributes;

• policy mistakes;

• every form of hijacking.

Recent routing-security research continues to emphasize that origin validation solves an important class of problem while other BGP risks require additional mechanisms and operational controls.

RPKI and IRR Still Serve Different Purposes

RPKI and the Internet Routing Registry are often discussed together.

They should not be confused.

RPKI primarily provides cryptographically verifiable origin authorization.

IRR provides broader routing-policy information.

A network may therefore use:

RPKI

to verify:

Is this ASN authorized to originate this prefix?

and:

IRR

to help understand:

What routing relationships and policies has the operator registered?

NRS explains these complementary roles in RPKI vs IRR: What’s the Difference and Why You Need Both.

Neither dataset should be assumed to describe the complete running network by itself.

Why ROV Is Ultimately an Operational Decision

ROA publication can be handled largely at the resource-management level.

ROV requires production-routing decisions.

A network needs to decide:

• where validation occurs;

• how RPKI data reaches routers;

• which routing policy is applied;

• what happens to Invalids;

• how exceptions are handled;

• how failures are monitored;

• who owns the process.

That creates organizational dependencies.

Routing teams, security teams and resource administrators may all need to coordinate.

This helps explain why adoption can lag even when the underlying technology is available.

Why Large Networks Matter Disproportionately

ROV does not need every Autonomous System to deploy simultaneously before it has value.

Large transit providers, major ISPs and Internet Exchange Points can influence significant portions of Internet routing.

APNIC has highlighted how major networks and IXPs can accelerate validation by applying filtering at strategically important points.

This is one reason ROV adoption statistics should not be interpreted only as:

What percentage of ASNs deploy it?

The position of those ASNs within the routing topology also matters.

A relatively small number of highly connected networks can affect routes seen by a very large portion of Internet users.

Why IXPs Can Accelerate ROV Deployment

Internet Exchange Points can also help.

Many IXPs operate route servers through which numerous networks exchange routing information.

If an IXP route server performs RPKI validation and applies appropriate policy, participating networks can benefit from centralized routing-security improvements.

Indonesia’s experience demonstrates this effect.

The same principle has been observed elsewhere:

Shared infrastructure can lower the operational cost of adopting good routing-security practices.

This does not eliminate the need for individual networks to understand RPKI.

It can accelerate adoption.

What Network Operators Should Audit in 2026

ROA coverage statistics are useful, but operators should focus on their own resources.

A routing-security audit should answer:

1. Which prefixes do we originate?

Document all important:

• IPv4 prefixes;

• IPv6 prefixes.

2. Which ASN should originate each prefix?

Create a reliable mapping:

Prefix → Intended Origin ASN

3. Do matching ROAs exist?

Check:

• prefix;

• origin ASN;

• maxLength;

• validity.

4. Does live BGP match?

Verify what is actually visible on the Internet.

5. Do IRR records agree?

Look for stale or conflicting route objects.

6. Who controls RPKI administration?

Avoid depending on a single employee.

7. Are routing changes linked to ROA changes?

Provider, ASN and prefix changes should trigger routing-security review.

8. Do we monitor Invalid announcements?

An Invalid state should generate investigation rather than remain unnoticed.

NRS provides a wider framework for reviewing these dependencies in How to Audit Your Company’s Internet Number Resources.

A Practical RPKI Control Checklist

The objective is not simply to achieve a high RPKI score.

It is to keep routing authorization aligned with operational reality.

What the 2026 Data Says About Internet Routing Security

The data suggests several clear lessons.

1. ROA adoption has passed an important threshold

Around 60% of observed global IPv4 and IPv6 routes were Valid in APNIC’s February 2026 analysis.

That is substantial progress.

2. A large Not Found population remains

More than one-third of routes still lacked relevant ROA coverage in the same dataset.

Authorization coverage remains incomplete.

3. ROV is the next major deployment gap

Measured global ROV adoption remained around 27% during 2026 under APNIC Labs’ methodology.

The ability to validate exists faster than enforcement is being deployed.

4. Regional differences are enormous

South East Asia reached over 92% IPv4 Valid coverage while East Asia remained around 31%.

There is no single global adoption pattern.

5. High ROA coverage does not guarantee high ROV

India provides a clear example: very high ROA coverage alongside very low measured validation enforcement.

6. Accuracy matters as much as adoption

An outdated ROA can turn legitimate routing into Invalid routing.

More ROAs alone are not enough.

7. RPKI does not replace operational discipline

Routing security still depends on:

• accurate resource records;

• correct BGP configuration;

• well-maintained ROAs;

• appropriate validation policy;

• monitoring;

• change management.

The Bigger Principle: Authorization Should Follow the Running Network

The Internet needs reliable records.

It also needs those records to describe the network accurately enough to support real operations.

RPKI illustrates this clearly.

A ROA can provide cryptographically strong authorization.

But that authorization creates the most value when:

• the prefix is correct;

• the origin ASN is correct;

• the prefix length is correct;

• the resource relationship is current;

• validation is actually used;

• operational changes are reflected promptly.

This leads to a broader infrastructure principle:

A security record is most useful when it remains aligned with the system it is intended to secure.

Registry records, RPKI objects and BGP routing each describe different layers.

Resilient network operations depend on maintaining the relationship between them.

Final Thoughts

2026 routing-security data shows strong progress in RPKI adoption.

More than 60% of observed IPv4 and IPv6 routes were Valid under APNIC’s February analysis.

But measured ROV deployment remained much lower, at roughly 27% globally under APNIC Labs’ methodology.

That difference highlights the next stage of Internet routing security.

The industry has made substantial progress answering:

Who is authorized to originate this prefix?

The next challenge is ensuring that more networks reliably use that information when processing routes.

For network operators, the practical lesson is straightforward:

Create accurate ROAs.

Keep them synchronized with BGP.

Deploy validation carefully.

Monitor Invalid announcements.

Review RPKI during transfers, migrations and ASN changes.

Treat registry, authorization and routing as connected but distinct layers.

The goal is not simply more RPKI objects.

It is a routing system in which accurate authorization data supports the reality of the running Internet.