Summary

  • RPKI certificates and signed entities do not route packets, but they can change the validation state on which networks apply routing policy. When a registry controls hosted keys, certificate issuance, revocation and publication, its actions can create operational consequences beyond ordinary recordkeeping.
  • Broad disclaimers have legitimate purposes. Registries cannot control a holder's ROA choices, every validator, every network's filtering policy, all BGP paths or a customer's business continuity. Free or member-funded services also cannot sensibly insure the Internet against unlimited consequential loss.
  • The present allocation can nevertheless be highly asymmetric. ARIN's published RPKI terms disclaim interruption, inaccuracies and errors, broadly exclude damages and state a low aggregate cap; current RIPE NCC terms provide service on a best-effort basis and exclude most damages except wilful misconduct or gross negligence; APNIC's published certification statement similarly places substantial risk on subscribers and relying parties.
  • These clauses operate under different laws, agreements and service arrangements. Their wording is evidence of institutional risk allocation, not a conclusion that every clause is enforceable against every holder, operator or downstream customer.
  • A certificate-service disclaimer audit should distinguish holder-authored mistakes, registry processing errors, unauthorised certificate action, publication failures, validator defects and operator policy. Responsibility should follow the step controlled and the fault evidenced.
  • The first remedy for a wrong certificate is not money but a fast, authenticated correction, a preserved pre-incident state, a public entity-level notice and verified convergence across independent validators. Financial responsibility becomes relevant when those controls fail or documented loss remains.
  • NRS can contribute positively by making exact RIR terms, emergency rights, liability exceptions and practical remedies comparable for resource holders. Collective scrutiny is more useful than claiming either that registries must insure all routing or that certificate power carries no responsibility.

A certificate does not move traffic, but it can change who receives it

RPKI's legal debate often begins with a technically correct sentence and ends too soon. A regional registry does not operate every router that relies on its certificates. A ROA is an authorisation, not a route announcement. A relying party validates entities, a router applies local policy, and BGP selects paths. The registry therefore does not directly switch customer traffic on or off.

Yet the certificate service is not causally irrelevant. If a hosted certification authority issues or revokes a certificate, or publishes a ROA that differs from the holder's authorised instruction, relying parties can produce a different validated payload set. A legitimate BGP announcement may become Invalid. Networks configured to reject Invalid announcements may then stop accepting it. The institutional action is not the last step, but it can be the first wrongful step in a traceable chain.

That distinction matters for responsibility. A power need not be physically immediate to create a duty of care within its scope. A securities registrar does not move every investor's money; an air-navigation data provider does not fly an aircraft. Their exact legal duties differ, but neither can answer a proven data error merely by pointing to the final user's decision.

RPKI should be analysed with the same precision. The holder controls declared routing intent. The registry or another certification authority controls parts of issuance and publication. The relying-party maintainer controls validation logic. The operator controls filtering policy and network resilience. A customer controls some business-continuity choices. Liability should not be assigned to one entity by default, but neither should it evaporate because several entities are involved.

The key contractual question is whether each party bears the consequences of risks it can reasonably prevent, detect or repair. Terms that reserve extensive certificate control while shifting every associated risk outward fail that test institutionally, even if a court might enforce particular wording in a particular dispute.

Hosted RPKI concentrates powers that ordinary recordkeeping does not

In a hosted service, the registry commonly operates the certification authority on behalf of the resource holder. It authenticates access through its member systems, generates or holds relevant key material, issues resource certificates, creates and revokes signed entities according to the holder's instructions, and publishes the resulting material. The holder receives convenience and avoids running a continuously available certification and publication service.

This arrangement solves a genuine adoption problem. Many networks do not have the security staff, hardware, monitoring and operational maturity to manage keys and publication around the clock. Central provision can improve consistency, patching and support. It can also make RPKI accessible to smaller organisations.

The concentration has a price. A registry defect, account compromise, mistaken resource update, faulty transfer process or publication error can affect many holders at once. The holder may be unable to correct the entity independently because the registry controls the hosted key and user interface. Even where the holder can request a change, the service controls when that request becomes a valid external entity.

RIPE NCC's current terms state this division plainly: for hosted certification, it is responsible for cryptographic operations and hosts the certificate holder's public and private key pair. Its service can issue or revoke certificates and create, modify or delete signed entities. ARIN likewise provides hosted RPKI under its published service terms. These are not passive noticeboards.

Institutional power should be defined at this operational level. The registry does not control downstream route policy, but it controls whether a holder's authorisation can be cryptographically validated under its branch. A fair disclaimer can reject responsibility for the former while accepting an appropriate standard for the latter.

Some limitation of liability is reasonable and necessary

