Summary

  • Hosted RPKI removes difficult certificate, renewal, manifest, revocation-list and repository duties from the resource holder. It has enabled organisations without specialist public-key teams to create and maintain route origin authorizations.
  • The service also bundles controls. Depending on the RIR, the registrar may hold the hosted CA private key, translate portal settings into signed entities, publish those entities, update certificate scope from resource records and remove them when service ends.
  • A portal outage does not automatically invalidate existing ROAs. The sharper risk is loss of change and recovery authority, or a registry decision that revokes the hosted CA or removes its entities. At that point the user may have no independent key or publication path with which to preserve intended authorizations.
  • Delegated RPKI gives the holder its own CA and private key. It can improve automation, multi-RIR management and independence from a hosted signing interface. It does not escape the parent: the RIR still issues the resource certificate and can narrow or revoke it.
  • Hybrid arrangements separate key custody from repository operation. They often offer the strongest practical balance, but publication by the parent remains a service dependency and a stale delegated CA can itself become a risk to relying parties.
  • Operators should choose a model by consequence, not fashion. Critical public services, complex multi-origin networks and large downstream delegations deserve stronger control and tested transition; small straightforward networks may rationally remain hosted if procedural safeguards and recovery facilities are credible.
  • Number Resource Society can help by publishing a model-comparison register, continuity tests and member-facing questions for RIR boards. It should strengthen informed choice rather than portray self-hosting as simple sovereignty.

The failure begins when a valid change cannot be made

A network is moving a service from one origin AS to another. Its engineers have configured the new BGP announcement and intend to create the new ROA before withdrawing the old route. Under hosted RPKI they must use the RIR's portal or interface. If the account is inaccessible, the interface is unavailable or the RIR has suspended certification, the operator cannot sign a replacement itself. It does not possess the hosted CA key.

This does not mean the existing route instantly fails. The existing ROA can remain published and valid while the portal is unavailable. In that case the immediate danger is change paralysis. The new origin can be Invalid if the old covering ROA authorizes only the old AS. Engineers may postpone a necessary migration, run a route that some networks reject or ask the registry to restore access under time pressure.

A more severe event occurs if the hosted CA is revoked or its signed entities are removed. The operator cannot republish the same entities under the same key from a backup because the key was never under its control. It cannot create a delegated child after the parent has ended the service unless the parent cooperates. The institution that supplies convenience has become the necessary route to recovery.

That is the convenience trap. It is not the claim that hosted RPKI is always unreliable, or that every service interruption removes ROAs. It is the concentration of authority at the moment the user most needs an independent option. A service can be easy in normal times yet brittle in a dispute, transfer, compromise or urgent routing change.

The correct comparison therefore begins with control paths, not slogans. Who can state routing intent? Who possesses the signing key? Who determines certified resources? Who publishes the entities? Who can revoke them? Who can keep a valid authorization visible during migration? Hosted and delegated RPKI answer these questions differently.

Convenience solved a genuine adoption problem

Operating an RPKI CA is not the same as creating an ordinary login certificate. The CA must protect keys, request and renew resource certificates, issue signed entities, maintain manifests and certificate revocation lists, publish fresh material, survive failure and interact correctly with parent systems. Its repository must be reachable by relying parties, directly or through a publication provider. Errors can change route-origin validation.

Most small and medium operators did not build teams for this task. They wanted to authorize their prefixes, not become public-key infrastructure specialists. Hosted RPKI let them choose an origin AS and prefix in a familiar member portal while the RIR handled certificate issuance, signing, renewal and publication.

The regional services describe this benefit openly. ARIN calls hosted RPKI the easiest option and says it operates the CA and high-availability repository. The RIPE NCC says hosted users mainly need to keep ROAs aligned with intended BGP routing while its system handles cryptographic operations and publication. APNIC manages certificate and publication infrastructure for hosted users and generates private keys on their behalf. LACNIC has offered hosted service since 2011.

This model creates positive externalities. A resource holder that would never deploy a delegated CA can still publish accurate authorizations. RIR interfaces can warn when a proposed ROA would make a known announcement Invalid. Central systems can automate renewal, key rollover, manifests and repository availability. Support staff can help members correct mistakes.

It would be perverse to define maturity as forcing every community network, university or local provider to operate a CA. Security that only large carriers can manage will remain incomplete. The case against excessive dependence must preserve the low-friction route into RPKI.

