AFRINIC and the economics of ROA revocation risk

The morning a prefix stops looking routine

The first alarm does not say that a registry has revoked anything. It says that a customer prefix is behaving differently depending on where the route is seen. A network operations centre in Nairobi sees a transit session accepting an AFRINIC-administered /22 from the customer's long-standing origin AS. A cloud onboarding team in Johannesburg sees the same customer asking to move the block into a bring-your-own-IP programme. A route collector in Europe still shows the route. An IXP route server now marks a more-specific announcement as outside the expected authorisation. A managed security provider sees a sudden rise in route-origin warnings. The customer's ticket is not written in the vocabulary of institutional law. It says that some paths work, some paths do not, and nobody can tell whether the change is a mistake, a planned migration, a registry publication problem or the first sign of a dispute.

Within an hour the vocabulary broadens. The transit provider asks for a current Route Origin Authorization. The cloud platform asks why the ROA covers the aggregate but not the more-specific it expects to announce. The customer's old provider says it still has a valid route for backup service. A validator report from one region shows the route as Invalid because the origin AS no longer matches the current ROA. Another monitoring system reports NotFound because its cache has not yet fetched the replacement ROA. A third system still has the old view because its relying-party cache has not aged out. The customer's business team asks whether this is a routing problem or an asset problem. The answer is both, and that is precisely why ROA revocation risk matters.

Nothing in this scene requires a malicious hijack. The sequence could begin with a member withdrawing a ROA too early during a cloud migration. It could begin with a maxLength edit that permits a /24 but accidentally leaves a /25 used for traffic engineering outside the authorised range. It could begin with a certificate or repository publication failure that makes previously valid ROAs disappear from some validators' usable view. It could begin with an administrative lock on a member account during a dispute. It could begin with a lawful correction of false authority. It could begin with simple expiry after nobody noticed that a signing process had failed. Before the cause is known, the economic result can look similar: counterparties begin to treat the address block as less reliable.

AFRINIC makes the scene sharper because the registry is not an abstract trust anchor in a quiet institutional environment. Public reporting has described a long crisis involving address-record integrity concerns, the Cloud Innovation dispute, bank-account freezes, receivership, board discontinuity, election annulment, later board restoration and continued litigation. The point is not that every AFRINIC resource is suspect. The point is that registry-controlled proof becomes economically charged when the registry's legitimacy has been visibly stressed. A ROA is technically narrow, but it is read by transit providers, cloud platforms, IXPs, buyers, auditors and customers as part of a broader reliance file.

In the exhausted IPv4 market, the real loss from a bad ROA event is not only packet loss. It is the loss of predictable acceptance. A prefix that cannot be cleanly validated may still be reachable through permissive networks, but it becomes harder to sell, lease, migrate, finance, insure, procure around or defend in a customer continuity review. A disputed validation state becomes a price signal. It tells counterparties that extra diligence is needed before the asset can be treated as ordinary infrastructure.

That is the institutional-economics problem. RPKI was designed to reduce route-origin uncertainty. ROAs help networks avoid accepting routes that do not match current authorisations. Route Origin Validation gives operators a simple language for risk. But any security system that becomes a condition of market access must also be judged by its correction process. When publication changes, who receives notice? When the change is wrong, who can cure it? When emergency action is required, how is it bounded? When a registry decision affects live routes, how is appeal made meaningful without turning every ticket into litigation? These questions are part of the cost of using scarce address resources.

The economics are more precise than a slogan about registry power. ROA revocation risk is the possibility that a change in route-origin authorisation, certificate validity, repository publication or validator propagation will cause networks and counterparties to downgrade, reject or delay reliance on a prefix before the affected holder has had a fair chance to understand and cure the problem. That risk is not a reason to weaken RPKI. It is a reason to make the authority behind RPKI narrow, documented, reversible where possible and resilient under institutional stress.

What ROA revocation risk actually means

The phrase "ROA revocation" is convenient, but it can mislead if it suggests a single legal act with one trigger and one consequence. A Route Origin Authorization is a signed routing authorisation in the RPKI system that authorises a specified autonomous system to originate a specified IP prefix, normally with an optional maximum prefix length. Route Origin Validation then compares a received BGP announcement with the set of currently usable ROAs. The validation outcome is commonly described as Valid, Invalid or NotFound. Valid means a matching authorisation exists. Invalid means a ROA exists for the relevant resource but the announcement conflicts with its origin AS or prefix-length limits. NotFound means the validator has no relevant ROA for the prefix.

ROA revocation risk, in the operational sense used here, covers several different mechanisms. The first is explicit withdrawal: a holder or registry-hosted system removes the ROA from publication. The second is replacement: an origin-AS change or maxLength edit creates a new valid state for some routes while making others invalid. The third is invalidation through the certificate chain: a resource certificate can expire, be revoked, fail validation or cease to cover the resource set in the way the ROA requires. The fourth is ROA expiry or stale publication, in which a ROA or related repository record is no longer valid because time moved on and the signing or publication process did not. The fifth is non-publication: the ROA that should exist is not published at the expected repository point, or a manifest and repository state make it unusable to validators. The sixth is cache propagation: relying-party caches fetch, retain and age data on different schedules, so the same route can appear in different states across the routing ecosystem for a period of time.

Those mechanisms are not the same. A holder intentionally withdrawing a ROA before a planned provider change is not the same as a registry revoking a certificate after proven false authority. A maxLength error is not the same as a court-related administrative lock. A repository outage is not the same as a policy sanction. A validator with stale data is not the same as a current registry decision. Treating all of them as one category called "revocation" obscures the facts that operators need. The economics depend on classification because each cause has a different cure path and a different legitimacy standard.