An RPKI certification authority cannot become the insurer of every commercial activity that happens to depend on an IP prefix. A short route interruption might be alleged to cause lost advertising, missed financial trades, breached cloud commitments, reputational harm and customer departures across several contractual layers. The resulting exposure could exceed the resources of a member-funded non-profit by orders of magnitude.

Causation is also complex. A wrong ROA may originate with the holder. An operator may ignore an Invalid state or reject it. A transit provider may have a separate route leak. A validator may be obsolete. A customer may lack multihoming or another continuity measure. The same certificate event can produce no reachability change in one network and a serious outage in another.

Disclaimers protect the shared institution from indeterminate claims and preserve affordable service. Excluding remote, speculative or punitive damages can be defensible. Requiring users to validate current entities and operate suitable software is sensible. Limiting use to the purpose for which resource certificates were designed prevents the certificate from becoming an unintended guarantee of identity, property title, route performance or commercial value.

RPKI standards themselves anticipate a legal allocation. RFC 3647 treats subscriber and relying-party agreements as important instruments for rights and obligations, and its framework includes warranty disclaimers, limitations on recoverable damage and liability caps. It does not prescribe the same answer for every certification authority. RFC 6484 requires each authority's practices to explain relevant controls while recognising that reliance must be reasonable in context.

The governance objection is therefore not to every exclusion. It is to an allocation so broad that the institution may control issuance, make a preventable error, delay correction and still disclaim substantially all meaningful consequence. Limitation should preserve the service; it should not remove the incentive to perform the service competently.

The audit starts with all governing documents, not one disclaimer page

An operator cannot understand its RPKI position by reading a headline terms page alone. Rights and obligations may be distributed across the certification-service agreement, repository terms, certification-practice statement, registration agreement, membership agreement, acceptable-use rules, service-level publication, policy documents and later amendments.

The relationships also differ. A resource holder using hosted RPKI may have a direct agreement with the registry. A delegated certification authority may accept separate provisioning or publication terms. A relying party downloading public material may be subject to repository conditions asserted through access. A downstream operator may use payloads produced by another organisation. A retail customer whose service is interrupted may have no agreement with the registry at all.

The audit should identify the exact document version applicable on the incident date. RPKI terms can change. The method of assent matters: signature, click acceptance, membership incorporation, continued use or mere download. Governing law, forum, limitation period and dispute path matter as much as the substantive cap.

Operational commitments may sit outside the contract. A public status page can publish service levels or incident notices without creating an enforceable warranty. A certification-practice statement may describe security and revocation controls while declaring that formal terms prevail. The difference between a public practice and a contractual promise should be explicit.

Finally, the audit maps documents to powers. Which text authorises certificate revocation? Which text allocates holder responsibility for ROA content? Which text covers a repository's stale view? Which clause addresses negligence by registry staff or software? Which remedy is available to a relying party rather than a member?

This document map prevents selective reading. A provider should not cite the holder's responsibility clause without the provider's own operating commitments. A claimant should not cite a security practice as if it guaranteed every route. Responsibility emerges from the complete relationship and the evidenced failure.

ARIN's published terms make the asymmetry unusually visible

ARIN's RPKI Terms of Service Agreement, version 1.1 dated 17 April 2019, offers a clear example of institutional risk transfer. The agreement describes RPKI as an emerging security framework, lists risks including key compromise, and states that the user bears risks connected with authorised and unauthorised access or use.

Its disclaimer section says the service and resource certification are provided as is with associated risks and faults. It disclaims a promise that the service will be uninterrupted, free from defects, inaccuracies or errors, meet user requirements, or work with the user's chosen configuration. It then broadly excludes liabilities and damages connected with RPKI services, including claims involving customers or clients.

The stated aggregate liability cap is the greater of the amount paid for RPKI services during the preceding six months or US$100. The agreement also contains a broad indemnification obligation in favour of ARIN for claims connected to use or access by the user and associated parties, subject to the full wording.

These provisions are commercially stark because ARIN simultaneously occupies the certification role for hosted service. If a preventable ARIN defect generated an incorrect certificate or failed to publish an authorised correction, the text appears designed to make substantial recovery difficult even where routing consequence was foreseeable. Whether every provision would be applied as written depends on facts, governing law and the claimant's relationship; the institutional allocation is nevertheless evident.

ARIN has rational reasons for protecting a non-profit registry from open-ended Internet loss. The audit question is narrower: does a nominal cap and broad exclusion remain proportionate when the alleged failure lies entirely within ARIN's own certificate control, rather than in holder intent, third-party software or operator policy?

A mature answer would distinguish those cases. The present language is much broader than that control-based distinction.

ARIN's access change makes assent and scope more important, not less

In June 2024, ARIN announced that customers with directly held resources under an RSA or LRSA could use RPKI without explicit acknowledgement of the separate RPKI terms within ARIN Online. The change reduced a barrier to adoption. It also makes the document map more important for risk review.

