RIPE NCC and the economics of ROA revocation risk

Summary

• ROA revocation risk is not only the risk that someone presses a delete button. It includes removal, replacement, expiry, certificate change, resource-set change, publication failure, hosted-to-delegated migration, delegated CA failure and uneven relying-party cache refresh.
• A route that was commercially accepted can become operationally rejected when the observed BGP announcement conflicts with the current ROA. The common triggers are an origin-AS change, a missing post-transfer ROA, an overly narrow maxLength, a certificate change or an emergency containment action.
• RIPE NCC's own RPKI material is useful as a factual exhibit: RPKI lets LIRs request resource certificates, ROAs state authorised origins and maximum prefix length, and BGP Origin Validation lets networks classify announcements as VALID, INVALID or UNKNOWN.
• The highest-value exhibit is the transfer and certification link. RIPE NCC documentation says that when a resource is moved or transferred, the listed organisation changes, the certificate changes, and underlying ROAs are removed and must be recreated. That is a built-in discontinuity risk.
• Hosted RPKI reduces engineering burden but concentrates continuity risk in RIPE NCC systems, account controls and portal/API authority. Delegated RPKI gives a holder more control but creates its own publication, manifest, CRL and long-term operability risks.
• The commercial shock is larger than packet loss. Invalid route rejection can stop a cloud BYOIP migration, cause an upstream filter refusal, extend a maintenance window, trigger customer SLA exposure, delay closing, increase escrow holdbacks and create lender haircuts.
• Account compromise matters, but it is only one narrow case. The more common economic problem is a legitimate change carried out in the wrong order, without enough notice, without rollback discipline or without a clear way to prove who should cure the defect.
• RIPE NCC should keep RPKI as reliable ledger/service infrastructure. It should not use route-origin status as a general lever over traffic, pricing, ownership, lending, transfer morality or private disputes.
• Guardrails should include pre-change visibility where feasible, high-consequence confirmation, clear event categories, cure clocks, emergency containment with minimal blast radius, independent escalation for severe cases, restoration language and durable logs.
• The right institutional bargain is stricter than "the market decides" and narrower than "the registry decides". Networks remain free to set routing policy; RIPE NCC must make the certification layer predictable enough that private acceptance decisions do not become a tax on uncertainty.

The rehearsal before the cutover

The continuity drill is scheduled for a Tuesday because nobody wants to discover the problem during the acquisition cutover itself. A European hosting company is buying a smaller network and intends to move a customer-facing /22 into its own AS, then later announce a /24 through a cloud provider's bring-your-own-IP service for a new region. The engineers have a route plan, a transfer timetable, a cloud ticket, letters of authority, customer notices and a maintenance window. They also have a line in the checklist that did not exist a decade ago: confirm that the ROAs will survive each stage of the move.

The first test fails quietly. The aggregate is still visible from the old origin AS. The planned new origin is accepted by one lab validator but marked INVALID by another route-checking view because the old ROA still authorises the seller's AS and no equivalent ROA has been created for the buyer. The cloud provider rejects the more-specific because the existing maxLength stops at /22. A transit desk asks for proof that the customer can authorise the new origin. One internal dashboard shows UNKNOWN because it is not seeing the covering ROA at all. The acquisition team had treated the ROA as a security line item. The routing desk now treats it as a closing condition.

The question is not whether RPKI is good or bad. The question is who bears the economic cost when ROA discontinuity turns accepted reachability into rejected reachability. A valid route can become invalid because a ROA is removed, not recreated after transfer, set with the wrong maxLength, tied to a certificate change, stranded during hosted-to-delegated migration, lost after an account error, or intentionally suspended during emergency containment. The party that pays may be the buyer, the seller, the cloud customer, the upstream, the lender, the enterprise user or a small access network that lacks staff for same-day repair.

This is a narrow issue, not a general theory of routing security. A ROA is a route-origin authorization, not a title deed. Route Origin Validation is a routing-policy input, not a court order. RIPE NCC does not push routes into the global table and should not be treated as traffic police. Yet the registry's certification layer now sits close enough to market reliance that a discontinuity can look like loss of asset quality. If a prefix cannot be cleanly authorised under the intended origin, counterparties price delay, demand warranties or refuse to proceed.

The point of a continuity drill is to expose that risk before money and customers are in motion. The point of governance is to ensure that the risk is not made worse by opaque authority. A registry that can alter certification evidence must be able to correct false authority, contain compromise and support transfers. It must also make its power bounded, predictable and auditable. Otherwise a security service becomes an unpriced veto.

Revocation is a chain, not a button

"ROA revocation" sounds like a single act. In practice the economic shock can come from many breaks in the chain. A holder may delete a ROA. A portal may replace it with a narrower one. A transfer may change the resource relationship and remove the old authorizations. A certificate may change because the covered resource set changes. A hosted CA may be revoked during a move to delegated RPKI. A delegated CA may stop publishing a usable manifest or CRL. A repository may have a publication problem. A relying-party cache may still hold the old view while another has already fetched the new one. The route becomes a moving target before the business team understands what has moved.

