Resource Public Key Infrastructure, or RPKI, has moved steadily from a specialist routing-security mechanism toward mainstream Internet infrastructure.
The data available in 2026 makes that shift increasingly visible.
APNIC reported in March 2026 that 60.3% of globally observed IPv4 routes were RPKI Valid, while 37.7% were Not Found and 2.0% were Invalid. Valid coverage had increased by roughly six percentage points since February 2025.
IPv6 showed a similar pattern: 60.9% Valid, 36.1% Not Found and 3.0% Invalid, representing an increase of roughly seven percentage points in Valid coverage over the previous year.
Those figures are significant, but the global average hides a more complicated picture.
Regional adoption varies dramatically. More importantly, publishing Route Origin Authorizations and actually using them to make routing decisions are two different stages of adoption.
That distinction matters for organizations that own, buy, transfer or lease IPv4 address space.
The question in 2026 is no longer simply:
“Is RPKI adoption growing?”
The more useful question is:
“What does the pattern of adoption tell us about how public IPv4 space should be operated?”
For the technical fundamentals behind RPKI, ROAs, maxLength and Route Origin Validation, see i.lease's existing guide:
RPKI and ROA Explained: How Route Origin Authorization Protects Your IPv4 Prefixes
This article focuses instead on what the 2026 adoption data reveals.
2026 RPKI Adoption at a Glance
APNIC's 2026 measurements provide a useful snapshot of where route-origin authorization stands.
| Indicator | 2026 Measurement | What It Suggests |
|---|---|---|
| Global IPv4 routes RPKI Valid | 60.3% | Valid ROA coverage has moved beyond the halfway point |
| Global IPv4 routes Not Found | 37.7% | A substantial share of routes still has no covering ROA |
| Global IPv4 routes Invalid | 2.0% | Incorrect or inconsistent authorization remains operationally relevant |
| Global IPv6 routes RPKI Valid | 60.9% | IPv6 Valid coverage is slightly ahead of IPv4 |
| Southeast Asia IPv4 ROA coverage | ~92.4% | Some regions are far ahead of the global average |
| South Asia IPv4 ROA coverage | ~89.9% | High ROA publication does not necessarily mean equivalent validation |
| East Asia IPv4 ROA coverage | ~31% | Adoption remains highly uneven |
| Estimated worldwide ROV adoption | ~26.6% | Route validation significantly trails ROA publication |
APNIC's 2026 routing-security analysis showed Southeast Asia at roughly 92.4% IPv4 ROA coverage, South Asia at approximately 89.9%, and East Asia at around 31%.
The same analysis estimated worldwide Route Origin Validation deployment at roughly 26.6%.
The gap between ROA coverage and ROV deployment is one of the most important findings in the data.
More networks are publishing cryptographically verifiable information about who may announce their prefixes than are actively using that information to influence route acceptance.
That tells us something fundamental about routing security in 2026:
Authorization is becoming mainstream faster than enforcement.
What Does RPKI Adoption Actually Measure?
RPKI statistics can describe several different parts of the system, and those measurements should not be treated as interchangeable.
A Route Origin Authorization, or ROA, links an IP prefix with an Autonomous System that is permitted to originate it.
When a BGP announcement is compared with validated RPKI information, its origin-validation state can be classified as:
Valid — an appropriate authorization matches the route.
Invalid — a covering authorization exists, but the origin ASN or announced prefix length conflicts with it.
Not Found — no relevant authorization covers the route.
Route Origin Validation, or ROV, represents the next stage.
ROV is what a receiving network does with that validity information when applying its routing policy.
That distinction is critical:
Publishing a ROA creates authorization data. Performing ROV makes that authorization operationally useful.
A country or network ecosystem can therefore have very high ROA coverage without having equally high ROV deployment.
For a detailed explanation of the three validation states, see:
Finding 1: RPKI Has Crossed a Meaningful Adoption Threshold
The first conclusion from the 2026 data is straightforward.
RPKI is no longer an edge-case routing practice.
Early-2026 measurements showed approximately 60% Valid coverage for both IPv4 and IPv6 routes.
That does not mean 60% of Internet routing is completely secure.
It does mean cryptographically verifiable route-origin authorization is now part of the normal operating environment for a large portion of public Internet routing.
For IPv4 holders, this changes the operational baseline.
RPKI status should increasingly be managed alongside:
- WHOIS and RDAP information
- IRR route objects
- Origin ASN information
- Reverse DNS
- BGP configuration
- Abuse contacts
- Other resource-lifecycle records
An IPv4 block can be correctly registered to an organization while still having a routing problem if its authorization does not match the announcement visible on the Internet.
As RPKI adoption grows, that mismatch matters more.
Finding 2: Regional Adoption Is Highly Uneven
The global average does not describe every region.
2026 measurements showed substantial differences:
- Southeast Asia: approximately 92.4% IPv4 ROA coverage
- South Asia: approximately 89.9%
- East Asia: approximately 31%
- Global reference: approximately 60.3%
Indonesia provides a particularly notable example.
RPKI adoption among the Indonesian ISP community reportedly grew from under 1% in 2021 to more than 90% coverage in 2026.
This matters because Internet routing is decentralized.
There is no single global control that enables RPKI everywhere.
Independent networks decide whether to:
- Create ROAs
- Operate RPKI validators
- Apply ROV
- Reject Invalid announcements
- Change routing preference based on validation
- Integrate validation into routing policy
Regional operational practices, training, coordination and the behavior of large network operators can therefore materially affect adoption.
For organizations operating infrastructure across multiple markets, a global RPKI percentage should not be interpreted as evidence that routing-security practices are uniform everywhere.
Finding 3: ROA Publication Is Ahead of ROV Deployment
The gap between authorization and enforcement may be the strongest takeaway from the 2026 data.
Worldwide ROV adoption has been estimated at roughly 26.6%, compared with approximately 60.3% global IPv4 Valid ROA coverage.
The measurements describe different parts of the routing-security system, but the contrast is useful.
Creating a ROA is an action taken by a resource holder.
ROV affects live routing policy.
Networks deploying ROV need to consider:
- Validator infrastructure
- Router support
- Routing-policy design
- Validator failure modes
- Monitoring
- Invalid-route handling
- Operational change control
ROV is also inherently difficult to measure.
There is no perfect global census of every router's routing policy, and different measurement approaches can produce different estimates.
The practical conclusion is therefore more important than any single percentage:
RPKI authorization coverage has advanced faster than widespread ROV enforcement.
Finding 4: High ROA Coverage Does Not Guarantee High ROV Deployment
India provides a useful 2026 example.
By late July 2026, measurements indicated that approximately:
- 88.04% of India's IPv4 route objects were covered by a Valid ROA.
- 97.91% of IPv6 route objects were covered by a Valid ROA.
Yet estimated ROV deployment remained much lower.
This difference illustrates the two-sided nature of routing authorization.
An ecosystem can become very good at publishing authorization without becoming equally advanced at acting on that authorization.
For RPKI to provide broader routing-security benefits, both sides matter:
Resource holders need accurate ROAs.
Receiving networks need validation policies.
This is why a single “RPKI adoption percentage” cannot fully describe the routing-security posture of a network ecosystem.
Finding 5: Incorrect ROAs Become More Consequential as Adoption Grows
Greater RPKI adoption provides stronger protection against unauthorized origins.
But it also increases the operational consequences of incorrect authorization.
Consider an IPv4 block that should be announced as:
203.0.113.0/24 → AS64550
If its existing ROA instead authorizes:
203.0.113.0/24 → AS64500
the legitimate new route can be classified as Invalid.
The same problem can occur when the ASN is correct but the announcement is more specific than the permitted maxLength.
As more networks use RPKI validity when making routing decisions, configuration mistakes become increasingly visible.
The practical lesson is simple:
More RPKI adoption increases the value of correct ROAs—and increases the cost of stale or incorrect ones.
The i.lease RPKI guide provides a deeper explanation of maxLength and common configuration errors:
How Route Origin Authorization Protects Your IPv4 Prefixes
Finding 6: RPKI Improves Origin Security, Not Every Aspect of BGP Security
RPKI is important, but 60% Valid coverage should not be interpreted as meaning 60% of Internet routing is fully secured.
Origin validation addresses a narrower question:
Is the AS claiming to originate this prefix authorized to do so?
This can help reduce unauthorized route-origin announcements and some forms of prefix hijacking.
But it does not validate every AS in the complete routing path.
RPKI therefore does not replace:
- IRR-based filtering
- Provider routing policy
- Route monitoring
- LOA verification
- Route-leak controls
- Operational incident response
- Broader BGP security mechanisms
It should be understood as one important layer in a wider routing-security model.
What the 2026 Data Means for IPv4 Buyers
For organizations purchasing IPv4 address space, RPKI should be part of both due diligence and post-transfer planning.
Before deployment, the buyer should understand:
- Whether a ROA currently exists
- Which ASN it authorizes
- The permitted prefix length
- Which ASN will originate the block after transfer
- What happens to the existing authorization
- When the replacement ROA can be created
- How the resulting route will be validated
This matters because a registry transfer and routing handover are related but separate processes.
The registry can correctly record the new resource holder while the block still requires RPKI, IRR, reverse-DNS or BGP changes before production use.
For the wider operational handover, see:
What Happens to IPv4 Records After an IP Address Transfer?
As RPKI adoption grows, stale authorization becomes increasingly difficult to dismiss as an administrative detail.
What the 2026 Data Means for IPv4 Sellers
Sellers should also understand the RPKI condition of a block before listing it.
The seller does not need to design the buyer's future network.
But it should be possible to establish:
- Whether the prefix currently has a ROA
- Which ASN is authorized
- Whether the resource is currently announced
- Which routing objects are active
- What will change after the transfer
This information reduces uncertainty during buyer due diligence.
It also illustrates a broader marketplace principle:
The marketability of IPv4 depends on operational clarity as well as block size and price.
A resource with understandable registry, routing and authorization records is easier to evaluate than one where the buyer first needs to reconstruct years of undocumented operational changes.
What the 2026 Data Means for Leased IPv4
RPKI becomes especially important in IPv4 leasing because the resource holder and the network operating the resource may be different organizations.
The customer may originate the leased prefix from its own ASN or through an upstream provider.
That means the RPKI authorization needs to match the actual origin.
A key feature of ROAs is that the prefix must be controlled by the signing resource holder, but the authorized origin ASN does not need to belong to that same organization.
This is what allows a holder to authorize a lessee's ASN or a lessee's upstream provider to announce the resource legitimately.
For the technical explanation, see:
Before activation, the lessee should establish:
- Who manages the ROA
- Which origin ASN will be authorized
- How quickly changes can be made
- Who verifies the final RPKI state
- What happens if the ASN changes
- What happens when the lease ends
- Who removes obsolete authorization
For the wider leasing workflow, see:
Rent or Lease IPv4 Addresses: Costs, Routing, Risks, and How It Works
LOA and ROA Are Not the Same Thing
IPv4 leasing frequently involves another form of authorization: the Letter of Authorization, or LOA.
An LOA and a ROA solve different problems.
An LOA is a human-readable authorization document used between organizations such as a resource holder, customer, transit provider or data centre.
A ROA is an RPKI object that allows route-origin authorization to be cryptographically validated.
One does not automatically replace the other.
A customer may have a valid LOA while the RPKI authorization is incorrect.
Or the ROA may be correct while an upstream provider is still waiting for the documentation required by its onboarding process.
For a deeper comparison, see:
What Is a Letter of Authorization in IP Leasing? LOA vs ROA and What to Verify
As RPKI adoption grows, operators should treat the LOA, ROA and routing records as complementary parts of the same deployment workflow.
Why “RPKI Supported” Is No Longer Enough
A provider saying:
“We support RPKI.”
does not tell a customer very much about the quality of its process.
The more useful questions are operational:
Who controls the RPKI workflow?
How are ROA requests submitted?
How quickly can the origin ASN be changed?
Who verifies that the route becomes Valid?
How are emergency routing changes handled?
What happens when the lease renews?
Who removes obsolete authorization after termination?
The 2026 adoption data gives these questions greater significance.
RPKI is moving from being an optional security feature toward becoming part of ordinary IPv4 lifecycle management.
As that happens, process quality matters as much as technical capability.
A Practical RPKI Checklist for IPv4 Operations
Organizations buying, transferring or leasing IPv4 resources should regularly verify:
- Prefix — Confirm the exact prefix being announced.
- Origin ASN — Confirm the ASN actually originating the route.
- ROA — Check whether an appropriate authorization exists.
- Validation state — Confirm the production route appears Valid rather than Invalid.
- Prefix length — Ensure the authorization matches the actual announcement structure.
- IRR — Review route objects separately; RPKI does not make them automatically correct.
- LOA — Confirm any routing authorization required by upstream providers.
- Monitoring — Detect unexpected origin-AS or validation-state changes.
- Change control — Update authorization before planned routing changes whenever practical.
- Exit process — Remove or replace obsolete authorization when a transfer, lease or routing relationship ends.
For a practical leased-IPv4 authorization checklist, see:
What Should We Expect Next?
The 2026 data suggests that the RPKI conversation is changing.
The earlier question was whether network operators would publish route-origin authorization at meaningful scale.
With Valid coverage around 60% in global measurements, that milestone has clearly advanced.
The next challenges are different:
- Broader ROV deployment
- Better operational change control
- Fewer accidental Invalid announcements
- More consistent regional adoption
- Better coordination between holders and networks using leased resources
- Continued development of routing security beyond origin validation
The broader RPKI ecosystem is also evolving toward mechanisms designed to address routing relationships that basic origin validation cannot fully verify.
But IPv4 operators do not need to wait for the next generation of routing-security technology to improve their position today.
The immediate priority is simpler:
Make sure the prefixes you actually announce have accurate authorization, and keep that authorization synchronized with operational changes.
Frequently Asked Questions
What percentage of Internet routes use RPKI in 2026?
Early-2026 measurements reported that approximately 60.3% of globally observed IPv4 routes were RPKI Valid, while 37.7% were Not Found and 2.0% were Invalid.
IPv6 Valid coverage was approximately 60.9%.
These measurements describe observed routing data rather than a census of every router or routing policy on the Internet.
What is the difference between ROA coverage and ROV adoption?
ROA coverage measures whether route-origin authorization exists for a prefix.
Route Origin Validation refers to networks using RPKI information when evaluating BGP announcements.
A prefix can therefore have a Valid ROA even when many networks receiving the route do not actively enforce ROV.
Is RPKI adoption the same in every region?
No.
2026 measurements show substantial regional differences.
Some parts of Southeast and South Asia have very high ROA coverage, while other areas remain much lower.
This is why global averages need context.
Can an incorrect ROA cause connectivity problems?
Yes.
A legitimate route can become Invalid if its origin ASN does not match the authorization or if the announcement is more specific than the permitted prefix length.
Networks that act on RPKI validity can then reject or otherwise treat that announcement differently.
Does RPKI prevent every BGP hijack?
No.
Route Origin Validation verifies whether the claimed origin AS is authorized for the prefix.
It does not validate every AS in the complete routing path.
RPKI should therefore be used alongside other routing-security controls.
Why does RPKI matter when leasing IPv4?
The party operating leased IPv4 may announce the prefix from an ASN different from the resource holder's own network.
The authorization therefore needs to match the actual origin ASN, making ROA management an operational dependency of the lease.
For more detail:
Is a ROA the same as an LOA?
No.
A ROA is an RPKI authorization used by routing-security systems.
An LOA is an operational document used to demonstrate permission for a routing arrangement.
Depending on the deployment, both may be needed.
See:
Final Thoughts
The most important finding in the 2026 RPKI data is not simply that adoption has increased.
It is that Internet routing security is entering a more operational phase.
Global measurements show more than 60% Valid coverage for IPv4 routes.
Some regions have moved far beyond that level.
At the same time, Route Origin Validation deployment remains behind ROA publication, and substantial regional differences remain.
For organizations that buy, sell or lease IPv4 resources, the practical conclusion is straightforward:
RPKI status needs to be managed throughout the IPv4 lifecycle.
Check authorization before deployment.
Monitor it during operation.
Update it when the origin ASN or prefix structure changes.
Review it during an IPv4 transfer.
And remove or replace obsolete authorization when a lease or routing relationship ends.
As more of the Internet relies on RPKI information, correct route-origin authorization becomes less of an optional enhancement and more of a basic component of keeping public IPv4 resources reliably reachable.
For the technical fundamentals behind ROAs, validation states and leased-prefix authorization, continue with:
RPKI and ROA Explained: How Route Origin Authorization Protects Your IPv4 Prefixes