RPKI Is 14 Years Old and Still Optional. That's About to End.

The RPKI standard was published in 2012. Origin validation has been technically possible since 2014. The first major transit operators started enforcing in 2018. As of 2026, ROA coverage globally is somewhere around 47 percent of advertised prefixes.

Fourteen years. Almost half the routing table. RPKI is the rare networking standard that everyone agrees is correct and that nobody enforces.

That changes in the next twelve months. Three things shifted in 2025 that aren't shifting back. The "optional" framing won't survive 2026.

Shift one — hyperscaler peering policy

Cloudflare started requiring valid ROAs in 2021. The big surprise was how mild the consequences felt. Then Google's enforcement in 2023 had teeth — invalid prefixes got dropped, peers without ROAs faced renegotiation at peering review. By 2025, Meta, Microsoft, and Amazon had all moved to similar postures.

The four largest content networks now require RPKI as a peering precondition. That isn't a "best practice". That's a procurement gate. A transit operator without ROA coverage cannot peer with the networks that account for somewhere between thirty and forty percent of internet traffic.

Shift two — RIR transfer rule changes

ARIN, RIPE NCC, and APNIC have all tightened their transfer policies in 2024-2025 to require RPKI validation on the recipient side within ninety days of transfer. A buyer of address space who doesn't publish ROAs is now a buyer who breaches policy. Penalties range from gentle reminders to actual reclamation in extreme cases.

This isn't a peering preference. This is an ownership obligation. If you bought IPv4 space in the secondary market in the last eighteen months, your acquisition was conditional on RPKI deployment.

Shift three — cyber-insurance language

Insurance underwriters started asking about RPKI status in 2024. By 2025 it appeared as a question in standard cyber-insurance applications for any organisation that operates an AS. By 2026, the bigger underwriters tag RPKI absence as a coverage exclusion for route-hijack-related losses.

This is the boring shift, and it's also the one that gets the executive sponsorship that the previous fourteen years of operator advocacy didn't. CFOs sign insurance policies. CFOs ask why coverage was excluded. The CIO answers. The network operations team gets the budget for RPKI deployment in a week that nobody questioned for a decade.

Why this combination tips the balance

Each shift on its own was survivable. A network operator could decline to peer with hyperscalers and accept the traffic loss. A network operator could choose not to transfer IPv4 space. A network operator could self-insure cyber risk.

In combination, all three together cover essentially every commercial AS. Either you peer with hyperscalers, transfer space, or carry insurance. The intersection of "none of these apply" is small enough that the optionality of RPKI is, practically, ending.

What "ending" means in the next twelve months

Three observable signals to watch.

ROA coverage crosses 60 percent. That's the threshold at which "having a valid ROA" stops being notable and "not having one" starts being notable. We're currently around 47 percent. The trajectory suggests 58-62 percent by end of 2026.

At least two major Tier-1 transits announce RPKI as a peering requirement. Today's enforcement is concentrated at content-network peering. Tier-1 transit enforcement is the harder political fight. Once one moves, the rest follow within twelve months because nobody wants to be the asterisk on the peering page.

RIR transfer disputes start naming RPKI compliance as a remediation requirement. The RIRs have been quiet about enforcement. Expect 2026 to see the first publicly-documented case where a transfer was unwound or restricted on RPKI grounds. Once one exists, every transfer counsel cites it.

The operational reading

If you're an AS operator who hasn't published ROAs yet, the cost has been "convince leadership it matters". That cost is dropping fast. The frame shifts from "network engineering best practice" to "insurance and procurement compliance".

If you have ROAs but haven't enabled validation at your edges, the next step is checking that your routers actually drop invalid paths. Publishing without validating is half the picture — you've documented your space, but you haven't protected your peers from accepting hijacks of others.

If you've been on the fence about ROV (Route Origin Validation) at the customer edge, the political cover for enabling it just arrived. You can point at hyperscaler policy, RIR transfer rules, and your own insurance carrier. The three of them have done the convincing work for you.

What this doesn't fix

RPKI catches origin hijacks. It doesn't catch route leaks (that's ASPA, separate post). It doesn't catch path manipulation by transits. It doesn't catch the harder attacks — sub-prefix announcements that fit inside a valid ROA's max-length.

The remaining BGP problems are real and substantial. RPKI was always the easy first step. The fact that we took fourteen years to get most of the way there says something uncomfortable about how the routing community moves.

The next fourteen months will probably get us most of the rest of the way. The political conditions are finally aligned. Now we find out if the operational discipline catches up.