The policy objective is optionality with safe defaults. Hosted service should remain an accessible default. Delegated and hybrid service should remain practical exits for users whose risk requires more control. Moving between them should not create an avoidable gap. Convenience is valuable when it is a choice, less so when it quietly becomes captivity.

Five controls are hidden inside one portal

The hosted interface presents one service, but at least five controls sit beneath it.

First is registration scope. The RIR decides which IP address blocks and AS numbers its records associate with the holder and will place within a resource certificate. A portal cannot authorize a prefix outside that scope.

Second is routing intent. The holder chooses the origin AS, prefix and any maximum length. In a well-designed hosted service, staff do not invent this intent. The user submits it through authenticated controls, and the system warns about obvious conflicts.

Third is key custody and signing. The hosted provider generates or stores the private key and uses it to create signed entities. RIPE NCC terms define a hosted CA as one in which it is responsible for cryptographic operations and hosts the holder's public and private key pair. APNIC similarly says it generates private keys on behalf of hosted users.

Fourth is publication. The RIR repository makes certificates, manifests, revocation lists and signed entities available to relying parties. Publication must remain fresh and globally retrievable. A correct signature that is not available to validators has little operational value.

Fifth is lifecycle authority. The service renews, replaces and revokes certificates and removes entities when resources or service status change. This is where registration, contracts and routing evidence meet.

The portal hides this complexity for good reason. The problem arises when governance hides it too. A user may believe it controls RPKI because it can click Create ROA, while the provider controls the key, publication and termination. The provider may emphasize that routers make local decisions, while understating how its lifecycle action alters the data those routers receive.

A useful service agreement should name each control and assign a duty. Without that map, responsibility appears only after an incident, when each party points to a different layer.

Hosted key custody is not ordinary outsourcing

Organisations routinely outsource email, payroll and cloud computing. Hosted RPKI differs in one respect: the service provider is also the parent authority that determines the scope of the certificate. It may therefore combine the power to define what can be signed with the ability to perform the signing.

This concentration is efficient. The provider can automatically update certificates when holdings change, renew entities before expiry and remove authorizations for resources no longer registered to the user. It can keep keys in a hardware security module and segregate operational roles more effectively than a small operator.

It also changes the threat model. A compromised user account could create harmful routing intentions if authentication and approval are weak. A compromised hosted signing environment could affect many CAs. A mistaken registration update could remove resources and trigger entity changes. An internal administrator might have powers no single employee should possess. A legal or contractual decision can be implemented without the holder taking a separate signing action.

These are not accusations that RIRs misuse keys. They are consequences of control concentration. The answer is strong service design: multi-factor authentication, role-based approval, delayed high-risk changes, independent audit, hardware protection, immutable history and separation between registration changes and certificate-impacting execution.

The holder should be able to export a complete, signed account of its routing intentions and current entity set. It cannot export the private key if the service correctly keeps that key non-retrievable, but it can retain enough information to recreate authorizations under a delegated CA or successor hosted CA. Data portability is not key portability.

The provider should also disclose whether an account administrator, RIR staff member or automated event can revoke the entire hosted CA; what approvals are required; and how quickly an erroneous revocation can be reversed. A security service becomes trustworthy when the controls around key use are as visible as the green Valid label in the portal.

The single point is revocation and recovery, not every outage

Calling hosted RPKI a single point of failure can be too crude. The repository may be replicated. Existing entities have validity periods. Relying-party software caches validated data and has rules for unavailable repositories. A short portal interruption can leave route validation unchanged. An RIR may operate far more resilient infrastructure than the member could afford.

The sharper single point is authority over revocation and recovery. If the RIR revokes the hosted CA or ends access to certification, the user cannot continue signing under that CA. If the RIR removes hosted entities when the service terminates, the operator cannot compel the old repository to serve them indefinitely. The parent must issue a new delegated certificate or restore hosted service before the user can regain a valid path.

Current terms illustrate the issue. RIPE NCC terms say all signed entities are removed when certification service terminates and allow revocation when a certificate conflicts with registration records, for technical or security reasons, for violation of terms or when the holder ends service. ARIN's agreement lists several grounds for immediate termination, links RPKI eligibility to other agreements and also reserves a notice-based termination right.