The risk also includes the distinction between technical invalidity and commercial unreliability. A route may be technically Invalid because a ROA authorises AS64500 while the customer is announcing through AS64501. If the mismatch is caused by a planned cloud migration and can be corrected in minutes, the commercial risk is small. If the mismatch is caused by a disputed loss of account authority, a certificate action or a registry decision that the holder cannot challenge, the commercial risk is larger. The packet does not know the difference, but the market does.

The NotFound state deserves equal precision. NotFound is not the same as invalid. Many networks do not reject NotFound routes because the absence of a ROA may simply mean the holder has not adopted RPKI. Yet in high-value or security-sensitive contexts, NotFound can still be a negative signal. A cloud provider may ask why a supposedly mature holder cannot publish a ROA. A public customer may treat NotFound as incomplete security posture. A buyer may require ROAs as a closing condition. A lender may see NotFound as a gap in operational assurance. Thus a ROA withdrawal that changes a prefix from Valid to NotFound may not break routes as sharply as an Invalid state, but it can still slow transactions and weaken confidence.

The term "revocation authority" should therefore be understood broadly but not carelessly. It is the practical power to alter the route-origin evidence that other parties use. The holder may exercise it by changing its own ROAs. The registry may influence it through hosted RPKI services, certificate status, account access, publication infrastructure and resource-record control. Validators and network operators influence the market effect through their refresh intervals and routing policies. A court or receiver may affect it indirectly by constraining who can act for the registry or a resource holder. The shock occurs when this distributed authority is not matched by clear procedure.

AFRINIC's relevance is not that it has uniquely poor RPKI technology. The sharper question is whether a registry that has experienced serious institutional turmoil can credibly guarantee that route-origin changes will remain narrow, documented and service-preserving even when disputes are intense. A ROA is meant to reduce uncertainty about route origin. If the process around removal or alteration creates new uncertainty about institutional discretion, the security artifact begins to carry a governance premium.

The economic definition is therefore this: ROA revocation risk is the exposure of a resource holder, operator, customer or counterparty to loss of route-origin reliance caused by withdrawal, replacement, certificate invalidity, expiry, non-publication, repository failure or uneven propagation of RPKI data, especially where the affected party lacks timely notice, a realistic cure path, a reversible correction mechanism or a credible appeal against high-consequence action. That definition is technical enough to be useful and broad enough to capture why a small signed authorisation can matter to balance sheets.

The lifecycle is a chain, not a switch

The lifecycle of a ROA begins before the authorisation is signed. It begins with the registry's recognition of a resource holder and with the holder's authority to manage the resource. AFRINIC's own public materials describe it as a member-based nonprofit registered in Mauritius that distributes and manages IP address space and autonomous system numbers for Africa and parts of the Indian Ocean. Its services include WHOIS, RDAP, reverse DNS, an Internet Routing Registry and a Resource Certification Program for RPKI. That catalogue matters because a ROA is not a free-floating cryptographic opinion. It rests on the registry's resource records, account controls, certificate issuance and publication systems.

In ordinary operation, the chain is boring. A holder has an AFRINIC account or another recognised path to manage certification. The relevant resources are covered by a resource certificate. The holder creates a ROA authorising an origin AS for a prefix and a maximum length. The signed ROA is published in the RPKI repository. A manifest lists published records so validators can detect whether repository content is complete and current. A certificate revocation list supports the certificate status model. Relying-party software fetches the repository, validates the chain and produces data used by routers or route policy systems. The holder monitors whether announcements remain Valid.

Each step can fail in a different way. Holder authority can be unclear after a merger, receivership, insolvency, public-sector reorganisation or contractor change. Account access can be compromised or frozen. A certificate can expire or be revoked. A ROA can contain the wrong ASID, prefix or maxLength. A signing process can fail. A repository can publish an incomplete set of records. A manifest can make validators distrust the view they fetched. A validator can continue using old data for a period rather than immediately switching to an empty or failed state. A network can apply ROV policy differently from its neighbour. The lifecycle is therefore not a switch between safe and unsafe; it is a chain of dependencies whose failure modes are economically distinct.

The lifecycle also interacts with real operating patterns. A holder may authorise its own AS for normal service, a transit provider's AS for backup, a cloud AS for a region-specific BYOIP deployment and a DDoS mitigation provider during attacks. It may announce an aggregate from one network and more-specifics from another. It may split a prefix after a data-centre migration. It may use multi-origin designs deliberately. Every one of those patterns depends on correct origin and maxLength choices. A narrow ROA can protect against accidental more-specific hijacks but block legitimate traffic engineering. A broad maxLength can preserve flexibility but increase the blast radius if a more-specific is misused. These are engineering decisions with commercial consequences.

In the AFRINIC region the lifecycle can be harder because documentation quality varies. Some resources are tied to old records, old corporate names, public agencies, universities or operators whose original engineers have left. KrebsOnSecurity's account of the 2019 address-heist allegations and the Internet Governance Project's analysis of the wider crisis both made clear that dormant or weakly controlled records can become valuable targets once IPv4 has market value. A registry trying to clean bad records faces a real problem. A holder trying to preserve service during cleanup faces a real problem too. RPKI inherits both.

The lifecycle therefore needs a status vocabulary richer than "the ROA exists" or "the ROA is gone." A change may be holder-requested, routine migration, account-recovery related, emergency compromise response, certificate-maintenance related, repository incident, dispute preservation, legal-order compliance or resource-status correction. Each category should imply a notice standard, a cure path, a review clock and a continuity default. The market can tolerate a hard action if it knows why it happened and how an error can be reversed. It struggles with unexplained disappearance.

