RPKI Protects 70% of Internet Routes—But One Setting Still Leaves a Door Open

The Internet just crossed a routing-security milestone that would have sounded unrealistic a decade ago: 70.3% of routed prefixes are now protected by Resource Public Key Infrastructure, or RPKI. That matters because the global routing system still depends on networks telling one another, in effect, “trust me, I can deliver traffic for these addresses.” RPKI adds cryptographic evidence to that claim. New measurements from IPinfo show that invalid routes now barely propagate, which is proof that the technology works at meaningful scale. But the same data exposes a less comfortable truth: many operators configure their protections too broadly, leaving millions of more-specific routes open to abuse even when the dashboard says “valid.”

Why Internet Routing Needed a Cryptographic Safety Layer

Border Gateway Protocol, or BGP, is the control plane that connects independently operated networks. Each autonomous system announces the IP prefixes it can reach and passes along routes learned from its neighbors. BGP was designed for cooperation among a much smaller community, not for a world where a mistaken configuration—or a deliberate hijack—can redirect traffic belonging to a bank, cloud provider, software repository, or government agency.

The classic example is the 2008 YouTube outage. Pakistan Telecom attempted to block YouTube domestically by announcing a more-specific route for YouTube’s address space. An upstream provider accepted and propagated the route globally. Because routers generally prefer more-specific prefixes, much of the world sent YouTube traffic toward Pakistan for roughly two hours. The incident was not an exotic cryptographic break. It was a believable-looking routing announcement accepted by systems that had no authoritative way to ask whether the announcing network was allowed to originate it.

RPKI changes that by letting the holder of an IP address block publish a signed Route Origin Authorization, or ROA. A ROA identifies which autonomous system may originate a prefix and can constrain the most-specific prefix length it may announce. Routers or supporting validators classify observed routes as valid, invalid, or not found. Networks performing Route Origin Validation can then reject invalid announcements instead of automatically trusting them.

That distinction is important. RPKI is not an alternate routing protocol, and it does not choose the best path. It supplies verifiable authorization data that BGP policy can use. Deployment therefore requires action from both sides: address holders must publish correct ROAs, while transit networks and other operators must validate routes and enforce a policy that drops invalids.

The 70% Milestone Is More Than a Vanity Metric

IPinfo’s September 2026 snapshot classified 70.3% of 1,614,288 observed routed prefixes as RPKI-valid, up from 54.0% one year earlier. The gain of 16.4 percentage points was larger than the increases of the prior two years combined. IPv6 is now ahead of IPv4: roughly 79% of routed IPv6 prefixes were valid, compared with 68% for IPv4.

The strongest evidence is not the coverage percentage itself, but what happens to bad routes. A typical valid prefix appeared at 596 public routing vantage points and a prefix with no RPKI record appeared at 595. A typical invalid prefix appeared at only two. Nearly half of invalid routes reached a single vantage point, and 71% of routes with the wrong origin—the clearest signature of a hijack or serious mistake—reached only one. In other words, enough networks now enforce origin validation that an invalid announcement is usually contained close to where it enters the system.

This is a real network effect. Publishing a ROA provides limited value if few networks validate it; validation provides limited value if few address holders publish ROAs. Once both populations become large, however, each new participant strengthens the protection available to everyone else. The new propagation data suggests RPKI has crossed from “promising deployment” into functioning Internet infrastructure.

The growth is uneven, though. China drove a large part of the headline increase, moving from 3.7% of its IPv4 addresses in valid routes in September 2025 to 83.0% a year later. IPinfo estimates that change accounted for almost 60% of the worldwide gain measured by addresses. Outside China, coverage still improved from 58.0% to 63.2%, but that slower movement is a better guide to the underlying global trend. Other major jumps included Egypt, Kazakhstan, Mexico, and South Africa.

Concentration cuts both ways. Nearly 60% of routed IPv4 space that was not protected by a valid route was located in the United States, with a significant share held by the U.S. Department of Defense. A global average can therefore hide large pockets of unprotected address space. Security teams should evaluate the prefixes and providers they actually depend on instead of assuming the Internet-wide number describes their own exposure.