The legal language differs by region and should not be flattened into one global rule. Nor does a contractual right prove that it has been used unfairly. The point is structural: hosted users depend on the same counterparty for continued signing and for the transition out of that signing arrangement.

A credible hosted service needs an exit guarantee. For non-emergency termination, it should offer a defined period to establish a delegated or replacement CA, export configurations, verify publication and coordinate route changes. Emergency revocation should include rapid re-enrolment under a clean key when the holder remains entitled to certification. Disputes over payment or identity should have a fast review route before routing evidence is unnecessarily destroyed.

Without these facilities, high availability in ordinary weeks does not answer the most consequential failure mode.

Delegated RPKI changes who can sign

In delegated RPKI the holder runs a child CA and controls its private key. The parent RIR issues a resource certificate to that child. The holder can then create ROAs and other permitted entities, automate changes from its network systems and, where supported, issue further child certificates.

This gives the operator three forms of independence. It does not need the hosted signing portal for each routing change. It can protect the key under its own security policy. It can manage resources received from multiple RIR parents through one local system, reducing inconsistent manual action across regional interfaces.

The independence is cryptographically meaningful. The RIR parent cannot sign a false entity with the child's key merely because it issued the child certificate. A locally retained audit history can show exactly what the holder signed and when. The operator can decide how closely changes in BGP intent and RPKI objects are coupled.

Delegation does not make the holder its own trust anchor for the resources. The parent still decides the resources in the certificate. It can replace a certificate with a narrower one after transfer or return. It can revoke the child certificate. If the holder signs beyond the valid scope, relying parties reject the overclaim.

This boundary matters in a dispute. Delegation protects against dependence on the parent's hosted key and user interface; it does not let a former holder preserve certification after a legitimate transfer. It does not make registry records irrelevant. It gives the operator control over statements inside the scope the parent currently certifies.

Delegation should therefore be sold as separation of duties, not secession. Its value is that no single institution both possesses every signing key and controls every parent decision. Its limit is that the resource hierarchy still needs an authoritative parent.

Publication creates a third model

The usual comparison of hosted and delegated RPKI misses a useful middle ground. A holder can operate its own CA and private key while using the RIR's repository publication service. ARIN calls this Repository Publication Service. RIPE NCC offers Publish in Parent. APNIC offers publication for self-hosted clients.

This hybrid model separates signing custody from distribution. The operator can create entities without the RIR's hosted CA, while the RIR provides a highly available repository already fetched by relying parties. It avoids requiring every holder to expose and defend a global publication service.

Hybrid service often offers the best balance for a capable operator. Local key control reduces dependence on the hosted signing interface. Parent publication reduces operational burden and the proliferation of fragile repositories. Standards such as RFC 8181 define authenticated publication and withdrawal requests, allowing the CA and repository to be run by different parties.

The separation is not complete independence. The publication provider can fail to accept a change, become unavailable or remove material under its terms. The parent still issues the child resource certificate. An operator that needs the strongest autonomy may run both CA and repository, while accepting the resulting availability and security duties.

APNIC's 2025 discussion of RPKI availability states the trade-off directly. A delegated CA gives the holder greater control over its RPKI state and responsibility for issuing and renewing entities. Yet it remains dependent on the APNIC trust anchor and, if it uses APNIC publication, that repository. The paper also warns that many delegated repositories are single instances in one location.

The useful model is therefore a spectrum. Hosted places signing and publication with the RIR. Hybrid keeps signing local and publication with a provider. Fully delegated keeps both local. Parent certification remains above all three. Organisations should choose deliberately which dependency they are equipped to absorb.

Self-hosting has its own revocation trap

An argument for delegated RPKI that ignores operational failure is incomplete. A CA must issue fresh manifests and revocation lists before their next-update times. Its repository must serve consistent material. Keys must survive hardware failure without becoming easy to steal. Staff must understand overclaiming, key rollover and parent exchanges.

A neglected delegated CA can burden relying parties and leave its own entities unusable. RIPE-847 addresses an extreme case: when the RIPE NCC cannot discover and validate a delegated CA's current manifest and revocation list for more than three months, it is to revoke the resource certificate after reasonable discovery and notice efforts. The policy explicitly targets persistently non-functional CAs rather than ordinary short outages.

This policy reveals the reciprocal duty. Delegation gives the holder signing control, but the parent and relying-party community need assurance that the child will not remain indefinitely broken. The parent must be able to prune a dead branch. The holder must receive evidence of failed validation, notice and a restoration path.