The right lifecycle principle is continuity with controlled correction. False authority must be removed. Compromised accounts must be contained. Incorrect ROAs must be fixed. Lawful orders must be respected. But correction should be designed so that innocent downstream customers do not become the cheapest way to create pressure. In a networked economy, the cost of abrupt route-origin change is rarely borne only by the party named in the registry record. It is borne by the customers, public services, counterparties and providers who built around the route.

Invalid and NotFound are different economic events

Invalid and NotFound are often compressed into the same business fear: the route is no longer clean. Technically they are different, and the difference matters. A BGP announcement is Invalid when a validator finds covering ROA data but the announcement conflicts with it. The usual reasons are an origin-AS mismatch or a prefix length longer than the ROA's maxLength permits. A BGP announcement is NotFound when there is no covering validated ROA. In many networks, Invalid is a direct rejection candidate while NotFound is accepted but watched. In commercial diligence, both can raise questions, but they raise different questions.

Invalid is sharper because it says the holder's published authorisation and the observed route disagree. That makes it useful against hijacks and leaks. It also makes innocent errors dangerous. A provider change that updates BGP before the ROA is changed can create Invalid routes. A cloud onboarding that announces a /24 while the ROA authorises only the aggregate without a suitable maxLength can create Invalid routes. A DDoS mitigation event that originates traffic from an emergency AS can create Invalid routes if the emergency ROA is absent. A delegated customer that changes origin without telling the holder can create Invalid routes. The status does not explain motive. It only signals conflict.

The market treats Invalid as a fault that needs explanation. A carrier may reject the route automatically where its policy enforces route-origin validation. An IXP route server may suppress it to protect members. A cloud provider may block onboarding until the customer fixes the mismatch. A buyer may delay closing because the asset cannot be deployed through the intended AS. A public-sector customer may interpret the invalid as failure of security controls. An insurer may ask whether route-origin monitoring is adequate. The cost appears as tickets, outages, delay, contractual friction and reputational damage.

NotFound is softer but still important. A route that was previously Valid and becomes NotFound after a ROA withdrawal may continue to pass through many networks. Yet a Valid-to-NotFound change removes positive evidence. If the holder intentionally deauthorised RPKI because a dispute is pending, counterparties may read that as risk. If the change came from repository failure, they may read it as service fragility. If it came from expiry, they may read it as poor operational control. If it came from a registry account problem, they may read it as institutional dependency. In a world where more counterparties expect RPKI, NotFound is increasingly a weaker commercial state even when it is not a routing failure.

The contrast also affects cure. Invalid usually has a concrete fix: adjust the origin AS, adjust maxLength, change the route, publish an additional ROA, correct the certificate or reverse the mistaken edit. NotFound may require restoring the whole publication chain or deciding whether a ROA should exist at all. A NotFound caused by deliberate withdrawal during an unresolved dispute cannot be cured by a transit engineer alone. A NotFound caused by repository non-publication may require registry infrastructure repair. A NotFound caused by certificate expiry may require renewal or reissuance. The ticket must find the right owner.

For AFRINIC, the distinction should shape governance. A resource-status dispute should not automatically push live routes into Invalid if the existing origin is the last verified safe state and no immediate hijack risk exists. A suspected false ROA may require immediate containment, but the status should be time-limited and reviewed. A publication incident should be communicated as an infrastructure incident, not left for counterparties to interpret as holder fault. A planned migration should allow overlapping authorisations where safe so that origin changes do not create avoidable Invalid windows.

Invalid is a direct contradiction between announcement and authorisation. NotFound is absence of usable authorisation. The first often creates immediate filtering risk in networks that enforce ROV; the second creates assurance loss and may later become a commercial obstacle. A mature revocation framework distinguishes them before acting, explains them while acting and supports rapid cure after acting. Without that discipline, route-origin validation can protect against one class of bad route while creating an institutional shock in another.

Cache propagation turns registry time into market time

RPKI does not move through the internet in a single instant. Validators fetch repositories on schedules. Operators set local policies. Caches retain validated data until refresh. Publication points may be reachable from one network and slow from another. A manifest or certificate problem may be interpreted differently depending on software version and local configuration. Some routers consume validation data from one local cache, others from a redundant pair, and still others from outsourced or hosted services. This means the economic event created by a ROA change does not have one timestamp. It has a propagation curve.

That curve matters during revocation or withdrawal. If a holder removes a ROA at 10:00 UTC and publishes a replacement at 10:05, some validators may see a clean transition. Others may see the old ROA, then the new ROA. Others may briefly see neither. If the route changes before the new ROA is fetched, the route can be Invalid in one network and NotFound or Valid in another. If a repository has a freshness problem, a validator may continue using cached data for a period before declaring the data unusable. The operator experiencing a rejection may not know whether the problem is current state, stale state or local policy.

That is why planned ROA changes require choreography. The holder should know which route will be announced, from which origin AS, at which prefix length and through which providers. The ROA should be published before the route changes, not after, where security permits. Old and new origins may need overlap during migration. maxLength should be chosen to authorise intended more-specifics without authorising unnecessary ones. Monitoring should confirm global visibility before customers are moved. Rollback should be prepared. These are ordinary change-management practices, but the registry's processes can either support or disrupt them.

Unplanned changes are harder. A compromised account, false ROA, suspected hijack or lawful emergency order may require immediate action. Yet even emergency action has propagation effects. If the registry or holder removes a ROA to stop a false origin, legitimate backup or mitigation routes may become Invalid if the ROA covered multiple operational uses. If a certificate is revoked, all dependent ROAs may disappear from validation even if only one route was problematic. If a repository is taken offline during an incident, validators may move through different states according to their own rules. Emergency design must assume that the action will be read by machines before humans understand it.