The distinction matters because each failure has a different cure. A wrong origin AS can be fixed by publishing an additional ROA or changing the route. A bad maxLength can be widened or the more-specific route can be withdrawn. A missing post-transfer ROA requires the new recognised holder to create the right authorizations after the certificate changes. A delegated CA failure may require the holder to repair its own publication point. A hosted CA revocation may require planned downtime or migration discipline. A suspected account compromise may require locking risky changes while preserving known-safe authorizations. Treating these as one undifferentiated "revocation" hides the operational owner of the repair.

RIPE NCC's RPKI page says the system lets LIRs request digital certificates listing the Internet number resources they hold. Its BGP Origin Validation page explains that ROAs state which AS may originate a prefix and what maximum length is allowed, and that other networks can set routing preferences based on validity. Those facts are enough to show why the discontinuity is serious. A change in the authorization layer changes what other networks believe they are seeing.

The official validity terms are also important. The RIPE page describes VALID, INVALID and UNKNOWN outcomes. In operational speech, UNKNOWN is often called NotFound or RPKI-unknown when no covering ROA is available. INVALID is sharper because it means the route conflicts with current authorization: wrong origin or a prefix more specific than maxLength permits. UNKNOWN is less severe in many routing policies, but it can still weaken commercial confidence when a previously valid route loses positive evidence.

The chain becomes economically visible when a counterparty has an automated rejection rule. A route server may suppress an INVALID route. A transit provider may refuse a customer prefix until the ROA aligns. A cloud platform may pause BYOIP onboarding. A security-sensitive enterprise may ask for a clean validation report before go-live. In each case the registry has not ordered a rejection. The market has attached consequences to the state of the certification chain.

For that reason, the governance question is not whether every ROA should be permanent. They should not. Incorrect authorizations should be removed; stale authorizations should be cleaned; emergency harm should be contained. The question is whether the process around removal, replacement and restoration is clear enough for the market to distinguish routine maintenance from a real loss of authority.

The certificate follows the resource, and the market follows the certificate

The most important factual exhibit for this topic is RIPE NCC's own explanation of what happens when a resource is moved or transferred. Its Using the RPKI system page says that when an Internet number resource is moved or transferred, the organisation listed in the RIPE Database changes, the certificate changes, and the underlying ROAs are removed and must be recreated. The sentence is technical; its economic effect is large. Transfer does not merely update a registry line. It can break the route-origin evidence that counterparties were relying on unless the new holder rebuilds it quickly and correctly.

That built-in discontinuity changes how transactions should be priced. A buyer of IPv4 space, or a buyer of a company whose revenue depends on that space, does not receive full operational continuity simply because the registered holder changes. It must receive the ability to publish correct ROAs under the intended origin ASes, test them, wait for relying-party propagation and coordinate the route change. If the transfer closes on Friday and the ROAs are rebuilt on Monday, the market may still treat the weekend as risk. If the cloud platform expected a /24 but the post-transfer ROA only covers the /22 with no appropriate maxLength, the buyer owns a clean record but not a clean route.

This is why ROA continuity belongs in deal mechanics. Closing conditions should ask whether pre-transfer and post-transfer routing states are mapped. Escrow terms should address who bears cost if the route becomes INVALID because the old ROA disappears before the new one is live. Customer notices should distinguish registry settlement from operational cutover. The seller should not be able to say simply that it delivered the resource; the buyer should not be able to assume that certification will follow automatically without work. The registry should not decide the price, but its process should be predictable enough that parties can write contracts around it.

The certificate also matters for lenders. A lender financing a network purchase may not understand RPKI in detail, but it will understand continuity evidence. If the borrower's revenue depends on prefixes that could fail validation during transfer, the lender asks for covenants, reserves or haircuts. If the borrower can show rehearsed ROA recreation, validator checks, cloud acceptance and rollback procedures, the discount falls. The certificate chain becomes one input into credit quality because it affects whether address-dependent revenue is durable.

The same logic applies to insurance and customer contracts. A customer with service-level commitments does not care whether the failure began as a ROA removal, certificate reissuance or cache timing problem. It cares whether service was reachable. A managed service provider that announces customer space through its own AS needs explicit authority and a plan for how ROAs change when the account or holder changes. Without that plan, the holder and provider are left arguing under pressure while validators and filters execute their current view.

RIPE NCC should not become guarantor of these private arrangements. Its role is narrower: publish clear technical semantics, make transfer-triggered ROA removal easy to anticipate, preserve logs, support timely post-transfer recreation and make unusual certification events visible enough that counterparties do not confuse routine resource movement with institutional punishment. The certificate follows the resource. The market now follows the certificate.

INVALID is an outage risk; UNKNOWN is a confidence risk

INVALID and UNKNOWN are different states, and the distinction should not be blurred. An INVALID route says that a covering ROA exists but the observed BGP announcement conflicts with it. The origin AS may be wrong. The prefix may be longer than the allowed maximum. The route may be a hijack. It may also be a legitimate migration performed in the wrong order. The status is blunt because it is designed to be machine-readable. It does not explain motive.

That bluntness is useful in security and costly in commerce. A network that rejects INVALID routes can reduce exposure to mistaken or malicious origin announcements. But the same policy can turn a clerical or sequencing error into immediate unreachability. If a cloud platform announces a customer's /24 while the holder's ROA only authorises the /22, rejection can appear at the moment the customer expects a migration to complete. If an upstream changes origin before the holder has added the new AS, the route can fail exactly when the old path is being drained. If a post-transfer certificate removes the old ROAs and the new holder is not ready, validation can become a transaction trap.