An operator must now ask which RPKI provisions apply through its registration agreement, which remain separately relevant, and what act constitutes acceptance. The announcement itself does not answer the enforceability or scope of every clause in a future dispute. Nor does removal of an extra click necessarily remove substantive limitations incorporated elsewhere.

This is not a criticism of simpler access. Security services benefit when avoidable legal friction does not deter deployment. The risk is that simpler enrolment can make responsibilities less visible. A resource holder may create ROAs without having compared the liability cap, emergency correction route, bankruptcy provisions and account obligations that shape its practical remedy.

ARIN can resolve much of this through a concise service-specific statement shown before activation and retained by version. It should identify the controlling agreements, the exact responsibility for holder-entered data, ARIN-produced certificates and publication, the correction route, the cap and exceptions. A user should not need litigation to discover which document governed.

The same clarity benefits ARIN. It reduces allegations that important exclusions were hidden and lets the organisation show which risks the holder knowingly retained. Transparency is not an admission of unlimited duty. It is evidence that a consequential shared service was entered with informed expectations.

RIPE NCC's terms accept a narrow fault exception but retain broad protection

The RIPE NCC Certification Service Terms and Conditions effective in June 2026 define a hosted certification authority as one in which RIPE NCC is responsible for cryptographic operations and hosts the holder's key pair. The service issues or revokes certificates and creates, modifies or deletes signed entities. The terms also warn holders that a ROA inconsistent with routing intent can result in rejected announcements.

The service is stated to be available on a best-effort basis, and RIPE NCC reserves operational suspension powers for technical, legal, anti-abuse and other stated reasons. Its liability section places use at the holder's own risk and makes the holder responsible for use of the service and certificate.

RIPE NCC then excludes damages, including business loss, lost profit, third-party damage, personal injury and property damage, except where its own wilful misconduct or gross negligence is involved. It excludes specified force-majeure circumstances, requires the holder to indemnify it against third-party claims connected with the holder's use, and states a one-year period after awareness for rights connected with certificate generation, replacement and use.

The separate repository terms apply risk allocation to users downloading hosted material. They place access and use at the user's risk, assign responsibility for decisions based on outdated data to the user, and similarly preserve an exception for wilful misconduct or gross negligence.

This model is not identical to ARIN's. The express fault exception matters, and the legal setting differs. Yet the same structural tension remains: a hosted authority controls keys and publication while most ordinary negligence consequences may be difficult to recover if the threshold is gross negligence.

The audit should therefore ask what conduct meets the exception under applicable law, what evidence users can obtain, and whether the emergency correction remedy works before financial litigation becomes relevant.

APNIC similarly places substantial risk on subscribers and relying parties

APNIC's published RPKI Certification Practice Statement describes hosted and self-hosted certification arrangements, certificate life-cycle controls, trusted roles, key protection, publication and relying-party use. It also contains operative legal language concerning liability.

The statement places repository download, data access and service use at the relying party's risk. It makes the subscriber liable for use of the certificate and creation of signed entities. APNIC excludes direct and indirect damages, including business and third-party losses, except in cases involving its wilful misconduct. It assigns responsibility for decisions based on material other than the most recently published instances to relying parties and includes force-majeure protection and a one-year claims period.

The document also says relying parties should check revocation information and use the latest repository version, while repository availability is on a best-effort basis. Those are rational operational duties. The harder case is one in which the most recently published instance is itself wrong because of an APNIC-controlled error, or in which the service prevents the holder from publishing a timely correction.

Again, wording is not outcome. Queensland law, the exact entity relationship and the incident facts would shape any legal analysis. APNIC's statement is nevertheless valuable evidence of how risk is allocated: the subscriber and relying party carry broad responsibility, while APNIC retains a narrow exception for its own wilful misconduct.

The comparison with RIPE NCC shows that similar structures recur without being textually identical. That should raise common audit questions, not a claim that every region has one contract. It also shows why operators cannot rely on a generic assumption that a registry stands behind the economic consequences of its certificate service.

There is no single RIR liability regime

Regional registries are formed under different laws, serve different membership structures and publish different combinations of agreements and certification statements. National registries and delegated authorities add further layers. Even similar clauses can operate differently depending on assent, bargaining context, statutory controls and the kind of loss claimed.

This article's examination of ARIN, RIPE NCC and APNIC does not supply a complete survey of every authority or historical version. It identifies recurring risk-allocation features in current public materials: best-effort service, user responsibility, broad damage exclusions, short claim periods, indemnities and narrow fault exceptions.

The absence of a published judgment applying a particular RPKI clause does not prove immunity or liability. Many incidents produce no loss, are repaired quickly, remain confidential or are resolved commercially. Economic-loss doctrines, limits on exclusion for serious fault, duties to third parties and collective-member remedies vary.