AFRINIC's institutional history adds another propagation layer: narrative propagation. When a quiet registry changes RPKI publication, operators are more likely to assume a routine maintenance issue. When a stressed registry changes publication during litigation, receivership, election controversy or public allegations, counterparties may infer broader trouble. The same technical state can therefore carry a different market meaning. This is not always fair, but it is how risk is priced. Silence during a ROA event invites counterparties to fill the gap with the worst plausible explanation.

The antidote is operational transparency without reckless disclosure. A registry should not publish private litigation files, security details or customer contracts. It can still publish service-status facts: whether RPKI repositories are operating, whether a publication incident is under investigation, whether member portal actions are delayed, whether emergency restrictions are temporary and whether affected holders have been notified. Holders can tell counterparties whether a change is planned, whether an invalid is expected to clear after cache refresh and what route should be considered authoritative. Good communication does not eliminate propagation lag; it makes the lag less alarming.

In a scarce IPv4 market, time is not neutral. A prefix that spends a day in inconsistent validation can create more damage than a routine database error because the inconsistency touches multiple counterparties at once. Registry time, validator time, provider time and customer time become one business clock. AFRINIC's challenge is to ensure that any high-consequence ROA change is classified, communicated and correctable within that clock, not only within the slower rhythm of institutional process.

MaxLength and origin edits are small fields with large consequences

A ROA's maxLength field looks like a technical detail until it blocks a business model. If a holder authorises a /20 without permitting longer prefixes, the ROA may validate only the /20 origin. If the holder later announces a /24 for traffic engineering, DDoS mitigation, cloud onboarding or regional failover, the announcement can be Invalid because the route is longer than the authorised maximum. If the holder sets maxLength too broadly, more-specific announcements may validate even when the holder did not intend such flexibility. The field is a risk allocation device disguised as a number.

Origin-AS edits carry similar weight. A customer may move from its own AS to a cloud AS, from one transit provider to another, from a data centre to a DDoS mitigation service or from a reseller arrangement to direct origination. The ROA must follow the intended origin. If the old origin remains authorised for too long, the holder may preserve attack surface or former-provider leverage. If the old origin is removed too early, backup service may break. If the new origin is authorised without enough notice to affected providers, the change may look like suspicious transfer of authority. In a clean environment, those are operational trade-offs. In a disputed environment, they become evidence.

The economics are clearest in BYOIP. A cloud platform cannot simply accept a customer's statement that it may advertise a prefix. It needs route-origin evidence. Some platforms use challenge tokens, letters of authorisation, registry contacts, RPKI checks and route monitoring. If a customer lacks a ROA for the cloud origin, onboarding may stall. If a ROA authorises the cloud AS but maxLength does not cover the required more-specific, the service may be technically close but commercially unavailable. The address block exists, but its value is not fully deployable.

Transit and IXP cases are less glamorous but no less important. An African access provider may need to announce a customer prefix through a new upstream to reduce cost or improve latency. An exchange may need to accept a route at a route server. A data centre may need to move customer traffic during a fibre cut. A university or public agency may need continuity while changing contractors. In each case the difference between a correct ROA and a wrong ROA may be the difference between a routine engineering change and a week of escalation.

This is where AFRINIC's procedures should be proportionate. A routine maxLength correction requested by a verified holder should not require an expansive inquiry into the holder's commercial model. An origin change during a documented migration should have a clear path, with notice to relevant contacts and monitoring for unexpected invalids. A high-risk change that removes a long-standing origin or adds a broad more-specific capability should receive stronger checks. A disputed change should preserve the last verified operational state where safe while the narrow route-origin question is reviewed. The process should distinguish a typo from an attempted asset seizure.

The maxLength problem also shows why revocation risk is not only about deletion. A ROA can remain present and still create a shock. Tightening maxLength can invalidate more-specifics. Changing the origin AS can invalidate old announcements. Splitting a prefix into multiple ROAs can make some routes valid and others invalid. Reissuing a certificate can affect the set of repository records validators accept. The market may experience these as revocation-like even if no one used the word "revoke." A good framework therefore treats consequential edits as part of the same risk family.

Small RPKI parameters carry large economic meaning because they are consumed by automated systems and trusted by counterparties. Treating them as mere configuration underestimates the harm of surprise. Treating them as full property adjudications overstates what they can prove. They require a middle discipline: technical narrowness, procedural seriousness and reversibility when the wrong small field creates a large market shock.

AFRINIC's crisis made certificate discretion visible

AFRINIC's public crisis is not the subject of this article for drama. It matters because it shows how registry discretion becomes economically visible when IPv4 scarcity, institutional weakness and route-origin security meet. The Internet Governance Project's 2021 analysis described the Cloud Innovation dispute as a collision between AFRINIC's attempt to clean up perceived misuse and a member whose business depended on large IPv4 holdings. It described court orders, bank-account freezes and the risk that ordinary registry operations could be impaired. The NRO's 2023 statement described the appointment of a receiver to maintain status quo, oversee elections and restore functional governance. The Register later chronicled election delays, annulment, board restoration, continued litigation and ICANN interventions. None of those sources should be treated as final judgment on every legal claim. Together they show that the registry layer became a live risk surface.

Certificate discretion matters in that environment because it is less visible than a court order or a public transfer denial. A registry can influence route-origin reliance through hosted RPKI controls, member-account access, resource certificate status, repository publication, support response, classification of disputes and emergency restrictions. Many of these decisions are operational, not political. Yet if the standards are opaque, the affected holder may experience them as power without a clear remedy. The counterparty sees only a change in validation or a delay in obtaining clean evidence.

