The Border Gateway Protocol, commonly known as BGP, enables independently operated networks to exchange routing information and direct traffic across the Internet. Its flexibility supports global connectivity, but its original design did not include a built-in mechanism for verifying whether a network is authorized to originate a particular IP prefix.

Resource Public Key Infrastructure, or RPKI, helps address this weakness. It allows IP address holders to create cryptographically verifiable Route Origin Authorizations that identify which autonomous systems may originate their prefixes.

However, publishing more ROAs is only one part of improving routing security. The practical value of RPKI also depends on whether networks validate routes, apply sensible routing policies, maintain accurate records, and coordinate infrastructure changes carefully.

Organizations examining RPKI adoption data for 2026 should therefore look beyond the percentage of covered address space. Effective adoption requires both authorization by resource holders and enforcement by network operators.

What RPKI Actually Validates

RPKI connects Internet number resources to digital certificates. An organization holding an IP prefix can use this system to publish a Route Origin Authorization, commonly abbreviated as ROA.

A ROA generally specifies:

• The authorized IP prefix
• The autonomous system number permitted to originate it
• The maximum prefix length that may be announced
• The cryptographic authorization associated with the number resource

Network operators can compare received BGP announcements against validated RPKI data. The origin-validation process described in RFC 6811 assigns an announcement one of three states:

• Valid: The route is covered by a ROA, and its origin ASN and prefix length are authorized.
• Invalid: A relevant ROA exists, but the announcement conflicts with its authorized origin ASN or permitted prefix length.
• NotFound: No applicable ROA covers the announcement.

These states give operators an additional source of information when applying routing policies.

Importantly, RPKI origin validation does not independently decide whether a router should accept or reject a route. Each network must determine how validation results affect its local routing policy.

ROA Coverage and Route Validation Are Different Metrics

RPKI adoption is sometimes summarized through a single coverage percentage. Although useful, that figure does not provide a complete picture.

There are at least two separate activities involved.

First, IP address holders must create accurate ROAs. This increases the proportion of Internet number resources covered by cryptographic origin authorization.

Second, network operators must perform Route Origin Validation, or ROV, and use the resulting status in their routing decisions.

A prefix can have a correctly configured ROA while many networks continue to accept conflicting announcements. Conversely, a network may enforce ROV while receiving numerous routes that remain NotFound because the resource holders have not created ROAs.

Meaningful routing-security analysis should therefore consider:

• The percentage of announced prefixes covered by ROAs
• The proportion of address space with valid authorizations
• The number of networks performing origin validation
• The number of networks rejecting or deprioritizing invalid routes
• Regional differences in deployment
• Changes in invalid announcements over time
• The accuracy and maintenance of published ROAs

Separating these measurements helps analysts distinguish nominal coverage from operational protection.

Why Legitimate Routes Can Become RPKI Invalid

An invalid route is not necessarily malicious. Configuration mistakes and poorly coordinated network changes can also cause legitimate announcements to fail origin validation.

Common causes include:

An outdated origin ASN

An organization may move a prefix to a different network provider without updating the corresponding ROA. Once the new provider begins announcing the prefix, the route may appear invalid because the authorization still identifies the former origin ASN.

A restrictive maximum prefix length

A ROA may authorize an aggregate prefix but not its more-specific announcements.

For example, an organization might authorize a /20 while operationally announcing several /24 prefixes. If the permitted maximum length is not configured appropriately, the more-specific routes can become invalid.

DDoS mitigation changes

During an attack, an organization may temporarily allow a mitigation provider to originate its prefixes. If the appropriate ROAs have not been prepared, the mitigation announcement may be classified as invalid precisely when connectivity is most critical.

Transfers and organizational restructuring

IP address transfers, acquisitions, mergers, and network consolidations can alter which autonomous system originates a prefix. RPKI records must be updated as part of the transition.

Incomplete decommissioning

A temporary authorization created for a migration or secondary provider may remain active after it is no longer required. Although this might not immediately produce an invalid route, it can leave unnecessary origins authorized.

These cases demonstrate why RPKI must be incorporated into normal network change management rather than treated as a one-time compliance exercise.

The Importance of Careful Maximum-Length Policies

The maximum-length field in a ROA determines how specific an authorized announcement may be.

Broad permissions can simplify certain network operations, but they can also expand the range of more-specific prefixes that an attacker might attempt to originate. Overly restrictive settings, on the other hand, can cause legitimate announcements to become invalid.

RFC 9319 provides operational guidance on the use of the maximum-length field. It recommends avoiding unnecessarily broad permissions and creating authorizations that reflect intended routing behavior.

A sound approach is to authorize only the prefix lengths that the organization expects to announce. Any exceptions required for traffic engineering, DDoS mitigation, or operational failover should be documented and reviewed regularly.

Why Immediate Rejection Requires Preparation

Rejecting RPKI-invalid routes can strengthen routing security, but deployment should be managed carefully.

If a network begins rejecting invalid announcements without assessing its dependencies, legitimate services affected by incorrect ROAs may become unreachable. Operators should understand how origin-validation states appear in their routing environment before applying strict enforcement.