The operator also faces human continuity risk. The one engineer who built the CA may leave. Backup keys may exist but be unreadable. A company acquisition may separate the network team from the security device. A crisis can expose that local sovereignty depended on one laptop and one memory.

Delegated service is not necessarily expensive in computing terms; modern CA software can run on modest hardware. The real cost is institutional: ownership, on-call responsibility, change review, backup testing, repository monitoring and succession. Large carriers can fail at these tasks, while a disciplined small operator can perform them well.

The comparison with hosted service must therefore count both revocation single points. Hosted users risk dependence on the provider's decision and recovery. Delegated users risk becoming the failing authority inside their own branch. Hybrid design and strong parent process can reduce, but not eliminate, either risk.

Migration is where optionality is tested

A market offers choice only if users can change their choice. Migration between hosted and delegated RPKI is technically delicate because the old and new CAs may cover the same resources, while relying parties retrieve data at different times.

RIPE NCC hosted documentation says a user moving to delegated service must revoke the hosted CA first and that make-before-break migration is not currently possible there. APNIC says hosted and self-hosted modes can run in parallel during transitions. ARIN tells users to contact Registration Services when changing deployment. These are materially different operational experiences.

The ideal transition preserves valid routing intentions while keys and publication points change. The user should export its current authorizations, prepare the new CA, test parent and repository exchanges, publish equivalent entities and observe them from independent validators before the old CA disappears. If regional policy forbids overlap, the service should support a scheduled cutover with rapid rollback.

Parallel certification is not automatically benign. Duplicate or inconsistent entities can confuse operators, and an old key should not retain authority longer than needed. A safe overlap needs fixed duration, equivalent resource scope, clear responsibility and automatic closure. The alternative, however, should not be an unexplained period in which the user has neither hosted nor delegated control.

Migration also matters during transfer, merger and corporate restructuring. A buyer may want delegated control while the seller used hosted service. A group operating through several RIRs may consolidate CAs. The RIR should treat RPKI transition as a standard part of resource movement, not an afterthought left to the closing day.

Portability metrics would improve accountability. Each RIR could publish the normal steps, minimum notice, expected period without change access, whether overlap is available and the escalation contact for failed cutover. If optionality cannot be exercised safely, the hosted default has more lock-in than its simple interface suggests.

Critical networks need a consequence-based choice

There is no single correct deployment model for every holder. The choice should depend on the consequence of being unable to change an authorization, the complexity of routing and the organisation's ability to operate a CA.

A small provider with a few stable prefixes and one origin may rationally use hosted service. The RIR can protect keys, renew entities and operate publication more reliably than the provider. Delegation could add failure modes without meaningful gain. The provider should still export its ROA inventory, maintain emergency contacts and understand termination terms.

A multi-RIR carrier with frequent routing changes, multiple origins, customers and automated mitigation has a stronger case for delegated signing. It can integrate authorization with approved network changes, keep one control surface across parents and reduce dependence on several portals. Hybrid publication can avoid running many public repositories.

Public-sector networks require particular care. Hospitals, emergency communications, tax systems, public clouds and research networks can suffer disproportionate harm from fragmented reachability. That does not mean every agency should self-host. It means the chosen model should have explicit continuity targets, tested access recovery, more than one trained administrator and a pre-agreed escalation path with the parent.

Downstream responsibility also matters. A direct holder may create ROAs for customers that cannot participate directly in an RIR service. If one hosted account controls many downstream origins, account suspension or takeover has a larger blast radius. Delegated sub-CAs can distribute control, but only where the parent and holder can support them safely.

Boards should ask a simple question: if the current provider or local CA became unavailable during a routing change, how would valid authorization be restored? The answer should name people, keys, parent contacts, publication paths and maximum tolerable delay. A model selected only because its setup screen was easy has not passed that test.

Member governance should shape the default

RIRs are not ordinary software vendors. They coordinate unique resources within regional, community-governed institutions. Their hosted RPKI terms can affect members that cannot take the same addresses to a competing parent. That makes membership accountability central to service design.

Members should approve or scrutinize the classes of event that permit revocation, the notice attached to each class, the treatment of disputed accounts and the exit path to delegated service. Technical communities should review certificate and repository practice; legal and governance communities should review termination and liability language. Neither discipline is sufficient alone.