The maxLength Trap: When ‘RPKI Valid’ Is Not Safe Enough

RPKI validates the authorized origin, but a ROA can be written broadly. The optional maxLength field allows the named autonomous system to originate more-specific prefixes beneath the authorized block. This is operationally convenient for traffic engineering and DDoS mitigation, but it can also create a window that an attacker can exploit by forging the authorized origin ASN on a more-specific route.

A 2026 incident involving a Hetzner address block illustrates the problem. A forged route for a /24 used Hetzner’s own AS24940 as the origin. The covering ROA authorized the larger /16 and permitted announcements down to /24. The forged route therefore passed origin validation. Because no legitimate /24 competed with it, normal longest-prefix-match behavior preferred the malicious route. Attackers reportedly used the diversion to obtain a legitimate TLS certificate and distribute a malicious Virtualizor update to hypervisors.

Nothing in that sequence meant RPKI malfunctioned. The authorization was broader than the operator’s actual announcement, and the attacker stayed inside the permission it described. This is the difference between cryptographic correctness and secure policy. A signature can prove that a statement is authentic; it cannot make an overly permissive statement safe.

IPinfo found that 138,698 of 855,217 RPKI-covered IPv4 routes—16.2%—had a ROA looser than the route being announced, with no legitimate more-specific route filling the space. The IPv6 rate was 20.9%. Across both address families, the researchers estimated roughly 18 million potential more-specific prefixes that could be forged while remaining RPKI-valid and uncontested.

The practical rule is simple: do not set maxLength unless you genuinely announce, or are prepared to announce, every permitted prefix length. RFC 9319 recommends leaving maxLength unset, which authorizes only the exact prefix. If more-specific announcements are required, publish narrow ROAs that match the intended routing plan rather than one broad authorization that covers hypothetical future routes.

What RPKI Still Cannot Verify

Route Origin Validation answers one question: is this autonomous system authorized to originate this prefix? It does not prove that the entire AS path is legitimate. A route leak can keep a valid origin while advertising the route through an unauthorized provider relationship. An attacker can also forge an allowed origin, as the maxLength case demonstrates. RPKI reduces a major class of BGP failures, but it does not authenticate every hop.

Autonomous System Provider Authorization, or ASPA, is the emerging complement. With ASPA, a network publishes signed records naming its authorized upstream providers. Other networks can compare observed paths with those relationships and detect leaks that origin validation cannot see. Deployment is early but accelerating: IPinfo counted 3,272 networks publishing ASPA records in September 2026, up from 131 a year earlier.

That 25-fold increase is encouraging, but effective coverage remains modest. About 9.7% of observed routing passed ASPA checks, and much of that comes from short paths that pass structurally under the draft validation rules. After removing that baseline, published records actively verified about 3.5% of routing, up from roughly 0.1%. Most paths are neither valid nor invalid; they are unknown because too few networks along the path have published enough information.

This stage resembles early RPKI deployment: tooling and registry support matter as much as protocol design. The ASPA growth curve rose in steps when regional Internet registries made signing available. Security standards become operational reality when they are integrated into the portals and workflows operators already use, with safe defaults and monitoring for stale records.

What This Means for Network Operators and IT Leaders

For organizations that own address space or operate an ASN, the milestone should trigger an audit rather than a victory lap. RPKI is mature enough that missing or incorrect records create measurable risk, and invalid announcements are now likely to be filtered. That makes accuracy and lifecycle management essential.

• Publish ROAs for every prefix you originate, including less-visible disaster-recovery and secondary-site ranges.
• Make each ROA match the real routing policy. Leave maxLength unset by default and narrowly authorize required more-specifics.
• Continuously compare ROAs with observed BGP announcements. A route can remain reachable after a ROA disappears, silently losing protection.
• Run multiple validating caches where availability matters, monitor repository freshness, and test failure behavior before enabling rejection policies broadly.
• Apply Route Origin Validation at every practical edge and document exceptions instead of leaving invalid routes generally acceptable.
• Publish complete ASPA records as tooling becomes available, and keep provider relationships current when transit arrangements change.