A staged deployment can include:

1. Collecting validation data without changing route selection.
2. Monitoring which received announcements are invalid.
3. Investigating important or frequently used invalid routes.
4. Communicating with customers and peers about incorrect authorizations.
5. Introducing lower route preference where appropriate.
6. Rejecting invalid routes after operational risks have been evaluated.
7. Maintaining an exception process for documented emergencies.

This process gives engineering teams visibility into potential problems before enforcement affects production traffic.

RPKI Does Not Validate the Complete AS Path

RPKI origin validation answers a specific question: Is the origin autonomous system authorized to announce this prefix?

It does not prove that every network in the AS path is legitimate. An attacker may attempt to manipulate another part of the path while leaving the authorized origin visible.

RPKI should therefore be treated as one layer in a broader routing-security program. Other useful controls include:

• BGP prefix and AS-path filtering
• Customer route validation
• Maximum-prefix limits
• Bogon filtering
• Routing anomaly detection
• Peer and transit-provider monitoring
• Mutually Agreed Norms for Routing Security practices
• Accurate Internet Routing Registry records
• Documented incident-response procedures

The effectiveness of these controls depends on consistent implementation across network boundaries.

Building RPKI Into Change Management

Many RPKI incidents originate from a gap between routing operations and resource administration.

The team responsible for BGP announcements may not be the same team that manages RPKI certificates and ROAs. A provider migration can therefore proceed technically while the associated authorization remains unchanged.

Organizations can reduce this risk by including RPKI checks in standard workflows for:

• Activating or terminating transit providers
• Adding a DDoS mitigation service
• Changing origin ASNs
• Announcing more-specific prefixes
• Transferring IP address resources
• Completing mergers or acquisitions
• Deploying anycast infrastructure
• Establishing backup routing arrangements

Every routing change should answer three questions:

1. Which ASN will originate the prefix?
2. Which prefix lengths will be announced?
3. Do current ROAs authorize that exact configuration?

Answering these questions before implementation can prevent avoidable routing failures.

Monitoring Is as Important as Initial Deployment

A ROA that is accurate today may no longer reflect the network six months from now. Continuous monitoring is therefore necessary.

Operators should track:

• Newly invalid announcements involving their prefixes
• Unexpected changes in origin ASN
• ROAs approaching certificate or authorization issues
• Prefix-length conflicts
• Authorizations belonging to former providers
• Validation inconsistencies between monitoring systems
• Differences between intended and observed routing

Tools such as the Cloudflare RPKI Portal can help organizations inspect route-origin information and understand how announcements are classified.

Monitoring should ideally use more than one observation point. BGP visibility differs among networks, and relying on a single collector or validator can provide an incomplete view.

How to Evaluate RPKI Adoption Data

RPKI measurements should clearly define what is being counted.

A report may measure adoption by announced prefix count, total address space, autonomous systems, traffic volume, or observed routes. Each method answers a different question.

For example, a small number of large prefixes may represent substantial address space, while thousands of smaller prefixes may represent broader organizational participation. Neither measurement alone proves that invalid routes are being filtered.

Useful questions for evaluating RPKI statistics include:

• Does the analysis measure prefixes or total address space?
• Are unannounced resources included?
• How are overlapping ROAs counted?
• Does the dataset distinguish Valid, Invalid, and NotFound routes?
• Is enforcement measured directly or inferred?
• Which BGP collectors or observation points were used?
• What period does the dataset cover?
• Can the methodology be reproduced?

Transparent methodology makes it easier to compare results across regions and reporting periods.

A Practical RPKI Checklist

Organizations responsible for Internet number resources can take several practical steps:

• Create ROAs for prefixes intended to be announced.
• Confirm that every authorized origin ASN is correct.
• Set maximum lengths according to actual routing requirements.
• Prepare authorizations for backup and mitigation providers.
• Remove unnecessary authorizations after migrations.
• Monitor route-validity states continuously.
• Test validation before enforcing rejection.
• Coordinate RPKI updates with routing changes.
• Document emergency procedures and responsible contacts.
• Review ROAs at regular intervals.

Transit providers and other network operators should also give customers clear visibility into invalid announcements and provide practical guidance for correcting authorization errors.

Conclusion

RPKI provides a cryptographic basis for verifying whether an autonomous system is authorized to originate an IP prefix. That capability addresses an important weakness in Internet routing, but coverage statistics alone do not guarantee protection.

Effective adoption requires accurate ROAs, widespread Route Origin Validation, carefully designed enforcement policies, continuous monitoring, and close coordination between routing and resource-management teams.

Organizations assessing routing-security progress should distinguish between published authorization, observed route validity, and operational enforcement. Examining all three provides a more realistic view of whether RPKI is reducing routing risk.

As dependence on digital infrastructure grows, maintaining trustworthy routing information will remain a shared responsibility. RPKI is a significant part of that effort, but its success ultimately depends on how consistently and carefully networks use it.