This does not mean AFRINIC should never act decisively. The 2019 address-heist allegations reported by KrebsOnSecurity and others were a reminder that number-resource records can be abused at large scale. A registry that cannot correct false authority is not protecting members. A compromised account cannot be allowed to publish ROAs indefinitely. A fraudulent route-origin authorisation should not be preserved merely because the affected route has customers. A lawful court order may require action. The question is not whether correction power exists. It is whether the power is bounded by notice, evidence, continuity and review.

AFRINIC's policy materials also show a long-standing tension between stewardship language and market reality. The official manual describes need-based allocation, documentation requirements and the idea that number resources are public resources rather than ordinary property. The exhaustion page records the pressure created by scarcity and the soft-landing process. IGP's 2021 analysis noted that AFRINIC's historically low-fee allocation environment collided with global IPv4 prices. The Register's 2026 reporting captured the continuing fight over whether addresses should be treated as economic assets or non-property resources administered by policy. RPKI sits precisely where that argument becomes operational.

If certification is used only to answer a narrow question--which origin AS is authorised for which prefix under current recognised authority--it can reduce conflict. If it is used to express broader disapproval of a business model, a customer geography, a leasing practice or a political faction, it turns security into leverage. The difference may not be obvious to a validator, but it will be obvious to the market. Buyers and customers will ask whether route-origin validity depends on technical correctness or on institutional favour.

This is why the appeal mechanism matters before the dispute occurs. A holder should not have to discover during an emergency that there is no practical way to challenge a high-consequence RPKI action. A registry should not have to improvise under litigation pressure. Courts should not be forced to learn route-origin validation in the middle of a service crisis. The categories should exist in advance: routine edit, suspected compromise, false authority, resource-status dispute, publication incident, legal-order action, emergency suspension and final revocation. Each should have a defined authority, notice expectation, review path and continuity default.

AFRINIC's recovery should be measured by these operational constraints as much as by board meetings and budgets. A rebuilt institution can still be risky if certificate discretion remains opaque. Conversely, a stressed institution can preserve confidence if it shows that RPKI services are insulated from unrelated conflict. The market does not require perfection. It requires enough predictability to know that route-origin assurance will not become collateral damage in a fight over governance, fees, elections, commercial ideology or institutional survival.

The institutional conclusion is narrow. AFRINIC is not merely a bad example, nor is it merely a victim of litigation. It is a stress test for the RIR system's assumption that registry trust anchors can be treated as neutral infrastructure without a detailed continuity constitution. ROA revocation risk is where that assumption meets the balance sheet.

Notice, cure and appeal are not legal ornaments

Notice is the cheapest safeguard in a high-consequence route-origin system. It does not decide who is right. It tells affected parties that a change is coming, what category of change is at issue and how to respond before the change becomes an outage or a market signal. For ROA withdrawal or replacement, the affected parties may include the resource holder, current origin AS, proposed origin AS, delegated operator, relevant maintainer contacts, large downstream customers and sometimes a court-appointed or insolvency representative. The list need not be public. It must be operationally real.

Notice should be calibrated to risk. A routine holder-requested addition of a new origin for a planned cloud migration may need short notice and clear confirmation. A maxLength tightening that could invalidate existing more-specifics should warn the holder and current origin before the change. A suspected false ROA supporting active hijack may justify immediate temporary action followed by rapid notice. A certificate revocation affecting many ROAs should require heightened internal review because it can alter multiple routes at once. A repository incident should be announced as a service incident rather than hidden as individual holder fault.

Cure is the second safeguard. The goal of cure is not to keep bad authorisations alive. It is to prevent curable defects from becoming asset freezes. A stale contact can be updated. A wrong origin AS can be corrected. A missing maxLength can be changed. A transfer sequencing error can be resolved. A cloud onboarding route can be pre-authorised. A certificate expiry can be renewed. A holder with weak historical records may need to produce corporate continuity documents. The cure path should be proportionate to the defect and fast enough to matter to live networks.

The documentation burden of cure must not be ignored. AFRINIC serves a region with large differences in institutional capacity. A multinational carrier can assemble registry records, corporate approvals, counsel letters and routing evidence quickly. A small African ISP may not. A university may have old allocation records but no current engineer from the original period. A public agency may move slowly because authority sits in procurement, ministry or state-company channels. A rural operator may rely on a managed provider that holds technical knowledge. If cure rules assume a large carrier's paperwork capacity, the system becomes regressive.

Appeal is the third safeguard, and it must be narrower than a full property trial but stronger than a suggestion box. The question on appeal should be whether the RPKI-affecting action matched the published category, evidence standard, notice rule, continuity default and review clock. Was emergency action justified? Was the change limited to the affected resource? Did the registry preserve the last verified safe route where possible? Was the holder given a realistic way to cure? Did new evidence require reversal? These questions are sufficient to discipline the route-origin process without asking the registry to decide all commercial rights.

The appeal path should also distinguish temporary containment from final action. A temporary lock after suspected compromise may be justified before all facts are known. A final revocation or certificate action that impairs live resources should require stronger evidence and independent review. If the same standard is used for both, either emergencies become too slow or final actions become too easy. The remedy ladder should be explicit before crisis.

Continuity during appeal is the hard part. If the disputed ROA appears fraudulent and supports active misrouting, preserving it would harm the internet. If the disputed ROA supports a long-standing customer route and the dispute is about a contract, removing it immediately may punish innocent users. The default should be preservation of the last verified safe operational state unless that state itself is the source of immediate harm. This principle does not decide ownership. It prevents the validation system from becoming the instrument by which one side wins before review.

AFRINIC's history makes these safeguards more than theory. The Cloud Innovation conflict involved attempted resource withdrawal, injunctions, bank freezes and existential claims on both sides. Election disputes involved allegations around powers of attorney and member credentials. Receivership was meant to preserve status quo while governance was restored. In such an environment, route-origin changes need to be visibly insulated from broader fights. Notice, cure and appeal are the insulation.