Policy should therefore resist two global assertions. The first is that registries cannot be responsible because operators make final routing decisions. The second is that any wrong certificate automatically makes a registry liable for all downstream loss. Both skip control, fault, causation, contract and law.

A comparative audit can still be standardised. It can report the provider's certificate powers, stated service standard, user duties, warranty exclusions, damage exclusions, cap, fault exceptions, indemnities, claims period, governing law, emergency remedy and third-party position. The fields are common even when legal effects are not.

That is the proper role for institutional analysis: make the allocation visible, identify asymmetry and leave final legal conclusions to the competent forum with the actual facts.

"Wrong certificate" describes several failures with different responsibility

A resource certificate may be wrong because it lists resources inconsistent with the authoritative registration state. A child certificate may temporarily over-claim after a parent changes. A certificate may be revoked without proper authority. It may fail to renew, become unavailable, or be valid individually but inconsistent with the publication set. A ROA may accurately reflect a holder's mistaken instruction, or inaccurately reflect a correct instruction.

These cases should never share one liability rule. Holder-authored content belongs primarily to the holder if the service clearly displayed what would be signed and faithfully executed the authorised request. The registry remains responsible for secure authentication and accurate execution, but it should not guarantee the holder's routing plan.

Registry-produced inconsistency is different. If a transfer process updates parent and child certificates in an unsafe order, the holder may have supplied no erroneous instruction. The certification authority controls sequencing and atomicity. A broad clause saying the holder is responsible for certificate use should not obscure that technical control.

Unauthorised action is different again. Account compromise may involve the holder's credential practices, registry authentication controls or both. Allocation should examine which safeguard failed and whether each party followed the published standard.

Publication delay has its own structure. A correct entity may exist but remain unavailable to relying parties. The publisher controls external delivery; validators control fetch behaviour; operators control cache and route policy. Time to expiry and correction affects loss.

The disclaimer audit should list these failure modes and attach a responsibility rule to each. A single phrase such as "use at your own risk" compresses distinct controls into one outward transfer. That may simplify legal defence, but it weakens operational accountability.

Causation should follow the first wrongful divergence

An RPKI claim can be analysed as a time-ordered comparison between expected and observed state. The expected state begins with the holder's authenticated instruction and the applicable resource registration. The observed state proceeds through certificate production, signed-entity creation, repository publication, relying-party validation, RTR delivery, router policy and BGP outcome.

The first point at which observed state wrongfully diverges is the primary technical cause. If the holder requested AS64500 when it intended AS64501, divergence begins with holder instruction. If the request was correct but the service created a different entity, divergence begins at certification. If the entity was correct but never became externally available, divergence begins at publication. If all published material was valid but a validator discarded it incorrectly, divergence begins in relying-party software.

This method does not eliminate contributing causes. An operator may fail to monitor an Invalid state or run one validator without redundancy. A transit provider may enforce a route policy more strictly than expected. A registry may delay an emergency correction after a holder mistake. Responsibility can be shared.

The method does prevent circular blame. Each entity can produce evidence for its step: signed request, entity digest, publication observation, validation log, RTR serial, route-policy version and BGP record. Times should use controlled clocks, and evidence should be retained before repair changes the state.

Legal causation includes questions beyond this technical sequence, including foreseeability, remoteness and contractual scope. But a court, insurer or member review cannot answer them sensibly without first knowing where the system departed from authorised state.

The service contract should promise access to this evidence under appropriate confidentiality. A liability exception that requires proof of gross negligence is hollow if the provider controls the only records capable of showing what occurred.

RIPE NCC's 2021 incident is a concrete control case, not proof of universal loss

RIPE NCC's January 2021 post-mortem reported that an outgoing inter-regional transfer caused its system to publish an updated parent certificate before the related child certificate. The child temporarily over-claimed resources. Some older relying-party implementations responded by rejecting all certificates in the manifest if one entry was invalid.

The organisation estimated that 327 relying-party instances were affected and said the event may have resulted in outages. It proposed tighter sequencing, faster re-issuance and ultimately atomic publication. The account identifies a registry-controlled production failure and a validator-specific amplification.

This is exactly the kind of case a disclaimer audit should test. The resource holder did not necessarily create a wrong ROA. The certification process produced a temporary inconsistency. Older validators expanded the affected scope. Network policies determined whether payload loss changed reachability. Several controls mattered, but the first divergence was in certificate publication sequencing.

The public evidence does not establish the amount of customer loss, the identities of affected networks or the enforceability of any term. It should not be used to invent damages. It does establish foreseeability: certificate-ordering defects can escape into public repositories, validators can react differently, and routing consequence is possible.

After such an event, a best-effort clause may explain why absolute continuity was never promised. It does not answer whether the provider met the care appropriate to a hosted authority, whether monitoring should have detected the inconsistent chain, or whether affected parties received a sufficiently fast remedy.

