Summary
- RPKI adoption has at least three distinct dimensions: authorization coverage, validator usage, and routing enforcement. Collapsing them into a single percentage obscures where security improves and where institutional failure gains reach.
- The security benefit is significant: an unauthorized origin can be classified against cryptographically verifiable resource authority. However, classification does not prove motivation nor identify whether an invalid route is due to attack, stale data, a transfer, a max-length error, or a legitimate service arrangement.
- Measurements from 2023 to 2024 showed rapid growth of ROA-covered prefixes while thousands of invalid announcements persisted, most attributable to identifiable operational conditions. More coverage therefore increases both defense capacity and the cost of a false authorization.
- A consistency failure by RIPE NCC in January 2021 demonstrated how a resource transfer, asynchronous certificate updates, and varying validator behavior can magnify a narrow defect. The lesson is not that RPKI failed, but that adoption turns implementation details into institutional risk controls.
- Certificate portability, delegated control, atomic publication, diverse validation, external route monitoring, and practiced correction should grow with adoption. Redundancy at the validator level cannot heal a common faulty fact issued higher in the authority chain.
- Compensation should be tied to controlled actions. Resource holders remain responsible for their authorizations; certification and repository providers should bear consequences for preventable errors they control; validating operators remain responsible for the routing treatment they choose.
- The Number Resource Society can support adoption by making authority limits, proof rights, portability, and loss allocation ordinary membership protection rights rather than discretionary favours after a failure.
Adoption Changes the Incident Coefficient
Security technologies are often evaluated by counting deployment and estimating blocked attacks. This approach is necessary but incomplete for hierarchical infrastructure. Deployment does not just change the probability that a bad announcement will be stopped; it changes the number of networks that can react to the same upstream mistake.
Consider a prefix without authorization. An accidental or hostile origin announcement enters a routing environment where ordinary BGP controls, filters, and commercial relationships determine propagation. RPKI coverage adds a signed statement about the authorized origin and allowed prefix length. A validating network can compare the route against this statement. If the route conflicts, the network can reject it, lower its preference, restrict exports, or flag it for investigation. The shared fact enables many networks to make a better decision without central routing control.
Now consider a wrong signed statement. The holder may omit a legitimate origin, set an unsuitable max length, fail to update authorization during a service change, or lose timely access to their account. A parent certification authority may update the resource scope inconsistently. A repository may publish an incomplete state. A relying party may apply an interpretation that turns a narrow defect into a broad rejection. The same distribution that makes correct proofs useful makes incorrect proofs consequential.
The scale relationship is not perfectly linear. Operators apply different policies. Some reject invalid announcements; others only lower their preference or enforce at selected borders. Cache state and update timings differ. Overlapping routes may preserve partial reachability. A content network, access provider, and small business are not equally exposed. Nevertheless, the direction is clear: the more consequential networks use the classification, the higher the expected external cost of an upstream mistake.
This can be described as an incident coefficient. The triggering defect is multiplied by certificate scope, repository distribution, validator interpretation, routing policy strictness, topology, and duration. Adoption increases the protection coefficient against unauthorized origins and can increase the harmful coefficient for invalid state due to errors. Mature governance attempts to maximise the first while limiting the second. A deployment chart alone reports neither.
Coverage, Validation, and Enforcement are Different Denominators
Public discussion often says that a country, region, or segment of the Internet has adopted RPKI. The term can refer to at least three distinct actions.
The first is authorization. A resource holder creates a ROA covering an address range, identifying one or more autonomous systems authorised to originate it, subject to prefix length limits. Coverage can be counted by announced prefixes, address units, origin pairs, or registered resources. Each denominator answers a different question. A small number of large address blocks can dominate an address-weighted count, while many small networks dominate a prefix count. IPv4 and IPv6 figures should not be merged.
The second is validation. A relying party fetches repository material, validates certificates and signed entities, and produces validated payloads for routers or policy systems. A network may operate multiple validators for resilience. Public observation rarely provides a complete count because the fetch infrastructure may be hidden behind resolvers, proxies, or shared services. Counting visible instances is not counting autonomous networks, and counting networks is not counting traffic.
The third is enforcement. A router or route policy system uses the validation state. It may reject invalid routes, lower local preference, mark them for selective treatment, protect customer relationships differently from peers, or observe without changing selection. Enforcement may be partial by address family, router class, location, or business relationship. It can also change during an incident.
These denominators interact but must remain separate. High ROA coverage with weak enforcement creates proofs that many networks do not yet decisively use. Strong enforcement with incomplete or low-quality authorizations can cause avoidable disconnections. Many validators running the same software against the same faulty signed state provide operational redundancy but no factual diversity. A few large transit or content networks enforcing at scale can influence more paths than thousands of small validators.
The RIPE NCC annual report 2025 illustrates why definition matters. It reported increases in IPv4 ROA coverage from 71% to 75%, IPv6 coverage from 40% to 42%, validated ROAs from 47,566 to 54,857, and certificates from 21,045 to 21,751 within its service context. These are useful indicators of authorization growth. However, they do not establish the proportion of global traffic subject to rejection, the configuration of each validator, or the reachability consequence of a future error. Institutional claims should specify exactly which layer and which denominator they have measured.
The Security Gain is Real and Should Not Be Diluted
Concentration criticism is sometimes used carelessly, as if any hierarchy makes origin validation undesirable. This conclusion ignores the base problem. BGP was not designed to establish cryptographic authority for every origin announcement. Attackers and accidental misconfigurations can announce another network's prefix. Traditional prefix filters, Internet Routing Registry data, bilateral knowledge, and operational response help but are uneven and often difficult to maintain globally.
RPKI provides a limited, machine-verifiable answer: does the announced prefix and origin match at least one valid authorization derived from the relevant resource certificate chain? This answer does not secure the entire path, prove benevolent intent, or guarantee availability. It nevertheless removes the ambiguity that attackers and errors exploit. When an unauthorized more-specific or false origin announcement is rejected by networks with significant topological reach, traffic is less likely to be redirected or blackholed through that announcement.
The benefit extends before an incident as well. Operators can monitor their own resources, detect stale or conflicting authorizations, and test proposed route changes. Transit providers can build clearer customer controls. Public monitors can compare signed authorizations with observed BGP states. Procurement and risk teams can ask whether routes are covered and whether the operator has a correction practice. These are genuine improvements in proof quality.
The correct answer to institutional risk is therefore not to preserve a less accountable routing environment. It is to demand that the new authority be as observable and challengeable as the consequences it can create. Route origin validation becomes more defensible when holders retain meaningful control, providers publish reliable state, validators fail safe, operators document treatment, and affected networks can get quick correction.
Scepticism should improve the system, not blur the distinction between protection and power. A false claim that RPKI eliminates hijacking would be hype. A false claim that any certificate hierarchy is unacceptable would be equally unhelpful. The empirical task is to measure prevented propagation, false classification, correction time, and loss allocation together.
Invalid is a Classification, Not a Judgment on Behaviour
An invalid route is a route whose observed prefix and origin do not match the relevant validated authorizations. The state is strong enough to support routing policy. It is not a complete explanation of why the discrepancy exists.
The authorization may name the wrong origin after a network migration. Its max length may not permit a legitimate more-specific announcement. A customer may activate a DDoS mitigation provider that temporarily originates the prefix. A leased block may be announced by a party not included in the holder's current ROA. Corporate groups may use multiple autonomous systems while their public organisation records lag. A transfer may change resource scope faster than any dependent authorization is updated. Some cases may indeed be hijacks. The state alone does not distinguish them.
An NDSS 2026 study using RouteViews, RIPE RIS and daily RPKI snapshots examined the period from January 2023 to July 2024. It reported that the proportion of announced prefixes covered by ROAs rose from 43.6% to 52.8% over the study interval. The observed number of invalid prefixes decreased from 7,989 to 6,802, representing about 0.7% to 0.6% of total prefixes in their collected BGP data. Across multiple snapshots, researchers observed 42,654 unique invalid prefixes. Reproducing earlier classification methods, they attributed 35,445 or 83.1% to possible misconfiguration categories before examining additional cases.
These numbers should be read with their limitations. Collector visibility is sampled. Organisation mapping and relationship inference are imperfect. A category consistent with misconfiguration does not prove every announcement was harmless. The study nevertheless shows why adoption and errors must be measured together. Coverage grew quickly, but invalid announcements did not disappear. The remaining set included both ordinary operational arrangements and unresolved risk.
The same study found measurable disconnection for lease-related invalid entries: 4.5% for direct-lease prefixes and 5.7% for broker-leased prefixes in their method. This establishes no universal failure rate. It shows that classification can become commercial harm, especially when resource holder, lessee, origin, and registry record are separate. Serious adoption policy treats these relationships as an assurance problem, not statistical noise.
January 2021 was a Compact Lesson in Amplification
On 7 January 2021, RIPE NCC published inconsistent RPKI certificate states during an outgoing interregional resource transfer. Its post-mortem explained that the parent production certificate was updated before the corresponding child member certificate. For a period, the child claimed resources no longer present on the parent.
The triggering event was narrow: a transfer and an ordering problem under certificate update processes. The amplification came from architecture and implementation diversity. Some older relying party software applied a strict interpretation that rejected all certificates listed in a manifest if one entry was invalid. RIPE NCC reported that these validators rejected all RPKI certificates for RIPE resources during the inconsistent period and estimated from access logs that 327 relying party instances were affected.
Several facts are important. The inconsistency lasted a limited time. Not every relying party behaved the same. Not every operator necessarily rejected routes based on the affected output. The post-mortem claimed no complete global outage count. It did identify possible failures and a causal chain from a transfer to parent-child inconsistency, validator rejection, and potential routing consequences.
Corrective actions were equally instructive. RIPE NCC proposed checking member certificates whenever its certificate changed, forcing reissuance for overclaims, shortening the inconsistency period, and pursuing atomic publication. It recommended current relying party versions. These are technical answers, but they are also governance controls because each limits how far institutional mistakes travel.
The episode should not be used as evidence that centralised certification always fails. It is evidence that an ordinary registry event can interact with the certificate hierarchy and validator interpretation in ways that simple adoption statistics overlook. A transfer completion metric might count the event as successful. A ROA coverage chart would barely move. Yet the order in which authority changed mattered to distant relying parties.
Every adoption report should therefore include incident evidence: affected certificate scope, visible relying parties, changed validated payloads, observed routes, operator policy where available, time to correction, and remaining uncertainty. Without this record, the institution celebrates the denominator while outsiders carry the unexplained remainder.
Institutional Risk Travels Through Different Controlled Actions
Responsibility becomes blurred when RPKI is described as a single service. It is a chain of controlled actions performed by different parties.
The resource holder decides which origins and prefix lengths are authorised, unless it has delegated that decision to a provider. A certification authority issues and updates certificates representing resource scope. A publication service makes certificates, revocation information, manifests, and signed entities available. Relying party software fetches this material and validates it according to standards and implementation decisions. A cache provides validated payloads to routers. The network operator decides how the validation state affects routes received from customers, peers, or transit.
BGP then propagates the consequences through independently controlled networks.
Each action has a different error type. A holder may authorise too broadly, too narrowly, or too late. A certification authority may revoke, refuse, mis-scope, or sequence changes poorly. A repository may be unreachable, stale, or inconsistent. A validator may reject too much, retain data too long, expire it too quickly, or deviate from another implementation. A router may apply the wrong policy to the wrong session. An operator may enforce without a tested exception path or fail to enforce where protection was promised.
The chain is hierarchical in authority but distributed in action. This distinction prevents two opposite errors. The first is to claim that a registry directly turned off a route simply because its certificate action contributed to the invalid state. The second is to exonerate the registry because autonomous operators made the final routing decisions. Causality can be shared without becoming unbounded.
Governance should tie evidence and remedies to the controlled link. Who changed the resource scope? Who signed? Who published? Who validated? Who transmitted the payload? Who changed the route treatment? What could each party observe at the time? What correction could each perform? This yields a defensible accountability story without pretending that one organisation controls the entire Internet.
It also helps with compensation. A holder who omitted a legitimate origin should not offload every loss onto a certification provider that published exactly what the holder requested. A provider that published inconsistent state should not hide behind the operator's independent rejection policy. An operator who configured brittle enforcement without redundancy should not portray its local choice as an inevitable command from the certification authority. Loss should follow control, foreseeability, and the ability to prevent or limit harm.
Concentrated Authority Is Most Dangerous When Exit is Ceremonial
A resource holder may appear to control its ROAs because an online portal allows it to create and delete them. The practical distribution of authority may be different. If the registry runs the certification authority, holds the private key, controls account access, provides the sole accepted publication point, and can suspend service under broad conditions, the holder's control is conditional. It can request an action but may be unable to continue signing or publishing after a dispute.
Hosted service is valuable. Small networks should not be forced to run sensitive cryptographic systems without support. The institutional problem arises when convenience becomes non-transferable dependence. If a holder cannot switch from hosted to delegated certification, change the publication provider, export necessary history, or maintain continuity during a service dispute, adoption has increased the provider's practical leverage.
Delegated certification can reduce this concentration by allowing the holder or a chosen specialist to control subordinate signing keys. It does not eliminate the parent authority. A parent can still change or revoke the certificate under which the subordinate operates. Nor does delegation solve publication reliability, key loss, or staff capability. It changes the ordinary balance: the holder controls routine signing and can separate operational support from permanent custody of its authority.
Portability should involve more than possession of key material. The holder needs an understandable record of certificates, signed entities, publication references, current and intended changes, audit evidence, and dependencies. A move must avoid conflicting valid states or a gap in publication. The outgoing and incoming provider need a limited handover with independent observation. The parent must not use the migration to impose unrelated commercial terms.
Exit is therefore a risk control. A provider that knows holders can leave has stronger incentives to maintain service quality, explain adverse actions, and price support separately from authority. A holder that can leave has a credible remedy before a dispute reaches litigation. As RPKI enforcement increases, ceremonial exit becomes less acceptable because the consequence of a failed exit is no longer inconvenience at a portal; it may be a diminished ability to authorise global reachability.
Validation Diversity Does Not Create Independent Truth
Operating multiple validators is sound practice. It protects against process failures, local host problems, software bugs, network isolation, and implementation-specific behaviour. Using separately maintained implementations can expose deviations that identical instances would reproduce. Geographically and administratively separate caches reduce common local dependencies.
But validation diversity has a limit. Validators generally consume the same signed hierarchy. If the controlling certificate or ROA is wrong and validly signed, all compliant validators may agree on the same harmful output. Agreement in this case indicates consistent computation, not correct institutional judgment.
The distinction matters because organisations often describe redundancy as if it solved concentration. Five validators under a faulty parent fact can make deployment resilient while making the shared mistake more reliably available. Multiple repository instances can replicate stale or wrong material. Independent software can correctly reject the same overclaim. Diversity under a common authority does not diversify authority.
The remedy is multi-layer. Validator operators should use current implementations, compare outputs, monitor timeliness, and test failure modes. Certification providers should use atomic or safely ordered publication, independent pre-publication checks, and externally visible change logs. Resource holders should receive notifications about material state changes and maintain a verified correction path. Operators should define how conflicting validator outputs affect routing instead of letting an undocumented first answer decide.
The 2020 study on relying parties provides a further warning. Researchers observing three certification authorities identified inconsistent fetch behaviour and found that almost 90% of observed relying parties could not connect to delegated publication points under certain tested conditions. The authors warned that such behaviour could cause spurious invalid states and reachability loss. The exact internet-wide incidence cannot be deduced from this experiment, but it shows that implementation diversity and repository topology can introduce their own correlated weaknesses.
Adoption reports should therefore distinguish instance count from authority diversity, software diversity, network path diversity, and administrative independence. A high instance count may still represent a managed service, a software family, or a trust decision. Resilience claims are credible only when they identify the failure class that each duplicate can survive.
Operator Autonomy Is Real, But Convergence Can Still Cause Common Harm
Standards separate validation state from routing action. A router can mark a route as Valid, Invalid, or NotFound and leave policy to the network. This preserves a core principle of Internet routing: autonomous networks decide which routes to accept and prefer according to their technical and commercial circumstances.
Autonomy does not prevent correlated outcomes. Large operators read the same security guidelines, use similar vendor examples, and face similar pressure to reject invalid announcements. A few topologically important networks can influence many downstream paths. Managed security services can distribute a policy over numerous customers. Procurement requirements can turn a voluntary control into a practical market expectation. Convergence may be reasonable, but it increases the cost of a common upstream error.
The answer is not to demand permissive routing. An operator that promises origin validation should be able to reject clearly unauthorised routes. It should also know what it is rejecting and how it will react when credible evidence points to a mistake. Policy should be explicit by peer class and address family. Changes in validation state should not trigger destructive router behaviour. Multiple caches, timeliness alarms, and safe re-evaluation reduce avoidable instability.
Exception mechanisms require care. A local assertion can preserve reachability during an adverse certificate action or documented error but changes only the local view. If used casually, exceptions can hide poor authorization hygiene and weaken protection. If unavailable, a network may have to choose between following a suspect invalid state and restoring an important customer through a makeshift filter. A controlled exception should name the affected prefix and origin, the justification, the approving person, the start, the expiry date, and the review condition.
Operators should publish aggregate enforcement descriptions without revealing sensitive topology. They can state whether invalid entries are rejected from customers, peers, and transit; whether IPv4 and IPv6 differ; how many validator views are required; what happens during stale data; and how an affected network can submit evidence. Transparency makes adoption measurable and gives holders a realistic correction path.
The final routing decision remains local. So does the responsibility for a brittle policy. Institutional risk transfer should not turn a valid security recommendation into immunity for operators who have ignored available resilience controls.
Transfers, Leasing, and Mitigation Expose the Seams
Static ownership examples make RPKI seem simpler than operating networks is. Risk arises at transitions and shared roles.
An IPv4 transfer changes the recognised resource authority. The seller may have existing ROAs, delegated certificates, repository references, and customer routes. The buyer may plan a different origin, announce through a transit provider, or subdivide the block. If registry recognition switches before old authorisation is withdrawn or before new can be published, the transaction can create an invalid state or a period without useful authorisation. The January 2021 incident showed that even parent-child resource sequencing beyond the two parties can matter.
Leasing separates the registered holder from the originating operator. The lessor may control RPKI while the lessee depends on timely authorisation. A broker may coordinate commercial terms but have no certificate authority. A transit or hosting provider may announce on behalf of the lessee. When the arrangement ends, authorisation must be removed at the right time. Too early causes disconnection; too late leaves authority beyond the commercial relationship.
DDoS mitigation creates another temporary origin relationship. During an attack, a specialist may originate more-specific routes and funnel filtered traffic back through a tunnel. If authorisation is missing or the max length is too tight, the protective action can be classified as invalid precisely when the customer is under stress. An overly broad pre-authorisation can extend a provider's authority that is only occasionally used. The correct design aligns scope, activation evidence, and revocation.
Mergers, network outsourcing, and corporate restructurings create similar seams. The legal entity, resource holder, operating network, and public name may change on different dates. RPKI does not decide the commercial transaction, but its state can make an incomplete transition visible through routing consequences.
These cases explain why adoption quality cannot be assessed only by asking whether a ROA exists. The better measure is whether authorisation accurately follows the operational relationship through changes. Transfer records, certificate changes, observed BGP, and correction intervals should be examined together. A high-coverage environment that handles transitions poorly may be safer on ordinary days and more fragile in the moments when authority matters most.
External Monitoring Must Be Independent of the Authority Being Measured
A certification provider needs internal alarms, but internal assurance cannot be the sole evidence of correctness. The organisation that signs or publishes states has incentives to detect mistakes quickly, but it also controls the records used to explain its performance. Independent observation offers a different perspective.
The NIST RPKI Monitor demonstrates the type of evidence available. It compares ROAs with RouteViews BGP data at six-hour intervals and enables analysis by date, address family, and registry region. It distinguishes invalid causes such as origin mismatch and max length mismatch, lists prefix-origin pairs, examines overlapping routes, and records validation state changes over selected intervals. Its method does not observe every path or operator policy. It creates a reproducible external report of what selected global routing data and signed authorisation showed.
RIPE RIS and RouteViews add archived BGP observations from participating peers and collectors. Independent validators can preserve signed state snapshots and logs. Operator looking glasses and reachability tests can show whether an affected route remained visible from selected locations. Incident reports can cross-reference these clocks.
Monitoring design should prevent a provider from grading its own work. A public record should identify certificate and authorisation changes, repository timeliness, validator disagreements, visible route state changes, reported reachability impact, and correction milestones. Sensitive account evidence can remain protected. The external result needs enough detail for another qualified examiner to reproduce the timeline.
Measurement limits should be explicit. A route missing at one collector may be visible elsewhere. A valid route may still be hijacked through a path attack or subject to ordinary failure. An invalid route may remain reachable where operators do not reject it. Access logs show fetches, not necessarily router enforcement. Customer reports may reveal harm but mix routing, DNS, transport, and application issues.
These limits do not justify opacity. They justify multiple evidence classes. The goal is not magic global truth input. It is to ensure that the authority whose change may have caused harm cannot define the incident solely through its own dashboard.
Correction Speed Must Be Measured End-to-End
An institution can correct its database quickly while external impact persists. End-to-end recovery has multiple clocks.
The first clock runs from error creation to detection. The resource holder may notice a route failure, an external monitor may detect a state change, or the certification provider may find an inconsistency. The second runs from detection to an accepted correction request. Account access, identity verification, and escalation determine this interval. The third runs from approval to corrected publication. The fourth includes repository fetch and validator update. The fifth includes cache-to-router distribution, local policy re-evaluation, and BGP convergence.
Reporting only the clock controlled by one party can make performance look better than the user's experience. A certification provider may say a ROA was corrected within minutes of approval while approval took hours and validators retained the previous state. An operator may say it quickly restored a local exception while most other networks continued to reject the route. A holder may say it transmitted correct data in timely fashion while its own earlier authorisation caused the incident.
A mature service should publish percentile measurements for each controllable interval and a bounded external estimate for the entire sequence. High-impact events deserve a timestamped public report. Routine corrections can be aggregated to protect customer confidentiality. Tail performance is more important than a simple average because a long outage can endanger contracts, emergency services, or a small operator's solvency.
Service expectations should reflect adoption. As enforcement becomes more widespread, a correction target suitable for an optional information service becomes inadequate. The authority should maintain 24-hour reachable escalation for certificate errors with credible reachability impact. This does not mean every complaint gets an immediate authorisation change. Fraud is possible, and competing claims require preservation. It means the institution can quickly distinguish an authenticated holder correction from a contested attempt and apply the narrowest safe interim measure.
Recovery drills should include transfers, max-length errors, account lockout, repository inconsistency, validator deviation, and delegated provider failure. The drill succeeds when external monitors and selected operators see the expected corrected state, not just when an internal interface reports completion.
Compensation Turns Accountability from Politeness into Discipline
Many infrastructure agreements exclude broad categories of consequential damages. Some limitation is understandable. Registries and security providers cannot guarantee global routing, and the value resting on a prefix may exceed any reasonable service fee. Unlimited liability might discourage useful services or make access prohibitive.
Total practical immunity creates the opposite problem. If a provider controls certificate issuance or publication, can foresee that a preventable error may affect reachability, and bears none of the resulting costs, adoption transfers risk to holders and their customers without transferring discipline. Apologies and post-mortems improve knowledge but do not restore lost transactions or emergency capacity.
Compensation should be structured, not theatrical. A service credit scheme can cover missed publication or correction commitments. A funded claims mechanism can cover verified direct response costs for serious, provider-caused incidents. Insurance can cover defined operational failures. Independent determination is required where the provider disputes causality. Caps can vary by service level and controlled risk rather than claiming every network has the same exposure.
The claimant should demonstrate a causal chain using certificate state, publication records, validator evidence, route observations, and documented loss. The standard should not require that every network on earth rejected the route. It should separate direct mitigation costs, contractual service penalties, lost revenue, and speculative reputational harm. Contributory negligence matters: stale holder authorisation, weak operator redundancy, or delayed reporting may reduce recovery without eliminating provider responsibility.
Non-monetary remedies are also important. Correction, public clarification, evidence preservation, independent review, fee waiver, portability assistance, and changes to controls can reduce future harm. Repeated errors should affect assurance status and provider eligibility.
The point is not to monetise every routing incident. It is to ensure that the institution best placed to prevent a class of error has a reason beyond reputation to invest in prevention. If adoption increases the blast radius of that error, compensation capacity should also increase.
An Adoption Risk Dataset Should Combine Facts Usually Kept Separate
The strongest empirical test for 2020–2027 is a connected event study. Existing sources often isolate one layer: ROA counts, certificate statistics, validator observations, BGP routes, outage reports, or transfer logs. Institutional risk appears in the connections between them.
The unit should be a material authorisation state change affecting an observed prefix-origin pair. For each event, researchers should record time, certificate authority, authorisation before and after, max-length change, resource transfer or account event where public, repository timeliness, validator outputs from multiple implementations, BGP visibility, overlapping routes, operator reports, corrective actions, and total duration. Personal and commercially sensitive data can be minimised.
Events should be cautiously classified: holder configuration, certification action, publication inconsistency, validator error, repository unreachability, transfer transition, leasing relationship, mitigation service, suspected hijack, unresolved mismatch, and mixed cause. Classification confidence should be published. A route may change category as evidence improves.
Adoption exposure should be estimated through multiple proxies: covered prefixes, address units, visible validating networks, topological reach of known enforcers, affected path count, and observed disconnection. A single proxy is limited public evidence. The outcome should compare the same error class across adoption levels and time.
Analysis should test both benefit and cost. How often did invalid treatment constrain a likely unauthorised origin? How often was a legitimate operational arrangement invalidated? How long did each persist? Which certificate or repository errors produced wide validator disagreement? Did overlapping valid routes preserve reachability? Did correction become faster as institutions gained experience? Did high-enforcement environments create stronger incentives for clean authorisation?
The expected outcome is not simple condemnation. Adoption may reduce overall routing harm even while increasing the severity of rare upstream errors. This would support continued adoption with stronger safeguards. Alternatively, some architectures may show high authorisation coverage but weak operational correction, suggesting that progress at the top has outpaced institutional maturity. Only connected evidence can distinguish these outcomes.
The Test in 2027 Should Be Prospective and Falsifiable
The final year in the 2020–2027 horizon has not yet delivered a complete record. It should be treated as a test period with published questions, not as an already known outcome.
First: Does authorisation growth continue without an increasing absolute load of persistent legitimate invalids? The denominator should include newly covered prefixes and separate temporary deployment errors from long-lived conflicts. Second: Do certification providers publish full incident histories, including events that did not become globally visible? Third: Do validator and repository operators disclose timeliness and deviations in a way holders can understand?
Fourth: Can holders switch between hosted, delegated, and qualified publication arrangements without losing continuity? Fifth: Do transfer and leasing transitions show measured authorisation switches? Sixth: Can an affected operator reach a 24-hour correction path and receive a reasoned response? Seventh: Are large validating networks transparent enough about policy and exceptions for incident analysis without revealing sensitive routing design?
Eighth: Does any compensation mechanism actually pay a claim or provide material remedy when a provider-controlled error causes verified harm? A remedy that exists only in favourable publicity is not a control. Ninth: Do independent monitors retain sufficient historical data to challenge an incomplete institutional account? Tenth: Are assurance audits targeted at the certificate and repository risks that adoption has made consequential?
These tests are falsifiable. Portability can be demonstrated through completed moves and timed drills. External monitoring can be verified against stored snapshots. Correction can be measured from first credible warning to observed recovery. Compensation can be audited in anonymised aggregation. Persistent invalids can be measured against stated collection limits.
Adoption targets should be paired with these tests. A provider that promotes more ROAs while refusing to publish correction performance reports only the benefit side of its power. An operator that advocates strict rejection but offers no credible incident contact transfers operational risk to parties it may disconnect. A holder that demands compensation while neglecting its own authorisation hygiene asks others to insure an avoidable choice. The framework applies to every controlled action.
The Number Resource Society Can Turn Risk Transfer into an Explicit Membership Deal
The Number Resource Society (NRS) has a constructive role if it avoids treating RPKI either as a branding instrument or as grounds for acquiring unbounded certificate power. Its contribution should be a clear deal: members support route origin security, and the institution limits the authority that security requires.
The first safeguard is choice. Members should be able to use a supported hosted service, operate a delegated certification authority, or appoint a qualified specialist, subject to interoperable security requirements. The Society should not retain private keys simply because support is easier when custody is centralised.
The second is portability. Certificate and publication arrangements should have tested transition procedures, exportable evidence, and time-bound cooperation obligations. A member in a billing, governance, or policy dispute should not lose routine signing control unless a narrow, demonstrated security or legal ground requires action.
The third is independent observation. The NRS should fund monitors not subordinate to the certificate service team and should publish incident records with clear evidence boundaries. Members and external researchers should be able to compare signed state with observed routing without relying on privileged access.
The fourth is remedy. Terms should assign duties among holder, certification provider, repository provider, and operator. Emergency correction, review, evidence preservation, and compensation should be constituted before broad adoption. Providers should hold financial capacity proportional to the errors they control.
The fifth is humility about reach. The NRS cannot force every network to accept a route, guarantee that a valid route is safe, or eliminate the authority of an RPKI parent. It can make its own services replaceable, its decisions reviewable, and its incident evidence credible. That is a significant positive contribution because it makes adoption less dependent on sole institutional trust.
The NRS should be judged on completed drills and negative cases, not on declarations. A member that cleanly moves its certification service, corrects an error under pressure, and receives a remedy after a provider fault demonstrates more than another coverage chart. The institution gains legitimacy when it can support stronger routing security while accepting limits on its own power.
Conclusion: Security Adoption Needs an Institutional Balance Sheet
RPKI adoption is often presented as a one-way transfer from uncertainty to security. The more accurate representation has two sides. Correct authorisation and sensible route treatment reduce the reach of unauthorised origins. The same shared authority can increase the reach of faulty certificate, repository, and configuration states.
This is not a paradox that invalidates deployment. It is the normal condition of infrastructure that becomes consequential. Power grids, payment systems, and identity systems all gain value from shared controls while acquiring correlated failure modes. The answer is separation of powers, portability, independent measurement, tested recovery, and credible loss allocation.
For RPKI, the balance sheet must preserve architectural precision. Certification authorities influence validated resource authority; they do not operate every router. Operators choose routing policy; they do not create the upstream certificate facts they consume. Holders control authorisations to varying degrees; they may still depend on hosted custody and account access. Validators compute states; they cannot correct a validly signed institutional error.
Adoption data should therefore be published alongside error and failure data. Coverage should be linked with persistent invalids, certificate changes, transfer events, validator behaviour, routing observations, and correction time. The 2021 RIPE NCC event and the 2023–2024 research on invalid routes show that narrow defects can be amplified and that most observed invalids require more explanation than a hijack label.
The policy direction is positive but conditional. Continue to increase accurate ROA coverage. Continue to provide diverse validation and proportionate route treatment. Simultaneously give holders meaningful certificate choice, require secure publication, observe externally, practise correction, and compensate verified harm according to control.
By the end of the 2020–2027 study horizon, success should mean more than a higher adoption percentage. It should mean that a malicious or accidental unauthorised origin announcement is less likely to propagate, while an institutional upstream error is less likely to become an unassailable global penalty. Security improves when authority becomes effective. Legitimacy improves when effective authority can be observed, challenged, moved, and forced to bear the costs of its own avoidable mistakes.
Sources and Scope
- RIPE NCC Annual Report 2025– 2024-2025 figures for IPv4 and IPv6 ROA coverage, validated ROAs and RPKI certificates in the RIPE NCC service context, and institutional resilience priorities.
- NIST RPKI Monitor Methodology– Six-hourly RouteViews comparison, invalid classification, overlapping route analysis, and historical validation state changes.
- RIPE NCC, RPKI Outage Post-Mortem, 8 January 2021– Parent-child publication inconsistency during an outgoing transfer, estimated affected relying parties and corrective actions.
- RFC 6811, BGP Prefix Origin Validation– Valid, Invalid, and NotFound states for origin validation.
- RFC 7115, Origin Validation Operation Based on RPKI– Operator policy considerations and the distinction between validation information and routing action.
- RFC 8210, RPKI to Router Protocol– Validated cache sessions, serial numbers, refresh, retry, and expire behaviour.
- RFC 8211, Adverse Actions by a Certification Authority or Repository Manager– Limited analysis of harmful authority and repository actions.
- RFC 8416, Simplified Local Internet Number Resource Management with RPKI– Local filters and assertions that can address certain adverse or exceptional states without changing the global signed authority.
- RFC 9324, Policy-Based Route Leak Protection– Evidence that route re-evaluation behaviour can itself cause destructive load and operational instability.
- Kristoff et al., On Measuring RPKI Relying Parties– 2020 relying party measurement, repository fetch behaviour and limits of instance-level resilience claims.
- Zhang et al., Demystifying RPKI-Invalid Prefixes: Hidden Causes and Security Risks– 2023-2024 ROA coverage, persistent invalid observations, cause classification, and measured lease-related disconnection.
- RIPE RIS DocumentationandRouteViews API Documentation– Independent sampled BGP observation, suitable for limited incident timelines.
The numerical results in this article maintain the denominator, observation period and visibility limits of their cited sources. Route collectors do not observe every path, visible validators do not represent every enforcing network, and a validation state does not prove legal claim or malicious intent. Recommendations on portability, compensation, linked incident data and NRS membership protection rights are prospective institutional proposals for assessment by 2027.

