By Yair Knijn · November 19, 2025

You never published a ROA, so the day your prefix got hijacked you had no defense

The network architect who allocated the prefix is rarely the one who signs it. You carve the address plan, hand routing to the WAN team, and assume the registry side is handled. It usually isn't. The prefix lives in your IPAM as an allocation, the routers announce it, and nobody ever published a Route Origin Authorization saying which AS may originate it. You are announcing space you have no cryptographic claim to.

That gap is invisible right up until someone else announces your prefix. Then it's a hijack, and you have no signed record that would have let a validating router drop the bogus route on sight.

What a ROA does and why filtering routers honor it

A Route Origin Authorization is a small, signed object in the RPKI. It binds one of your prefixes to the AS permitted to originate it, plus a maxLength capping how specific a covered announcement can be. A router doing Route Origin Validation (RFC 6811) checks each BGP route against the ROAs it holds: matching origin and prefix length is valid, a covered prefix with the wrong origin or too-long a length is invalid, and uncovered space is not-found. Validating networks drop invalid routes before the best-path decision.

What makes this work is that you don't have to convince anyone to trust you. Once the ROA exists, every operator already running ROV honors it automatically. Without one, your prefix stays not-found, and a hijacker's announcement is treated exactly as legitimately as yours.

The June 2025 root-server BGP hijack as a cautionary case

On June 20, 2025, Cisco ThousandEyes monitors caught AS3132 (Red Cientifica Peruana) originating 199.7.83.0/24, the IPv4 prefix of L-Root, a DNS root server belonging to ICANN's AS20144. The legitimate path was withdrawn in favor of the bogus one, and roughly ten percent of ThousandEyes' global agents ended up forwarding L-Root DNS queries through the offending network.

The detail worth sitting with: only 19 of hundreds of BGP monitors flagged it. A hijack of root infrastructure stayed nearly invisible to the global observation fabric. If that can happen to a root-server operator, your enterprise prefix announced from one transit provider will not trip anyone's alarm. The defense that scales is not detection after the fact. It is a valid ROA, so validating routers reject the wrong origin on arrival.

Inventorying prefix-to-ROA coverage in your address plan

You cannot sign what you cannot enumerate. The first task is reconciling what you announce, what you allocate, and what is actually signed. For every public prefix:

• Confirm a ROA exists at the RIR (ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC) for the prefix and the originating AS.
• Check that maxLength matches your real announcement granularity, not a wide-open value that invites more-specific hijacks.
• Flag prefixes you announce but no longer allocate, and allocations you've stopped announcing; both produce ROAs that drift out of sync.
• Note prefixes originated from a different AS after an acquisition or transit change.

The output is a coverage map: which prefixes are valid, which are not-found, and which would go invalid the moment your announcements changed. Most orgs have never produced that map.

Making RPKI status a field in your IPAM, not an afterthought

ROA coverage rots because it lives outside the system of record. The address plan is in IPAM, the signing is in an RIR portal, and nothing reconciles them. A new allocation ships announced and unsigned, and an old ROA outlives the prefix it described. Treat RPKI validation state as a property of the prefix itself (origin AS, ROA present, maxLength, validation status) and the drift shows up at allocation time instead of during an incident.

Spot IPAM keeps that status next to the prefix in your Environment, so an unsigned or stale-ROA prefix is flagged the moment it's allocated rather than the day it's hijacked. You can see how it surfaces this in the features overview. A ROA you never published is a defense you never had, and the cheapest place to catch that is in the inventory, before the announcement leaves your edge.