The right institutional response is a control-based review, not a slogan. RIPE NCC's move toward atomicity was valuable because it reduced the cause. Contract design should reinforce that engineering incentive.

ARIN's 2025 incident shows that narrow scope can still expose a consequential defect

ARIN's October 2025 public incident report followed deployment of support for ROAs during transfers. ARIN said a customer report revealed an issue affecting hosted RPKI, paused in-process transfers, reviewed the service and found that one customer was affected under a specific ROA configuration condition. It deployed a correction and added validation steps.

The notice is appropriately bounded. One affected customer is not evidence of regional failure. The report does not quantify routing loss or say that every related announcement became unreachable. It does show that a code defect in a registry-controlled transfer feature can affect a hosted customer's ROA state.

The incident raises practical contract questions. Did the customer have an emergency route that could authenticate the problem while transfer processing was paused? Was the pre-transfer ROA state preserved? Could the customer prove when the hosted output diverged from the expected configuration? Did the liability allocation distinguish a holder mistake from the deployed defect that ARIN later fixed?

ARIN advised source organisations to check ROA validity before and after transfers and, where practical, modify associated ROAs beforehand. That is prudent holder practice. It does not transfer authorship of the software defect to the holder. Both statements can be true: users should verify critical changes, and service operators should be responsible for reasonable care in features they control.

A well-balanced term would say precisely that. It would condition certain remedies on timely holder verification while preserving responsibility for an evidenced service defect. Blanket exclusion is simpler, but it does not align incentives as well.

Customers often bear consequences without a direct remedy against the certificate authority

The party most visibly harmed by a routing interruption may be an enterprise customer of the affected network, not the resource holder that accepted the RPKI terms. That customer may lose access to cloud services, communications or public-facing systems while having no direct contract with the registry.

ARIN's terms expressly address claims involving clients and customers within broad exclusions and indemnification language. RIPE NCC and APNIC materials also allocate third-party risk outward. From the registry's perspective, this prevents an unlimited class of strangers from converting public certificate reliance into claims.

From the customer's perspective, the result is a remedy gap. Its claim usually lies against its connectivity provider under that service agreement. The provider may in turn face a low cap or broad exclusion upstream. Risk accumulates with the operator even where the first error occurred in a certificate service it could not independently correct.

This does not mean customers should receive unrestricted direct rights against registries. A workable design can use contractual chains. The operator compensates its customer according to the connectivity agreement; the resource holder or operator receives a proportionate upstream remedy where it proves a registry-controlled fault; insurance covers residual consequential loss. Subrogation and notice rules can prevent duplicate recovery.

For critical public services, direct operational rights may matter more than damages. An authenticated downstream operator should be able to report an apparent certificate error, receive a scoped incident confirmation and obtain evidence needed to protect routing while the holder relationship is verified. The registry need not accept routing instructions from the customer to listen to technically credible evidence.

The disclaimer audit should therefore state not only who cannot recover, but how downstream harm reaches the party capable of correction.

A reasonable disclaimer should pass a control-and-remedy test

The first question is control. Does the excluded risk arise from an action the provider exclusively or predominantly controls? Hosted key operation, certificate sequencing, repository publication and service authentication are strong provider-control areas. Holder routing intent, router configuration and customer business continuity are not.

The second is preventability. Could a competent provider reasonably have prevented the failure through atomic updates, validation, separation of duties, expiry monitoring or tested rollback? Absolute protection is impossible, but ordinary controls can distinguish unavoidable failure from deficient operation.

The third is detectability. Did the provider monitor the externally valid result or only its own components? A provider that could not see an inconsistent certificate chain may have a stronger governance problem than one that detected and contained it immediately.

The fourth is remedy. Can the affected holder authenticate through an independent emergency channel, secure a correction before material expiry or route filtering, and obtain a verifiable notice? A broad financial exclusion is more defensible when operational correction is fast and dependable.

The fifth is evidence. Does the claimant receive enough retained information to establish the first divergence and contribution by other parties? A fault exception without evidence access offers little practical protection.

The sixth is proportionality. Does the cap bear any relation to foreseeable direct loss, service fees, insurance or the provider's degree of fault? A nominal cap may be acceptable for ordinary best-effort interruption yet inadequate for wilful or grossly negligent certificate misuse. Applicable law may already constrain exclusions; the contract should not rely on later litigation to discover the boundary.

These questions do not promise a claimant success. They test whether the disclaimer preserves a fair relationship between institutional power and institutional responsibility.

Responsibility should be allocated by failure class

For holder-authored ROA content, the holder should bear primary responsibility when authentication, preview and execution were accurate. The provider should give a clear representation of prefix, origin and maximum length before signing, preserve the authorised request, and offer rapid correction.