UNKNOWN, or NotFound in common operator language, is less direct. Many networks still accept routes without ROAs. But a Valid-to-UNKNOWN change is not commercially neutral. It removes positive evidence that a route had been authorised. In a low-risk context that may be acceptable. In a cloud onboarding, public-sector service, regulated enterprise migration or acquisition diligence file, it can trigger questions. Why did a mature holder lose its ROA? Is the certificate broken? Was there a transfer? Is a dispute pending? Did a delegated CA fail? Is this an intended security downgrade or an operational accident?

The price of those questions is delay. A carrier may open a manual review. A cloud provider may ask for an updated ROA and a fresh route check. A buyer may refuse to release escrow until the validation state is stable. A customer may delay traffic movement. A lender may reserve against uncertain address continuity. None of these counterparties needs RIPE NCC to make a policy decision. They are reacting to a weak or conflicting signal.

This is where maxLength becomes an economic term, not merely an RPKI field. A narrow maxLength can prevent more-specific misuse and is often prudent. A broader maxLength can preserve operational flexibility for traffic engineering, DDoS mitigation or cloud deployment. The wrong choice can either leave too much authority in circulation or block a legitimate route. The cost of that choice rises when the prefix supports revenue. A /24 used for emergency mitigation may look like a minor technical exception until the ROA blocks it during an attack window.

The cure is not to make every ROA broad or permanent. It is to make intended routing explicit and tested. Holders should know which ASes will originate which prefixes under normal, migration and emergency conditions. Upstreams and clouds should test validation before maintenance windows. RIPE NCC should make the status semantics and change paths legible. INVALID should mean conflict, not mystery. UNKNOWN should mean absence of covering authorization, not a hidden story about why the authorization disappeared.

Hosted RPKI lowers burden and concentrates dependence

Hosted RPKI is attractive because it removes much of the cryptographic burden from the holder. RIPE NCC operates the certification environment, handles key operations and publication, and gives members a portal and API for ROA control. For many networks, especially small and medium-sized holders, this is the difference between usable RPKI and no RPKI at all. A security system that only large operators can run safely would be economically regressive.

Convenience, however, concentrates dependence. In the hosted model, portal access, account authority, API credentials, internal controls, service availability and RIPE NCC's certification platform become part of route-origin continuity. If the account is compromised, a bad ROA can be created. If the account is locked during an authority dispute, a good ROA may be hard to change. If a transfer changes the certificate, the new holder must be able to rebuild the required authorizations. If a hosted CA is revoked during a move to delegated RPKI, a continuity gap can appear unless the migration is planned.

RIPE NCC's Hosted Certification Authority page states that the certificate is automatically updated when resources change, including allocation, transfer in or out, or return. It also states that if resources are removed for which current ROA configurations exist, published ROAs will be updated automatically. The same page says that revoking the hosted CA deletes and removes the CA entirely, including ROA configurations and history, and that a make-before-break migration to delegated CA is currently not possible. These are not policy slogans. They are operational facts with balance-sheet effects.

A make-before-break gap matters because markets hate uncontrolled discontinuity. A sophisticated holder may schedule the hosted CA revocation, create the delegated CA, publish the new material, monitor validators and hold routes steady until the new state is visible. A smaller holder may misunderstand the sequence. A deal team may assume that "moving to delegated" is merely a preference change. A cloud onboarding team may see only that validation changed. A lender may learn too late that the holder's evidence trail was removed when the CA was revoked. The risk is not that hosted RPKI is bad; it is that hosted convenience can hide the sharp edge of discontinuity.

This also affects audit. If a ROA disappears, counterparties need to know whether the event was a holder deletion, automatic update after resource removal, hosted CA revocation, account recovery, platform incident or registry action. Each category carries a different inference. A holder-requested change may be ordinary. An automatic update after transfer may be expected. A registry-initiated emergency lock may need review. A platform incident may require service reporting. Without event categories, the market fills the gap with suspicion.

RIPE NCC's proper response is not to micromanage routing policy. It is to make hosted RPKI safer as a dependence layer: strong account controls, high-consequence confirmation for destructive actions, clear warnings for hosted CA revocation, exportable pre-change snapshots, logs visible to authorised account holders, and restoration procedures when a mistake is identified. The more hosted RPKI becomes the default for ordinary networks, the more its discontinuity semantics become market infrastructure.

Delegated RPKI gives control and creates another failure mode

Delegated RPKI solves one problem by creating a different one. In the delegated model, the holder operates its own CA software and can choose where to publish its certificate and ROAs. RIPE NCC's Using the RPKI system page describes this as giving the holder control over the resource certificate and private key, and the ability to choose publication arrangements. That control is valuable for large operators, security-conscious networks and holders that want operational independence from the hosted platform.

Control does not eliminate dependence. The delegated CA still has to interoperate with the RIPE NCC parent system. It has to publish usable material. Its manifest and CRL have to validate. Its repository has to be reachable by relying parties. Its keys and software have to be maintained through staff changes, acquisitions, insolvency events and emergency incidents. If the delegated CA goes stale, the holder's theoretical autonomy becomes an operational liability. A route can lose clean validation not because RIPE NCC made a broad discretionary decision, but because the holder's own publication chain stopped working.

