RPKI ROA: Stop Route Hijacks Before They Start

By Savvas Bout, Founder of Prefixx. Last updated 23 October 2026.

The announcement of every prefix without a valid ROA record can be hijacked by others.

A correctly configured ROA, a single control point, even does more for routing security than most other parts of the BGP configuration.

This article outlines the Route Origin Authorization in all its glory. Walks through the RPKI validation chain (starting from the Trust Anchor and ending in your router’s RPKI cache) and briefly describes what to do when a ROA is missing, misconfigured or expired.

We then outline the RPKI certificate for each RIR, how to set a max-length for a ROA, how to announce multi-homed address space and what to expect when acquiring/leasing address space for use on the Internet and needing to prepare the appropriate routing paperwork in order to announce new address space. Proper preparation of routing information ensures that announcements will pass validation checks and reach their intended destinations without being filtered.

What is an RPKI ROA per the internet engineering task force

RPKI and ROA are two related but separate concepts. RPKI is the public key infrastructure (PKI) for IP address resources, which allows holders to prove ownership and validate routing announcements for those resources. A Route Origin Authorization (ROA) is a signed object in the RPKI framework for a single IP address prefix that is authorized to be announced by a single Autonomous System.

What a ROA actually contains and its maximum length

A ROA is a digitally signed object used in RPKI.

A single ROA can cover multiple prefixes, but best practice is one ROA per prefix.

How it differs from an IRR route object

A ROA is a digitally signed object that is issued under a CA certification authority chain that is rooted at each of the RIRs.

Routers running Route Origin Validation reject announcements whose origin ASN and prefix do not match a valid ROA. Unsigned IP addresses carry no such proof. Relying parties that perform this validation include both edge routers and dedicated validator software deployed by network operators.

What Prefixx prepares for you at maximum length

As part of our lease or transfer brokerage service, we create the LOA, origin validation record and IRR route objects for you. We provide you with a ready to route block of space, rather than reams of confusing paperwork. How these objects are then moved through BGP to reach your router is also outlined here.

How RPKI and ROAs work in autonomous system BGP security

RPKI uses together cryptographic certificates, signed objects and BGP policy to prevent route hijacks and stop them before they spread. All steps from a resource holder to a router.

ROA content: what gets signed

First, a resource holder creates a ROA that names an origin ASN and a maximum prefix length. Then, the RIR's certification authority (i.e., a secure daemon on a server) creates a digital signature for that ROA, and can also delete ROAs, using a private key that is chained to that RIR's trust anchor.

That signed ROA is then uploaded to a RPKI repository where the RPKI relying-party software can download it. Resource holders typically use their RIR's web portal or API to create ROAs that bind their address blocks to the correct origin autonomous system.

The certification authority, validation chain, and maximum length

The trust anchors for the RIRs serve as the foundation for each region's entire chain.

Route origin authorization and validation in BGP

Each announcement received by routers is checked against the Validated ROA Payload. If the announcement is for an ASN authorized by the root certificate and within max-length, then the announcement is marked RPKI-valid. Conversely, if the announcement conflicts with a ROA checked by an RPKI validator, then the announcement is marked RPKI-invalid and will typically be removed from consideration. Announcements for which there is no covering ROA will be marked as not-found. These prefixes will be unverified but not removed from consideration.

Route origin validation for the PAA question: RPKI in BGP is used to verify whether an AS can originate routes for an address holder or not.

Prefixx prepares LOAs, RPKI ROAs, and IRR route object s as part of every lease and transfer. If you need a block that arrives route-ready, contact the Prefixx team. Once you understand the validation flow, the next step is getting the ROA fields themselves right.

Creating and managing ROAs at each RIR

First, your organization needs to hold a valid Resource Certificate issued by the Certification Authority of a Registry for the resources you want to number at that Registry. That certificate includes the bindings of the resources (of the type addressed by numbers provided by that registry) to the public key of the certification authority. Additionally, Serves as the cryptographic root for all ROAs published by that organization. The Resource Certificate is itself a digital certificate that binds the holder's resources to their cryptographic identity.

Creating ROAs at ARIN, RIPE NCC, and APNIC

ARIN resource holders can create and manage ROAs using ARIN Online or the RegRWS API. ROAs are specified by an origin ASN, a prefix, and an optional max-length. The IRR Auto-Manager can also keep your IRR route objects in sync with your ROA set automatically.

In RIPE NCC’s hosted certification authority within the RIPE NCC portal, you can manage the full lifecycle of a publication. First select a prefix, then choose an origin ASN, set a max-length and then publish it. LACNIC and AFRINIC also offer RPKI services within their respective member portals. These services are based on the prerequisite of a resource-certificate. For more context, see Resource Public Key Infrastructure.

APNIC members also use MyAPNIC to manage their resources. The workflow for creating a ROA is very similar to RIPE NCC’s way of doing things: select the resources for which you want to create a ROA, then define the ROA parameters and submit them. In all three portals you can check whether a ROA is valid against the current RPKI state. If valid, the ROA is finalized.

How to create ROAs and validate coverage