For registry record errors that flow into certificates, the registry should bear responsibility for verifying that certificates match the registration state it controls. If the underlying registration itself is disputed, the contract should provide a separate review route rather than treating routing consequence as ordinary user risk.

For certification software defects, the service operator should bear an appropriate standard tied to development, testing, change control and response. Liability can be capped for ordinary fault while preserving stronger remedies for serious misconduct, repeated known defects or unauthorised action.

For repository transport failure, the publisher should be responsible for reasonable availability, semantic integrity, freshness monitoring and protocol diversity. Operators retain duties to cache, update and run supported validators.

For relying-party defects, the software maintainer and deploying operator carry responsibility according to their agreements, support status and update practice. The repository remains responsible for standards-conforming publication and foreseeable compatibility communication.

For router policy, the network operator owns the final decision. A registry should not guarantee that every route will be accepted. But local policy does not sever causation where a wrong certificate predictably caused the Invalid classification the policy consumed.

For downstream business loss, the customer agreement, mitigation and proof of direct effect determine the first remedy. Upstream allocation should remain possible where the operator proves another party's controlled fault.

A table containing these rules would do more for legitimacy than pages of undifferentiated capital-letter exclusions.

The first hours of correction are more valuable than years of litigation

Routing harm can emerge far faster than a contractual dispute. The service therefore needs an emergency correction commitment independent of financial liability.

The holder should be able to report a suspect certificate, ROA, revocation or missing publication through a continuously monitored channel. Authentication should use more than the ordinary account path in case that path is compromised or unavailable. The provider should acknowledge the report, identify the affected branch and freeze only the action necessary to prevent further harm.

The next step is a safe comparison of expected and published state. If the provider confirms its own error, it should issue or restore the correct entity through a documented emergency procedure. If the holder's instruction was wrong, the service should facilitate an authenticated replacement without altering history. If authority is disputed, a scoped restraint may be safer than an unreviewed transfer of control.

External convergence must be verified. Publishing a correction at origin does not prove that independent validators have fetched it or that RTR clients have updated. The incident should remain operationally open until a defined probe set validates the repaired branch.

A signed notice should identify entity digests, affected prefixes and times without exposing private account material. Transit providers and customers can then distinguish the real correction from fraudulent messages. The notice should state whether the event produced Invalid, NotFound or another condition under tested validators.

These duties can be promised even where consequential damages remain excluded. They align the institution's unique certificate power with the remedy only it can deliver. Failure to meet the emergency commitment can then become a separate and more defensible basis for responsibility.

Evidence access determines whether fault exceptions are real

ARIN, RIPE NCC and APNIC each publish extensive technical or legal material, but an individual incident may depend on non-public evidence: account authentication, authorised request contents, certificate-generation events, key operations, publication times, security alerts and staff actions.

The provider has legitimate reasons to protect this material. It may contain personal information, security detail or data concerning other holders. Complete public disclosure would create new risks. The answer is controlled access, not absence.

Terms should require retention for a stated period and allow an affected holder, independent reviewer, insurer or competent authority to obtain relevant extracts under confidentiality. Cryptographic digests and time attestations can prove entity state without exposing every system detail. Security-sensitive records can be reviewed by a neutral expert who publishes bounded findings.

Evidence should include negative facts. If no authorised revocation request exists, the provider should be able to establish that. If the correct entity reached the repository at a particular time, outside observations should corroborate it. If a holder ignored repeated warnings about an inconsistent ROA, those notices matter.

Claim periods should account for discovery. A one-year period after the claimant knew or reasonably could have known of a right may be manageable for a visible outage, but hidden certificate effects can be discovered later. The exact legal result varies; operationally, evidence should not be destroyed before a plausible claim can be investigated.

An institution cannot credibly say liability exists for gross negligence while withholding the records needed to distinguish gross negligence from an unavoidable event. The audit should score evidence rights alongside the wording of the exception.

Caps should encourage insurance and careful service design rather than moral hazard

Unlimited RPKI liability could deter registries from offering hosted service or lead them to price it beyond smaller networks. A cap is therefore not inherently illegitimate. The design question is what behaviour the cap encourages.

A cap tied only to a free or bundled service fee may approach zero even when the provider exercises substantial control. That can create moral hazard: the institution captures the efficiency and governance benefits of centralisation while externalising nearly all operational downside. A fixed nominal amount has the same problem if it is unrelated to direct response cost or foreseeable loss.

A tiered cap is more coherent. Ordinary interruption without provider fault may carry no damages beyond service restoration. Ordinary negligence in a provider-controlled function may carry a meaningful but bounded direct-loss cap, perhaps linked to membership fees, insurance or a published amount. Gross negligence, wilful misconduct, unauthorised certificate action or concealment may receive a higher cap or no contractual protection to the extent law permits.