The accepted 2025-02 implementation makes this tension explicit. RIPE NCC's Policy Implementation Status page says the Routing Working Group accepted a proposal on 15 October 2025 giving RIPE NCC a mandate to revoke resource certificates associated with long-time non-functional delegated CAs to reduce relying-party workloads. It says updated certification service terms were published on 6 May 2026 and came into effect on 8 June 2026. After that, RIPE NCC says it will monitor and notify delegated CA operators if their current manifest and CRL cannot be validated and when the delegation is revoked after being non-functional for 90 days.

That is a sensible factual case to discuss because it is neither arbitrary nor trivial. Relying parties should not carry endless broken delegated branches. A dead delegated CA imposes costs on validators and weakens the cleanliness of the system. At the same time, revocation after non-functionality can have route-origin consequences for the holder and its customers. The 90-day clock, notice and category of non-functionality are therefore not administrative decoration. They are the guardrail that separates infrastructure hygiene from sudden market shock.

The market question is how these revocations are seen outside the certification team. If a delegated CA is revoked after clear notice and long non-functionality, counterparties should not interpret the event as an ownership judgement or sanction. It is a technical continuity failure. If a holder repairs the CA or moves back to hosted service, the restoration path should be clear. If the holder claims it never received notice, the audit trail should be strong enough to resolve that claim. If downstream customers were using routes under the affected resources, they need language that explains the technical cause without inflaming private disputes.

Delegated RPKI therefore requires a stricter operational constitution than hosted RPKI, not a looser one. Autonomy means the holder bears more engineering burden. RIPE NCC bears the burden of precise thresholds, notices, escalation and revocation records. Validators and networks remain free to decide how to route. The certification layer should tell the truth about functionality without becoming a discretionary tool for judging the holder's business.

Transfers expose the hidden timing problem

Transfers are where ROA discontinuity becomes easiest to price. RIPE NCC's transfer page says it authorises and facilitates transfers of Internet number resources, and that a transfer changes holdership from one party to another. That change may be legally and administratively complete before routing acceptance is commercially complete. The gap between those two forms of completion is the timing problem.

In a clean transfer, the seller and buyer map the route state before the registry action. They list current ROAs, current origins, intended origins, cloud origins, emergency mitigation origins, maxLength requirements, dependent customer routes and monitoring views. They decide which old authorizations should survive until cutover and which should be removed. They build the post-transfer ROAs as soon as the certificate permits. They test validation through multiple relying-party views. They coordinate upstream filter updates. They tell customers that the resource transfer and the routing cutover are related but not identical.

In a weak transfer, the registry record changes and the ROA plan is discovered afterward. The seller no longer has authority or incentive to manage old authorizations. The buyer has not created the new ones. The cloud platform cannot proceed. An upstream sees INVALID or UNKNOWN. The route may still work through permissive networks, which creates a dangerous ambiguity: some customers are reachable, some are not, and nobody can prove that the cutover is safe. The commercial problem is not that the transfer was invalid. It is that the routing evidence did not move with the deal.

Escrow is the natural market response. A buyer may hold back part of the price until post-transfer ROAs are live and accepted by agreed counterparties. A seller may demand rapid release once it has done everything the registry required. A lender may require a post-closing validation certificate from the borrower, not from RIPE NCC but from the borrower's technical advisers. A cloud provider may refuse to schedule BYOIP until it sees the new holder's authorization. A customer may require a second maintenance window because the first is spent waiting for propagation.

This is not a reason for RIPE NCC to supervise price or deal terms. It is a reason for RIPE NCC to publish clear transfer-and-RPKI semantics and for market actors to use them. If underlying ROAs are removed and must be recreated after certain moves, the notice should be impossible to miss. If automatic updates occur when resources are removed, holders should know what that means for live routes. If make-before-break is not possible in a hosted-to-delegated move, the risk should be explicit before a buyer makes it part of a closing plan.

Transfers also create moral hazard if revocation authority is unclear. A seller might delay cooperation to gain leverage. A buyer might accuse a seller of creating invalidity to justify holdback. An upstream might refuse routes because it does not understand the transition. A registry might be pulled into private disagreement because its certification records are the most visible trigger. Clear guardrails reduce that hazard by separating registry facts from commercial blame.

Clouds and upstreams turn certification state into market access

RIPE NCC does not decide whether a cloud provider accepts a BYOIP request or whether an upstream rejects an invalid route. That discretion sits with the network or platform. Yet the registry's RPKI data feeds those private decisions. This is the institutional-economics point: a narrow technical state can become a market-access condition when enough counterparties rely on it.

Cloud BYOIP is the clearest example. A customer bringing its own range into a cloud region often has to prove control of the prefix, align routing records, provide letters of authority and ensure that ROAs permit the cloud AS to originate the relevant prefix. If the customer wants to announce a /24 inside a larger allocation and the ROA maxLength does not permit it, the project can stop. If a transfer removed the old ROA and the new one has not been created, the cloud platform sees an incomplete or conflicting file. If a delegated CA failure turns a formerly valid route into UNKNOWN, the cloud's risk team may ask for repair before onboarding.

