RPKI won't stop your route being hijacked: signing the origin doesn't secure the path

This afternoon, Cloudflare's public routing observatory was seeing 1,445,943 routes in the global BGP table. Of those, 1,016,683 — 70.31% — carried a valid RPKI signature. And 15,300 were covered by a signature saying exactly the opposite: invalid, and still there, visible from 79 vantage points. That small number sums up the real state of routing better than any adoption percentage: signing is easy, validating is another matter, and neither one stops the hijack that actually gets used.

We are writing this from the side that runs BGP sessions every day: we operate our own network with transit and peering, and we publish an open looking glass at lg.everywan.com precisely so anyone can check what we see and what we announce. From there, the sentence you hear most in meetings — "relax, we already have RPKI" — is not a lie, but it is incomplete in a dangerous way. A ROA signs who may originate a prefix. It does not sign the path the traffic takes, nor who had the right to hand it to you.

What a ROA actually says (and what it leaves out)

A ROA is a signed statement with three fields: this prefix, this autonomous system number as origin, and up to this length. The router compares the announcement against the signature and tags it — valid, invalid or not-found — as per RFC 6811. What it then does with that tag is local policy, and that is where the problems start. Three things a ROA does not cover and are worth keeping in mind:

The hijack that passes validation with a green light

Here is the bit that ruins the calm. An attacker who wants your prefix does not fight your ROA: they copy it. They announce your prefix with your autonomous system number in the origin position and their own in front of it, as if they were the neighbour giving you transit. The router receiving that runs origin validation, checks the origin of the AS_PATH against your ROA, and gets valid. The light turns green for an announcement you never made. How much traffic they take is no longer a matter of cryptography but of geography: they get the traffic of every network for which their path looks preferable — or of all of them, if they also announce a more specific prefix than yours.

And the piece that would sign the whole path? It exists on paper — BGPsec — and remains undeployed, for a reason the analysis published on RIPE Labs on 21 July 2026 puts it well: a single non-adopting AS in the path strips the security information. A chain that needs every link to exist, across a network of more than a hundred thousand independent actors, is a chain that never closes. Meanwhile, the attack costs exactly what one configuration line in a router costs.

Today's counter, with the small print it needs

We queried Cloudflare Radar's public API while writing this, and the counters leave little room for interpretation: 3,188 origin-conflict events — what Radar labels as hijacks — over the last 30 days, and 6,537 route leaks in the same period. Over the last 24 hours, 88 and 515 respectively. On top of that sit 413,960 routes with no ROA, 28.6% of the table: neither valid nor invalid, simply unsigned. Almost a third of the internet has not reached the starting line yet.

And now the caveat, which is half the value of any number: most of those events are not attacks. They are automated detections of origin conflicts and of announcements going where they should not, and behind nearly all of them is a fat finger, an ill-considered deaggregation, a filter that was not there, or a lab that escaped into production. Reading it as "there are three thousand cyberattacks a month against routing" is an exaggeration. But the comfort is short-lived, because the correct reading is just as uncomfortable: if a stranger's misconfiguration can divert someone else's traffic until somebody notices, whoever does it deliberately achieves the same with less noise. The difference between the accident and the attack is intent, not difficulty.

The four families nobody is validating

The RIPE Labs work we quoted sorts routing attacks into four broad categories. Worth reading them in one go, because they show at a glance where cryptography reaches and where it does not:

And the figure that puts all of it in order, from the same analysis — a longitudinal study across more than 28,000 autonomous systems: 36.2% do not implement origin validation at all, and only 12.3% achieve full protection on their routes. Read that next to the 70.31% of signed routes from the top and the gap is obvious: the community has signed seven out of ten routes and fully validates barely one network in ten. Signing is an administrative task you do once in your RIR portal. Validating means touching the configuration of every router you own and accepting that, if you get it wrong, you are the one who stops seeing half the internet. That is why one number climbs and the other does not.

The checklist we review a network with

There is no silver bullet, there are seven boring things that do almost all the work. These are the criteria we review a network with, and what we ask of a transit provider before signing anything:

The expensive part is none of the seven: it is that nobody owns the job of reviewing them every quarter, which is where they rot. And the underlying pattern is the one we described for denial-of-service attacks: the box in your rack will not save your link, because the problem happens upstream, outside your perimeter. Routing works the same way: what decides whether you get hijacked is not in your firewall, it is in the policy of your neighbours' neighbours.