These are compared to what a relying party (a router or RPKI-Validator like Routinator or OctoRPKI) fetches from the trust anchor(s) for that AS. Any mismatch between the max-length defined in route origin authorizations ROAs, cryptographically signed objects, and the length of the actual announcement(s) will produce an "Invalid" instead of "Valid" route-origin validation result.

Show current ROA status for each registry portal. Third-party dashboards can then aggregate RPKI data to summarize worldwide coverage and indicate any coverage gaps or conflicts between all trust anchors.

Deleting and replacing ROAs for IP addresses

When removing an ROA it gets deleted as an atomic operation, so it disappears from the repository immediately.

However, much can go wrong in the details.

Public key infrastructure RPKI invalid: what it means and why it matters

An RPKI invalid state is the most disruptive outcome in routing security.

Resource public key infrastructure and the three rov states

Route origin validation uses public key infrastructure to validate each routing announcement against the RPKI repository for a given prefix. Each prefix is validated to be in one of three states: valid (i.e. the origin ASN and prefix are covered by a valid ROA), not-found (i.e. no ROA exists for the given prefix).

What triggers an invalid IP prefix result

Three causes are most common.

• The ROA lists the wrong ASN, so the routing announcement originates from another ASN.
• The announced prefix is more specific than the ROA's maxLength allows.
• A stale ROA can cause a legitimate announcement to be seen as fraudulent after a transfer or renumbering.

Why network operators drop invalid routes

Network operators who enforce Route Origin Validation treat invalid as a hard reject, so a single cryptographic validation failure is enough to get a prefix black-holed globally.

Our team of experts audits every ROA, among other digitally signed objects, before a block of internet number resources is shipped to a buyer, thus preventing them from being unloaded with stale or misconfigured records.

How Prefixx handles ROA and RPKI paperwork for clients

Prefixx can now generate LOA’s, RPKI ROAs and IRR route objects as part of every lease and BYOIP. Our team handles the paperwork so you can focus on your network.

• Included, not an add-on. Route origin authorizations, LOAs, and IRR objects come with every lease and BYOIP deployment.
• Tixx quality control: We check every block for RPKI validity and routing hygiene before we sell or lease it to you.
• IP registered in various registries around the world. We act as broker for ARIN, RIPE NCC, and APNIC registrations. A LACNIC registration was facilitated for this purpose.
• Cloud BYOIP support. Our consultants support BYOIP programs on AWS, GCP, Azure, OCI, and Cloudflare and can also assist with the deployment on the Netrouting partner network.

Slow down deployment for routing security paperwork?

Frequently asked questions about internet routing registry

How do digital certificates help RPKI validators manage multiple ROAs to secure BGP?

RPKI (Resource Public Key Infrastructure) is a cryptographic framework designed to improve routing security by letting IP address holders prove ownership of their prefixes using certificates issued by the five RIRs. A ROA (Route Origin Authorization) is a signed object within that framework. It states which ASN is authorized to originate a specific prefix, and up to what maximum prefix length. Each certificate issued to an address holder is classified as an end entity certificate, which sits at the leaf of the hierarchical chain.

How does RPKI help validate and secure BGP announcements?

RPKI is used to validate BGP route announcements before a router accepts or propagates them. When a router receives a prefix, it checks the RPKI repository to see whether the originating ASN matches a valid ROA.

How do ROAs help validate BGP announcements and route origins?

A ROA is a cryptographically signed record that binds a prefix to the ASN permitted to announce it. Route origin authorizations ROAs include three fields: the prefix itself, the authorized origin ASN, and a maximum-length value that controls how specific a sub-prefix announcement can be while still passing validation. ROAs are created as a cryptographically signed object through your RIR's member portal or, for leased space, by your broker or LIR on your behalf. Prefixx prepares ROAs as part of its white-glove routing paperwork on every lease.

What happens if my ROA is marked rpki-invalid?

An RPKI-invalid state means a ROA exists for the prefix but your announcement contradicts it, either the ASN you use to originate routes does not match, or the announced prefix is more specific than the ROA's max-length allows. Many major networks and transit providers drop RPKI-invalid routes outright, so your prefix can become unreachable across significant portions of the internet.

The fix is to update or replace the ROA so it covers the correct ASN and prefix length before you announce. Prefixx's BGP monitoring tool continuously validates ROA objects and flags RPKI validity issues so they surface before causing an outage.

Do I need both a route origin authorization ROA and an IRR route object?

A ROA handles cryptographic RPKI validation, which modern routers check automatically. An IRR route object handles policy-based filtering, which many networks still use to build prefix-lists and AS-path filters independently of RPKI.

Some networks filter on IRR alone, others on RPKI alone, and many check both. Omitting either one risks reachability problems with at least a subset of the internet.

RPKI ROAs are straightforward but have large consequences if not set up correctly. A misconfigured max-length field or an old origin ASN can turn a valid prefix into an RPKI Invalid. Therefore it is important to get the prefix, the origin ASN as well as the max-length correct the first time.

In addition to the issues above, ongoing management of ROAs is required.

If you are acquiring, leasing, or transferring IPv4 space, Prefixx prepares the LOA, cryptographic route certificate, and IRR route objects as part of every deal. Tixx checks routing hygiene on every block before it reaches you. Contact the Prefixx team to get your next block routed correctly from day one.