Upstreams create a different form of pressure. A provider that enforces route-origin validation may drop INVALID routes. A provider that does not drop them may still use the state as an escalation trigger. A route server may have a published policy that suppresses invalid announcements. A DDoS mitigation provider may need an emergency origin authorized before it can absorb traffic. These policies are privately chosen, but they are not optional for the customer that needs the route to work. The customer's bargaining position depends on whether the certification state is clean.

This turns maintenance windows into financial windows. A bad ROA sequence can make a two-hour migration into a weekend outage. Engineers may wait for cache refreshes across multiple relying-party systems. Sales teams may have to explain why service acceptance varies by network. Customer support may face complaints that cannot be reproduced from every vantage point. The postmortem may conclude that no single institution "caused" the outage, yet the economic loss is real.

For small networks, the burden is especially high. A large carrier can run pre-flight checks, query multiple validators, maintain RPKI staff and negotiate directly with clouds and upstreams. A regional ISP, university network or local hosting company may have one engineer who manages BGP, procurement, customers and the registry portal. The same validation rule that looks efficient at scale can become a fixed compliance tax for smaller holders. If RIPE NCC's status language is vague, that small holder pays more because it must translate the event for every counterparty.

Private rejection of invalids is not a flaw in itself. It is the point of route-origin validation. The flaw would be allowing the upstream consequences to grow while the upstream cause remains obscure. RIPE NCC can help by making certification events machine-readable and human-readable: planned holder action, transfer-induced removal, hosted CA revocation, delegated CA non-functionality, emergency containment, account recovery, service incident or correction. The network still decides whether to route. The market gets a better explanation of what it is deciding on.

Notice and cure are economic controls

Notice is often treated as a legal courtesy. In ROA continuity it is an economic control. The cost of a bad change often comes from surprise rather than from the change itself. If a holder knows that a transfer will remove ROAs, it can schedule recreation. If a delegated CA operator knows that a manifest and CRL have not validated for a defined period, it can repair the CA or move to hosted service. If a cloud migration team knows the maxLength is too narrow, it can change the ROA before the first route is announced. If an account appears compromised, the holder can agree which existing authorizations should be preserved while risky changes are frozen.

Cure is the paired control. A system that can only punish error is too brittle for production networks. Many defects are curable: stale contact authority, wrong origin AS, missing maxLength, post-transfer sequencing, expired operational knowledge, delegated publication failure, incomplete cloud origin plan or mistaken deletion. A cure path should tell the holder what evidence is needed, who can submit it, what clock applies, what state will be preserved during review and when escalation begins. Without that path, ordinary defects become asset freezes.

The design problem is consequence tiering. Not every ROA change deserves the same process. A routine holder-created ROA for a new origin may need normal account authentication and logging. A destructive hosted CA revocation should require clearer confirmation and pre-change warnings. A maxLength tightening that could invalidate current more-specifics should show live-route impact before acceptance. A transfer-induced removal should be part of the transfer checklist. A delegated CA revocation after 90 days of non-functionality should have notice evidence. Emergency containment after suspected compromise should be fast but narrow and time-bounded.

Notice and cure should also distinguish the parties involved. The current holder may not be the current origin. A managed provider may originate on behalf of the holder. A cloud platform may need future origin authorization. A buyer may become holder only after the transfer. A lender may have a covenant but no technical role. RIPE NCC cannot notify every customer on the Internet, and it should not try. It can, however, define which account contacts and technical contacts receive which category of certification notice, and it can give holders a way to add operational contacts for high-consequence RPKI events.

The cure path must avoid two mistakes. One is letting bad authorizations persist indefinitely because interruption would be costly. False authority and active harm must be contained. The other is treating every defect as proof of illegitimacy. A wrong maxLength is often a planning error. A delegated CA failure may be staff turnover. A missing post-transfer ROA may be sequencing. A compromised account may be unrelated to the holder's right to use the resource. The response should fit the category.

Markets price procedure. If a buyer knows there is a clear cure clock for RPKI defects, it can write a narrower escrow term. If a lender knows high-consequence revocations are logged and reviewable, it can reduce uncertainty. If a customer knows validation repair has a defined path, it may tolerate a short maintenance risk. Notice and cure are not bureaucratic ornaments. They are the cheapest way to prevent a security mechanism from becoming a commercial shock.

Emergency authority must isolate the blast radius

Emergency authority is necessary. A compromised account can publish a malicious ROA. A false authorization can make a hijack look legitimate to networks that use route-origin validation. A delegated CA could be broken in a way that burdens relying parties. A legal constraint or clear evidence of false resource authority may require fast action. A registry that cannot act in these cases would make RPKI less trustworthy, not more.

The danger is that emergency language can become too elastic. If every dispute, unpaid invoice, transfer disagreement, policy irritation or suspicious change becomes an emergency, certification power turns into leverage. The institutional line should be narrow: emergency RPKI action is for route-origin harm, account compromise, certificate integrity, repository integrity, delegated CA non-functionality, demonstrable false authority or immediate legal constraint affecting the certification service. It is not a general method for traffic control, price discipline, private bargaining or capital movement.

