RPKI and ROA Explained: How Route Origin Authorization Protects Your IPv4 Prefixes

RPKI (Resource Public Key Infrastructure) is a security framework that lets IP address holders publish cryptographically signed statements about who is allowed to announce their address space in BGP. A ROA (Route Origin Authorization) is that signed statement — it names the prefix, the ASN authorized to originate it, and how specific the announcement may be. Together they give the world’s routers a way to reject false announcements about your prefixes before the traffic ever moves.

This has stopped being optional. A growing number of major networks now perform Route Origin Validation and drop announcements that conflict with a published ROA — which means RPKI cuts both ways. A correct ROA is the single highest-leverage record you can publish to defend a prefix against the origin-forgery hijacks described in our guide to BGP hijacking. A wrong ROA is worse than none: it turns your own legitimate announcement Invalid at every enforcing network, producing an outage that looks like everything and nothing at once.

There is also a control dimension that matters for anyone leasing or acquiring address space. Only the registered holder of a prefix can create a ROA for it. A lessee cannot publish one themselves — their entire RPKI posture depends on the holder’s cooperation, which makes ROA handling a lease term to verify in writing, not a technical detail to sort out later. This article explains what RPKI and ROAs are, how validation works, how to get the settings right, the mistakes that break reachability, and exactly what to confirm about ROAs before leasing or buying IPv4 space.

What Is RPKI?

RPKI is a public key infrastructure for Internet number resources: it lets the parties who hold IP address space and ASNs prove that authorization cryptographically, so routing decisions can be based on verifiable records rather than on trust alone.

It works as a certificate hierarchy that mirrors how addresses are allocated. The Regional Internet Registries (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) issue resource certificates to the organizations that hold address space, certifying which prefixes each holder controls. A holder can then use that certificate to sign statements about their own resources — most importantly, ROAs. Any network on the Internet can fetch these signed objects, verify the signatures against the RIR hierarchy, and trust the result because the cryptography, not the announcer’s word, guarantees it.

The essential shift RPKI introduces is worth stating plainly. As we explain in our guide to how BGP works, the base routing protocol accepts announcements on trust. RPKI adds a layer of proof on top: a way for the legitimate holder to make a machine-verifiable declaration about their space that routers everywhere can check. It does not replace BGP; it gives BGP something to validate against.

What Is a ROA?

A ROA is a cryptographically signed record stating that a specific ASN is authorized to originate a specific prefix, up to a specified maximum length. It is the workhorse object of RPKI — the thing you actually create to protect a prefix. Every ROA contains three pieces of information, and each one has a direct operational consequence:

• The prefix. The address block the authorization covers — for example, 203.0.113.0/24. The signing holder must actually hold this prefix; the RIR certificate enforces that.
• The origin ASN. The autonomous system number permitted to announce the prefix in BGP. Any announcement of this prefix originated by a different ASN becomes RPKI-Invalid.
• The maximum length (maxLength). The most specific prefix size the authorization permits. A ROA for 203.0.113.0/24 with maxLength /24 authorizes only the exact /24; set to /25, it also authorizes the two /25s inside it. This field governs which more-specific announcements are valid — and it is the setting operators most often get wrong.

One property of ROAs is the technical key that makes IP leasing work, and it is worth understanding precisely: the prefix in a ROA must be held by the party signing it, but the origin ASN named in it does not have to belong to that party. A holder can publish a ROA authorizing someone else’s ASN — a lessee’s, or a lessee’s upstream provider’s — to originate the holder’s prefix. This is exactly the mechanism that lets leased address space be announced legitimately from the lessee’s routing setup: the holder signs, but the authorization points at the announcer. Without this design, leased space could never pass origin validation. With it, a leased prefix can be as RPKI-protected as owned space — provided the holder actually publishes the right ROA.

How Route Origin Validation (ROV) Works

Route Origin Validation is the action networks take with ROAs: their routers check each BGP announcement against published ROA data and label it Valid, Invalid, or NotFound — then decide what to do with each label.

The mechanism has two halves, and both must happen for RPKI to protect anyone. First, holders create ROAs (the previous section). Second, networks deploy validators that fetch all published ROAs, verify them against the RIR hierarchy, and feed the resulting authorization data to their routers, which evaluate every announcement they receive. The three possible outcomes:

State	Meaning	Typical treatment at an enforcing network
Valid	A ROA exists for the prefix, and the announcement’s origin ASN and specificity match it	Accepted normally
Invalid	A ROA exists, but the origin ASN is wrong or the announcement is more specific than maxLength allows	Rejected — the route is dropped
NotFound	No ROA covers the prefix at all	Accepted, but with no RPKI protection — the legacy default