The default should be hosted because adoption matters, not because institutional concentration is invisible. At enrolment, the user should receive a plain comparison of control. Hosted means the provider manages the key and repository. Delegated means the holder manages the key and perhaps publication. Hybrid divides those duties. All remain under the parent certificate.

Users should not need to prove exceptional status to choose delegation if they meet published technical requirements. Nor should a board force delegation on members unable to operate safely. Service fees should reflect actual cost without pricing cryptographic independence as a luxury reserved for large incumbents.

Changes to terms deserve advance community notice unless urgent security or law makes that impossible. RIPE NCC's 2026 terms, for example, define hosted and delegated custody and specify revocation conditions. Comparable clarity should be available in every region, even where the exact rule differs.

The institution should publish incident classes and restoration performance. Members cannot judge whether the convenience bargain remains sound if they know only service uptime. A portal can be available while a holder is wrongly unable to change entities; a repository can be reachable while a registration error has removed the right ones.

Contracts should distinguish misuse from disagreement

Broad termination clauses protect providers against fraud, compromise and unlawful use. They can also combine unrelated disputes with certification continuity. An unpaid invoice, a corporate-document question, an abuse allegation and a stolen private key do not present the same routing risk.

Service terms should divide them. Confirmed key compromise may require immediate revocation. Loss of entitlement after a completed transfer requires rapid certificate change. Suspected account takeover calls for a freeze on new signing, strong re-authentication and preservation of existing valid entities where safe. A disputed fee may justify service remedies, but automatic destruction of route authorizations should be a last resort if the resource remains registered to the holder.

This distinction does not create an unconditional right to certification. It aligns the remedy with the threat. RPKI should not become a general collection mechanism merely because it is effective. Nor should an RIR continue signing for a party that no longer holds the resource.

Written reasons matter most for hosted users because they cannot act around the provider. The notice should identify whether the restriction affects portal access, creation of new entities, publication, certificate scope or the entire CA. A temporary access freeze is different from revocation, and users need to know which condition applies.

Review should be fast enough for routing operations. A technical reviewer can first verify identity, resource scope and the entity diff. A separate contractual reviewer can decide the underlying dispute. Emergency contact should be available outside ordinary office hours for widespread validation impact.

Liability terms should also reflect allocated control. The hosted user is responsible for incorrect instructions and credential security. The provider is responsible for faithfully implementing accepted instructions, protecting the key under its custody and following published revocation process. Remote networks remain responsible for their own routing policy. Clear division is more credible than a clause implying that every consequence belongs to the weakest party.

Continuity needs rehearsal, not a policy page

An operator should test its RPKI recovery before a crisis. The exercise can begin without changing public entities. Teams should list current prefixes, origin ASes, maximum lengths, parent CAs, hosted configurations, delegated children and publication providers. They should compare that inventory with actual BGP announcements and validated payloads.

Hosted users should verify that at least two authorized people can access the service through independent credentials. Operational and legal contacts should be current. The team should know how to reach the RIR when normal access fails and how identity will be re-established. It should retain a machine-readable copy of intended authorizations.

Delegated users should test key backup and restoration in an isolated environment, monitor certificate renewal, validate manifests and revocation lists, and observe publication from outside their own network. More than one person should understand parent and repository exchanges. Documentation should survive an acquisition or staff departure.

Hybrid users should test both halves. A successful local signature is not enough if the publication service rejects the entity. They should know how to distinguish a CA fault from a repository fault and whether an alternate repository can be established under the parent in time.

All users should rehearse a change of origin AS. The test should include creating the new authorization before the route change, observing it through independent validators, applying BGP changes, checking validation state and withdrawing obsolete authorization after convergence. Where a live test is unsafe, a regional test environment can expose process failures.

The result should be a continuity objective stated in hours, not adjectives. Different organisations will choose different tolerances. The exercise is successful when it reveals the exact dependency that controls recovery and assigns an owner to fix it.

Relying parties complete the risk picture

The resource holder and RIR do not decide reachability alone. Relying parties fetch and validate RPKI material. Routers receive validated payloads and apply local policy. This distributed design limits central command, but it also makes consequences uneven.

If a hosted CA disappears and no covering authorization remains, a previously Valid route may become NotFound. Many networks continue accepting NotFound. If a surviving covering authorization conflicts with the route, it may become Invalid, and networks that reject Invalid may drop it. Caches and refresh timing mean the change appears at different moments.