Blast-radius control is the practical rule. If one suspicious ROA is new, disable or reverse that ROA rather than disrupting unrelated authorizations where possible. If an account is compromised, freeze high-risk changes while preserving last-known safe routes unless those routes are themselves harmful. If a delegated CA fails validation for a long period, follow the published clock and communicate the category rather than leaving counterparties to infer misconduct. If a resource-set change removes coverage, make the consequence visible before the change is treated as routine. The aim is to contain the harm without using customers as collateral.

Time bounding is equally important. An emergency lock that has no review clock becomes indefinite uncertainty. A temporary suspension that quietly becomes final revocation invites market discounts. A holder, buyer or upstream needs to know when the state will be reviewed, what evidence can change it and who can escalate if the first decision is wrong. The more severe the route-origin effect, the stronger the escalation path should be.

Reversal language matters because mistakes happen. A monitoring alert may be wrong. A legitimate emergency origin may look suspicious. A transfer file may be misunderstood. A customer route may be more-specific for an operational reason. A court order may be clarified. If a ROA or CA state is restored, the explanation should tell counterparties that restoration is deliberate and not a transient artifact. Otherwise the repaired route remains commercially contaminated.

Independent escalation should be reserved for high-consequence cases. It need not be slow or judicial. It can be a separate technical and policy review inside the institution, with a written event category and a decision trail. The point is not to ask RIPE NCC to settle every private dispute. It is to discipline the moment when certification power affects live routes and market reliance. Emergency authority should strengthen trust by proving that the tool is narrow. If the tool looks discretionary, every emergency becomes a precedent to be priced.

Account compromise is real but should not dominate the frame

Account compromise is the easiest version of ROA revocation risk to explain. A bad actor gains access to a registry portal or API credential, changes ROAs, authorises a wrong origin, deletes a valid authorization or widens maxLength to permit more-specific misuse. The harm can be fast, measurable and serious. Strong authentication, role separation, API token controls, high-risk change confirmation, alerting and rollback records are therefore basic requirements.

But compromise should not dominate the frame. The more common economic problem may be legitimate authority exercised in the wrong sequence. An acquisition team fails to recreate ROAs after transfer. A cloud project announces before authorization. A holder moves from hosted to delegated RPKI without planning the gap. A delegated CA stops publishing correctly after the engineer responsible leaves. A maxLength change is treated as cleanup but invalidates a backup path. A registry action meant to correct resource status has broader routing consequences than expected. None of these requires a criminal actor.

That distinction matters for controls. Security controls around compromise focus on preventing unauthorised change. Continuity controls focus on making authorised change safe. A system can have excellent login security and still create economic shock if destructive changes are easy to perform without impact preview. A system can have strong certificate practices and still fail the market if transfer-triggered ROA removal is not included in transaction planning. A system can catch suspicious changes and still harm customers if it freezes all authorizations rather than isolating the risky one.

The account model should therefore support roles. A finance contact should not have casual ability to perform high-consequence RPKI changes. A routing engineer may need ROA authority without full corporate update authority. A managed provider may need delegated ability to propose or maintain specific ROAs while the holder keeps ultimate control. A buyer in a pending transaction may need read-only access to the current ROA plan before closing. A lender may need evidence that controls exist but not the power to change routes. Crude all-or-nothing access makes both compromise and continuity worse.

Audit logs are the bridge. If a ROA was deleted, the holder should be able to see when, by which authorised role, under what account path and with what confirmation. If the deletion was automatic because the resource changed, the log should say so. If the event was registry-initiated under a published category, the log should identify that category. If the action was reversed, the reversal should be visible. Without logs, every disputed change becomes a contest of memory.

Framing the risk too narrowly as compromise also creates moral hazard. A registry might overuse security language for broader control. A holder might blame compromise for bad change planning. A counterparty might treat every invalid route as evidence of fraud. A mature system avoids all three by classifying events precisely. Compromise is one narrow risk. Discontinuity is the wider market problem.

Auditability is the boundary between service and discretion

Auditability is not the same as public exposure of every sensitive detail. It means that authorised parties, and where appropriate the wider community, can understand the category, timing, authority and effect of certification changes. A ROA deletion should not vanish into a portal history known only to one engineer. A delegated CA revocation should not be legible only to the person who read a policy page months earlier. A transfer-triggered ROA removal should not surprise a buyer during a maintenance window. Auditability turns route-origin power from discretion into service.

There are several layers. The first is holder-level logs: who changed which ROA, what prefix and origin were affected, what maxLength changed, what certificate event occurred, when the repository published the result and whether the action was holder-requested, automatic, emergency or registry-initiated. The second is account-level controls: which roles were authorised to perform destructive changes, whether multi-factor controls were active and whether high-consequence confirmation was used. The third is service-level reporting: whether RIPE NCC had an RPKI incident, repository issue, portal problem or delegated CA monitoring action. The fourth is policy-level evidence: whether published clocks and notices were followed.

None of this requires RIPE NCC to command routing decisions. Networks can still reject INVALID routes, accept UNKNOWN routes, set local preference, build exceptions or ignore RPKI in defined contexts. Auditability does not centralise routing. It tells the market what happened in the certification layer so private routing decisions are based on clearer evidence. That is the difference between infrastructure and control.