Two points deserve emphasis. First, Invalid is an active rejection, not a warning. At networks enforcing ROV, an Invalid announcement is discarded as if it did not exist — which is precisely how RPKI defeats a hijacker announcing your prefix from their ASN, and precisely how a misconfigured ROA silences your own legitimate route.

Second, enforcement is not universal. Publishing a ROA does not guarantee every network will reject Invalids about your space — only that networks performing ROV will. Coverage of enforcement has grown substantially and includes many of the largest carriers, but it remains partial. A ROA raises the probability that a forgery is rejected across the Internet from “rarely” toward “usually”; it does not make rejection universal. This partial-but-substantial reality is the honest frame for everything RPKI does.

What RPKI Protects Against — and What It Doesn’t

RPKI validates the origin of a route — not its path, and not everything else that can go wrong in routing. Understanding the boundary prevents both underuse and false confidence.

What ROAs and ROV reliably address: the common hijack, where an unauthorized ASN announces your prefix (or a more-specific of it) claiming to originate it. Validating networks see the origin mismatch and reject the announcement. This is the largest single category of routing incident, and origin validation is the best-deployed defense against it — which is why ROAs are worth publishing even though they are not comprehensive.

What RPKI does not do:

• It does not validate the AS path. RPKI checks who claims to originate a route, not the sequence of networks the announcement claims to pass through. A sophisticated attacker who forges an announcement ending in your legitimate origin ASN — at the end of a fabricated path — can pass origin validation. Path-authorization mechanisms (such as ASPA) exist to address this and related route-leak problems, but they are in early adoption. Independent analysis in 2026 stressed this gap directly: even with origin coverage at record levels, whole classes of routing attack — forged-origin hijacks, route leaks, and others — pass straight through origin validation.
• It does not encrypt anything. A common misconception. RPKI is an authorization framework for routing announcements; it has nothing to do with encrypting your traffic. Confidentiality comes from TLS and similar protocols, entirely separately.
• It does not replace IRR route objects or LOAs. These records serve overlapping but distinct functions. Many providers still build filters from IRR data, and Letters of Authorization remain part of how announcements get approved operationally. RPKI is one of three authorization records a prefix typically needs aligned — ROA, route object, and LOA — not a substitute for the others. We cover LOAs in a dedicated guide.

The correct posture is to publish ROAs because they defeat the common attack, while keeping IRR objects accurate, choosing upstreams that filter, and monitoring for what slips through — the layered approach detailed in the BGP hijacking prevention section.

Hosted vs Delegated RPKI

There are two ways to run RPKI: hosted, where the RIR operates the certificate authority and signs ROAs on your behalf through a web portal, and delegated, where you run your own certificate authority infrastructure. The choice is largely one of scale and control.

Aspect	Hosted RPKI	Delegated RPKI
Who runs the CA	The RIR	Your organization
How you create ROAs	Through the RIR’s portal or API	Through your own CA software and repository
Operational burden	Minimal — the RIR handles keys, signing, and publication	Significant — you maintain infrastructure, keys, and uptime
Best for	The large majority of holders, including most businesses and lessors	Very large operators and platforms managing ROAs at scale or needing automation

For most organizations, hosted RPKI is the right answer: it removes the need to operate certificate infrastructure while providing the full protective benefit. Delegated RPKI matters mainly to large networks and to platforms — including some IPv4 leasing operators — that manage authorizations for large numbers of prefixes and need automated create/revoke workflows, for example to authorize a lessee’s ASN quickly at lease start and revoke it cleanly at lease end. From the customer’s side, which model a lessor uses is less important than whether their ROA turnaround is fast and reliable.

Getting maxLength Right

maxLength should match the most specific prefix you actually intend to announce — no broader, no narrower. This single field causes more self-inflicted RPKI problems than any other, in both directions:

Too tight, and you break your own announcements. If your ROA for a /22 sets maxLength to /22, but you need to announce a /24 out of that block — for traffic engineering, for a specific service, or as an emergency counter-announcement to reclaim traffic during a hijack — that /24 is more specific than the ROA allows, so it evaluates as Invalid and gets rejected by enforcing networks. You have blocked yourself. This directly constrains the hijack-response tactic from our BGP hijacking guide: counter-announcing more-specifics only works if your ROA’s maxLength permits them.

