Current Status of RPKI — ROAs and ASPAs Across the Internet
Post by Gaurav KansalData last refreshed: 2026-09-14 16:52 ISTLIVE — AUTO-UPDATED EVERY 24H
22812993613
RPKI (Resource Public Key Infrastructure) lets an Autonomous System prove two things
with a cryptographic signature instead of just trusting BGP announcements: Whether any ASN is
actually allowed to originate any given IP prefix, and whether it is actually allowed to sit
in the path as someone's transit provider. A ROA (Route Origin Authorization) covers the
first case — it stops one network from announcing someone else's IP range by mistake or
on purpose. An ASPA (Autonomous System Provider Authorization) covers the second — it
stops route leaks, where a network accidentally forwards a route to the wrong upstream.
This is a living post rather than a one-time write-up. The charts and numbers below are
regenerated automatically every 24 hours directly from the RPKI repositories and each RIR's
own delegation records, so what you're reading reflects the actual state of adoption as of
the timestamp above.
📡 This data was captured
14 minutes ago (at last check).
1789384952000
The Global Picture
As of this refresh, here is ASPA adoption across all five Regional Internet Registries:
RIR
ASNs with ASPA
Total ASNs
Coverage
RIPENCC
1,958
39,863
4.912%
ARIN
623
34,103
1.827%
APNIC
329
31,297
1.051%
LACNIC
140
14,345
0.976%
AFRINIC
0
2,787
0.000%
ROA Publication — the Mature Baseline
Unlike ASPA, ROA (Route Origin Authorization) is well-established across every RIR. 'ASNs with a ROA' only means an
ASN has signed at least one IPv4 or IPv6 resource — it doesn't mean everything
that ASN announces is covered. A network with 1 of its 50 announced prefixes signed counts
exactly the same as one with all 50 signed, if you only look at that column. The table
also shows the actual object count — the total number of individually signed resources
(VRPs) per RIR — and the average number of signed objects per covered ASN, which gives a
sense of how deep the coverage actually goes, not just how many networks have started.
RIR
ASNs with ≥1 ROA
Total ASNs
ASN Coverage
Total ROA Objects
Avg No of Obj Covered per ASN
RIPENCC
27,394
39,863
68.720%
41,031,058
1497.8
APNIC
19,230
31,297
61.444%
39,350,593
2046.3
ARIN
13,294
34,103
38.982%
15,357,897
1155.3
LACNIC
7,091
14,345
49.432%
5,983,560
843.8
INDIA
2,983
6,209
48.043%
42,127
14.1
AFRINIC
1,708
2,787
61.285%
4,041,514
2366.2
The chart above shows the ASN-presence metric only for visual consistency with the ASPA
chart.
ROV — Is Anyone Actually Checking?
Publishing a ROA or ASPA only matters if other networks validate against
it. ROV (Route Origin Validation) measures that missing piece — not what's published,
but what's actually enforced. APNIC Labs runs a continuous global measurement of this using
anycast beacon routes delivered to end-user devices via an ad-measurement network: one route
is permanently RPKI-valid as a control, another is permanently RPKI-invalid, and APNIC tracks
what fraction of a country's users can still reach the invalid one — those users are sitting
behind networks that are not dropping invalid routes. (The exact prefixes used aren't
publicly disclosed, deliberately — publishing them would let networks treat them a special one
rather than genuinely enforcing ROV everywhere. Full methodology:
APNIC Labs, "How we measure".
Worth noting: independent researchers (in the
TORCH paper,
which cross-checked APNIC's results against their own multi-prefix measurement) have
pointed out that relying on a single invalid test prefix gives only a partial view
compared to testing many prefixes simultaneously — treat
these numbers as a solid trend indicator rather than an exact figure.)
As of 2026-09-13, 26.99% of internet users globally sit
behind networks enforcing ROV.
Why isn't this just 0% or 100%? For any one person's connection, the answer
really is close to binary — either the specific route they're using got blocked, or it
didn't. The percentage you see is what happens when you average millions of individual
"yes" or "no" answers together across a whole country, and the mix comes out somewhere
in between for two main reasons.
The first is simple: a big operator runs routers in many cities, upgraded at different
times, so some of its own customers are protected and others temporarily aren't, even
under the same company.
The second is more interesting, and it's the one worth mentioning: you can end
up protected even if you personally do nothing. If every path your network uses
to reach the internet happens to go through an upstream provider that blocks invalid
routes, that invalid route simply never arrives at your door — your own network gets
counted as "protected" purely because of what your provider did, not because of anything
you configured. Researchers studying this (at
Cloudflare
and independently at APNIC)
call this "inherited" protection, and it's real enough that APNIC had to specifically
redesign their measurement to account for it. The catch: this only holds if every
path you use is through a provider that blocks invalids. The moment you have even one
upstream, or one peer, that doesn't — the invalid route can slip in through that gap
instead, and you're only partially protected.
KEY TAKEAWAY
A handful of major ISPs turning on ROV could protect the majority of a country's
users — even users whose own ISP does nothing at all. This is exactly what the
inherited-protection mechanism above means in practice: protection cascades downstream
through the network, so adoption doesn't need to be universal to have an outsized effect.
For India specifically: if Jio, Airtel, BSNL, Vi, and Tata all turned ROV on, India's
score would very likely jump well past 90%, for two different reasons layered together.
Jio, Airtel, Vi, and BSNL are mainly retail providers — most of India's actual
internet users connect through one of them directly, so their own adoption protects those
users immediately, with no inheritance needed at all. Tata Communications is different:
it's a major wholesale carrier that many smaller Indian ISPs buy transit from, so
its adoption would cascade down to those smaller networks' customers too,
protecting people who never touched Tata's network directly. The one thing that would
hold the number back from a clean 90%+: any smaller ISP that also buys transit from a
second, non-adopting provider as backup would still leak through that second path — so
the real ceiling depends on how many of India's smaller networks are single-homed to one
of these five versus quietly multihomed elsewhere too. Still, decisions by five
companies moving the needle for an entire country is the whole point of this mechanism.
Where does India stand next to the countries doing this best? Here's the same 28-day
filter rate, worldwide and then narrowed to Asia, both anchored on India so its position
is easy to see either way:
Both lists are restricted to countries with roughly 10 million or more internet users, so
small countries with unusually high (or low) numbers don't crowd out the comparison. This
candidate list is a manually maintained estimate, not a live feed, and is only
recalculated every 48 hours rather than on every refresh, since these rankings don't move
much day to day.
The APNIC Region
Zooming into APNIC specifically — 329 ASNs out of
31,297 total APNIC-delegated ASNs
(1.051%) currently publish an ASPA object.
Not every ASPA declares real upstream providers — some declare none at all, on
purpose. An ASPA can list Provider AS 0 instead of actual ASNs, which is
a formal declaration: "I am at the top of the routing hierarchy — I have no transit
providers." This is different from simply not publishing an ASPA at all (which just means
"unknown" to a validator). An AS0 declaration converts that ambiguity into a hard "Invalid"
if that network is ever seen receiving purported transit from anyone — useful specifically
for networks that should never legitimately have an upstream, like an Internet Exchange's
route server or a registry's own internal infrastructure.
Currently, 3 APNIC-region ASN(s) publish an AS0 ASPA:
64 of India's 6,209
APNIC-delegated ASNs (1.031%) currently publish ASPA.
Progress Report — Who's Adopting, and When
The numbers above are a snapshot; this table is the timeline behind them. Every APNIC-region
ASN gets logged here the first time it shows up publishing ASPA, with the date it was first
observed - so instead of just knowing the current count, you can see who's actually been
adopting it and when, not just India's ASNs but the whole APNIC region. Newest entries first.
The flip side of the table above: ASNs that WERE publishing ASPA and no longer are. This
usually means one of a few things — a network deliberately withdrew it, a CA transition
or renewal briefly dropped it. Newest removals first. If an ASN
adopts, is removed, and later re-adopts, each removal is logged as its own separate event
here — nothing gets silently merged or overwritten.
For ROA, the picture is far more mature: 2,983 ASNs
(48.043%) publish at least one ROA, covering
42,127 signed resources in total.
The number that actually matters most for India: only 1.14%
of users are behind networks that enforce ROV — against a global average of
26.99%. Publishing ROAs
and ASPAs doesn't protect anyone if the networks carrying India's traffic aren't actually
checking them. That gap matters far more than the publication numbers above.
If you run a network, here's the plain case for turning these on:
A ROA stops someone else from accidentally (or deliberately) claiming your IP addresses.
Without one, any network in the world can announce your address range, and other networks
have no way to tell that's wrong. It's happened by accident more times than anyone would like —
a typo in a router config at some other company, and suddenly some of your traffic goes
to them instead of you.
An ASPA stops your traffic from getting rerouted through the wrong path.
Even with ROAs everywhere, a network can still leak your route to the wrong upstream by
mistake. An ASPA is you explicitly saying "these are my only legitimate upstream providers" —
so a leak through anyone else gets caught immediately instead of silently working (badly).
Turning on ROV means you actually get the benefit of everyone else's ROAs and ASPAs.
Publishing your own ROA protects other people's networks from routing mistakes involving
your prefixes. Turning on ROV protects your own network from other people's mistakes. You
need both sides for any of this to actually work — a signature nobody checks doesn't stop
anything.
None of this requires trusting a single central authority blindly.
You're not asking anyone to take your word for it — the whole point of the cryptographic
signatures is that any network can verify it independently, automatically, without a phone
call or a support ticket.
It's a one-time setup, not an ongoing burden.
Once a ROA, ASPA, or ROV filter is configured, it runs itself. The cost is mostly a few
hours of setup and testing; the benefit is permanent protection against a whole category
of routing mistakes that otherwise go undetected until something breaks.
Closing Thoughts
These numbers move slowly, and that's expected — ASPA only protects a network once that
network actually publishes it, and that depends on how ready each RIR's tools are and
whether individual network operators get around to setting it up. This post keeps
refreshing on its own, so come back for the current numbers instead of trusting whatever
you read here on any one day.
Data sources: rpki-client console output, APNIC/RIPE/ARIN/LACNIC/AFRINIC delegated
statistics files, RDAP lookups against rdap.apnic.net. Auto-refreshed every 24 hours.
Snapshot generated: 2026-09-14 16:52 IST.