The audit boundary also protects RIPE NCC. A registry that can show event category, notice, cure, escalation and restoration is less vulnerable to claims that it acted arbitrarily. A registry that cannot show those facts invites every affected holder to describe a technical change as political, commercial or punitive. The more valuable IPv4 becomes, the more likely such claims become. Auditability is not a concession to critics. It is institutional risk control.

The boundary should be especially clear for high-consequence revocation. A published category such as delegated CA non-functionality is different from suspected account compromise. A holder-requested hosted CA revocation is different from a registry-initiated certificate action. A transfer-triggered removal is different from a correction of false authority. The same route may become unreachable in each case, but the legitimacy standard and cure path differ. Markets need the distinction because they price recurrence risk.

Auditability should be durable. M&A diligence may occur months after a ROA event. A lender may review a route history after refinancing. A customer may investigate an outage after the maintenance window has closed. If destructive changes erase history, or if history is visible only while an account remains in a certain state, the evidence file weakens. Durable logs, exportable reports and clear event labels let the certification layer support market trust without pretending to be a title registry.

Small networks pay the fixed cost

ROA continuity is easier for large networks to absorb. They have routing specialists, automation, counsel, compliance staff, relationships with clouds and transit providers, and monitoring across multiple validators. A large carrier can rehearse a transfer, stage ROA changes, contact RIPE NCC support, push upstream exceptions and explain validation states to customers. For a small network, the same event may land on one engineer and a director who barely speaks the same technical language.

The fixed cost appears in evidence collection. The holder must know current ROAs, origins, maxLength settings, intended future origins, delegated publication status, hosted CA state, contact roles, account credentials, upstream filtering rules and customer dependencies. It must know which validators and route monitors to trust. It must communicate with a cloud platform that may have its own acceptance language. It must answer a lender or buyer that wants evidence but does not understand how RPKI works. The burden is not simply technical; it is translation.

RIPE NCC's service region makes that burden uneven. It includes global carriers and tiny access providers, mature cloud markets and developing connectivity corridors, sanctioned jurisdictions and ordinary commercial markets, universities, hosting firms, public networks and legacy holders. A single ROA interface must serve actors with very different resources. If the process assumes that everyone has a dedicated routing-security team, smaller networks pay in delay, consultant fees and lost bargaining power.

The market can respond harshly. A buyer may demand a discount because the seller's ROA history is poorly documented. A lender may treat a small network's address-dependent revenue as fragile because the evidence file is thin. A cloud provider may require manual escalation that a large customer can navigate but a small one cannot. An upstream may refuse an exception because the holder cannot produce the expected proof quickly. The route may be technically repairable, but the commercial moment is missed.

Good design lowers fixed costs without weakening security. Impact previews can show which live routes would become INVALID before a ROA is changed. Plain event categories can tell a holder whether the issue is maxLength, origin AS, certificate change, delegated publication or transfer sequencing. Templates can help holders document current and intended routes before transactions. APIs can let larger networks automate checks without forcing smaller networks into bespoke scripts. Support materials can explain UNKNOWN and INVALID in commercial language without overstating what RIPE NCC guarantees.

Small-network burden is also a fairness issue. If route-origin assurance becomes necessary for market acceptance, then the cost of using it should not become an entry barrier. RPKI was meant to make origin evidence cheaper and more trustworthy. If opaque revocation or discontinuity processes force small holders into private intermediaries merely to remain acceptable, the system has moved backward. RIPE NCC's strongest contribution is not broader authority. It is clearer service.

Counterparties should ask narrower questions

Buyers, lenders, clouds and upstreams often ask the wrong broad question: is the block "clean"? The better question is narrower: what route-origin state is required for the intended use, and what could cause that state to disappear? Cleanliness is too vague. A resource can have a current registry holder and still lack the ROAs needed for a cloud origin. It can have valid ROAs for current routes and still be at risk during transfer. It can use delegated RPKI and still have a stale publication chain. It can be UNKNOWN and still route acceptably in some networks, while failing a platform's acceptance rule.

Before an acquisition, the diligence file should list current prefixes, origin ASes, ROAs, maxLength values, hosted or delegated mode, certificate status, delegated publication health if applicable, planned post-close origins, cloud or mitigation origins, upstream filter dependencies and prior validation incidents. It should identify which changes occur automatically when resources move and which must be performed manually. It should include a rehearsal date, not merely a closing date.

Before a cloud BYOIP migration, the platform and customer should confirm the exact prefix length to be announced, the origin AS, the required maxLength, whether the prefix is currently covered by another ROA, whether any old origin remains authorised for backup service and whether transfer or account changes are pending. If the platform rejects INVALIDs, that rule should be clear before the customer changes traffic. If UNKNOWN is acceptable only temporarily, the duration should be stated.

Before lending against address-dependent revenue, the lender should ask whether the borrower can maintain route-origin authorizations under ordinary, emergency and transfer scenarios. It should not ask RIPE NCC to guarantee value. It should ask the borrower for evidence of control, logs, roles, monitoring and continuity procedures. The lender's haircut should reflect the borrower's operational discipline, not merely the registry region.