Too loose, and you help hijackers. If your ROA for a /22 sets maxLength to /24 but you only ever announce the /22, you have pre-authorized any ASN named in the ROA to announce more-specific /23s and /24s — and more importantly, you have widened what counts as “Valid” for your space in ways you do not use. The security best practice is to authorize exactly the specificity you announce and nothing more, so that any more-specific announcement you did not intend stands out as Invalid rather than blending in as Valid.

The rule that avoids both failures: enumerate every prefix length you actually announce or plan to announce, and set maxLength (or create additional ROAs) to cover exactly those and no others. If you announce a /22 and occasionally a specific /24 within it, your ROA data should authorize the /22 and that /24 — deliberately, as a documented decision, not as a loose range picked to avoid thinking about it.

Common RPKI Mistakes That Break Reachability

The most damaging RPKI incidents are not hijacks — they are operators turning their own legitimate routes Invalid. Because an Invalid route is dropped at enforcing networks, these mistakes produce a distinctive and confusing symptom: partial unreachability that looks like a normal outage. Your servers are up, your local routers are announcing the prefix, one transit provider still sees the route — but another network shows it dropped, and you are reachable from some of the Internet and invisible to the rest. The usual causes:

1. ROA names the old ASN after a provider or announcement change. You migrate to a new upstream or begin announcing from a different ASN, but the ROA still authorizes the previous one. Every enforcing network now rejects your legitimate announcement. This is the single most common cause of accidental Invalids, and it is especially easy to hit with leased space, where the ROA and the announcement are controlled by different parties.
2. maxLength doesn’t cover an announcement. Per the previous section — a more-specific route you legitimately announce is rejected because the ROA doesn’t reach that length.
3. A prefix is forgotten. You publish ROAs for most of your space but miss a block, leaving it NotFound and unprotected, or you announce a prefix no ROA covers when neighboring prefixes are covered, creating inconsistency.
4. Expiry and renewal lapses. ROAs and the certificates behind them have validity periods. If a ROA expires or a certificate renewal lapses, the protection disappears and — depending on configuration — the route’s state can change, potentially becoming Invalid or falling back to NotFound. Hosted RPKI handles much of this automatically, but the responsibility to keep records current does not vanish.
5. Deleting or revoking a ROA while still announcing. Removing a ROA for a prefix you are actively announcing drops it from Valid to NotFound (losing protection) or, if a conflicting ROA remains, to Invalid (losing reachability). ROA changes on production prefixes need the same change-management discipline as any other routing change.

A reassuring note that does not lessen the caution: studies in 2026 found that the large majority of RPKI-Invalid prefixes observed globally are misconfigurations rather than attacks, and that traffic to them often falls back to less-specific or non-enforcing paths, limiting the harm in some cases. But “often limited” is not “safe” — a business whose specific service is unreachable from a major carrier because of a stale ROA is experiencing a real outage, regardless of the aggregate statistics.

RPKI for Leased IPv4 Space

For leased address space, the defining fact is that only the registered holder can publish the ROA — so the lessee’s RPKI protection is entirely a function of the lease arrangement. The lessee announces the prefix (from their own or their upstream’s ASN); the holder must publish a ROA authorizing that ASN. Neither works without the other, and only one party controls each half.

This division is exactly why the ROA-can-name-any-ASN property covered earlier matters so much in practice: it is what allows a holder to authorize a lessee’s ASN legitimately. But the mechanism only helps if the holder actually uses it — correctly, promptly, and throughout the lease. That makes several things lease terms to confirm in writing before committing, not operational details to resolve afterward:

• Explicit ROA authority and commitment. Does the lease obligate the holder to publish a ROA naming your origin ASN (or your upstream’s) for the leased prefix? Ambiguity here is how a “Valid” route becomes “Invalid” on day one of onboarding.
• Turnaround SLA. How quickly will the holder create, update, or revoke ROAs — for routine changes and for emergencies? A provider change or a hijack response that waits days for a ROA update is a reachability incident in progress. Clear turnaround commitments (routine within a defined window, faster for emergencies) are the difference between a lease that supports live operations and one that only supports steady state.
• maxLength agreement. Which prefix lengths will the ROA authorize? This must match what you plan to announce, including any more-specifics for traffic engineering or hijack response — the maxLength discipline from earlier, negotiated across the lease relationship.
• Lifecycle at start, change, and end. ROA created and verified before you announce (avoiding a NotFound onboarding window); updated cleanly if your ASN or announcements change; and revoked appropriately at lease end so the space returns to the holder in a clean state. Mature leasing operations automate this lifecycle; informal arrangements often leave it undefined.

