What is RPKI? BGP security explained

If you've read our BGP and route hijacks post, you know the internet's routing protocol runs largely on trust. RPKI is the long-running effort to fix that — to give routers cryptographic proof that an announced route is legitimate.

Most users never hear about RPKI. Network operators have been deploying it for fifteen years and have made enormous progress. In 2026 it's mature enough that most major networks reject invalid announcements automatically, even if it'll still be a few more years until coverage is universal.

Here's the practical version.

The two-line summary

RPKI ("Resource Public Key Infrastructure") is a cryptographic system that lets the holder of an IP block certify which Autonomous System is allowed to announce it. Routers can validate received BGP announcements against published RPKI records and drop ones that don't match.

In other words: BGP gets a verifiable "did you actually own this IP?" check, where before there was none.

What problem RPKI solves

Recap: in BGP, networks announce routes to their neighbors. "I can reach 203.0.113.0/24 via these ASes." Neighbors believe these announcements unless they've manually filtered them.

The vulnerabilities:

Origin hijacking — an AS announces an IP block it doesn't own. Either deliberate (Pakistan/YouTube 2008, MyEtherWallet 2018) or accidental (China Telecom 2010, countless misconfigurations).
Route leaks — an AS that learned a route through one peering forwards it to a wrong peer, sending traffic on a path the operators didn't intend.

Before RPKI, the defense was manual prefix filters at every interconnection point. Networks maintained lists of "these are the prefixes I expect from this peer," and dropped anything else. Effective when done well, but inconsistent and labor-intensive at scale.

RPKI automates the first part — origin validation — using cryptography.

How RPKI works

The mechanism is built around ROAs (Route Origin Authorizations). A ROA is a small signed document that says:

"AS 65001 is authorized to originate the prefix 203.0.113.0/24, with maximum length /24."

The owner of 203.0.113.0/24 creates this ROA in their regional internet registry's RPKI portal (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC). The ROA is signed by the registry's key, which chains up to the IANA root.

Anyone — every BGP router operator on the internet — can fetch the global set of ROAs and use them to validate incoming BGP announcements.

When a BGP router receives an announcement "AS 65002 reaches 203.0.113.0/24":

Look up ROAs covering that prefix.
ROA says: only AS 65001 is authorized.
Announcement origin (AS 65002) doesn't match.
Marked RPKI Invalid. Router can drop it, log it, or downpref it.

If the announcement matched the ROA's authorized origin, it's RPKI Valid. If no ROA covered the prefix, it's RPKI NotFound — the system has nothing to say about it. Most routers treat NotFound as "accept by default" because RPKI coverage isn't universal yet.

Why this took so long

Three reasons.

1. Bootstrapping cryptographic identity for the entire internet

Every IP block holder needs an identity in the registry's PKI. Every router needs software that can fetch and validate ROAs at scale. Every operator needs to update their workflows. Building this took years.

2. The "ASN-0 attack" complication

Early RPKI had a subtle issue: an attacker could create a ROA with origin AS 0 (a special "this prefix should never be announced" value), making valid prefixes appear invalid. The protocol was tightened with ASPA (Autonomous System Provider Authorization) and other extensions, taking additional years.

3. The chicken-and-egg deployment problem

If only 1% of networks publish ROAs, validating incoming announcements is mostly NotFound — RPKI doesn't help. If only 1% of networks validate, publishing ROAs gives no protection. Both sides needed to grow together.

By 2026, Cloudflare reports global RPKI coverage at roughly 65% of route announcements (publishing ROAs) and validation deployed at roughly 60% of internet traffic. Both numbers grow steadily.

What RPKI doesn't fix

Path validation. RPKI only checks the origin AS. The full AS path (the chain of ASes the route traveled through) isn't verified. BGPsec is the proposed extension that does this, but adoption is much slower because it requires new router hardware capabilities.
Route leaks. A leak isn't an origin hijack — the origin can still be correct, but the path is wrong. ASPA is the in-progress extension to address this.
DDoS or other attacks. RPKI is purely about routing legitimacy.
Misconfigured ROAs. If you publish a ROA for a prefix with the wrong origin or a too-restrictive max length, you can break your own routing. Real incidents (Cloudflare 2020, others) have demonstrated this. ROAs need to be maintained as networks evolve.

How to verify your network has RPKI deployed

If you're an end user: you can't directly. But you can probe upstream:

Visit valid.rpki.cloudflare.com (announces a prefix with valid ROAs) and invalid.rpki.cloudflare.com (intentionally invalid). If your network drops invalid routes, the second hostname will be unreachable.
Tools like Cloudflare Radar or NLNOG RING show RPKI deployment statistics by ASN and country.

If you operate a network: your routers should be configured with RTR (RPKI-to-Router) protocol to fetch validated ROA data from a local validator, then apply policies based on RPKI status.

What end users see

Almost nothing, day to day. RPKI is invisible.

Indirect benefits:

Fewer global routing incidents. Misconfigurations that would have caused 2010-style internet outages are now caught and dropped at major peering points.
Less need for manual filter maintenance. Operators still maintain prefix filters as a backup, but RPKI does the heavy lifting.
Better trust posture. Investors, regulators, and partners increasingly expect networks to deploy RPKI. Networks that don't are the laggards.

RPKI and CDNs

The big content networks (Cloudflare, Google, Meta, AWS, Microsoft) deployed RPKI early — both publishing ROAs for their prefixes and validating incoming announcements. This shifted the practical deployment center of gravity: a huge portion of the global internet now sees RPKI in action because so much traffic goes through these networks.

Cloudflare in particular has pushed the project hard, including the public test page and consistent advocacy. They've also published their own validator software (OctoRPKI) for operators to deploy.

Quick FAQ

Do I need to do anything? If you're an end user, no. If you operate a network with public IP space, yes — publish ROAs for your prefixes, deploy ROV at your edge.

Will RPKI break my routing if I deploy it? It can if you misconfigure ROAs or apply ROV too aggressively. The standard guidance is "publish ROAs for everything you announce, then deploy ROV with logging-only mode for a while before enforcing." Real-world breakage incidents have happened; lessons are documented.

Is RPKI used outside the public internet? Mostly not. Internal networks (corporate, data center, VPN) typically use ACLs and IGPs that don't rely on RPKI's trust model.

Does RPKI work with both IPv4 and IPv6? Yes — same protocol, separate ROA records per prefix.

Can RPKI catch the next Pakistan/YouTube? A simple version of that incident, yes — the announcement would be RPKI Invalid because Pakistan Telecom isn't authorized to originate YouTube's prefix. A more sophisticated attack (announcing with the legitimate AS in the path) might still slip through; that's what BGPsec is for.

TL;DR

RPKI lets IP block holders cryptographically authorize which AS can announce their prefixes.
Routers validate incoming BGP announcements and drop invalid ones.
Adoption is at roughly 60–65% globally and growing.
It catches origin hijacks but not path-level attacks.
For users: invisible, but quietly reduces "BGP screwup" incidents.
For operators: publish ROAs, deploy ROV, expect to spend a few weeks getting it right.

If you've heard "the internet's routing is more secure than it used to be" and wondered what changed, RPKI is most of the answer.