Consequential loss can remain restricted while reasonable incident-response costs are recoverable. A network may need emergency engineering, customer communication and temporary transit changes even when lost-profit claims are too remote. These direct mitigation costs are easier to evidence and encourage rapid containment.

Registries should disclose whether they maintain relevant cyber or professional liability cover and the broad class of risk covered, without exposing sensitive policy detail. Resource holders can then decide whether to buy their own continuity cover. Collective insurance through membership may be more efficient than pretending the risk does not exist.

The goal is not a damages market around every ROA. It is to ensure the party best placed to prevent a failure retains enough downside to invest in prevention.

Delegated RPKI changes control but does not erase the parent relationship

A resource holder can reduce hosted-key dependence by operating a delegated certification authority. It controls its keys and signed entities, subject to the parent certification relationship. It may also run its own repository or use a publication service. This can align operational control with responsibility for sophisticated networks.

Delegation is not a universal answer. It requires secure key management, supported software, monitoring, publication continuity, incident response and staff competence. A poorly operated delegated authority can create more risk than hosted service. Smaller holders may reasonably prefer the registry's infrastructure.

The parent still controls important functions. It issues the child certificate based on the resource relationship and may update or revoke that certificate under defined circumstances. Provisioning between parent and child can fail. Resource transfers can alter the certified set. If the delegated authority publishes under a parent-operated repository, publication control remains shared.

Terms should map this division rather than state that delegated users simply accept all risk. The holder owns its key security and entity content. The parent owns accurate, timely parent certification and provisioning within its control. The publication provider owns the service it operates. Each needs compatible evidence and emergency contacts.

Choice also needs practical portability. A holder should be able to move between hosted and delegated arrangements through a tested sequence that avoids duplicate or missing authority. If the liability solution is "run it yourself" but exit from hosted service creates an unsafe transition, the choice is incomplete.

A mature registry can offer both models and publish their different responsibility maps. That supports operator autonomy without using delegation as a waiver of every parent duty.

Unilateral term changes need continuity safeguards

RPKI service terms often permit amendment through notice, publication or continued use. Providers need that flexibility because standards, law and security threats evolve. A certification authority cannot remain bound forever to obsolete procedures.

The same flexibility can alter risk after operators have integrated the service into critical routing. A new cap, narrower fault exception, shorter claim period or broader revocation power may materially change the value of reliance. The holder cannot always leave immediately without moving keys, repositories and operating procedures.

Material amendments should therefore receive clear advance notice, a comparison of old and new clauses, and a reasonable transition period. Emergency security changes can take effect faster, but should be narrowly scoped and reviewed later. The historical version must remain accessible so incident-date rights can be identified.

Holders should have an exit path. They may move to delegated certification, another supported publication arrangement, or discontinue signed entities through an orderly process. Exit should not create a gap in valid authorisation merely because the holder declined a new liability term.

Member governance can add legitimacy. Where the registry is a membership association, major changes to certificate control and responsibility should receive member scrutiny rather than being treated as ordinary website text. Technical communities should review operational consequences; legal review alone may miss how quickly a wrong entity propagates.

The provider also benefits. Transparent amendment reduces surprise and demonstrates that broad discretion is exercised within a stable institutional process. A term governing an Internet security dependency should be managed with more care than a routine consumer feature.

Courts need a bounded technical record, not a theory of the whole Internet

If a dispute reaches court or arbitration, the claimant should not need to prove how every network on Earth treated the certificate. It should prove the path relevant to the claimed loss: authorised state, wrong entity or publication, validator output, operator policy, BGP consequence and customer effect.

The provider should be able to challenge each link. Was the holder's request accurate? Did another valid ROA preserve the route? Did the operator use supported software? Was the route already unavailable for another reason? Could reasonable mitigation have reduced loss? These are factual questions suited to retained evidence.

The forum should also distinguish direct from remote loss. Emergency engineering and documented traffic loss may be closer to the event than a customer's projected future revenue. Contract wording and applicable law decide recoverability, but technical proximity helps organise the analysis.

A regulator or court should be cautious about imposing one operational model on all RPKI. Strict liability could suppress useful hosted services. Total immunity could weaken incentives around a critical trust function. A fault- and control-based standard is more adaptable.

Independent expertise will often be necessary. RPKI certificate paths, manifests, caches and route policy are specialised. Expert replay should use preserved entities and named software rather than hypothetical screenshots. Conflicts should be disclosed, especially where experts contribute to the same software or institutions under review.

The narrower the factual record, the less tempting it becomes to decide the political status of Internet number resources through a routing incident. A certificate liability case should answer who controlled the failed service step and what loss it caused, not convert RPKI into a universal property judgment.

NRS can turn collective concern into a practical disclaimer audit

NRS's public charter advocates accurate number registration, operational stability and limits on registry power. Its NRS Shield material already directs resource holders to identify the exact agreement governing liability, suspension, termination and practical remedy. That is a concrete starting point for RPKI scrutiny, not a claim that NRS operates a certification service.

