Eleven years of data say RPKI isn't the routing-stability risk operators feared

For years, one of the quiet objections network operators have raised against deploying RPKI — the cryptographic system that lets routers verify who is actually allowed to announce a given block of IP addresses — is that it might do more harm than good to day-to-day routing stability. Every time a Route Origin Authorization (ROA) is created, modified, revoked, or expires, routers running Route Origin Validation can reconsider whether a route is still valid, potentially triggering a cascade of BGP updates across the internet. If that churn were large, RPKI's security benefit could come at a real operational cost. An APNIC analysis published in October 2026, built on more than 11 years of combined RPKI and BGP data, finally puts a number on that fear — and the number is small.

The research reconstructed historical RPKI events from the RIPE RPKI Archive's daily snapshots and cross-validated the method against RPKI-Flutter, a higher-frequency data source available since 2024, finding the two approaches produced remarkably similar update volumes. Using a deliberately conservative counting window that likely overestimates RPKI's footprint, the analysis found that RPKI-triggered BGP updates have never exceeded 1% of total global BGP update volume, even as ROA creation, modification, and revocation activity has climbed steadily for both IPv4 and IPv6 since 2014.

Why this finding matters beyond one paper

BGP hijacking remains one of the internet's least-solved security problems precisely because the fix requires collective action: RPKI only protects a route if the route's legitimate holder has published a ROA for it, and it only stops a hijack if enough networks along the path actually validate against that ROA before accepting a route. Historical data on coverage has consistently shown somewhere around half of globally announced IPv4 address space still lacking ROA coverage, meaning the other half remains exactly as hijackable today as it was before RPKI existed. Every operator who delays deployment because of stability concerns is both leaving their own routes unprotected and weakening the collective defense for everyone else, since ROV adoption only pays off at scale.

The 2018 hijack of Amazon's Route 53 DNS infrastructure, which redirected traffic for a cryptocurrency service and led to real financial losses, remains the textbook example of what unvalidated routing makes possible: an attacker needed only to announce someone else's address space more specifically or more convincingly than the legitimate holder, and enough of the internet's routers believed it. RPKI with ROV is the direct technical answer to that specific attack pattern. The APNIC data suggests the internet does not have to choose between that protection and routing stability — it can largely have both.

Large content and cloud networks have already been pushing adoption past the point of voluntary best practice. Cloudflare has published its own ROV measurements for years and treats invalid-origin routes as a signal worth publicly tracking network by network, and transit providers increasingly condition favorable peering and routing policy on a network having published ROAs for its own prefixes. MANRS (Mutually Agreed Norms for Routing Security), the industry initiative that codifies these practices, has steadily added network operators and internet exchange points as members precisely because customers and peers now treat route-origin hygiene as a baseline expectation rather than an optional extra. None of that pressure required proof that RPKI was stability-neutral, but the APNIC data removes the last credible technical objection operators could raise against joining them.

What the data doesn't settle

The finding that RPKI-related churn stays under 1% of BGP updates is an average across the global routing table, not a guarantee for every individual network. Operators who mismanage ROAs — publishing records that are too broad, too narrow, or inconsistent with their actual announcements — can still create local instability for their own prefixes, and the APNIC authors are explicit that their recommendation depends on ROAs being “managed correctly” alongside standard operational best practices. The research is also a backward-looking measurement: as ROV adoption itself increases, more routers will actually act on RPKI validation results rather than just observing them, and the authors recommend continued monitoring precisely because that dynamic could change the picture.

Actionable takeaways

• Stop treating stability risk as a reason to delay ROA deployment. Eleven years of data say the collective churn is small; the operational risk is concentrated in how carefully you manage your own ROAs, not in the existence of RPKI itself.
• Audit your ROAs for correctness before scaling up, not after. Overly broad ROAs (covering more address space than you announce) or stale ones for decommissioned prefixes are the actual source of self-inflicted instability operators have reported.
• Turn on strict ROV if you haven't already, not just ROA publication. Publishing authorizations without validating against others' authorizations only secures your own routes, not the paths your traffic takes across the rest of the internet.
• Revisit this annually, not once. The 11-year trend is reassuring, but the authors' own caveat — that growing ROV adoption could change the update-volume picture — means this is a number worth re-checking as deployment accelerates, not a settled question to file away.