The opposite is also true. A registry that treats notice as courtesy, cure as discretion and appeal as delay invites the market to protect itself privately. Carriers will create stricter policies. Clouds will require more documents. Buyers will demand discounts. Customers will seek alternatives. Larger actors will manage through relationships and lawyers; smaller operators will absorb delay. Weak procedure therefore does not only hurt the party under review. It raises the cost of trust for the whole region.

Emergency suspension must be narrow and reversible

Emergency power is necessary in route-origin security. A false ROA can lend apparent legitimacy to a hijack. A compromised account can publish new origins. A stolen credential can alter maxLength to permit more-specifics. A repository compromise can poison data. A court order can require immediate preservation. A registry that cannot act quickly against real harm would fail its members. But emergency power is also the easiest place for discretionary control to hide because urgency weakens ordinary scrutiny.

The first rule of emergency suspension is purpose limitation. The emergency must relate to route-origin harm, false authority, account compromise, certificate integrity, repository integrity or immediate legal constraint affecting the certification service. It should not be used to punish nonpayment, enforce a broad commercial policy, discipline an unpopular business model or pressure a litigant unless the published rules clearly connect that issue to certification and continuity safeguards apply. If everything can be an emergency, the category has no discipline.

The second rule is minimal blast radius. If one ROA is false, suspend that ROA rather than revoking a certificate that invalidates many unrelated routes, unless certificate-level action is necessary. If one origin is disputed, avoid disabling unrelated origins. If account control is compromised, lock high-risk changes while preserving existing valid authorisations where safe. If repository publication is uncertain, communicate the incident and preserve validated state where standards and software behaviour permit. Emergency action should be a scalpel before it is a hammer.

The third rule is time bounding. Emergency suspension should start a clock. Within a defined period, the registry or holder should classify the event, notify affected parties, collect evidence, decide whether to restore, replace, narrow or escalate, and record the result. A temporary lock that quietly becomes indefinite revocation is a governance failure. In a scarce IPv4 market, indefinite uncertainty may destroy value even if the route later returns.

The fourth rule is reversible correction. Mistakes happen. A holder may fail to recognise a legitimate delegated operator. A registry may misread a document. A monitoring system may flag a false positive. A court order may be clarified. A maxLength change may have unintended consequences. The system should make reversal operationally feasible without forcing the holder to restart from the beginning. Reversal should include not only publication but explanation to affected counterparties where appropriate. The market needs to know that the restored state is deliberate, not accidental.

The fifth rule is independent review for severe cases. A registry staff team can make an immediate containment decision, but long-duration or high-impact suspension should be reviewed by a separate authority inside or outside the registry. That review need not be slow. It can be expedited and technical. The key is separation from the team or institutional actor that initiated the action. A registry under litigation pressure needs this protection for itself as well as for members. Independent review reduces the claim that emergency security is merely institutional self-help.

Emergency suspension also needs downstream awareness. A prefix may support hospitals, banks, universities, government portals, payment systems, cloud workloads or customer VPNs. The registry may not know every downstream dependency, but it can assume they exist. The holder should maintain dependency maps for high-value prefixes. Transit providers and clouds should maintain contact paths. Emergency action should consider whether collateral harm can be reduced by preserving a last-known safe origin, limiting the suspension to a new suspicious ROA or using a short notice window before broader action.

The purpose of emergency power is to preserve trust. Overuse destroys trust because holders begin to fear the tool designed to protect them. Underuse destroys trust because false authority remains live. The balance is not rhetorical. It is procedural: narrow grounds, minimal blast radius, short clocks, reversible correction, independent review and communication. AFRINIC's opportunity is to demonstrate that even under institutional stress, emergency RPKI action remains a security instrument rather than a discretionary lever.

Smaller African operators carry the hidden documentation burden

ROA revocation risk is often discussed as if the affected holder is a large address portfolio company with lawyers and routing engineers on call. Many affected networks are not like that. They are access providers, universities, public agencies, local data centres, research networks, content hosts, regional enterprises and managed-service firms that depend on a small number of scarce prefixes. For them, the burden of proving authority after a validation event can be more damaging than the event itself.

The burden begins with records. A small operator may have joined AFRINIC years ago under a different corporate name. Its original technical contact may have left. Its administrative contact may be a director who no longer manages networks. Its invoices may be paid by an affiliate. Its routing may be outsourced. Its customer allocations may have grown through informal operational practice rather than clean documentation. None of this means the operator is illegitimate. It means the operator's proof file may be weaker than its operational dependence.

When a ROA problem occurs, that weakness becomes visible. The registry may ask for corporate documents, board authority, identity proof, current contacts, network plans, utilisation data, customer delegations, origin-AS confirmations or historical records. A transit provider may ask for a letter of authorisation. A cloud platform may ask for a current ROA and registry contact validation. An IXP may ask why the route differs from expected data. A customer may ask whether service will continue. The same small team must answer all of them while fixing the route.

Documentation burden is not simply cost. It is bargaining power. A provider with a weak file may accept unfavourable terms from an upstream because the upstream can route faster. A buyer may demand escrow holdback. A cloud project may slip. A customer may choose a larger competitor. A lender may classify address-dependent revenue as fragile. The inability to prove authority quickly becomes a market disadvantage independent of the underlying right.

AFRINIC's region has a development interest in lowering this burden without lowering security. That requires predictable evidence tiers. Routine ROA changes by an established holder with current contacts should be easy. Changes involving old contacts, disputed corporate authority or new origins should require more proof but still have clear checklists. Public-sector and university cases should recognise slower authority chains. Managed-service delegations should allow the holder to authorise technical delegates without surrendering ultimate control. Historical clean-up should be supported by staged verification rather than sudden route-origin disruption.