These are precisely the coordination points a structured arrangement is built to handle. A managed IPv4 leasing platform should treat ROA publication, turnaround, maxLength, and lifecycle as defined parts of the service — because on leased space, RPKI protection is not something the lessee can achieve alone, however competent their own network team. The same coordination applies at acquisition: when you buy IPv4 addresses, publishing correct ROAs under your own control should be part of completing the transfer, alongside the routing and reverse-DNS steps, so the space arrives protected rather than NotFound.

Why RPKI Stopped Being Optional

RPKI has crossed from a specialized security practice into mainstream Internet operations, and the trend line only points one way. As of mid-2026, Hurricane Electric’s adoption report put RPKI coverage at roughly 67 percent of routed prefixes carrying a signed ROA, :antCitation[]{citations=”ca11c822-fc8e-4ff5-a61c-9620cef0ac01″ injected=”space”} with IPv6 coverage running ahead of IPv4. That is up from the point, celebrated only two years earlier, when IPv4 first crossed the halfway mark — a steady climb sustained over years.

Two developments in 2026 illustrate the momentum. China’s national registry moved from negligible coverage to the large majority of the country’s routes in a matter of weeks, and analysis showed that the share of Internet traffic destined for RPKI-Valid routes has climbed well above the share of routes covered, because the largest, highest-traffic networks are disproportionately likely to both sign and enforce. The practical implication for any operator: an increasing fraction of the Internet will silently reject an Invalid announcement about your space — whether that Invalid is a hijacker’s forgery (good) or your own stale ROA (bad). Both effects grow as adoption grows.

Provider and regulatory expectations are moving in the same direction. Major transit providers increasingly enforce ROV as a default, routing-security initiatives treat ROA publication as baseline good practice, and regulators in some jurisdictions have begun nudging providers toward RPKI-backed routing security. For a business operating public IPv4 space, the question has shifted from “should we publish ROAs” to “are our ROAs correct and current” — because in an enforcing Internet, an absent ROA leaves you exposed and a wrong ROA takes you offline.

Practical Checklists

If you hold your own prefixes

1. Publish ROAs for every prefix you announce — and every prefix you hold but don’t yet announce (dormant space is a hijack target).
2. Set maxLength to match exactly the specificity you announce, including planned more-specifics; no broader.
3. Use hosted RPKI unless you have a specific scale or automation reason for delegated.
4. Keep ROAs aligned with reality after every provider change, ASN change, or new announcement.
5. Monitor your prefixes’ RPKI state so you catch an accidental Invalid before your customers do.
6. Treat ROA changes on production prefixes with full change-management discipline.

If you lease your prefixes

1. Confirm in writing that the holder will publish a ROA naming your origin ASN for the leased prefix.
2. Get the ROA create/update/revoke turnaround SLA in writing — routine and emergency.
3. Agree maxLength to cover every prefix length you plan to announce.
4. Verify the ROA is published and Valid before you begin announcing, to avoid a NotFound onboarding gap.
5. Confirm how ROA updates are handled if you change ASN or upstream mid-lease.
6. Confirm ROA revocation handling at lease end.

Practical Note from i.lease

RPKI has a quietly asymmetric quality that catches operators off guard: the same mechanism that protects a correctly configured prefix will actively disconnect a misconfigured one. Publish an accurate ROA and a large and growing share of the Internet will reject forgeries of your space automatically. Publish a wrong one — an old ASN after a provider change, a maxLength that misses your /24 — and that same share of the Internet will reject you, with a symptom that reads like a mysterious partial outage rather than a records problem. The technology does exactly what it is told, globally, which is its strength and its trap.

On leased space, this asymmetry runs straight through the lease relationship, because the person who announces the prefix and the person who can fix the ROA are different people. A lessee with a flawless network can still be Invalid across half the Internet because a ROA they cannot touch names the wrong ASN. That is why the questions worth resolving before signing are not really technical — they are about authority and speed: will the holder publish the ROA your setup needs, will they update it fast when something changes, and what happens to it at lease end? A structured arrangement answers those in writing and automates the lifecycle. An informal one leaves the lessee holding responsibility for a record only someone else can create. Whichever way you hold address space, RPKI rewards the same thing the rest of routing security does: correct records, kept current, by someone with the authority and the incentive to maintain them.

Final Thoughts

RPKI turns routing authorization from a matter of trust into a matter of proof: RIRs certify who holds which resources, holders publish signed ROAs declaring which ASN may originate each prefix and how specifically, and validating networks reject announcements that don’t match. A ROA is the highest-leverage record a prefix can carry — it is the best-deployed defense against the common origin-forgery hijack, and in an Internet where a majority of routed space is now covered and enforcement keeps spreading, publishing accurate ROAs has become baseline operational hygiene rather than advanced security.