Before an upstream accepts a new customer route, it should distinguish current validation conflict from absence of RPKI. An INVALID route needs repair or a conscious exception. An UNKNOWN route may be acceptable under policy but may still need explanation if the customer promised RPKI alignment. If a route was valid yesterday and UNKNOWN today, the provider should ask what changed. A narrow question produces a narrower cost.

These questions protect RIPE NCC's boundary as well. The more precise counterparties become, the less they ask the registry to settle private business meaning. The registry can state certificate and ROA facts. The parties can allocate commercial risk. Networks can set routing policy. Customers can decide whether continuity evidence is sufficient. Narrow questions keep a powerful technical signal from becoming a vague instrument of market exclusion.

The institutional bargain for RIPE NCC

The institutional bargain is simple to state and hard to execute. RIPE NCC should provide reliable ledger/service infrastructure for RPKI: stable certificates where the resource relationship supports them, predictable ROA management, clear transfer effects, hosted and delegated continuity, strong account controls, accurate status language, notice where feasible, cure paths, emergency containment, escalation and logs. It should not become the owner of address value, insurer of routeability, traffic police, price controller, private court or capital-control authority.

This bargain respects both sides of the system. RPKI is valuable because it lets networks reduce origin uncertainty. A weak or timid certification service would harm the Internet. False authority must be removed. Broken delegated CAs cannot be ignored forever. Compromised accounts must be contained. Transfers must update certificates. Holders must maintain ROAs that match intended routing. Networks must remain free to reject invalid routes. Security requires real authority.

But security authority must be bounded because it sits close to economic value. A route-origin change can affect cloud admission, upstream acceptance, customer uptime, acquisition closing, escrow release and credit terms. The cost can fall on people far from the holder's registry account. The more the market relies on RPKI, the more important it becomes that certification events are explainable and reviewable. Otherwise security power begins to look like discretionary market power.

The answer is not to weaken RPKI or to tell networks to ignore invalids. It is to harden procedure around discontinuity. Destructive actions should have impact previews. Transfer pages should treat ROA recreation as operational settlement. Hosted-to-delegated migration should carry explicit continuity warnings. Delegated CA revocation should remain tied to published non-functionality thresholds and notice evidence. Emergency containment should isolate the risky authorization where possible. Restoration should be visible. Logs should survive the event.

The same bargain requires humility from private counterparties. A cloud provider should not treat every UNKNOWN route as proof of illegitimacy. A lender should not mistake a ROA for title. An upstream should not use a vague validation issue as a commercial bargaining tool. A buyer should not assume that registry transfer equals route readiness. Markets need RPKI evidence, but they also need to understand its competence.

RIPE NCC is well placed to hold this line precisely because its role is not to decide every downstream use. It can publish the facts, operate the service, classify events and support correction. It can refuse invitations to convert RPKI into a wider economic veto. That is the disciplined middle path: stronger route-origin assurance, lower uncertainty, fewer accidental shocks, and no conversion of a security service into a private adjudication system.

The route should not become collateral

The final test is customer continuity. A prefix is rarely just a tradable entry in a registry file. It supports payment systems, VPNs, hosting customers, public services, access networks, monitoring allowlists, mail flows, health portals, education platforms and ordinary businesses that do not know what a ROA is. When route-origin authorization changes abruptly, those dependencies may suffer before the named holder has finished arguing with a registry, seller, buyer, upstream or cloud provider.

That does not mean bad authorizations should be preserved for customer convenience. A false ROA that supports an active hijack must be removed. A compromised account must be contained. A non-functional delegated CA cannot be allowed to impose cost indefinitely. But continuity should be the default design question. What is the last verified safe state? Can the risky new authorization be isolated? Can existing valid routes continue while a disputed change is reviewed? Can notice be given before a maxLength tightening invalidates current traffic engineering? Can a transfer checklist prevent a post-close gap?

Customer continuity also clarifies what RIPE NCC is not. It is not a universal service guarantor. It cannot know every downstream dependency, and it cannot order every network to accept a route. It should not become a forum for SLA disputes. Its responsibility is narrower and more practical: do not let certification semantics be needlessly obscure, do not make destructive transitions surprising, do not allow emergency categories to sprawl, and do not leave affected holders without a cure path when the defect is curable.

The economics are cold. If counterparties fear that a ROA can disappear without a bounded explanation, they price the fear. Buyers delay. Lenders discount. Clouds require more documentation. Upstreams insist on manual exceptions. Customers demand indemnities. Small networks pay consultants. The registry may insist that it has only operated a technical service, but the market will have treated the service as a risk layer.

The better outcome is also cold. If ROA discontinuity is anticipated, classified, reversible where possible and logged, market actors can allocate risk precisely. A transfer holdback can be limited to post-close validation. A cloud migration can schedule the ROA change before BGP. A lender can check continuity rather than guessing. An upstream can distinguish invalidity caused by a migration error from a suspected hijack. A holder can fix a maxLength mistake without turning it into a dispute over legitimacy.

RPKI's promise is not that every route becomes safe. It is that one crucial form of uncertainty becomes cheaper to verify. ROA revocation risk is the shadow of that promise: the same system that creates trust can remove or interrupt the evidence on which trust rests. RIPE NCC's task is to keep that shadow small. It should operate the certification layer as infrastructure: precise, conservative, auditable and resistant to mission creep. The route should not become collateral for ambiguity.