The documentation burden also interacts with language, jurisdiction and legal form. AFRINIC's service region covers many legal systems and languages. Corporate evidence from one country may not resemble corporate evidence from another. Public agencies may have mandates that are not expressed in private-company board resolutions. Universities may have statutory governance structures. Small companies may use local documents that global cloud providers do not recognise easily. A rigid evidence model can unintentionally privilege familiar corporate forms over legitimate regional reality.

The cure is not to accept weak claims. It is to translate legitimate authority into usable evidence. AFRINIC can publish evidence categories, not just document names. It can say what it needs to establish: recognised holder continuity, current contact authority, technical delegation, origin-AS consent, customer dependency, emergency need and dispute status. Different documents can satisfy the same category in different jurisdictions. This lowers burden while preserving rigor.

If AFRINIC does not solve this, private actors will. Large carriers, clouds, brokers and security vendors will build their own evidence requirements. Those requirements may be stricter, less regionally sensitive and harder for small African operators to meet. The result would be a two-tier market in which large networks can prove themselves and smaller ones remain dependent on intermediaries. RPKI should reduce the need for private gatekeeping. Poor revocation process would do the opposite.

IPv4 scarcity turns continuity into capital protection

IPv4 scarcity is the reason ROA revocation risk has become an economic issue rather than a narrow network-security issue. AFRINIC's official exhaustion materials describe the scarcity of IPv4, soft-landing phases and the reduced availability of large allocations. IGP's 2021 analysis described the global transfer market and the rising per-address value of IPv4. Public reporting and market practice have made clear that address blocks can support significant business value even though registries and policies resist ordinary ownership language. The legal category may be contested; the economic dependency is not.

A prefix has value because other parties rely on it. Customers put it into firewall rules. Banks recognise it as a known source. Suppliers whitelist it. APIs bind to it. Security teams monitor it. DNS and reverse DNS point to it. Geolocation databases associate it with service regions. Cloud platforms route it. Transit providers accept it. Buyers diligence it. Lenders and insurers translate it into continuity risk. An address that can be replaced tomorrow is capacity. An address embedded in these relationships is capital-like infrastructure.

ROA validity is increasingly part of that embedding. A prefix that is consistently Valid under intended origins is easier to treat as a stable operational asset. A prefix that frequently becomes Invalid because of poor maxLength practice, erratic origin changes or unexplained publication gaps looks fragile. A prefix that is NotFound despite a security-sensitive use may require extra explanation. A prefix whose certification status can be changed without notice during institutional disputes attracts a risk premium. The route-origin layer becomes one component of asset quality.

This is especially important for leasing and delegated use. A holder may allow another network to originate a prefix for hosting, managed service, cloud, customer access or security mitigation. Whether one calls that leasing, delegation, customer assignment or service arrangement, the operational fact is that holder and origin may differ. The ROA is the bridge. If the holder can reliably authorise the origin, the arrangement has market value. If the holder cannot guarantee timely ROA changes or fears registry discretion, the arrangement becomes less bankable. Contract clauses begin to revolve around ROA maintenance, notification and indemnity.

Transfers create a similar issue. A transfer is not economically complete when a registry record changes. It is complete when the buyer can use the prefix through intended origins, publish appropriate ROAs, align IRR and reverse-DNS records, clear cloud or transit onboarding and satisfy customer diligence. A ROA revocation or non-publication event during settlement can create holdbacks, delays or price reductions. The more uncertain the registry's certification process, the more escrow and warranty language the market will demand.

AFRINIC's crisis illustrates the danger of treating continuity and institutional control as the same thing. Some official and community narratives emphasise protecting AFRINIC as the regional registry. Critics reply that the ledger function should be protected without preserving unchecked gatekeeping. The useful distinction is functional. Number uniqueness, registration accuracy, RDAP, WHOIS, reverse DNS, RPKI repositories and dispute records must continue. That does not mean every discretionary claim by the registry should be immune from review. Continuity protects the networks using the numbers. It should not be inverted into protection of the institution at the expense of those networks.

For holders, that means maintaining accurate ROAs, contacts, delegations and monitoring. For registries, it means reliable publication, constrained revocation authority and correction paths. For operators, it means clear ROV policies and communication. For buyers and customers, it means asking about route-origin control before signing. For courts and receivers, it means preserving technical continuity while legal disputes proceed. The value of IPv4 makes each party's failure more expensive.

AFRINIC is a test case because the region's need for connectivity, local interconnection, cloud adoption and public digital services collides with scarcity and institutional recovery. A trustworthy ROA system can make African resources more usable and more valuable. A discretionary or opaque one can attach a governance discount to them. In a market where every address is costly to replace, continuity is not a courtesy. It is capital protection.

The limited contrast with IRR shows why RPKI needs stricter safeguards

IRR route records and RPKI ROAs are often discussed together because both relate to prefix-origin claims. The contrast is useful only if kept limited. An IRR route record is a routing-policy database entry. It can feed filters at carriers and exchanges, but its authority depends on the source, maintainer rules, mirrors, duplicate records and operator policy. A ROA is a signed RPKI record validated through a resource-certificate chain. It is narrower in what it asserts and stronger in how many systems can process it automatically. Both can affect reachability. They do so through different trust models.

The IRR problem is messy pluralism: stale route records, AS-SET recursion, source selection, mirror lag, maintainer authority and deletion standards can all produce conflicting operational signals. This article's point is different. ROA revocation risk is not mainly about fragmented text databases. It is about a higher-authority routing-security signal whose failure can directly create Invalid or NotFound states across networks that rely on validators. The IRR problem is fragmented authority. The ROA problem is concentrated reliance on a certificate-backed publication chain.