If you do not run your own AS (which is the norm)

The vast majority of companies do not speak BGP with anyone, and have no need to. Their lever is not technical: it is the conversation with whoever provides their connectivity. One question is worth all the others and fits in a single email: "do you drop RPKI-invalid routes, or do you just tag them?" If the answer is that they tag them and accept them anyway, you know where you stand; and if they say they drop them, that can be checked from outside. The second, for anyone holding provider-independent addresses, is just as uncomfortable: who maintains that ROA, with what maximum length, and who reviews it the day you change operator? That object outlives contracts, and we have seen too many signatures pointing at an autonomous system that no longer serves anyone.

ASPA: the missing piece, and the honest caveat

The answer being built for what RPKI does not cover is called ASPA: every autonomous system holder declares, signed, who their providers are. With that information, a path travelling where it should not stops being a suspicion and becomes verifiable. The objects have been publishable in the regional registries' repositories since December 2025, and the RIPE Labs analysis estimates that deployment by strategically positioned systems could cut the number of autonomous systems affected by leaks by up to 96% — which is not the same as cutting the leaks themselves.

And now the part that does not make it into the slides: that same analysis counted 1,314 registered ASPA objects. The two figures are not directly comparable — one counts objects published in the repositories, the other systems seen announcing — but side by side they give the order of magnitude: 1,314 against the 116,353 distinct origins Radar was seeing in the global table today. It is the right direction, it is cheap to publish and it is worth doing. But if anyone sells you ASPA as protection today, they are selling you a deployment that does not exist yet. Publish yours because of what it adds to the whole, not because you will sleep better tonight.

The last myth: that this is about you

There is a myth symmetrical to the one we started with, and it deserves dismantling too: the idea that, having read all this, you should rush off and build something. If your addresses come from your operator, if you have no autonomous system and your connectivity is a fibre line with the provider's router, none of this is a job for you. Do not stand up a validator or request an AS "for security": your lever is the conversation above and the contract. And if you do have a /24 and an AS number because it seemed like a good idea once, but a single transit provider and nobody watching the table, your real risk is not the sophisticated hijack: it is that on the day something happens, there will be nobody on call who knows where to look. That needs saying too.

What you can actually do

Internet routing works because tens of thousands of strangers believe what they tell each other. RPKI does not change that: it has only turned part of that trust into something verifiable. That is a lot and very little at the same time. Signing your prefixes sensibly, genuinely dropping invalids, filtering your neighbours and watching where the traffic goes does not prevent the attack, but it hugely shortens the window in which nobody notices. And in routing, that window is all there is.

If you want us to look at how your connectivity stands — what is announced in your name, what your provider filters and what would happen on a Sunday — that is part of what we do in networks and communications.

Sources (verified): the global BGP table and event figures come from the public Cloudflare Radar API, queried by us on 6 August 2026 at 15:30 UTC (79 vantage points): 1,445,943 routes, 1,016,683 valid (70.31%), 413,960 with no ROA (28.6%), 15,300 invalid, 116,353 distinct origins; 3,188 hijack events and 6,537 route leaks over 30 days, and 88 and 515 respectively over 24 hours. These are live counters: they move between queries, so the figures hold for the moment we took them, not forever. On top of that, the events Radar labels as hijacks are automated origin-conflict detections: they include misconfigurations and are not equivalent to confirmed attacks, and we have written the post accordingly. The four-family breakdown of attacks, the origin-validation figures (36.2% of systems with no ROV and 12.3% with full protection, measured in a longitudinal study across more than 28,000 autonomous systems), the state of BGPsec, ASPA being publishable since December 2025, the 1,314 registered objects and the estimate for reducing the number of systems affected by leaks come from Antonio Prado's analysis published on RIPE Labs on 21 July 2026. The standards cited are RFC 6811 (BGP prefix origin validation), RFC 7908 (problem definition and classification of BGP route leaks, which describes six types), RFC 9319 / BCP 185 (the use of maxLength in the RPKI, October 2022) and RFC 9234 (route leak prevention and detection using roles). Social image photograph: aerial view of the interchange between Ontario Highways 401, 403 and 410, by Coolcaesar, Wikimedia Commons, CC BY 4.0.