Signing Your Prefixes Is the Easy Half
RPKI adoption gets reported as a single number, and that number looks encouraging. Route Origin Authorisations grew 23% during 2025, from 280,692 to 344,209, and the count of unique origin ASNs appearing in ROAs rose 11% to 52,661. 1
The number underneath it is the one that matters. On the path side, an ASPA record is published for roughly 0.5% of autonomous systems in the global routing table. 1
Those two figures describe the real state of routing security in 2026. Origin signing is mainstream. Everything above the origin has barely started.
Signing and validating are different jobs
Signing means publishing a ROA that says AS64500 is authorised to originate 203.0.113.0/24. It protects you, and only if others check it. It's a form you fill in at your RIR.
Validating means running an RPKI validator and dropping or depreferencing invalid routes. It protects your traffic from being hijacked away, and it's real operational work: running validators, keeping them fed, deciding your policy on invalid, and accepting that you'll occasionally drop a route because somebody else fat-fingered a ROA.
Signing is a compliance checkbox. Validating is engineering. Growth in the first number tells you very little about the second.
The gap is wider than the headline
The clearest illustration came from ARIN's most recent members' meeting. Within the Internet2 community, which spans roughly 1,100 US research and education networks, exactly two had deployed ASPAs. GÉANT, the pan-European research network and one of the more diligent operators anywhere, had about 33% of its address space covered. 2
If the well-resourced, security-conscious research networks are at two out of 1,100, the commercial internet is not quietly ahead of them.
The same session made a point about why this is hard rather than merely neglected: one commercial address block discussed there would need more than a thousand individual ROAs to be fully covered. 2 RPKI is easy to describe and fiddly to operate at scale, and the fiddliness is where the mistakes live.
Most invalids are your own doing
That last point should reframe how you think about invalid routes. The everyday causes aren't attackers.
Stale ROAs left behind after a renumbering. Sloppy maxLength values that authorise more specifics than intended. A ROA created for one AS while the prefix is announced by another. Forgotten authorisations for space that has since been transferred.
That matters for two reasons. If you're hesitating to drop invalids because you fear breaking legitimate traffic, you're right to be careful, and the fix is to clean up your own ROAs rather than to keep accepting everything. And RPKI's day-to-day value is at least as much error prevention as attack prevention. It catches the leak a tired engineer is about to cause at 2am, which is a far more likely way to lose your prefix than a deliberate hijack.
What RPKI doesn't do
Worth being blunt about, because it gets oversold. RPKI doesn't validate the AS path, only who originates the prefix. It doesn't eliminate route leaks, since a leak can be RPKI-valid when the origin is legitimate and only the propagation is wrong. And it doesn't fix stale ROAs or bad maxLength values, which are your job.
Path-level protection needs ASPA and BGP Roles, and the 0.5% figure above is what that effort looks like today. RPKI is a floor rather than a ceiling.
AS210464, and what we validate
We operate AS210464, and we're on the validating side of that gap.
We run RPKI validation on the routes we accept. If you announce a prefix to us through a BGP session and your ROA doesn't authorise it, that's a conversation before it becomes an outage.
We publish a full BGP community set so you can control your own announcements rather than filing tickets. That covers selective announcement, meaning do not announce to a specific AS, to customers, to direct peers, to IXP peers, to route servers or to upstreams, along with regional controls, prepending from one to three times, local-preference control for backup routes, and remote-triggered blackholing for when you're under attack and need a prefix dropped at the edge rather than at your server.
BGP sessions start at €5/mo. Every VM already comes with a routed /48 of IPv6, which isn't the same thing as space you can announce: for that you either bring your own, or lease IPv6 space from us. Sessions peer against local gateway addresses, 10.0.0.1 for IPv4 and fd10::1 for IPv6, which is what lets your addressing move between our nodes down to a single /32 or /128. That arrangement requires multihop enabled on your side at TTL 255, whether you run BIRD or something else.
You can verify our routing before buying anything. The looking glass runs live BGP route lookups, ping and traceroute from Tirana, Skopje, Amsterdam and London, with no account required. If a provider won't let you see their routing table, ask yourself why.
If you do one thing this week
Audit your own ROAs. The highest-probability routing incident in your future is one you cause. Check that every prefix you announce has a ROA, that the origin AS is correct, that maxLength matches what you announce rather than being set generously just in case, and that nothing is left over from space you no longer hold.
Then, if you don't validate at all, start. Log invalids without dropping them for a month, see what you would have broken, clean up what's yours, and then turn on enforcement.