Operators should not assume that repository availability or certificate revocation produces one immediate global result. APNIC's availability paper warns against relying on RPKI more strongly than the architecture intended, such as demanding ROAs from customers and rejecting every route not covered by one without considering availability characteristics.

This caution does not weaken the case for origin validation. It calls for layered security. Networks can combine RPKI with customer contracts, route filters, Internet Routing Registry data, direct verification and emergency exceptions governed by strict controls. An exception should not quietly become permanent acceptance of bad routing data.

Relying-party diversity can also aid recovery. Holders and RIRs should observe more than one validator implementation and vantage point before declaring a cutover complete. A repository may appear healthy locally while remote validators cannot fetch it. A signed entity may be present but rejected for overclaiming or stale supporting material.

The convenience trap is therefore visible from both ends. Producers can become dependent on one signing provider. Consumers can become dependent on one class of validation data without a plan for its temporary loss. Mature routing security keeps RPKI authoritative about what it can prove while refusing to treat it as the only evidence available in every emergency.

A better hosted bargain has concrete terms

The hosted model can be improved without making it cumbersome. The first reform is an entity escrow record: a continuously exportable, signed list of current routing intentions, certified resources and publication identifiers. It would not expose the hosted private key. It would let the holder rebuild equivalent authorizations under a replacement CA.

The second is a revocation ladder. Low-risk account problems should restrict changes while preserving existing entities where safe. Higher-risk registration events should produce notice and a transition. Confirmed compromise can trigger immediate revocation and clean-key recovery. Each rung should have named approval and review.

The third is portable enrolment. A user choosing delegation should be able to prepare identity exchange, publication and equivalent entities before the hosted CA is removed, subject to safeguards against uncontrolled overlap. Regional services that cannot support this should publish the exact gap and a plan to reduce it.

The fourth is independent confirmation for destructive actions. Revoking an entire hosted CA, removing all configurations or shrinking certified resources should require dual control except where automated renewal or a pre-authorized transfer follows a verified event. The system should show the expected effect on known announcements before execution.

The fifth is service reporting that measures more than uptime. RIRs should report certificate-impacting registration errors, failed migrations, emergency revocations, restoration time and notification performance. Small counts should be disclosed carefully without pretending to support global rates.

The sixth is a narrow remedy. If the provider's error removes valid authorization, it should offer immediate restoration, specialist support, a preserved incident record and an independent review. Serious repeated failure should reach the board and membership, not remain a private support ticket.

These safeguards make hosted RPKI more convenient, not less. They reduce the amount of bespoke negotiation required when normal assumptions fail.

What Number Resource Society can add

Number Resource Society presents itself as an advocate for accurate registration, holder rights, participation and lower bureaucratic barriers. Hosted RPKI is a suitable place to turn those principles into measurable member service.

NRS could publish a deployment-choice register comparing the five RIRs. It should list who holds the private key, whether delegated service is available, whether parent publication is offered, how migration works, what revocation grounds are published, what notice applies and where a holder can seek review. Each entry should link to the relevant RIR material and state unresolved questions.

It could maintain three continuity exercises: one for hosted users, one for delegated CAs and one for hybrid publication. The hosted exercise would test access recovery and configuration export. The delegated exercise would test keys, manifests, parent exchange and succession. The hybrid exercise would test local signing against remote publication. Results could remain private to the entity while common failure themes are published without unsupported rates.

NRS could also bring smaller operators into regional policy discussions. Large networks can evaluate CA software and negotiate urgent support through established relationships. A rural provider or non-profit network may not know that portal access, certificate scope and entity publication are separate controls. Plain questions at member meetings can improve service for everyone.

The contribution should remain bounded. NRS advocacy does not establish that it is an RPKI trust anchor, certificate authority, repository operator or neutral adjudicator. It should not imply that every holder can self-host safely or that RIR service is inherently suspect. Its useful role is to make choice informed, exit practical and accountability comparable.

Positive institutional criticism is more durable than suspicion. A register that praises strong transition design and identifies weak notice can give RIR boards a practical improvement list. It can also show operators when hosted service is the responsible choice rather than treating local key custody as a badge of status.

Common objections miss the allocation question