The discipline RPKI demands is precision. Its power to reject false announcements is exactly its power to reject your own if the origin ASN is wrong or the maxLength misses your route, so the work is keeping ROAs correct and current through every change. For leased space, that work is shared: the holder alone can publish the ROA, the lessee alone announces the prefix, and protection exists only where the arrangement between them makes it exist. Understand the origin/path boundary, get maxLength right, keep the records aligned with what you actually announce, and — if you lease — put ROA authority, turnaround, and lifecycle in the agreement before the first announcement. Do that, and RPKI becomes what it was designed to be: a prefix that the world’s routers will defend, whether you own it or lease it.

Frequently Asked Questions

What does RPKI stand for?

RPKI stands for Resource Public Key Infrastructure. It is a cryptographic framework that lets IP address and ASN holders publish verifiable statements about who is authorized to announce their resources in BGP.

What is a ROA in networking?

A ROA (Route Origin Authorization) is a cryptographically signed record stating that a specific ASN is authorized to originate a specific IP prefix, up to a specified maximum length. It is the object holders create in RPKI to protect a prefix against unauthorized announcement.

Who can create a ROA?

Only the registered holder of a prefix — the party the RIR has certified as controlling that address space — can create a ROA for it. A lessee cannot publish a ROA for leased space themselves; the holder must publish it on their behalf, which is why ROA handling is a lease term to confirm in writing.

Does RPKI encrypt my traffic?

No. This is a common misconception. RPKI is an authorization framework for routing announcements — it controls who may announce your prefixes, not the confidentiality of your data. Traffic encryption comes from protocols like TLS, entirely separately from RPKI.

What is maxLength in a ROA?

maxLength is the most specific prefix size a ROA authorizes. A ROA for a /22 with maxLength /22 authorizes only the exact /22; set to /24, it also authorizes more-specific /23s and /24s. It should match exactly the specificity you announce — too tight blocks your own more-specifics, too loose widens what hijackers could announce as Valid.

What does RPKI “Invalid” mean?

An announcement is RPKI-Invalid when a ROA exists for the prefix but the announcement’s origin ASN is wrong, or it is more specific than maxLength allows. Networks enforcing Route Origin Validation reject Invalid announcements — which stops hijacks, but also takes your own route offline at those networks if the Invalid is caused by a misconfigured ROA.

Is RPKI mandatory?

It is not universally mandated, but it has become effectively expected. As of 2026 a majority of routed prefixes carry ROAs, many major carriers reject Invalid routes, and provider and regulatory expectations continue to push toward RPKI-backed routing security. In practice, publishing accurate ROAs is now baseline operational hygiene.

Can a ROA name an ASN I don’t own?

Yes — and this is essential to how leasing works. The prefix in a ROA must belong to the signing holder, but the origin ASN it authorizes does not. This lets a holder publish a ROA authorizing a lessee’s or a lessee’s upstream’s ASN to legitimately announce the holder’s prefix.

Who creates ROAs for leased IP addresses?

The registered holder (the lessor or the party they designate) creates the ROA, naming the lessee’s origin ASN. The lessee announces the prefix but cannot publish the ROA themselves. The lease should explicitly commit the holder to publishing and maintaining the correct ROA, with a defined turnaround for changes.

What happens if my ROA expires?

ROAs and their underlying certificates have validity periods. If a ROA expires or a certificate renewal lapses, the prefix loses its protection and its RPKI state can change — potentially falling back to NotFound or, if a conflicting ROA remains, becoming Invalid and being dropped by enforcing networks. Hosted RPKI automates much of the renewal, but keeping records current remains the holder’s responsibility.

Does RPKI replace an LOA?

No. RPKI ROAs and Letters of Authorization serve overlapping but distinct purposes, and many providers still use IRR route objects as well. A prefix typically needs its ROA, route object, and LOA all aligned; RPKI strengthens routing security but does not by itself replace the other authorization records.

Also Read

• What Is BGP Hijacking? How Route Hijacks Work, Famous Incidents, and How Networks Prevent Them
• What Is BGP? How Border Gateway Protocol Turns IP Addresses into Reachable Services
• How to Prevent IPv4 Hijacking During a Transfer: 10 Security Steps
• How DDoS Mitigation Works: Scrubbing, BGP Diversion, Anycast, and What Network Operators Should Prepare