By 2026, RPKI is no longer a niche edge feature. Large providers now reject invalid routes, and enterprises that publish bad origin data can blackhole their own traffic.
That changes BGP RPKI deployment. You aren’t only reducing hijack risk. You’re making sure your announcements survive stricter upstream policies.
Start with route ownership and source-of-truth cleanup
RPKI uses ROAs to state which ASN may originate a prefix. Routers then apply ROV, route origin validation, and mark routes as valid, invalid, or not-found. The fastest way to fail a rollout is to tune routers before you clean the data.
Most enterprise invalids come from stale records after M&A, ISP changes, cloud migrations, or DDoS playbooks. First, inventory every originated IPv4 and IPv6 prefix, every ASN you use, and every place you announce them. Include direct transit, IX, cloud edge, SD-WAN internet exits, and scrubbing providers. Cloud and CDN contracts often hide extra origin ASNs, so include them in the inventory and confirm who may announce on your behalf.
Build one worksheet from RIR allocations, IRR (Internet Routing Registry) route objects, router configs, cloud route export settings, and carrier LOAs. If two sources disagree, fix that before you publish ROAs. A prefix that looks correct in IRR but points to the wrong ASN in a ROA will still be invalid to networks doing ROV.
Before publishing or changing any ROA, verify these points:
- Each prefix has a matching origin ASN in both IRR and ROA data.
- ROA maxLength matches real announcements. If you advertise a /24 from a /23, the ROA must allow it.
- Temporary more-specifics for migrations or scrubbing are listed with an owner and expiry.
- Retired prefixes, test ASNs, and divested networks are removed from templates and route-maps.
Most RPKI invalid alarms in enterprises are change-control failures, not attacks.
Recent RPKI adoption analysis and Orange’s deployment guidance show why this cleanup matters. ROA coverage now sits above 60% of IPv4 space, yet invalids still appear every day. Most are plain operator error, so your first control is data hygiene.
Build validator redundancy before you enforce policy
Use at least two validators per region and keep them close to the edge. A validator fetches ROAs from the RIRs and serves results to routers over RTR, the RPKI-to-Router protocol. Many enterprises start with Routinator, then add a second instance or another validator such as OctoRPKI for diversity.
Place validators on reliable internal paths, not on the public internet you are trying to protect. Then point every external-facing router to more than one validator. Test cache expiry, restart behavior, certificate refresh, and routing state after loss of reachability. A lab setup often passes happy-path checks but fails during maintenance because timers or firewall rules were never tested.
This comparison helps frame outage behavior when validators disappear:
| Mode | Best fit | Main risk |
|---|---|---|
| Fail-closed | Security-first edges with proven validator redundancy | Route loss during validator outage |
| Fail-open | Uptime-first edges with backup filters | Invalid routes may pass during outage |
Rejecting routes marked invalid is now common. The harder choice is what to do when validator lookups fail. Current practice favors fail-closed where you have redundant local validators, tested recovery, and good out-of-band access. However, uptime-sensitive sites may keep fail-open for validator transport failure, while still dropping routes that are explicitly invalid.
Also standardize policy states across vendors. Some platforms call it not-found, others call it unknown, and evaluation order varies. In most enterprise rollouts, valid is accepted, invalid is rejected, and not-found stays subject to existing prefix filters. During rollout, change one edge pair at a time and confirm each carrier’s behavior. Some upstreams drop invalids, while others only tag them. A practical ROV implementation guide helps when mixed teams need a shared baseline.
Monitor invalids, test exceptions, and document rollback
RPKI is an operating control, not a one-time hardening task. After deployment, track three numbers on every internet edge: valid route count, invalid route count, and validator session health. A sudden jump in invalids usually points to your own ROA mistake, a provider announcement problem, or a cloud service moving traffic under another ASN.
Keep the runbook short and precise:
- Alert when invalids rise above baseline, or when a router loses all validator sessions.
- Log prefix, peer, validation state, and matched policy for every drop.
- Record each approved exception with owner, reason, start time, expiry, and rollback step.
- Re-test after new transit, scrubbing changes, peering moves, or cloud interconnect work.
Change management matters as much as routing policy. Put ROA changes in the same window as BGP policy changes, and pre-brief your NOC. For example, a temporary more-specific used during a migration may need a short-lived ROA update. If that update isn’t time-boxed, it becomes next quarter’s outage. Keep one matrix for your multi-vendor environment that shows how each platform treats valid, invalid, and not-found. For trend data and operational context, see APNIC’s RPKI 2025 year in review.
The hard part of BGP RPKI deployment isn’t turning on validation. It’s keeping prefix data, validator health, and exception handling aligned as your edge changes.
Run the prefix inventory before your next maintenance window. If ROAs, IRR objects, and provider expectations match, enforcement becomes a planned change, not a routing surprise.