Defenders of hosted RPKI often say that RIRs already control registration, so delegated keys add little. The premise is partly right: the parent can narrow or revoke a delegated certificate. The conclusion is wrong. Child-key control still prevents the parent from signing the child's routing intentions and lets the operator make changes without the hosted interface. Separation does not erase hierarchy; it reduces concentration inside it.

Critics say hosted service is unsafe because the RIR holds the key. That is also too broad. A well-run RIR can protect keys, renew entities and publish repositories more reliably than many members. The relevant question is whether its security, authorization and recovery controls match the concentration of power.

Another objection is that parallel migration weakens uniqueness. It can if designed badly. Short, controlled overlap for equivalent authorizations is different from indefinite competing certification. Where even short overlap is unacceptable, scheduled cutover and rapid rollback remain possible.

Some argue that relying-party local policy makes producer continuity less urgent. Local policy does soften or vary the consequence. It cannot recreate a missing valid authorization, and it does not prevent selective reachability loss. Producers still need accurate, continuous evidence.

Finally, some members will say that sophisticated options raise fees for everyone. Regional communities can keep hosted service simple while charging transparent incremental cost for delegated support or publication. The essential safeguards - reasons, notice, export and restoration - are not luxury features. They are basic duties of a service tied to unique resources.

Each objection becomes clearer when framed as allocation. Which party controls the risk, which party can prevent it and which party can recover? Hosted and delegated models should be judged by those answers rather than by ideological preference for central or local operation.

Evidence should improve before confidence becomes absolute

Public material explains architectures, terms and individual incidents, but it does not provide a complete cross-RIR record of revoked hosted CAs, failed migrations, blocked changes, restoration times or route effects. Service pages disclose capabilities, not every operational outcome. Private support cases and security events are appropriately not all public.

This limits empirical claims. It is not possible to estimate a global probability that hosted RPKI will cause route loss. Nor can public evidence prove that delegated operation is more reliable across all holders. The regional service models and control paths are observable; comparative failure rates are not.

RIR reporting can close part of the gap. It should distinguish portal unavailability, signing failure, repository unavailability, parent-certificate error, user misconfiguration and involuntary termination. It should record whether current entities remained valid, whether route state changed and how long restoration took.

Operators can contribute anonymised accounts with verifiable timelines. Researchers can observe public certificate and entity changes but should avoid inferring intent from disappearance alone. A transfer, key rollover or deliberate ROA withdrawal can look like failure from outside.

Confidence should therefore be strongest on architecture and weaker on prevalence. Hosted service concentrates named controls. Delegated service redistributes some of them. Both remain under an RIR parent. These are documented facts. How often each arrangement causes material harm remains insufficiently measured.

A governance programme that admits this limit is more credible than one that selects a few outages or uptime figures to prove a universal case. Better evidence will allow future communities to adjust the default without guessing.

Convenience should be reversible

Hosted RPKI has done what good infrastructure often does: it made a hard security practice ordinary. Operators can create route authorizations without building a CA, managing manifests or defending a public repository. That achievement should be preserved.

The danger appears when ease of entry is paired with no safe exit. If the registrar holds the key, publishes the entities, changes certificate scope and controls re-enrolment, a dispute or error can leave the operator unable to maintain its own routing intent. High normal uptime does not remove that structural dependency.

Delegated RPKI supplies a meaningful counterweight. The holder signs with its own key, can automate local changes and can manage several parents coherently. Hybrid publication reduces the burden. Neither option eliminates the parent CA or the duties of reliable operation.

The mature settlement is plural. Hosted service remains the default for straightforward users. Delegated signing is a standard right for capable holders. Parent publication is available as a middle path. Migration is tested and, where safe, make-before-break. Revocation grounds are precise, ordinary disputes do not trigger disproportionate routing consequences, and emergency action carries rapid review and recovery.

Convenience is not the opposite of control. It is a way of borrowing another institution's control for routine operation. The bargain is sound only when the borrower can see the terms, retrieve its intentions, choose a different arrangement and recover when the lender of convenience makes a mistake.

RPKI asks networks to rely on cryptographic statements. Its governance should apply the same discipline to institutional promises. Who holds the key, who can revoke, who publishes and who restores should be as unambiguous as the prefix and origin AS in a ROA. When those answers are explicit and reversible, hosted service is an on-ramp. When they are hidden and inescapable, it is a trap.

Sources