Summary
- RPKI is not merely a security feature in five member portals. It is a trust system in which certificate authority, repository publication, ROA management, validator configuration, TAL distribution, hosted-service dependence, delegated-service availability and registry governance can all become routing-reliance factors.
- The NRO RPKI Program openly aims for a more consistent, uniformly secure and reliable RPKI service across all five RIRs, while its 2025 objectives include transparency, robustness, security and concern about current trust anchor configuration. Coordination is useful, but it also means resilience must be measured by shared failure domains rather than by the count of RIR brands.
- A serious RPKI resilience standard should ask which failures are independent, which are common, which can be delegated away from a registry, which require emergency operator support, and which require public review before certificate state changes affect routing acceptance.
The logo count is not a resilience metric
The public map of RPKI looks reassuring at first glance. There are five Regional Internet Registries. Each has its own region, public site, member portal, resource certification pages and trust anchor material. The NRO's RPKI Content Repository links to distinct RPKI portals, resource-certification pages, Trust Anchor Locator information and Certification Practice Statements for AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC. The surface seems distributed because it is visibly plural.
Plural appearance is not the same as independent resilience. Five public brands can still share one governance assumption. Five trust anchors can still converge through a common program direction. Five portals can still depend on similar account-control practices, similar hosted-service incentives, similar legal interpretations of holder authority and similar emergency-continuity expectations. Five repositories can still be consumed by the same validator ecosystem and routed into the same downstream filtering decisions.
A failure that appears regional at the signing point can become global at the relying-party point if operators ingest the result through common tools and common routing policies.
That is the central problem beneath joint RPKI trust. RPKI was designed to make route-origin authorization more verifiable. It binds number resources to cryptographic certificate material and lets a legitimate holder authorize an autonomous system to originate a prefix. That is a major improvement over loose trust in route announcements and stale route objects. But once routing acceptance begins to rely on certificate state, the governance of that certificate state becomes part of the Internet's control surface. The issue is no longer simply whether each RIR has a logo and a portal.
The issue is which failures can remove, stale, misstate or delay the evidence that routers and route filters consume.
The NRO RPKI Program makes the coordination layer explicit. It says the NRO agreed to work toward a robust, coordinated and secure RPKI service, with the purpose of providing a more consistent and uniformly secure, resilient and reliable service and removing barriers experienced by operators who create RPKI objects through multiple RIRs. That is a sensible goal. Operators with resources across regions should not need to learn five incompatible security cultures. A global routing-security layer benefits from consistency.
Consistency, however, also changes the resilience question. When a service is intentionally made more uniform, an observer must ask whether uniformity reduces error or concentrates it. A common baseline can eliminate weak local practice. It can also spread a mistaken assumption across all regions. A common documentation set can make adoption easier. It can also obscure regional differences that matter for delegated service, emergency access, account recovery, ROA revocation and legal authority. A joint program can harden security. It can also make policy choices look technical because they arrive in operational language.
The correct metric is therefore failure domain, not logo count. A failure domain is the set of components, authorities, assumptions, people, legal rules, software dependencies, publication points and review paths that can fail together. If five institutions share the same domain for a particular risk, counting them as five resilience units is misleading. If one institution has two genuinely separate domains for a risk, counting it as one is also misleading. The audit has to follow the decision and the dependency, not the emblem on the page.
RPKI turns registry authority into routing evidence
RPKI begins as a technical architecture, but it does not stay outside governance. RFC 6480 describes an infrastructure to support improved routing security. Its foundation is a Resource Public Key Infrastructure representing the allocation hierarchy of IP addresses and AS numbers, together with distributed repositories for the signed objects used in routing security. It describes how a legitimate holder can authorize one or more ASes to originate routes for address space and how such verifiable authorizations can support route filters.
That architecture follows resource allocation. IANA sits at the root of the allocation hierarchy. The RIRs manage address and AS number allocation within defined regions. Resource certificates attest to holdings; ROAs provide origin authorization. The certificate is not a decorative artifact. It is a statement that can affect whether a route is considered valid, invalid or not found by operators using RPKI origin validation. A registry record thus becomes routing evidence.
The governance consequence is direct. When a registry controls hosted RPKI service for a holder, it is not merely maintaining a website feature. It is operating part of the holder's route-origin evidence. When a registry changes certificate state after a transfer, account compromise, court order, nonpayment, sanctions review, holder death, corporate merger, dispute or suspected fraud, that change can move from registry desk to validator cache to route filter. The distance between governance and routing shrinks.
This does not mean RIRs should avoid RPKI authority. The existing allocation structure made RIR involvement natural. RFC 6480 says the PKI structure corresponds to existing resource allocation, making management a natural extension of organizations already responsible for resource allocation. It also says resource certificates do not verify personal or organizational identity in the ordinary public-PKI sense; they attest to resource holdings. That boundary reduces some liability while sharpening another question: what registry fact is the certificate competent to express?
The answer should be narrow. A resource certificate should express resource-holding authority and related delegation state, not a registry's view of every commercial, political or moral issue surrounding the holder. A ROA should express route-origin authorization within a recognized resource state, not settle every underlying dispute. An RPKI repository should publish current cryptographic evidence, not become an opaque disciplinary tool. The more operators rely on the output, the more important it becomes to keep the input authority precise.
Failure-domain analysis starts here. A registry governance failure can become an RPKI failure if the registry can incorrectly revoke, fail to publish, refuse to update, delay transfer handover, mishandle delegated publication, lose account control, misread holder authority or apply a common policy assumption too broadly. A validator failure can become a routing failure even if the registry is correct. A repository outage can become a stale-data failure. A trust-anchor rollover can become a global configuration failure. A legal dispute can become a certificate-state delay.
None of these risks is solved by saying there are five RIRs. The same operator may depend on all five. The same validator may fetch all five. The same major network may apply route filters based on all five. The same NRO program may push all five toward common documentation and features. The system is distributed in some ways and concentrated in others. The resilience map must show both.
The TAL is a small file with large institutional meaning
The Trust Anchor Locator is one of the clearest examples of hidden concentration. RFC 6490 explains that a trust anchor in RPKI is represented by a self-signed X.509 Certification Authority certificate, and that the TAL specifies data used to retrieve and verify the authenticity of a trust anchor. The TAL contains a URI and public key material used by relying-party software. The point is to avoid redistributing the trust anchor itself every time the set of Internet number resources associated with the trust anchor changes, so long as the public key and location remain stable.
That description sounds technical, but the TAL is also an institutional dependency object. A relying party that configures a TAL is deciding which authority to trust for a region's resource certificates. If the TAL location changes, if the key changes, if the repository is unavailable, if the CA certificate is mishandled, if a rollover is poorly communicated, or if a crisis raises questions about who can authorize changes, the issue is not only cryptography. It is trust governance.
The NRO's RPKI Content Repository makes this dependency visible by listing TAL information for each RIR. It also links to CPS material and support resources. That is useful transparency. It lets operators find the pieces they need. But it does not answer the deeper resilience questions. Who decides when a TAL should change? How much notice is necessary? What happens if an emergency operator must maintain service? Can a local court order affect trust-anchor material? How are conflicting claims handled? What if a registry is operationally alive but governance-impaired? How do validators treat old and new material during transition?
Short-lived trust-anchor certificates, repository publication methods, delegated-service support and hosted-service design all affect that picture. The NRO roadmap for core RPKI services lists hosted service as available from all five RIRs, delegated service from APNIC, ARIN, LACNIC and RIPE NCC with all RIRs targeted by the end of the first quarter of 2026, API management goals, ROA objects through interface and API, and short-lived TA certificates offered by APNIC, ARIN and LACNIC with a target for all by the end of 2025. These feature gaps and targets are governance facts, not just product notes.
If every RIR eventually offers the same core feature set, some adoption barriers fall. A multi-region holder can design better internal controls. Relying-party expectations become more predictable. Documentation can improve. But common target dates do not automatically create independent failure domains. If the same assumption about trust-anchor rollover is embedded everywhere, a mistake can travel. If all regions adopt a similar hosted-service default, delegated self-reliance may remain underused. If all regions align terminology but not cure rights, operators may understand a denial better without being able to challenge it.
The TAL is therefore a good resilience test. Count the number of configured TALs, then ask how many independent governance paths protect them. Count the number of repositories, then ask whether relying parties treat failure differently. Count the number of RIR brands, then ask whether a common NRO program or common implementation decision could change all operator expectations at once. Count the number of certificates, then ask which legal actor can authorize emergency continuity.
The answer will vary by risk. Repository availability may be more distributed than legal interpretation. Portal multi-factor controls may be region-specific. Validator implementation behavior may be global. Trust-anchor communication may be partly coordinated. Emergency continuity may be underdefined. The point is to map those domains explicitly, not to assume plural logos equal plural resilience.
Hosted convenience is not the same as operator control
The NRO baseline page on RPKI services reports that hosted service is available at all five RIRs. Hosted service is valuable because many resource holders lack the staff, time or security engineering to run delegated RPKI. A small network can create ROAs through a familiar registry portal. A larger operator can manage route-origin evidence without operating its own CA. Hosted service accelerates adoption, and adoption matters because RPKI only improves routing security when enough holders publish correct objects and enough networks validate them.
The governance cost is dependence. In hosted mode, the registry's portal, account authentication, authorization model, change logging, support desk, staff process, outage handling and legal interpretation sit between the holder and its route-origin evidence. If the holder's account is compromised, the registry process matters. If a transfer closes, the handover process matters. If an urgent maxLength correction is needed, the service desk matters. If sanctions screening or legal review freezes an account, certificate state can become collateral damage.
If a registry crisis disrupts staff access or payment systems, the hosted RPKI service is part of the service-continuity problem.
Delegated RPKI changes the balance. It allows the holder to run its own CA or publication arrangement under a registry-issued certificate. It can reduce portal dependence and give sophisticated operators more direct control. But delegated service is not an escape from the registry. The parent certificate, trust anchor, resource recognition, transfer updates and policy boundaries still matter. Delegation shifts some operational failure domains away from the registry while leaving others with it.
The NRO's overview of RPKI services shows that delegated service availability and hybrid publication features are not uniform. Hosted service is universal. Delegated service is listed for four RIRs in the December 2025 overview, with AFRINIC marked as not offering it there. Hybrid publication service also varies. API support, transaction history, route collector suggestions and alignment between RPKI and IRR sources vary. These differences matter because they tell operators which failures are local, which are avoidable and which are inherent in the parent-trust structure.
A resilience audit should therefore ask three questions for every resource holder. First, what can the holder do without registry staff if something breaks today? Second, what can the holder do without the registry portal if credentials, payment status, sanctions review, local court process or support queues become problematic? Third, what cannot be done without parent-registry action no matter how competent the holder is?
For a small hosted user, the answer may be: almost everything depends on the registry interface and support model. For a delegated operator, the answer may be: routine ROA publication is independent, but parent certificate state, resource changes, transfer handover and trust-anchor events remain registry-dependent. For a multi-region holder, the answer may differ across RIRs. For a downstream cloud or transit provider, the answer may be invisible unless the holder documents it.
This is why "five RIRs offer RPKI" is not enough. A system can be widely available and still concentrated in decision rights. The question is not only whether a feature exists. It is who can exercise the feature during stress, who can override it, who can recover it, who can audit it, and who bears the cost when the registry and the operator disagree.
Coordination improves consistency and concentrates assumptions
The NRO RPKI Program is candid about its objectives. For 2025, it says the program focused on transparency, robustness and security of the RPKI system, including a solution for consultation with the technical community addressing concerns regarding current trust anchor configuration. It also aims to increase consistency of user experience through consolidated documentation, standardized terminology, recommended best practices, a gap analysis of RPKI interfaces across RIRs and a roadmap for an agreed set of core features.
This is exactly what a mature coordination body should do. RPKI is too important to leave to five unrelated product cultures. Operators need clarity. Validators need predictable behavior. Multi-region holders need similar concepts. Security researchers need comparable artifacts. Confusion increases misconfiguration, and misconfiguration can make legitimate routes invalid. Coordination can reduce that risk.
The concentration risk lies inside the word "agreed." An agreed set of core features can harden the weakest region. It can also make every region inherit the same blind spot. If the agreed baseline says little about appeal rights after certificate suspension, all regions may treat that silence as normal. If the agreed baseline favors hosted convenience over delegated autonomy, adoption may rise while operator control remains weak. If the agreed baseline improves transparency but not emergency authority, a crisis may be well documented and still unresolved.
If the agreed baseline standardizes terminology without standardizing public incident reporting, operators may talk about outages more consistently while lacking better evidence.
RPKI is particularly sensitive to common assumptions because relying parties tend to automate. A legal or governance mistake does not need to persuade every human operator individually once it is expressed as certificate state and consumed by validators. The route-origin result can travel through caches, routers and filters. That automation is the point of RPKI; it is also why governance must be precise.
The right response is not to keep every RIR different. Arbitrary difference is a failure too. If one region lacks delegated service, API access, transaction history or reliable support, operators suffer. If one region uses confusing terminology, adoption suffers. If one region has weak security controls, the whole system is less credible. The right response is to classify which differences are harmful and which differences provide resilience.
Harmful differences include unclear ROA management, weak authentication, missing transaction history, poor repository availability, unstable support, inconsistent guidance on maxLength, unclear TAL instructions, and poor visibility into hosted versus delegated mode. Resilience differences include independent incident review, region-specific legal safeguards, alternate publication arrangements, ability to run delegated services, separate operational teams, diverse software stacks, local appeal paths, public service metrics and published handover plans.
The NRO can coordinate the first category without erasing the second. It can require every RIR to support a secure baseline while allowing different accountability designs. It can align terminology while preserving local legal disclosures. It can standardize incident severity labels while requiring each RIR to publish its own root-cause statement. It can recommend delegated service without forcing every operator into identical architecture. It can consult on trust-anchor configuration while publishing failure-domain analysis for the options.
The phrase "single, global RPKI system" should therefore be handled carefully. The routing security layer is global in effect. The allocation hierarchy is global in structure. The relying-party ecosystem is global in consumption. But resilience improves when the system contains controlled diversity: independent publication paths, independent review, independent regional reasons and operator ability to delegate away from unnecessary hosted dependence. A single global system should not mean a single unquestioned governance assumption.
Failure domains that should be measured
The first failure domain is authority. Who has the right to create, revoke, change or refuse RPKI objects? The answer can involve the resource holder, portal user, legal representative, registry staff, sponsoring organization, NIR, transfer counterparty, court-appointed officer or emergency operator. If those roles are confused, the risk is not technical. It is authority ambiguity expressed through technical state.
The second domain is account control. Hosted RPKI depends on portals. Portals depend on credentials, multi-factor authentication, role assignment, staff support and recovery. The NRO service overview reports multi-factor authentication features across RIR portals, with different methods and mandatory thresholds. A security audit should not merely ask whether multi-factor exists. It should ask who can add a user, reset a factor, approve a role, recover from compromise, and see the transaction trail.
The third domain is publication. RPKI uses repositories for certificates, ROAs, manifests and related objects. Repository failure, stale content, manifest problems, RRDP or rsync issues, and validator fetch behavior can all affect route-origin information. The domain is not just the RIR data center. It includes content distribution, protocol support, monitoring, incident notices and relying-party cache behavior.
The fourth domain is trust-anchor configuration. TALs must be distributed securely, configured by relying parties and maintained through key or location changes. A trust-anchor concern can affect all operators that depend on a given TAL. If multiple RIRs coordinate trust-anchor changes through the same program and schedule, communication improves, but common timing risk appears. If they do not coordinate at all, relying parties face confusion. The resilience design must balance those risks.
The fifth domain is service mode. Hosted and delegated arrangements place different responsibilities on the registry and holder. A mature audit should report the percentage of resources under hosted service, delegated service and hybrid publication where available, not merely whether the option exists. A feature unused by most holders is not an effective resilience layer.
The sixth domain is legal intervention. Court orders, sanctions lists, insolvency, receivership, mergers, creditor claims, fraud investigations and government demands can all create pressure on certificate state. The registry must know which facts it can verify and which require external adjudication. It also needs reversible remedies: temporary holds, notations, narrow freezes, independent audits, emergency stays, and staged updates rather than irreversible revocation when the evidence is incomplete.
The seventh domain is common program direction. If the NRO program sets a feature roadmap, terminology, best practice and response posture, that program becomes a failure domain for assumptions. It should therefore publish not only outputs but alternatives considered, rejected options, risk tradeoffs and dissenting technical views where they exist.
The eighth domain is validator behavior. RIRs publish signed material, but relying-party software and operator filters decide how that material affects routing. If major validators interpret edge cases differently, the same repository state can produce different operational results. If major networks converge on one implementation, software diversity shrinks. If route servers apply RPKI filtering in a localized way, the effect differs from Tier-1 filtering. These downstream domains sit beyond RIR logos but shape real resilience.
The ninth domain is emergency continuity. The 2025 draft RIR Governance Document defines emergency continuity and emergency operator concepts, and the NRO Stability Fund describes mutual support for serious disruptions. RPKI continuity should be part of any emergency plan. The public should know what continues, what freezes, who can sign, who can publish, how old objects are treated, and how authority returns to normal.
The final domain is public evidence. Operators need proof, not reassurance. Service availability metrics, repository health, incident reports, TAL-change notices, transaction history, support response times, delegated-service adoption, appeal outcomes and emergency drills should be visible enough to let the market price resilience. Without evidence, five logos become theater.
What happens when governance becomes certificate state
Consider a transfer. The seller has ROAs. The buyer needs route-origin authorization. The registry must recognize the transfer, update resource records, preserve continuity and avoid old ROAs lingering too long. If the transfer is ordinary, the process is administrative. If the transfer is disputed, financed, cross-border, court-affected, sanctions-screened or delayed by documentation, the RPKI state becomes a risk surface. Old authorization can survive too long. New authorization can arrive too late. A maxLength mistake can make legitimate more-specific routes invalid. A support delay can create customer outage.
Now consider a corporate succession. A legacy holder changes name, merges or dissolves into an affiliate. The registry must identify who can act. A portal user may still have credentials but not authority. A director may have authority but no portal access. A bank may require evidence. A court may issue an order. RPKI hosted service can become the place where those roles collide. The certificate state should not move until authority is clear, but indefinite delay can harm routing. The remedy is not broad discretion. It is an evidence ladder with temporary continuity.
Consider a registry crisis. If a registry cannot operate normally, RPKI questions arise immediately. Can existing certificates remain valid? Who monitors repository freshness? Who answers urgent ROA correction requests? Who can suspend dangerous changes without freezing ordinary service? Who communicates with relying parties? Does an emergency operator have signing authority, publication authority or only support authority? How are keys protected? How is handback audited?
The NRO's draft lifecycle governance is relevant because it recognizes that RIR operation and potential derecognition require more than entry criteria. But RPKI needs an even more detailed continuity annex. A registry can be recognized in general and still have a temporary RPKI signing problem. A registry can have RPKI running and still lack member confidence. A derecognition proposal can take time while routing evidence must be maintained daily. The certificate layer does not wait for institutional theory to settle.
The same is true for sanctions and legal restraint. A registry may need to comply with applicable law. It may need to prevent services to a sanctioned party. It may need to avoid facilitating fraud. But a legal hold should be precise. It should say whether existing ROAs remain, whether new ROAs are blocked, whether revocation is required, whether delegated publication continues, whether a court or regulator has spoken, whether unaffected prefixes continue and whether the holder has a review path. Otherwise certificate state becomes hidden enforcement.
The governance standard should be least destructive routing evidence. When facts are uncertain, preserve the last known safe state if possible. When a route authorization is clearly unauthorized, correct it. When authority is disputed, mark and pause the contested action rather than breaking unaffected service. When legal compulsion exists, describe the service consequence as narrowly as confidentiality allows. When a registry mistake occurs, publish correction and timeline. When emergency action is taken, make it reversible unless immediate security requires otherwise.
This standard would not weaken RPKI. It would strengthen reliance by making certificate state credible. Operators do not need perfect comfort. They need to know whether a validity change reflects routing authorization, stale data, legal restraint, account compromise, transfer timing, registry outage or governance crisis. Those are different facts with different remedies.
Joint trust needs independent proofs
The NRO's coordination role can produce a stronger RPKI system if it insists on independent proofs inside common standards. A shared baseline should not merely say that all RIRs provide hosted service. It should publish comparable service metrics: repository availability, update latency, incident counts, support response time, TAL-change notice periods, transaction-history availability, delegated-service adoption, emergency drills and root-cause publication. Comparable evidence lets operators see where resilience is real and where it is aspirational.
The baseline should also publish failure-domain maps. For each RIR, the map should show hosted portal, delegated path, repository publication, TAL management, CPS, account recovery, transfer handover, legal hold, emergency operator, support escalation and public incident channel. For the NRO program as a whole, the map should show which decisions are joint, which are regional, which require ICANN, which involve IANA, which rely on RFC-defined behavior and which depend on private operator deployment.
Independent review should be part of the map. If a resource holder says a ROA change was wrongly refused, who reviews? If a delegated publication point is misclassified, who reviews? If a transfer handover leaves stale authorization, who reviews? If a registry invokes legal restraint, can an affected holder see enough to challenge the service consequence? If a common NRO RPKI practice causes harm, is there a path to challenge the common practice or only five local support tickets?
The review body need not be a court. Many issues are technical and time-sensitive. The first reviewer can be an internal escalation team. The second can be an independent technical panel. The third can be an institutional appeal if the issue concerns authority or fairness. Courts remain relevant for legal entitlement, fraud, corporate authority or statutory compulsion. The point is that automated routing evidence should not remove human contestability when the dispute is about registry authority rather than cryptographic syntax.
Dissent should also be visible. If one RIR believes a proposed common RPKI baseline creates legal risk in its region, that dissent should be published with reasons. If one RIR cannot implement a feature because of local law, the gap should be named. If one RIR exceeds the baseline with stronger delegated-service autonomy or appeal rights, that improvement should not be hidden in regional documentation. Joint trust is stronger when operators can see variation and judge it.
Security engineers sometimes worry that too much governance discussion will slow deployment. That risk is real. RPKI adoption has already taken years, and route leaks and hijacks remain operational threats. But hidden governance risk also slows adoption. Operators hesitate when they fear unilateral certificate mistakes, unclear revocation, hosted custody, weak recovery or legal takedown. A clearer failure-domain model can increase adoption because it shows what is controlled and what remains risky.
The best case for the NRO program is therefore not "trust us, all five RIRs agree." It is "here are the common baselines, here are the independent domains, here are the known gaps, here is the appeal path, here is the emergency plan, here is the evidence." That is a stronger security message because it treats trust as verifiable.
Resilience should be tested by drills, not statements
RPKI continuity needs exercises. The exercises should be public enough to improve confidence and private enough to protect keys and attack surfaces. A trust-anchor communication drill can test whether relying parties receive notice, understand timing and update validators safely. A repository outage drill can test stale-cache behavior and operator messaging. A hosted-portal compromise drill can test account freeze, transaction review and holder notification. A transfer-handover drill can test old ROA cleanup and new ROA timing. A delegated-service failure drill can test parent coordination without seizing unnecessary control.
An emergency registry drill is especially important. It should ask what happens if a registry loses critical staff, faces insolvency, loses board authority, suffers a court-appointed caretaker scenario, or cannot operate its portal. The Joint RIR Stability Fund recognizes scenarios such as financial distress, loss of critical staff, natural disaster, political instability, criminal activity and structural infrastructure problems. RPKI should be a named service in any such event.
The drill should identify who can keep existing material valid, who can publish emergency notices, who can process urgent security corrections, and what actions are frozen until authority is restored.
The output should not reveal sensitive key-handling details. It should reveal service classes. For example: existing repository publication continues; new ROA creation is available for authenticated holders; high-risk account recovery requires dual approval; transfer-related certificate changes are processed under emergency review; contested legal changes are paused; unaffected resources continue; public updates appear at a defined cadence. Such statements turn resilience from assurance into an operating promise.
The drills should also include multi-RIR holders. A company with resources in several regions may face different portal controls, delegated options, support hours and legal requirements. A global incident can require changes in more than one region. If the NRO program wants to remove barriers for operators that create RPKI objects through multiple RIRs, it should test the multi-region emergency user journey.
Relying parties should be part of the exercise. RPKI is not complete until validators and networks consume the data. A registry can publish correctly while validators cache poorly, misinterpret edge cases or fail to alert operators. A drill should involve major validator implementations, route servers, transit providers, exchange points and large cloud networks where appropriate. The NRO does not control them, but it can coordinate communication and publish lessons.
The audit should reject vanity metrics. Number of ROAs is useful but incomplete. Percentage of routed prefixes covered is useful but incomplete. Number of RIRs offering a feature is useful but incomplete. Resilience requires time-to-detect, time-to-correct, stale-data behavior, support path, holder contestability, delegated fallback, incident transparency and emergency authority.
The most serious metric is blast radius. If one registry makes a wrong RPKI decision, how far does the effect travel? If one NRO baseline contains a flawed assumption, how many regions inherit it? If one validator behavior is wrong, how many networks apply it? If one trust-anchor communication fails, how many relying parties are affected? If one legal theory freezes certificate changes, how many prefixes lose operational flexibility? A system that cannot answer blast-radius questions is not resilient enough.
The public should not have to infer the trust model
RPKI trust should be explained in public language. Not every operator is a PKI specialist. Not every lawyer understands ROAs. Not every court understands validators. Not every member board knows the difference between hosted and delegated service. A mature registry system should make the trust model legible without oversimplifying it.
The NRO's baseline documents are a good start. They compare service modes, object support, APIs, authentication and related features. The content repository links to portals, TAL information and CPS documents. The program page explains why consistency is a goal. The roadmap names target dates. Those materials make the system easier to inspect.
The missing layer is governance translation. Each RIR should publish a short public document that answers: what does our RPKI certificate prove; what does it not prove; who can request changes; how are roles verified; how do we handle transfers; how do we handle disputes; how do we handle account compromise; what happens during legal restraint; what happens during registry emergency; how can a holder get urgent review; how can a relying party report repository or TAL issues; how do hosted and delegated service differ in control?
This translation should avoid legal overclaiming. A certificate is proof of recognized resource-holding state and authorization relation, not a universal identity credential. A ROA is route-origin authorization, not a complete security guarantee. A valid route-origin result does not mean the path is safe. An invalid result can arise from misconfiguration as well as attack. RPKI improves routing evidence; it does not abolish operational judgment.
The public explanation should also avoid institutional underclaiming. If registry action can affect route-origin validity, the registry should say so. If a support delay can affect routing, say so. If delegated service reduces some dependence but not parent-trust dependence, say so. If a TAL change requires relying-party attention, say so. Users trust institutions more when limits are visible.
The language should be consistent but not empty. "Robust, coordinated and secure" is a mission statement. Operators need the nouns behind it: key, TAL, repository, ROA, manifest, account, role, log, incident, appeal, emergency contact, handback, audit. Governance becomes credible when those nouns are connected to decisions.
A better standard for the NRO program
The NRO should keep coordinating RPKI. The alternative is worse: five uneven services, avoidable confusion, weaker security controls and harder multi-region adoption. But coordination should be judged by a higher standard than feature alignment. The program should publish a failure-domain register.
The register would list each core RPKI function and classify its independence. Hosted ROA creation: regional portal plus common baseline. Delegated service: regional availability with parent trust. Trust-anchor configuration: regional TALs with joint consultation risk. Repository publication: regional infrastructure with relying-party global consumption. API management: regional implementation with common feature goal. Incident reporting: regional duty with common severity terms. Emergency continuity: joint support with regional authority. Legal restraint: regional law with global routing consequences.
Validator communication: shared ecosystem beyond RIR control.
For each function, the register should name the primary failure, secondary dependencies, holder mitigation, relying-party mitigation, public metric and review path. This would make resilience testable. It would also show where common standards reduce risk and where they concentrate risk.
The program should also publish a common incident taxonomy. A repository outage is not the same as a portal outage. A TAL notice failure is not the same as a wrong ROA. A stale transfer ROA is not the same as account compromise. A legal hold is not the same as technical failure. Operators need these distinctions because remediation differs.
Finally, the program should protect independent regional proofs. Each RIR should publish its own CPS, incident history, service metrics, delegated adoption, support commitments and local legal constraints. The NRO should aggregate without erasing. The point of five RIRs is not to display five emblems. It is to preserve enough regional independence that failure, learning and reform do not all happen in one closed room.
Sources and limits
This analysis relies on RFC 6480 for RPKI architecture, RFC 6490 for Trust Anchor Locator structure, the NRO RPKI Program page for joint program objectives, the NRO joint RPKI baseline documents and service overview for cross-RIR features, the NRO RPKI Content Repository for TAL and CPS references, and the NRO roadmap for target feature alignment. It also uses NRO governance materials only to frame emergency continuity and recognition context. The sources support the claim that RPKI is coordinated across the five RIRs and that service features vary.
They do not prove an actual common outage, a hidden trust-anchor decision, or unlawful concentration. The argument is a resilience standard: count failure domains, not logos.