For enterprise IT leaders who do not operate BGP, the work is different but still relevant. Ask Internet service providers, DDoS mitigation vendors, and cloud platforms whether they enforce RPKI invalid-route rejection. Include routing-security posture in vendor assessments for services that sit on critical traffic paths. Monitor the RPKI status of public prefixes used by customer-facing systems, even if a provider manages the announcements on your behalf.

Homelabbers and small businesses usually cannot publish ROAs for provider-assigned addresses, but they can still understand the dependency chain. A self-hosted service exposed through a residential ISP, VPS, tunnel, CDN, or reverse proxy inherits routing risk from those providers. Checking the origin and RPKI status of the relevant prefix is a useful addition to availability troubleshooting. It will not replace DNS, TLS, or application monitoring, but it can explain failures that occur below all three.

Developers should also resist treating TLS as a complete answer to route hijacking. Certificate issuance, automated updates, package repositories, and control-plane callbacks can all interact badly with temporary traffic diversion. Strong update signing, certificate authority controls such as CAA, short-lived credentials, pinned trust where appropriate, and independent artifact verification remain important defense layers.

How to Audit an RPKI Deployment Without Breaking Routing

Routing changes deserve conservative rollout. A useful audit begins with visibility and proceeds toward enforcement. The goal is not merely to maximize a percentage, but to ensure that signed intent, observed announcements, and router policy agree.

1. Inventory every originated IPv4 and IPv6 prefix, its origin ASN, and any legitimate more-specific announcements.
2. Export current ROAs from the relevant regional registry and compare prefix, origin, and maxLength values against the inventory.
3. Observe validation states using at least two independent data sources or validator implementations to catch stale or incomplete views.
4. Correct missing and overly broad authorizations before changing router policy. Allow publication data to propagate and confirm the expected state.
5. Introduce invalid-route rejection in a monitored segment or at selected peers, then expand while tracking reachability and validator health.
6. Add expiry, disappearance, and mismatch alerts to routine network operations so protection cannot silently regress.

Operators should pay special attention to quiet failure. IPinfo documented networks whose ROAs disappeared while their routes remained reachable. That is dangerous precisely because nothing obvious breaks. Configuration management should treat ROAs like certificates or DNSSEC keys: versioned, monitored, renewed, and checked from outside the organization.

Looking Forward: From Origin Validation to Path-Aware Routing

RPKI’s rise to 70% coverage is one of the Internet’s more important—and least visible—security successes. It demonstrates that a decentralized ecosystem can deploy cryptographic authorization without replacing BGP wholesale. The observation that invalid routes usually die near their source is the outcome that matters most: the system now prevents real mistakes and constrains simple hijacks.

The next phase will be less about headline adoption and more about policy quality. Expect closer scrutiny of maxLength, better alerts when ROAs disappear, and provider dashboards that compare authorizations with live announcements. Insurance, compliance, and enterprise procurement may begin treating RPKI enforcement as a baseline control for network providers, much as DNSSEC and modern TLS configuration became checkboxes in security reviews.

ASPA is the development to watch. Its rapid publication growth shows that operators will adopt path-security mechanisms when registries provide usable tooling. Yet the large unknown region means path validation will take years to become broadly decisive. During that transition, measurements must distinguish between invalid paths and paths that cannot yet be evaluated; confusing the two would punish early adopters and produce misleading risk scores.

The broader lesson reaches beyond routing. Security infrastructure succeeds when the safe state is observable, automation-friendly, and difficult to configure too broadly. RPKI has proven that signed authorization can change Internet behavior at scale. The remaining task is to make those authorizations precise, persistent, and paired with path validation. Seventy percent is a milestone, not the finish line—and the last 30%, plus the quality of the first 70%, will determine how resilient Internet routing becomes.