That concentrated reliance is RPKI's strength. It reduces ambiguity about origin authorisation. It helps operators reject routes that conflict with published authority. It gives clouds, carriers and customers a stronger proof track. It can reduce dependence on private letters and stale IRR entries. But the stronger the proof track becomes, the more damaging it is when the authority behind it changes without process. A wrong IRR record may be one bad source among several. A wrong or missing ROA can make a route Invalid in strict networks.

AFRINIC should therefore avoid two mistakes. The first mistake is to treat RPKI as merely another registry service that can be bundled with ordinary account enforcement. Because ROAs can affect live route acceptance, they need service-specific continuity rules. The second mistake is to treat RPKI as a complete solution to routing-authority disputes. A ROA does not prove full ownership, settle leasing contracts, decide customer geography or resolve corporate litigation. It proves a current route-origin authorisation under the RPKI system. Its strength comes from staying within that boundary.

RPKI safeguards should therefore be stricter than IRR safeguards in three ways. First, service continuity should be protected because automated rejection can be severe where ROV is enforced. Second, severe actions should have independent review because certificate-backed evidence carries high authority. Third, repository and publication incidents should be reported with more urgency because validators depend on freshness and completeness. These standards do not weaken RPKI. They make adoption safer.

The policy conclusion is modest but demanding. IRR will remain part of routing operations for customer filters and routing-policy expression. RPKI should increasingly carry the origin-authorisation burden. The two systems should be layered, not collapsed. AFRINIC's task is to make its RPKI layer trustworthy enough that operators can rely on it without fearing that route-origin validity will become another discretionary battlefield. That means good cryptography, but also good procedure.

The standard AFRINIC should meet

The standard for AFRINIC is not that no ROA should ever be removed, changed or invalidated. That would be unsafe. False, stale and compromised authorisations must be correctable. The standard is that a route-origin change with market consequences should be narrow in purpose, visible in category, proportionate in evidence, protective of continuity, reversible when wrong and reviewable when severe. Anything less turns RPKI from a security service into a source of institutional shock.

The first requirement is a public classification model. AFRINIC should distinguish holder-requested routine changes, planned migrations, maxLength corrections, origin-AS replacements, certificate maintenance, repository incidents, suspected compromise, false authority, legal-order action, disputed-resource preservation and final revocation. The label does not need to reveal private details. It tells affected parties what kind of event they are dealing with and what process applies. Classification lowers panic.

The second requirement is a notice and cure ladder. Routine changes can proceed quickly. Changes that may invalidate live routes should notify affected contacts where feasible. Emergency actions can precede notice but should trigger rapid explanation and review. Documentation demands should be proportionate to the risk and realistic across African jurisdictions and operator sizes. Cure windows should be long enough for genuine response and short enough not to preserve bad authority indefinitely. The ladder should be known before a crisis, not invented during one.

The third requirement is continuity by default. Existing valid ROAs for live, long-standing routes should be preserved during disputes unless the route itself is the source of immediate harm or a clear legal order requires different treatment. New changes can be restricted while authority is reviewed. Suspicious additions can be suspended. But the last verified safe operational state should not be casually destroyed because the registry, holder, litigant or third party wants leverage. Dispute isolation is a form of routing stability.

In practice, that is the continuity firewall: separate the contested authority question from the live route unless the live route is itself the danger.

The fourth requirement is repository resilience and incident transparency. RPKI repositories, manifests, CRLs, certificates and publication systems should be treated as critical infrastructure. AFRINIC should be able to say whether the repository is functioning, whether publication is delayed, whether a manifest or certificate incident exists and whether members should take action. Aggregate metrics on availability, emergency actions, revocations, reversals and time to cure would help the market price reliability without exposing private cases.

The fifth requirement is independent review for severe route-origin harm. An internal escalation may be enough for ordinary mistakes. Long-duration suspension, certificate revocation affecting live routes or disputed final removal should be reviewable by a process that is not identical with the decision-maker in the underlying dispute. The review should focus on the RPKI action, not decide every commercial claim. This keeps the process fast while giving it legitimacy.

The sixth requirement is a clean boundary between security and policy enforcement. If AFRINIC believes a member has breached resource policy, it should use the relevant policy and contractual process. If RPKI action is necessary to prevent false authority or immediate harm, it should say so. It should not hide broad policy enforcement inside certificate ambiguity. Security legitimacy depends on restraint. The more RPKI is seen as neutral route-origin assurance, the more operators will adopt and enforce it.

The seventh requirement is market literacy. AFRINIC does not need to endorse every market claim about IPv4 property to understand that its actions affect capital, revenue and customer continuity. A /24 can support a business. A /16 can support a portfolio. A single ROA error can delay a cloud migration. A NotFound state can slow diligence. A prolonged Invalid can breach customer expectations. Recognising economic consequence is not the same as surrendering registry policy. It is the basis for proportional governance.

The opening scene should then end differently. A prefix changes origin for a cloud migration. The new ROA is published before the route moves. The old origin remains authorised for a defined overlap. Validators converge. The route server accepts the new route. The cloud onboarding ticket closes. Customers see no outage. If something goes wrong, the holder receives a specific warning, uses a known cure path and can reverse the mistaken field before the market treats the block as tainted. If an emergency requires suspension, it is narrow, logged, time-limited and reviewed.

That is the economics of ROA revocation risk. The record is small. The dependency it represents is not. AFRINIC's test is whether it can make route-origin authority strong enough to protect against bad routes and constrained enough not to become a shock absorber for institutional failure. In a market where IPv4 scarcity turns continuity into capital, notice, cure, appeal and reversible correction are not procedural luxuries. They are part of the infrastructure that lets scarce numbers remain usable.