NRS could publish a versioned certificate-service disclaimer register covering each regional and participating national authority. For every service model, it would list certificate powers, holder duties, best-effort language, fault exceptions, damage exclusions, cap, indemnity, claim period, governing law, emergency correction path, evidence access and transition rights.

The register should quote sparingly and link to the controlling documents. Legal reviewers in each jurisdiction should explain uncertainty rather than issue a universal verdict. Operators should test whether the stated emergency paths work. Registry staff should be invited to correct errors and explain why particular protections are necessary.

NRS could then publish an advocacy benchmark for public scrutiny. A responsible certificate service need not offer unlimited damages. It should accept an appropriate standard for actions it exclusively controls, preserve exceptions for serious fault, provide rapid correction, retain evidence, publish incidents and allow safe transition between service models. Adoption and execution of that benchmark would remain with RIRs, authorised operators and the competent review or legal forum.

Collective membership can also improve bargaining. A small network may be unable to negotiate a regional term alone. A group can ask for standard clarification, insurance options or an independent review mechanism without threatening the continuity of the registry.

NRS must apply the same transparency principle to the membership and advocacy services it actually provides, including the liability limits in its own membership terms. It is not an RPKI certification authority, repository operator or certificate-protection service, and this audit does not propose that it become one. Certificate issuance, publication, emergency correction and technical evidence custody remain with the relevant RIR, an authorised certification or publication operator, and any competent independent reviewer or court.

NRS's role is to research and compare those arrangements, advocate clearer terms and help members present evidence through the proper operational and legal channels. Institutional accountability is credible only when each institution is judged against the powers it genuinely holds.

A balanced certificate-service contract can be written in plain operational language

The provider promises to authenticate requests, operate hosted keys under stated controls, issue certificates consistent with the authoritative resource state, execute authorised entity changes accurately, publish semantically valid material, monitor external validity, preserve evidence and maintain an emergency correction service.

The holder promises to protect credentials, verify resource and routing information, review the exact entity before authorisation, monitor external route validity, maintain current contacts, report errors promptly and operate reasonable continuity measures.

The relying party and network operator promise to use supported validation software, retrieve current material, maintain prudent cache and validator redundancy, understand local route policy, monitor payload changes and preserve relevant routing evidence.

The provider does not guarantee universal route acceptance, absence of every interruption, market value, customer performance, identity beyond certificate scope or facts controlled by the holder. Consequential and speculative losses may be excluded or capped.

Where a provider-controlled error occurs, it promises immediate correction and a review. Direct mitigation costs and other damages are treated under a stated tier based on fault. Serious misconduct, unauthorised certificate action and concealment receive a clear exception to ordinary protection, subject to applicable law.

The agreement identifies who may raise an emergency, how identity is verified, when a response is due, what evidence is available, how an independent review starts and which historical version governs. Downstream parties receive a technical notice route without acquiring authority to change the holder's entities.

None of this requires a registry to promise the impossible. It requires the contract to mirror the actual service. When certificate control is concentrated, responsibility for competent certificate control is concentrated with it. When routing policy remains local, responsibility for routing policy remains local.

Institutional legitimacy depends on accepting responsibility no wider and no narrower than power

RPKI is valuable because a signed authorisation can change the confidence with which networks accept an origin. That value disappears if certificates are treated as inconsequential when wrong and authoritative when right. Institutions cannot claim the security benefit of control while denying that the same control can cause harm.

Nor can operators outsource every mistake. A registry does not choose the holder's routing design, upgrade validators, configure routers or guarantee customer continuity. Broad Internet dependence does not make the registry the insurer of all economic activity.

The defensible middle begins with the first wrongful divergence. It asks who controlled that step, what standard applied, whether the error was preventable, how quickly it was detected and corrected, and what consequence was evidenced. Contractual protection can then be proportionate rather than absolute.

The public terms examined here reveal a recurring imbalance. Users and relying parties assume broad risk, while providers preserve extensive protections even though hosted services control keys, certificate life cycles and publication. Fault exceptions in some regions narrow the imbalance but do not remove the need to test practical remedy and evidence access.

Reform should begin operationally: exact previews, atomic publication, external validation, emergency correction, preserved evidence and versioned incident notices. Liability terms should reinforce those controls through meaningful responsibility for provider-controlled fault while continuing to reject remote and unlimited claims.

NRS can help make this compact visible across regions and strengthen the collective position of resource holders without weakening the registries they need. The measure of success is not the size of a damages award. It is whether the institution with certificate power has every incentive to use it accurately, repair it quickly and explain it honestly.

A certificate service earns reliance when its legal position matches its technical role. Power without responsibility is not a stable trust anchor.

Sources