Summary
- RPKI makes routing safer by letting resource holders publish cryptographic route-origin authority, but the same trust chain can make ARIN account control, agreement status, hosted-service dependence, transfer timing and revocation rules part of IPv4 continu.
- The engineer sees the problem before anyone calls it governance.
The ROA that becomes a continuity question
The engineer sees the problem before anyone calls it governance. A customer migration is scheduled for the weekend. A managed-services platform is moving a group of IPv4 prefixes from one origin ASN to another, with a new transit mix, a narrower announcement plan and a customer contract that now treats route-origin validation as a normal security control. The BGP change is rehearsed. The maintenance window is booked. The customer wants the new route-origin authorisation in place before traffic moves. The engineer opens the ROA inventory and finds that the apparently technical step depends on a registry-facing chain of authority. The current authorisation sits under an ARIN account. The address block may have legacy history. The authorised origin is about to change. The customer wants assurance not only that the route can be announced, but that the route will be seen as valid by relying networks that use RPKI.
At first glance, nothing dramatic is happening. No one is hijacking a route. No court has frozen a resource. No hostile party is trying to seize account control. The registry is not in crisis. The question is smaller and therefore more revealing: who can make the route-origin statement, under which service relationship, and what happens if the recognised registry state does not move at the speed of the network?
The same question appears in a transfer file. A buyer looking at an address-heavy hosting business asks whether existing ROAs will be withdrawn cleanly by the source and recreated by the recipient. A lender asks whether revenue tied to scarce IPv4 space depends on a security service that can be interrupted by account status, agreement coverage or unclear authority. A lessee asks whether the lessor can publish and maintain ROAs for the lessee's ASN, remove stale authorisations at the end of the term and respond quickly if a downstream customer changes upstream providers. A board asks whether the company is relying on a registry-operated trust service without knowing the conditions under which that service can be delayed, limited, suspended or revoked.
That is the economic centre of ARIN's RPKI governance risk. RPKI is correctly promoted as routing security. It helps resource holders state which autonomous systems are authorised to originate which prefixes. It gives validators a cryptographic signal that ordinary BGP never supplied. It helps network operators reduce accidental leaks, mistaken origin announcements and malicious origin claims. But it is also registry recognition made machine-readable. The trust chain depends on a relationship between number resources, certificates, accounts, publication infrastructure, service terms and recognised authority. When that relationship is narrow, auditable and stable, RPKI lowers risk. When it is broad, opaque or hard to contest, it can turn registry recognition into a new continuity dependency.
ARIN is a useful case precisely because the North American setting is comparatively orderly. The concern is not that ARIN is visibly failing. The concern is that a mature post-exhaustion registry can acquire new practical leverage when security services become part of ordinary operations. ARIN's registration record, transfer recognition, account roles, agreement boundaries, reverse-DNS support, routing-registry support and RPKI services sit inside the same scarce-IPv4 economy. That service stack is valuable. It also requires institutional restraint because each additional trusted service can become another surface where resource holders, buyers, lenders, lessors and customers must ask whether the registry is acting as a narrow steward or a broader gatekeeper.
The article's question is therefore not whether route-origin validation is useful. It is useful. Nor is the question whether ARIN should run trust services casually. It should not. The question is whether ARIN's control over certification infrastructure is sufficiently constrained that a holder can adopt RPKI without handing the registry a discretionary switch over network identity. A ROA may be a compact signed statement, but when validators, customers and counterparties rely on it, the governance behind that statement becomes part of the price of continuity.
RPKI governance risk is registry power made cryptographic
RPKI begins with a technical weakness in routing. BGP lets networks announce reachability, but it does not by itself prove that the announcing ASN is authorised by the resource holder. A mistake can leak routes. A malicious actor can announce space it should not originate. A filter based only on habit, private letters, old routing-registry entries or informal trust can miss the problem. RPKI adds a resource-certification hierarchy around number resources and lets the resource holder publish a route-origin authorisation. The ROA says, in effect, that a named ASN may originate a specified prefix, usually within a stated maximum prefix length. Validators fetch the published material, check the certificate chain and produce route-origin validation states that network operators may use in their routing policies.
The cryptography is important, but the institutional claim behind the cryptography is more important for this analysis. A validator can verify that a ROA chains to the relevant trust structure. It cannot independently decide whether a predecessor corporation validly transferred a block, whether an old legacy holder's officer has authority, whether a lessee's commercial permission is still alive, whether an account change was made by the right person, or whether a service restriction reflects fraud prevention, a technical safety rule or institutional leverage. The certificate turns registry recognition into machine-readable routing evidence. It does not remove the registry from the system.
RPKI governance risk should therefore be defined carefully. It is the risk that cryptographic validation reduces routing mistakes while increasing dependence on a registry-controlled certification authority. The same service that lets an operator express intended route origins can also make account authority, agreement coverage, certificate state, hosted-service availability, delegated-service continuity, revocation procedures and registry judgement part of network continuity. The danger is not that every RPKI action is suspect. The danger is that the security layer can become difficult to distinguish from the governance layer that controls access to it.
The difference between a tool and a lever is the key distinction. A routing-security tool helps a resource holder express an operational fact: this ASN is authorised to originate this prefix. It reduces ambiguity for relying networks. It gives customers and transit providers a stronger signal. It should be boring, precise and tied to verified resource authority. A governance lever does something different. It allows a registry decision about account status, agreement coverage, transfer recognition, legacy posture, dispute classification, billing standing or institutional preference to alter the credibility or continuity of the route-origin statement.
Some registry control is unavoidable. A registry should not allow a compromised account to publish false ROAs. It should not let a party that is not the recognised holder certify a prefix. It should not ignore a completed transfer. It should not keep a certificate alive for a returned or misregistered resource. It should be able to correct false authority and comply with lawful decisions. A trust service that cannot revoke or constrain false statements is not trustworthy.
Unavoidable control, however, is not open-ended discretion. The more RPKI is adopted, the more ARIN decisions around certification, publication and service eligibility will be priced by buyers, lenders, lessors, customers and network operators. ARIN reported thousands of organisations signed up for its RPKI services by the end of 2025, with hosted RPKI accounting for the overwhelming majority of use. That is a sign of adoption and service value. It is also a sign of dependency concentration. When hosted service is the dominant model, the registry is not merely operating a helpful portal. It is becoming the operational custodian for most participants' route-origin publication.
This does not make hosted RPKI wrong. It makes its governance significant. The best technology in a post-exhaustion registry is not the technology that maximises registry centrality. It is the technology that reduces routing risk while keeping institutional authority constrained. The cryptographic chain should strengthen the holder's ability to operate, transfer, lease, finance and serve customers safely. It should not become an implicit argument that because the registry runs a security service, every service boundary, account rule or agreement condition may be used as an instrument of wider control.
Hosted convenience concentrates reliance
Hosted RPKI is attractive because it lowers fixed cost. A resource holder can use registry systems to create and maintain ROAs without building a complete certification operation of its own. Smaller networks, universities, enterprise holders, regional ISPs, hosting firms and public institutions are unlikely to want a separate RPKI publication system, specialist staff, key-management process and repository-monitoring regime. They want a stable service that lets them add the right origin, set the right maximum length, avoid stale authorisations and see clear change history. If a registry provides that safely, adoption rises and routing hygiene improves.
ARIN's reported adoption pattern shows why this matters. Thousands of organisations have signed up for RPKI services, and almost all of them use hosted RPKI. That ratio is not surprising. Hosted service is the convenient default. It matches the way many holders already use ARIN Online for registry management. It lets a network engineer work from the recognised account rather than from a separate certificate-operation stack. It makes ROA changes accessible to organisations that would otherwise postpone RPKI because the operational burden is too high.
The dependence is the other side of the convenience. In the hosted model, the holder's ability to express route-origin authority depends on ARIN account controls, service availability, publication systems, service terms, support responsiveness and interpretation of eligibility. The holder can decide what it wants to authorise, but the registry-operated system is the publication path. If account authority is unclear, the holder waits. If agreement coverage blocks access, the holder must change its legal relationship or find another route. If a transfer is pending, old and new parties must coordinate through the registry-facing sequence. If a dispute marker appears, the registry must decide what can safely change and what should be preserved.
That dependence is manageable only if the boundary is clear. A holder should know which facts can affect hosted RPKI access: resource registration, account authentication, agreement coverage, fee standing, suspected compromise, transfer state, legal restraint, returned resource, proven false authority or technical incident. It should also know which facts should not affect RPKI except through a defined rule: disfavoured commercial model, leasing posture, criticism of registry policy, aggressive but lawful IPv4 strategy, or broad discomfort with address monetisation. The service is trustworthy when the first category is narrow and the second category is excluded.
Hosted RPKI also makes service reliability a governance metric. A portal outage, repository incident, delayed support queue or unclear escalation path can become a routing issue. The harm may not be a universal outage. It may be a missed migration window, a customer onboarding delay, a route that remains unvalidated when a contract expected validation, or a stale ROA that makes a new origin appear invalid to stricter networks. The cost is borne by the holder, its customers and relying networks; ARIN's direct financial exposure may be much smaller.
The right response is not to discourage hosted service. The right response is to make the hosted model auditable. ARIN should be able to show aggregate service availability, ticket timing for RPKI requests, categories of publication incidents, recovery times, emergency lock use, revocation categories, transfer-related ROA delays and the share of changes handled automatically rather than manually. It need not publish private account details. It should publish enough for the market to know whether hosted RPKI is a reliable security service or a hidden queue whose delays are discovered only during customer migration.
Hosted convenience can be a public good if it is coupled with institutional modesty. The registry should make the safe path easy, not make the easy path the route into broad control. A holder that uses hosted RPKI should be treated as a resource holder using security infrastructure, not as a party that has accepted a larger discretionary dependency than the security function requires.
Delegated control is portability with a burden
Delegated RPKI points in the opposite direction. Instead of relying entirely on the registry's hosted publication path, a capable resource holder can operate more of its own certification environment under the registry's trust relationship. That can reduce single-institution dependence. It can let a large network, cloud operator, carrier, security provider or specialised address manager integrate RPKI into its own change-control, monitoring and incident-response systems. It may give the holder more direct control over publication timing, internal approvals and operational resilience.
Delegation is not independence from the registry. The trust chain still begins with registry recognition. The holder still depends on the registry to recognise the resource relationship and maintain the parent certificate relationship. If the registry record is wrong, if the holder's registration is disputed, if the resource is transferred, if a certificate relationship is constrained, or if a lawful order affects the resource, delegated operation cannot pretend the registry does not exist. Delegation moves operational work downstream; it does not abolish the institutional root.
The economic tradeoff is capability for portability. A small network may prefer hosted RPKI because the burden of running delegated infrastructure is not worth the independence. A large operator may prefer delegated control because the cost of dependence is higher than the cost of technical operation. A lender or customer may view delegated RPKI as evidence that the holder has mature controls, but it may also ask whether those controls are audited and whether the registry relationship remains stable. A buyer may prefer a seller whose delegated service has clean logs and procedures, but it still needs to know how the delegation terminates or moves at closing.
Delegation also creates its own failure modes. Keys must be protected. Repositories must remain available. Staff must understand certificate lifecycles, manifests, revocation material, validators and route-change timing. A misconfigured delegated setup can harm reachability confidence just as much as a hosted delay. A holder may gain independence from one registry portal while creating dependence on a thin internal team. If the holder is acquired, reorganised, insolvent or split across business units, delegated control can become another authority file that must be reconciled.
For ARIN, the governance lesson is that hosted and delegated RPKI should not be treated as a simple maturity hierarchy. Hosted service is not second-class; delegated service is not a complete escape. They are different allocations of operational burden and institutional dependence. The registry should make both options legible: what ARIN controls, what the holder controls, how transitions occur, what audit evidence exists, what happens during transfer and what emergency action is available if either side fails.
The portability question is especially important. If a holder can move from hosted to delegated service, or preserve RPKI continuity through transfer, without discretionary obstruction, then registry control is narrower. If the practical path from hosted dependence to delegated control is unclear, expensive or vulnerable to unrelated account conditions, then hosted adoption can create lock-in. Lock-in may be convenient for service metrics, but it is not healthy for a market built on scarce network identifiers.
Delegated RPKI therefore illustrates the proper direction of reform. The aim is not to remove ARIN from the trust chain. That would misunderstand RPKI's resource-certification design. The aim is to ensure that holders with the capability to carry more operational responsibility can do so under transparent conditions, and that holders using hosted service are not punished for choosing the lower-burden path. A mature registry should support different control models without converting either into leverage.
Transfer settlement now includes route-origin handover
IPv4 transfers make RPKI governance concrete because a transfer is not economically complete when money moves. It is complete when the registry record, account authority, routing authority, reverse DNS, abuse contacts and route-origin material align with the recipient's intended operation. A buyer that receives recognised registration but inherits stale ROAs, missing ROAs or delayed ROA access has not received the full continuity package it expected. The block may route. The contract may be signed. The public holder may have changed. Yet the buyer's customer commitments may still depend on whether RPKI is clean.
ARIN transfer guidance already recognises the operational problem. Source organisations in transfer contexts are expected to review existing ROAs, remove or edit transferring prefixes, check maximum-length settings, update routing-registry entries and coordinate reverse-DNS delegation. That guidance is practical and important. It shows that transfer is not only a legal or administrative event. It is a change in the security and naming state that other networks may consume.
The settlement problem is timing. A source may need to remove an old ROA before the buyer announces from a new ASN. The buyer may need to create a new ROA before a customer migration. If the resource moves through a merger or reorganisation path, the recipient may expect continuity because the network or operating business moved with the entity. If the resource moves through a specified-recipient path, source and recipient tickets, agreements, fees and recipient qualification must align. If the transfer is inter-RIR, another registry's rules and validation process enter the sequence. Each step can create a gap between private expectation and public route-origin confidence.
Escrow terms increasingly need to account for that gap. A serious buyer should not only ask whether the source is the current registered holder and whether the transfer path is available. It should ask whether all existing ROAs have been inventoried, which ASNs are authorised, whether maximum-length values match the buyer's plan, who will remove stale material, when the buyer gains service access, whether agreement coverage is required and what happens if the registry cannot process the change before the migration window. A seller should not promise security-state delivery if it lacks account authority or if legacy agreement status prevents the relevant service.
The problem is not confined to outright transfers. RPKI also affects leases and customer migrations that do not transfer registration. In many leasing structures, the holder remains the ARIN-recognised registrant while another network originates the prefix. That arrangement can be operationally legitimate. The ROA can express that the holder authorises the lessee's ASN. But the lessee depends on the holder or lessor to publish and maintain the ROA. If the lessor is slow, if service access depends on an agreement line, if a dispute arises at the holder level, or if a registry-side review limits changes, the lessee bears customer exposure without direct registry control.
A practical closing file now needs a route-origin section. It should list every prefix, every current ROA, every authorised origin, every maximum-length value, every intended post-closing origin, every dependent customer migration and every party with authority to change the state. It should specify whether old ROAs are removed before or after registry recognition, whether temporary overlap is safe, whether a staged announcement plan creates invalids, and whether the recipient has tested service access. That does not make ARIN responsible for private deal drafting. It makes clear that registry recognition and route-origin continuity now meet in the same settlement package.
The policy principle is straightforward: RPKI state should follow verified resource authority and operational authorisation as predictably as possible. A transfer hold may be justified where the source is not verified, the resource is disputed, documents are inconsistent, an account is compromised or legal restraint applies. It is much harder to justify delay where operational authorisation is clear and the only effect of delay is to make a valid migration riskier. A registry that wants markets to trust its certificate chain should treat ROA transition as part of settlement finality, not as an afterthought.
Legacy resources turn service eligibility into a governance line
ARIN's legacy-resource boundary is one of the sharpest places where RPKI becomes governance. Legacy resources may have entered the registry before ARIN's modern agreement structure. ARIN's public position has distinguished between basic legacy registry services that can remain available outside a current agreement and certain additional services, including RPKI and Internet Routing Registry support, that require the resources to be covered by an ARIN agreement. That distinction may be defensible in legal and operational terms. It is also economically consequential.
When RPKI was unusual, access to it could be treated as an optional service. A legacy holder that declined an agreement might still maintain basic public records and reverse DNS while deciding that route-origin certification was not essential. As RPKI becomes part of ordinary routing hygiene, customer assurance and acquisition diligence, the same service boundary changes character. The holder may feel pressure to enter the agreement perimeter not because its historical claim has changed, but because modern counterparties now expect certification. A service condition becomes a governance line around legacy reliance.
This is not a simple accusation of coercion. Security services carry real risk. A registry may reasonably want a clearer legal relationship before enabling a holder to publish statements that other networks rely on. The registry needs to know who can act, which resources are covered, what terms apply, how fees are handled, what happens on transfer and what remedy exists for false or compromised publication. RPKI is not a passive display service like a static public listing.
The question is proportionality. If agreement coverage is required for RPKI, what specific risks does the agreement solve? Does it solve authentication, liability, fee recovery, service terms, revocation authority, policy incorporation, or all of them at once? Which provisions are necessary for the security service, and which expand the holder's exposure to broader policy change? Can a legacy holder access route-origin certification through a narrowly tailored security relationship rather than a broad relationship that changes unrelated expectations? Can existing live routes be protected during the transition from non-agreement status to agreement-covered service?
Counterparties will not parse these questions as contract theology. They will price them. A legacy block with clean records and available RPKI support may command more confidence than a similar block whose holder cannot access ARIN-hosted RPKI without legal debate. A buyer may prefer a block already under a current agreement because route-origin handover looks easier. A lender may discount a non-agreement legacy portfolio if customers increasingly expect RPKI. A lessor may gain an advantage if it can offer ROA support from an agreement-covered pool. A legacy holder may view the same dynamic as loss of historical independence through security-service pressure.
ARIN's legitimacy depends on candour here. If RPKI access requires agreement coverage, the reason should be stated in service-specific language rather than wrapped in broad stewardship rhetoric. The registry should explain how the agreement protects the trust service, what rights and obligations are limited to the service, how policy changes affect the holder, how mistakes are corrected and how service disputes are reviewed. It should not rely on the fact that route-origin security has become operationally desirable to pull legacy holders into a wider discretionary field without acknowledging the economic effect.
Legacy resources are not exempt from modern security discipline. Stale contacts, unclear successors, compromised accounts and false authority can harm everyone. But legacy status is also not a weakness that should be exploited through service bundling. The proper standard is narrow: make the security service available on terms that solve the real authority and liability problem, while avoiding unnecessary conversion of historical reliance into gatekeeper dependence.
Revocation power is rare, but it is economically priced
The most dramatic RPKI governance fear is revocation. A certificate or related publication material is withdrawn; a ROA that once supported a route is gone or no longer chains properly; validators change their view; networks using route-origin validation may treat an announcement differently. In practice, many RPKI risks will be quieter than that. A needed ROA is not created in time. A stale ROA remains after a migration. A transfer recipient cannot access service quickly. A holder's account is locked while authority is checked. A repository incident produces uncertainty. Yet revocation matters because it reveals the power at the core of the system.
A registry must be able to revoke in some circumstances. If a resource is returned, transferred, misregistered, subject to proven false authority, affected by key compromise, duplicated in error, or restrained by a lawful decision, preserving old certification material may be unsafe. If an account compromise produces a false ROA, emergency action may be necessary. If a holder no longer has authority over a prefix, continuing to certify its route origin would mislead the routing system. No serious RPKI governance model can abolish revocation.
The economic question is when revocation is allowed, who reviews it, how notice is given, what safe state is preserved and how mistakes are repaired. Revocation power can be rare and still priced. A lender does not ask only how often a collateral interest is challenged; it asks what happens if it is. A customer does not ask only whether a provider has a ROA today; it asks whether the provider can maintain the validated state through dispute, renewal, merger, billing error or account recovery. A buyer does not assume that a rare risk is irrelevant if the consequence could affect a migration window or customer reachability.
ARIN's legal and service posture matters because registry liability may be much smaller than the holder's business exposure. That mismatch does not make every limitation illegitimate. A registry cannot realistically insure the entire downstream economy of every route. Relying networks choose their own routing policies. Holders must manage their own accounts and route plans. But the mismatch should narrow the registry's discretion. If the registry's downside is limited while the holder's customer costs can be substantial, severe RPKI action should be tied to specific, reviewable grounds.
The strongest revocation model would classify cases. Security compromise is different from resource return. Transfer completion is different from nonpayment. A lawful restraint is different from stale contact validation. A false claim to a resource is different from a commercial lease dispute. A completed transfer may require old ROAs to be withdrawn and new ones created. A disputed transfer may require preserving the last verified safe state while blocking risky new changes. A billing issue should not automatically become a route-origin event unless a published rule, notice period and cure path make that consequence clear and proportionate.
Non-publication should receive similar discipline. A registry can harm continuity by delay without announcing an adverse decision. If ARIN cannot process a needed ROA change before a customer migration, the operator may postpone service or announce without the validation posture it promised. If a legacy holder's agreement path is unclear, security adoption may be delayed. If a transfer recipient waits for account access, settlement finality is incomplete. Each case may have a reasonable explanation. The governance problem is whether the explanation is visible, time-bound and open to escalation.
The safest standard is preservation of live security where possible. Existing valid ROAs for live routes should not be disturbed merely because a non-routing dispute exists. New or changed ROAs may need review where authority is unclear, but the review should identify the authority defect rather than hide behind broad concern. Emergency action should be logged, notified and reviewed after the fact if prior notice would create risk. Severe action should have an appeal or independent review path fast enough to matter to operations. A certificate should not become easier to disrupt than the network services it protects.
Validators make account decisions travel outside the account
RPKI governance is not only a matter between ARIN and the resource holder. Validators and relying networks create externalities. A transit provider, cloud backbone, exchange route server, content network, enterprise security team or upstream filter may use route-origin validation as part of its routing policy. Those parties do not control the ARIN account. They may not know the holder's transfer history, legacy status or service relationship. They see validation results and adjust behaviour accordingly.
Registry-side decisions therefore travel outward. If a ROA is wrong, delayed, revoked or stale, the effect may appear in networks that never participated in the account ticket. If a transfer closes privately but route-origin material remains with the source, a relying network may see contradictory signals. If a lessor fails to update a ROA for a lessee's new ASN, the lessee's customers may face reachability complaints even though the lessee is not the registered holder. If a registry-side service incident affects publication, operators downstream must decide whether the problem is local, regional or systemic.
The externality is intensified by automation. A human reading a public registration record may understand that a record can be historical, messy or incomplete. A router applying validation policy does not interpret corporate nuance. It treats the validation result according to local policy. Some networks may prefer valid routes. Some may reject invalids. Some may monitor but not filter. The policy is distributed, but the signal comes from the registry-linked trust chain. That combination is powerful: centralised authority expressed through decentralised enforcement by others.
This is why RPKI governance cannot be judged only by account-level service terms. The affected population includes customers, downstream networks, hosted tenants, content users, lenders, buyers and relying operators that may never appear in ARIN's membership system. ARIN membership and community participation are important institutional checks, but they do not fully represent the externality. The resource holder may vote or participate. The customer depending on the route may not. The relying network applying validation may not have any relationship with the holder. The harmed party during a mistaken certification event may be two contracts downstream.
Externality does not mean ARIN should become liable for every routing choice made by every operator. Relying networks choose their own validation policies. Holders choose their own route plans. Lessors and lessees choose their contracts. But the registry controls the certification relationship strongly enough that it should account for external effects before severe action. A revocation, emergency lock, transfer-related hold or publication delay should be reviewed not only for internal rule compliance but for downstream continuity.
A mature registry would therefore publish aggregate externality metrics. How many RPKI support cases were related to transfer, account recovery, suspected compromise, legacy agreement status, publication incidents, maximum-length mistakes or mistaken origin changes? How quickly were they resolved? How many affected live routes? How many required emergency communication to holders or relying parties? How often were changes reversed? How many cases involved hosted service versus delegated service? These numbers can be aggregated without exposing private security details.
The purpose of such transparency is not blame. It is risk pricing. Operators adopting RPKI need to know whether the trust service is stable under ordinary changes. Buyers need to know whether ROA handover is a routine part of settlement or a specialist risk. Customers need assurance that routing-security commitments are not fragile. Relying networks need confidence that registry-side incidents are rare, communicated and corrected. Without those signals, adoption statistics can become misleading. A high adoption rate says many holders rely on the service. It does not say whether the governance around that reliance is strong.
RPKI succeeds only if the externality is positive: fewer leaks, less hijack risk, better route-origin confidence and more disciplined operational planning. It fails institutionally if the externality becomes a hidden dependency on low-visibility registry choices. ARIN's task is to keep the first effect while measuring and constraining the second.
Liability gaps become continuity-cost premiums
The structural mismatch in RPKI is that the party controlling the trust service may not bear the full cost of trust failure. A holder can lose customer confidence, delay a migration, face support costs, breach a service commitment, accept a lower transfer price or spend management time resolving a route-origin problem. A lessee can lose reachability confidence because a lessor or registry account cannot update a ROA. A buyer can wait on settlement while security state remains unresolved. A lender can discount address-backed revenue. ARIN's direct legal exposure for the same chain may be limited by service terms and by the practical difficulty of attributing route outcomes to a single registry act.
This mismatch is not unique to ARIN, and it is not proof of bad faith. Registries coordinate scarce identifiers, and unlimited liability would likely make them unable to function. Relying networks choose their own routing policies. Holders must manage their own accounts and route plans. Operators must monitor validation states. There are many causes between a registry action and a customer problem.
Limited liability should nevertheless discipline power. A low-liability registry can remain legitimate if it acts as a narrow, auditable bookkeeper and trust-service operator. It becomes harder to justify if it exercises broad discretion over security access, agreement leverage, revocation timing or transfer-related publication while externalising most downstream cost. The narrower the remedy available to affected parties, the narrower the discretionary field should be.
RPKI makes this principle sharper because route-origin validation can influence live traffic treatment. A mistaken public listing can mislead a diligence team. A mistaken reverse-DNS delegation can hurt mail reputation. A mistaken or missing ROA can alter how strict networks treat a route. The speed and automation of the effect raise the standard for governance. If a registry action can propagate through validators and filters, the action should have a decision record, a reason category, a review path and a correction clock.
The same standard should apply to service eligibility. If legacy holders must sign an agreement to access RPKI, the liability and service terms should be clearly explained as part of the security bargain. If hosted service dominates adoption, holders should know the service commitments and limits. If delegated service places more risk on the holder, ARIN should make the boundary clear. If transfer guidance places ROA cleanup responsibility on source and recipient, the parties should know how ARIN supports timing and what happens when one side cannot act. In each case, risk should be named before it is priced in a crisis.
Private instruments fill liability gaps. Purchase agreements add warranties about registry status and ROA cleanup. Escrows hold funds until transfer and service transition are complete. Customers demand routing-security commitments. Lenders ask about address control. Lessors write ROA support terms into leases. Insurers may exclude ambiguous registry failures. These instruments are rational, but they are costly. They are the private cost of uncertain public trust infrastructure.
ARIN can reduce that cost by making its RPKI governance more predictable. It does not need to promise that no mistake will occur. It needs to prove that mistakes are isolated, corrected quickly, explained clearly and prevented from becoming broad leverage over unrelated resources. It needs to show that severe action protects routing security rather than expanding institutional discretion. When liability cannot fully follow consequence, visibility and constraint become the substitute.
Measurement should reveal the trust layer
RPKI measurement often begins with adoption: how many organisations have signed up, how many prefixes have ROAs, how many routes validate, how many invalids exist, how many users choose hosted service and how many use delegated arrangements. Those numbers are useful, but they are not enough. Adoption measures how much reliance exists. Governance measurement should show whether that reliance is safe.
ARIN's service evolution makes the point. Publicly described improvements such as a ROA change log in ARIN Online and ASPA support in a testing environment are meaningful developments. A change log helps holders see what happened to their authorisations. ASPA work points toward broader routing-security automation. But each improvement also increases the need for auditability. If routing-security services become richer, more automated and more integrated with registry accounts, then governance around those services must become more visible.
The first measurement category should be dependency structure. What share of ARIN RPKI users rely on hosted service? What share uses delegated service? How does the share vary by holder size, resource type, legacy status and service plan category? How many legacy holders are excluded from ARIN RPKI because resources are not under agreement? How many later enter the agreement perimeter primarily to access routing-security services? These are not private secrets if reported in aggregate. They tell the market whether security adoption is widening or concentrating institutional dependence.
The second category should be continuity. What is RPKI service availability? How often do publication incidents occur? What are the median and tail times for ROA creation, modification and deletion support when manual intervention is needed? How often are transfer-related ROA changes delayed because source authority, recipient access, agreement execution or account recovery is unresolved? How often do holders request emergency support before a migration window? Service availability alone is insufficient if support delay is the real continuity cost.
The third category should be revocation and restriction. How many certificate-affecting actions occur each year, grouped by resource return, completed transfer, account compromise, mistaken publication, suspected false authority, legal restraint, nonpayment-related service issue, technical error or other category? How many are urgent? How many are later reversed or modified? How many receive prior notice? How many require post-action review? The public does not need names or prefixes to learn whether severe actions are rare, well-classified and reviewable.
The fourth category should be transfer and lease realism. Transfers should be measured not only by completion volume but by security-state handover. How often do source ROAs remain after transfer? How often do recipients create new ROAs within a defined period? How often do routing-registry entries and reverse DNS lag? How often do buyers request guidance on maximum-length values? How often does legacy status complicate security-service access? Such metrics would help buyers, sellers and brokers treat RPKI as a settlement component rather than an afterthought.
The fifth category should be incident learning. A mature registry should publish aggregate lessons from RPKI support incidents without exposing exploitable details. Was the failure technical, authority-related, documentation-related, service-boundary-related or user-error-related? What changed after the incident? Did ARIN improve account roles, notifications, validation warnings, transfer reminders, change logs, support escalation or member education? Trust grows when the institution shows it can learn from near misses before they become outages.
Measurement has a governance purpose. It prevents security rhetoric from hiding institutional leverage. If the numbers show that hosted service is reliable, revocations are rare and reasoned, transfer handovers are fast, legacy barriers are understood and incidents are corrected, ARIN's authority becomes more credible. If the numbers are missing, counterparties must infer from anecdotes, private brokers and customer incidents. A security service that asks networks to rely on cryptographic facts should not ask the market to rely on institutional mystery.
Portability is the safeguard against security lock-in
RPKI adoption should not require permanent dependence on one operational model. A holder that begins with hosted RPKI may later mature into delegated operation. A company that acquires a network may want to consolidate certificate operations. A cloud or carrier group may need different controls for different business units. A university may outsource operations and later bring them back. A transfer recipient may want a clean break from the seller's security state. In each case, portability determines whether RPKI is a security improvement or a lock-in device.
Portability has three parts. The first is informational. The holder needs a complete inventory of prefixes, current ROAs, authorised ASNs, maximum-length settings, publication status, account roles and relevant service terms. If the holder cannot see what it relies on, it cannot migrate safely. The second is procedural. The holder needs clear steps for moving between hosted and delegated models, changing account roles, replacing keys, staging ROA changes and restoring service after error. The third is institutional. The registry must not use the transition as an opportunity to impose unrelated conditions or delay a holder that has satisfied the defined security requirements.
This matters for small holders as much as large ones. A small ISP may never run delegated RPKI, but it still benefits from knowing that hosted use is not a trap. A hosting firm may begin with hosted service because it has limited staff, then need more direct control after customer routing requirements mature. A public-sector network may want hosted service for simplicity but require strict assurance that a billing or account-maintenance issue will not unexpectedly disturb live route-origin publication. Portability disciplines the registry even when most holders do not exercise it.
Transfer portability is more demanding. A buyer should be able to know whether it can establish a clean RPKI posture immediately after recognition, whether the seller's stale ROAs can be removed safely, whether customer cutovers can be staged without invalid states and whether delegated arrangements can be accepted or replaced. If the answer depends on ad hoc support judgement rather than visible rules, the buyer will price that uncertainty into the deal. If the answer is predictable, route-origin security becomes an asset feature rather than a settlement hazard.
Portability also protects ARIN. A registry that supports clear transitions can show that hosted dominance reflects user convenience rather than institutional lock-in. It can encourage adoption without inviting the suspicion that security service access is being used to expand contractual dependence. It can distinguish strict authentication from broad leverage. It can defend revocation when revocation is necessary because holders have had viable paths to maintain lawful, accurate and secure certification.
The test is whether a capable, cooperative holder can change its RPKI operating model without losing continuity, surrendering unrelated rights or depending on personal intervention. If yes, the trust service behaves like infrastructure. If no, every adoption statistic contains a second number that is not published: the share of the market whose route-origin security is locked into registry discretion.
The constructive ROA-continuity test
A practical governance test should begin where the operator begins: can the route-origin statement be maintained safely through ordinary business change? The first question is who controls the certificate relationship. Is the resource under hosted RPKI, delegated RPKI or no ARIN RPKI service? Which account role can create, change or delete ROAs? Is that role separate from billing, voting, legal representation and general account administration? Technical authority should not be accidentally bundled with every other form of institutional authority.
The second question is what record supports the ROA. Is the resource registered to the current holder? Is the Point of Contact current and validated? Is agreement coverage required and present? Is there a legacy boundary? Is there a dispute marker, legal restraint, pending transfer or account recovery issue? RPKI should express verified resource authority, not paper over unresolved identity problems.
The third question is what happens during transfer. Which existing ROAs must be removed, preserved or modified? Who is responsible for maximum-length review? When does the recipient gain service access? Does the source have authority to clean up old authorisations? Does escrow depend on ROA delivery? Does the buyer's customer migration depend on a validation state by a fixed date? Transfer closing should include a route-origin checklist because route-origin continuity is part of deployability.
The fourth question is what happens during a lease or customer delegation. Can the recognised holder authorise a lessee's ASN without implying transfer of registration? What contractual obligation forces timely ROA updates? What happens if the lease ends, renews, defaults or is disputed? Can downstream customers be protected during a defined cure period? The registry need not approve every commercial term, but the security service should be able to express legitimate operational authorisation without turning each lease into a policy trial.
The fifth question is what review exists before severe action. If a ROA is to be removed, publication constrained, hosted access suspended or a certificate relationship altered, what reason category applies? Is there notice? Is there emergency exception? Is there independent or senior review for high-consequence cases? Can the holder contest the action quickly enough for network operations? A route-origin control that cannot be reviewed in operational time is not a safe trust service.
The sixth question is how mistakes are isolated. If one prefix is disputed, do unrelated prefixes remain stable? If an account is compromised, are changes locked without public overstatement? If a billing issue exists, are live route-origin statements preserved where rules allow? If a transfer is paused, is the last verified safe state maintained? The registry should avoid turning one file's uncertainty into a portfolio-wide shadow.
The seventh question is whether the holder can port reliance. Can a capable holder move from hosted to delegated service under clear conditions? Can delegated operators recover if internal systems fail? Can a transfer recipient establish a clean new service relationship without avoidable delay? Can legacy holders enter a narrow security relationship without unnecessary expansion of unrelated obligations? Portability reduces the risk that adoption becomes lock-in.
The eighth question is who bears outage or validation uncertainty. If ARIN action is necessary, who is likely to be affected outside the account: customers, lessors, lessees, upstream providers, route servers, lenders, acquirers or public services? Can communication reduce harm without revealing private data? Can the decision record show why the action protects routing rather than expands discretion?
The ninth question is what independent evidence proves the action is security-related. The evidence may be account compromise, false authority, completed transfer, resource return, legal restraint, duplicate certification, technical failure or clear service term. General institutional concern is not enough. If the registry cannot connect the RPKI action to a defined security, authority or legal ground, the action risks becoming a governance lever.
This test would not make ARIN passive. It would make strong action more credible. A false ROA would be removed because the authority is false. A compromised account would be locked because the account is compromised. A transferred resource would be re-certified because the recognised holder changed. A disputed case would be preserved in the last verified safe state while the dispute is classified. Each outcome would point back to the trust service, not to a vague assertion of registry power.
The route should be safer than the gatekeeper
RPKI will become more important as operators, customers and security teams normalise route-origin validation. That is a good development if the governance architecture is strong enough. The Internet needs better protection against accidental leaks and hostile origin claims. Customers should be able to ask providers for a credible routing-security posture. Buyers should be able to close address transactions with clean route-origin handover. Lessors and lessees should be able to translate commercial authorisation into reliable routing evidence. Legacy holders should be able to improve security without feeling that security adoption rewrites every historical expectation.
The condition is that the route should become safer, not more dependent on an unconstrained gatekeeper. ARIN's RPKI role is strongest when it is narrow: verify resource authority, secure accounts, offer reliable hosted and delegated options, preserve publication, support transfer handover, revoke false or unsafe material under defined grounds, publish aggregate performance and provide review for severe action. It is weakest when certification access becomes entangled with broad agreement leverage, opaque service boundaries, unmeasured delays or discretionary judgement over lawful commercial use.
The North American setting makes the issue easy to understate. ARIN is not the dramatic crisis case in the RIR system. Its orderliness is real. Its documented processes, service improvements, member structures and transfer guidance help explain why the region remains a central part of the IPv4 economy. But order does not eliminate governance risk. It can make the risk quieter. A mature registry can still shape behaviour by defining which services require which agreements, how quickly account authority is restored, how transfers handle ROAs, how revocation categories are written and how much RPKI dependence remains hosted inside registry systems.
That quiet power should be constrained before it is tested in a bad case. The better model treats RPKI as critical trust infrastructure, not as a discretionary add-on. Existing valid route-origin publication should be preserved during ordinary disputes where safety allows. Severe changes should be categorised and reviewed. Transfer settlement should include route-origin continuity. Legacy service boundaries should be explained in service-specific terms. Hosted dominance should be matched by strong service metrics. Delegated options should remain real for capable holders. Liability limits should be offset by transparency and proportionality.
Counterparties will price the answer. A block whose route-origin authority is stable across transfer, lease, migration and account change is more valuable than a block whose security state depends on ambiguous registry discretion. A provider that can show ROA continuity will face fewer customer questions. A buyer that can stage RPKI handover will reduce escrow and migration risk. A lender that understands service dependencies can price address-backed revenue more accurately. A registry that publishes meaningful RPKI governance data will lower the hidden risk premium around its own trust chain.
The final question is the ROA-continuity question. Can an operator rely on RPKI as security infrastructure without granting ARIN a new discretionary switch over scarce network identity? If the answer is yes, RPKI becomes what it promises to be: a way to make routing safer by binding origin claims to verified resource authority. If the answer is no, adoption still may continue, but every valid route will carry a second question behind it: not only whether the ASN is authorised, but whether the institution behind the authorisation is constrained enough to be trusted.
The registry that wants networks to trust its certificates should welcome that test. Cryptography can authenticate a statement. Only disciplined governance can make the authority behind the statement safe to rely on.