Summary

  • LACNIC RPKI governance risk is not a protocol tutorial; it is a question of who controls certification state when hosted custody, delegated custody, ROA changes and validator timing affect commercial reliance.
  • Mistaken invalidity, rushed withdrawal, transfer ambiguity and lease-bound routing can turn a narrow certificate action into a continuity shock for customers, lenders, clouds and upstreams.
  • The right institutional design preserves RPKI as evidence infrastructure while requiring notice, cure, appeal, emergency scope, portability and a thin Number Resource Society-style future model.

The cutover room

The crisis begins in a room that does not look like an Internet-governance debate. A Brazilian payments company is moving a customer-facing service from one hosting stack to a cloud platform before the end of a quarter. The board wants the move finished before a lender's field review. The cloud team has accepted the contract, the upstream carrier has provisioned sessions, the firewall vendor has tested route maps and the fraud team has already whitelisted public endpoints. Then one item on the cutover sheet turns red: the prefix is not merely announced; it is being checked against Route Origin Authorizations, and one validator view says the announcement is invalid.

The engineers know the likely causes. A ROA was created for an older origin AS. A seller, lessee or service partner may have changed the routing plan without cleaning the attestation. A maximum-length value may have been too narrow for the more-specific route used during the migration. A certificate-publication delay may have made one cache see a different world from another. The address holder may be using a hosted RPKI service, while the account able to correct the entry sits with a person who left two acquisitions ago. None of this sounds like a constitutional moment. It is one line in a routing-security check. Yet the lender now asks whether the address block is bankable, the cloud platform asks whether onboarding should pause, the upstream asks for written comfort and the board asks why a certificate field can threaten revenue already booked.

That is the correct opening for RPKI governance risk. Not a lesson in certificates. Not a speech about routing hygiene. Not a complaint that security has become inconvenient. The important fact is that a narrow cryptographic attestation has moved into the room where customer continuity, credit, transfer value and market access are decided. When that happens, the institution able to maintain, delay, narrow, revoke or fail to publish the attestation has acquired economic influence even if it never claims to own the address space.

For LACNIC, the question is not whether Latin American and Caribbean networks should improve routing security. They should. Route hijacks, route leaks and sloppy origin claims impose real costs. The question is whether certification infrastructure can become a hidden permission layer over scarce number resources without hard limits on custody, notice, cure, transfer overlap and operational continuity. A signal built to protect reachability can itself become a reachability risk if the holder has no reliable way to keep valid routes valid while legal, commercial or administrative facts are being sorted.

The incident room shows the new economics. A prefix does not lose value only when a registry deletes a record. It loses value when counterparties can no longer rely on its route-origin evidence. A route does not fail only when routers reject it. It fails commercially when enough clouds, carriers, banks, public buyers and enterprise customers treat uncertainty as a reason to delay. RPKI is therefore not just a security add-on. It is an attestation layer sitting above market confidence.

Why this is not a registry-accuracy dispute

The database-accuracy argument asks whether holder names, contact data, transfer state, abuse reachability, routing-adjacent fields and public registry facts are dependable enough for buyers, lenders, operators and counterparties to use. That is a record-market problem. Bad data raises search costs. Stale contacts slow transactions. Unclear holder identity weakens credit. Inaccurate entries force every user of the record to add private verification before doing business.

RPKI governance risk is different. It is not mainly about whether the public record says the right thing. It is about how a cryptographic statement derived from the registry relationship becomes a market-access credential. Database accuracy supports legibility. RPKI can alter reachability. A stale contact may delay due diligence; a mistaken ROA can make a route invalid in the eyes of networks that use route origin validation. A wrong address in a registry record may create confusion; a wrong origin authorization can trigger filters before any lawyer, buyer or customer has time to read the file.

The distinction matters because the remedy is different. Database accuracy calls for better records, clearer correction channels, audit trails, holder authority evidence and public notation of uncertainty. RPKI governance calls for custody safeguards, continuity defaults, overlap during state change, emergency correction channels, validator-aware timing and review before a security statement becomes an economic weapon. One is about record truth. The other is about certificate power.

The risk is also softer than formal revocation. A registry does not need to cancel a resource for RPKI trouble to matter. If a certificate is not refreshed, a repository becomes unreliable, a ROA is removed without enough warning or an origin change is delayed during a transfer, the resource may still appear in the registry database while becoming less usable. In markets, partial usability is enough to change price. Lenders haircut collateral for uncertainty, cloud platforms delay admission for uncertainty, and buyers demand escrow holdbacks for uncertainty.

The record layer tells the world who should be able to speak for a resource. The RPKI layer supplies a machine-readable claim that a certain AS may originate a certain prefix. The two are related but not identical. A holder can be correctly recorded while a ROA is stale. A lease can be commercially valid while the route-origin attestation remains unclear. A transfer can be legally complete while validators still see old route-origin state. A court order can preserve a holding while certificate custody remains operationally trapped.

That is why treating RPKI as a mere extension of registry accuracy understates the risk. Accuracy is about faithful description. Certification is about relying-party behavior. A description can be wrong and still leave room for human judgment. A route-origin validity state can be read by automated filters before any human sees the documents. The economics are therefore more severe: RPKI translates institutional trust into machine-speed consequences.

Attestation as economic permission

RPKI is attractive because it gives the routing system a better way to reject false origin claims. It does not make the Internet safe by magic, and it does not decide every routing question, but it reduces a class of error that has long damaged operators and customers. The public technical record is clear on the narrow function: resource certificates follow the number-resource allocation hierarchy, and ROAs let a legitimate holder make a verifiable statement that a given AS may originate a given prefix. In a world of cloud migration, financial platforms, public services and cross-border commerce, that matters.

The institutional problem begins when the attestation becomes economically necessary while remaining governed as voluntary technical improvement. In theory, a holder can choose whether to create ROAs. In theory, each network can choose how to treat invalid routes. In theory, the market may reward better hygiene and punish weaker practice. In practice, adoption by major upstreams, cloud providers, security vendors, public buyers, insurers and lenders can make the signal difficult to refuse. No statute has to compel the holder. The credential becomes part of admission.

This is soft force. It is not the visible force of a prohibition. It is the quieter force of counterparties who say that without clean route-origin status the deal must wait, the service cannot onboard, the loan will be discounted, the contract will need extra warranties or the customer cannot accept the risk. Each decision is rational. Together they create an institutional fact: the certification layer has become infrastructure for market confidence.

Soft force is not automatically bad. Markets often improve behavior by turning technical discipline into commercial expectation. A network that refuses to maintain basic security evidence imposes risk on others. But soft force becomes dangerous when the credential is tied to a central custodian that lacks equivalent duties to preserve lawful continuity. If the holder needs the registry's cooperation to maintain validity, and if commercial actors require validity, registry discretion becomes market leverage.

The LACNIC region makes this visible because networks there often operate across uneven capital markets, currency risk, public-procurement demands, multinational cloud dependencies, local carriers, small ISPs, cable landing bottlenecks and cross-border corporate structures. A routing-security lapse is not just a matter for the NOC. It can affect payment services, outsourced call centers, regional content delivery, ports, banks, universities, health systems and retail platforms. The more the region's digital economy depends on globally accepted connectivity, the more any certification gap becomes a business-continuity event.

This does not make LACNIC a villain. It makes LACNIC a useful test case. A registry that provides or anchors RPKI sits at a trust junction. The better the service becomes, the more markets rely on it. The more markets rely on it, the more the service needs rules that look less like optional support and more like custody discipline. That is the paradox of success: when a security signal works, it stops being merely technical.

Hosted custody and the convenience trap

Hosted RPKI is the adoption engine. Many small and medium networks do not want to run their own certificate authority, maintain keys, monitor repository health and train each new engineer in route-origin practice. A hosted portal lowers the barrier. It lets a resource holder create and maintain a ROA without building a specialized operation. For a region with thousands of varied networks, that convenience is valuable. Without hosted service, route-origin coverage would be weaker.

Convenience, however, is not neutral. Hosted custody places the holder's route-origin authority inside the registry service environment. The holder may make the choices, but the registry controls the machinery that turns those choices into published attestations. Account access, corporate authority, service status, fee standing, sanctions review, transfer review, fraud suspicion, contact disputes and support delay can all touch the same surface from which ROAs are maintained. A system may intend to separate these matters. The holder experiences them through one door.

The danger is not only deliberate misuse. It is ordinary administrative coupling. A company changes ownership. The old RPKI user cannot be reached. The new signer has corporate authority but has not yet been recognized in the portal. A lease customer needs a temporary ROA update while the holder and customer negotiate renewal. A cloud migration requires a more-specific authorization during the week of cutover. A registry desk asks for more documents. A bank asks for proof that the route can remain valid. Everyone is acting prudently. The route still waits.

For a large carrier with a deep compliance team, waiting may be tolerable. For a regional hosting firm, a public-service supplier or a growing ISP, the delay may be existential. Customer contracts do not pause because a portal role is being verified. Public buyers do not always understand the difference between a registry record, a ROA and a route announcement. Cloud admission teams may not care that the problem is clerical. They see route-origin uncertainty and mark the onboarding as risky.

Hosted custody therefore needs the discipline of a serious trust service even if the legal form is not fiduciary. Existing valid ROAs should not be casually disturbed while unrelated questions are reviewed. Authority changes should have documented evidence standards, time targets and escalation channels. Account disputes should preserve established reachability unless there is acute fraud or a clear hijack threat. The holder should receive meaningful notice before a certificate-affecting change, except in narrowly defined emergencies. Logs should be usable by the holder, not merely by the registry.

Most importantly, hosted service must not become subtle lock-in. A holder that wants to move from hosted to delegated custody should be able to do so with a continuity plan. If the registry can make hosted use easy but delegated exit slow, the market will read convenience as dependence. That dependence becomes a governance discount on the resource itself.

Delegated custody and the parent-key problem

Delegated RPKI looks like the answer because it moves key handling closer to the holder. A sophisticated operator can run its own certification environment, manage publication, automate ROA changes, build dual control, preserve records and separate registry account drama from daily route-origin work. Delegation fits the doctrine that the common layer should remain thin and that operational control belongs closer to the networks that bear the risk.

Yet delegated custody is not full independence. The delegated certificate still depends on a parent relationship. If the parent certificate is not issued, not renewed, narrowed, suspended or otherwise interrupted, the holder's autonomy can collapse into the same chokepoint. Delegation reduces one dependence but does not remove the root of trust. This is the parent-key problem: the holder controls more machinery, but the registry or superior certificate authority still sits above the holder in the certification chain.

The economics are subtle. In a hosted model, the registry can affect ROAs directly. In a delegated model, it can affect the certificate environment that makes the holder's publication valid. For a lender or cloud platform, the distinction may not matter if the final validator outcome is invalid or unavailable. The holder may say it operates its own RPKI. The counterparty asks whether the parent can still interrupt it.

Delegation also creates a capacity divide. Large carriers, major cloud operators and technically mature networks can manage delegated custody. Smaller networks may rely on consultants or managed providers. That can be efficient, but it adds delegation risk without turning the service provider into the resource holder. Who may change keys? Who holds backup material? What happens if the managed provider is acquired? What if the customer's lease ends but the service provider controls the publication environment? What if the holder is in one jurisdiction and the technical operator in another?

These questions matter in Latin America and the Caribbean because regional operators often work through vendor ecosystems, outsourced NOCs, holding companies, multinational groups and mixed public-private arrangements. A simple binary between hosted and delegated does not describe the lived reality. Custody may be split among the legal holder, the network operator, the cloud partner, the security consultant and the transfer buyer. RPKI governance must handle that divided control without pretending it is clean.

A mature delegated model would give the holder clear ability to obtain and maintain delegated certificates, predictable renewal, transparent suspension criteria, continuity during dispute and a route back to hosted operation if a technical failure threatens customers. The parent should preserve uniqueness and security integrity. It should not use the parent role to become a general judge of the holder's business model, geography, leasing arrangement or transfer strategy. Delegated custody is valuable only if the parent remains thin.

The ROA lifecycle is a continuity lifecycle

A ROA is often treated as a small object in a technical system: prefix, maximum length, origin AS, validity period. In economic terms it is a continuity instrument. It tells relying networks that a particular route-origin claim should be accepted. The creation, alteration, replacement and withdrawal of that instrument can change the usability of a scarce resource. That makes the ROA lifecycle a continuity lifecycle.

Creation is the first risk point. A holder may create a ROA for the exact aggregate and forget that more-specific announcements are used during traffic engineering, DDoS response, regional failover or cloud bring-your-own-address design. A maximum-length value that looks prudent on a clean diagram may break a real mitigation plan. Conversely, a value that is too broad can authorize more-specific misuse if credentials are compromised. The right setting is not a moral choice. It is a risk allocation between hijack resistance and operational flexibility.

Change is the second risk point. Networks evolve. An origin AS changes during a merger, an outsourcing deal, a migration from one data center to another, a sale of address space, a lease termination or a cloud onboarding. A ROA that was accurate yesterday can become a trap tomorrow. If the sequence is poorly timed, old routes may become invalid before new routes are accepted. If validators cache different views, some networks may reject while others pass. If the old and new arrangements overlap, the certification system must allow safe transition rather than a cliff edge.

Withdrawal is the third risk point. A ROA may be removed because the holder no longer authorizes an origin, because a lease ended, because a hijack is suspected, because a transfer closed or because an error must be corrected. Withdrawal can be a legitimate protection against false origin claims. It can also become a shock if done without notice where traffic still depends on the old origin. A market cannot treat every withdrawal as harmless housekeeping.

Expiry and publication health are the fourth risk point. The holder may have done nothing wrong, yet a repository failure, timing mismatch, stale manifest or cache lag can change relying-party views. The resource remains in the database. The route remains announced. The certificate evidence becomes uncertain. That uncertainty is enough for automated systems and risk desks to react.

The remedy is lifecycle discipline. ROA changes that affect live routes should have reason codes, notice where possible, transition windows, rollback capacity and logs. Existing valid state should be preserved unless the security risk of preservation is greater than the continuity risk of change. A registry should not ask merely whether a ROA can be changed. It should ask what live reliance sits behind that change and how to avoid turning a correction into an outage.

Invalid, unknown and the price of a small field

RPKI's economic force is most obvious when a small field creates a large loss. A single origin AS number is wrong. A maximum-length entry does not cover a more-specific route. A prefix was split for traffic engineering but the ROA remained at the aggregate. A delegated publication point has stale data. A holder thought a transfer would preserve the old attestation until the new route was ready, but the overlap did not occur. The result is not a philosophical debate. It is an invalid route.

Invalidity is not uniform. Some networks reject invalids aggressively. Some prefer, warn or monitor. Some cloud and transit teams apply their own overlays. Some customer-facing risk systems simplify the state into a green or red mark. That variation can be worse than a clean outage because it produces partial failure. Customers in one geography can reach the service while others cannot. Monitoring may pass from one vantage point and fail from another. Sales teams may hear complaints before engineers see a universal alarm.

The transition between invalid and unknown is especially important. In the formal validation vocabulary, a route with no covering authorization may be treated as not found; many operational dashboards describe the same commercial condition as unknown. That is not the same as invalid. Unknown may mean a holder has not yet created ROAs, a publication point is unreachable, a transfer is not fully reflected or a migration is waiting for evidence. Invalid is stronger: it means a covering authorization exists but does not authorize the observed origin or length. Yet markets often compress these states. A bank asks for clean evidence. A cloud reviewer wants a clear pass. A public buyer asks whether the route is safe. The nuance matters technically, but the commercial response may still be delay.

Mistaken invalidity is expensive because responsibility is diffuse. The holder may have made the entry. A consultant may have advised it. A seller may have left stale state. A registry portal may have encouraged a risky default. A cloud platform may have required a narrow authorization that did not match the holder's failover pattern. A validator may have cached an older view. The customer does not care. It experiences unreachable service.

The price of the small field is therefore not only the outage. It is the burden of proving that the outage does not reveal deeper title, custody or competence problems. Once a route-origin error enters the risk file, counterparties ask wider questions. Who controls the resource? Who can update the certificate? Could the same issue recur after default? Is the lease enforceable? Can the buyer obtain clean custody at closing? Can the cloud provider rely on the representation?

That is why RPKI governance must treat misconfiguration as a market event, not just an operator mistake. Good tooling helps, but tooling alone is not enough. Holders need safe preflight checks, dry-run views, warnings for risky maximum length choices, transition templates for origin changes and emergency correction paths when a small mistake has large public consequences. The more the market relies on validity, the more institutions must make mistaken invalidity cheap to cure.

Validator propagation and the geography of lag

RPKI is not a single switch thrown in one place. Relying parties fetch and validate data from repositories, maintain local caches and pass validated payloads to routers through their own timing and policies. That distributed design is a strength because routing decisions remain with networks. It is also a source of uncertainty because a certificate change does not arrive everywhere at once.

Propagation lag matters during cutovers. A holder may create a new ROA, see it in one public validator and assume the problem is solved. An upstream, route server or cloud platform may still see the previous state. Another validator may treat the publication point as stale. A third may have a different refresh interval. If the route is already live, the difference between these views can be the difference between a successful migration and a patchwork outage.

The same problem appears during withdrawal. Removing an old origin may be correct, but not every relying network will stop seeing the old object at the same time. If the new origin is not already visible across the relevant validator population, there may be a period when old and new states conflict. In a purely technical account, that is propagation. In an economic account, it is settlement risk. The market has agreed that a resource should move, but the infrastructure that convinces counterparties has not settled uniformly.

Geography sharpens the point. A Latin American network may rely on upstreams in the region, global transit, cloud edge locations, exchange route servers and security vendors whose validator practices are not aligned. A route can be clean from one regional vantage and questionable from another. The business hears, incorrectly, that "the Internet is down in one country." The better description is that certification evidence is not synchronized across the institutions whose routers and risk screens matter.

This argues for validator-aware governance. Certificate-affecting changes should not be planned only by registry database timestamps. They should consider publication cadence, cache behavior, monitoring vantage points, route visibility and counterparty acceptance windows. A transfer or cutover plan that ignores validator propagation is not complete. A notice period that expires before relying parties can reasonably converge is not meaningful.

The solution is not central command over validators. The Internet's resilience depends on local choice. The solution is operational humility: preserve overlap, publish early, monitor widely, avoid unnecessary withdrawal of last-known-good state and give holders enough evidence to explain the transition to clouds, lenders and upstreams. RPKI must remain distributed. Governance must recognize that distributed systems have timing costs.

Transfers need overlap, not cliff edges

Transfers expose the difference between resource entitlement and route-origin continuity. A buyer may acquire an IPv4 block, a seller may sign the papers, the registry may record the change and the money may move. That does not mean the new origin AS is visible as valid everywhere, or that the old origin can be safely invalidated at once. Legal closing and routing settlement are related events, not the same event.

The market needs overlap. The seller's established route-origin state may need to remain valid while the buyer brings up new transit, tests cloud onboarding, updates customers and waits for validator convergence. The buyer may need pre-closing evidence that its intended origin can be authorized quickly after closing. The lender may need comfort that foreclosure or forced sale would not push the block into certificate limbo. Without overlap, the transfer price must include a risk discount for the possibility that a legally acquired block will not be commercially usable when needed.

Overlap is not a blank cheque. It should be bounded by time, prefix, origin and evidence. The seller should not be able to keep stale authorization indefinitely after it no longer controls the relevant routing. The buyer should not be able to obtain a live authorization before it has a legitimate basis to use the resource. But a narrow, documented transition window is different from disorder. It is the mechanism by which a market avoids turning security into a transfer tax.

The same logic applies to mergers, divestitures and corporate restructurings. A group may reorganize subsidiaries without intending any routing change. A data center business may be carved out with the address resources that serve existing customers. A bank may step into control after default. A court may freeze assets while operations continue. In each case, certificate continuity is not a side issue. It is part of preserving economic value.

If a registry treats the certificate as an instantaneous expression of record ownership alone, it will create avoidable cliff edges. If it treats the certificate as continuity evidence tied to lawful control, it can support clean transitions. The registry's job is to verify that the parties have authority, that no double claim is being created and that the planned route-origin change is not fraudulent. It is not to decide whether the buyer's business model is sufficiently virtuous, whether the price is acceptable or whether the region would prefer a different allocation of scarce addresses.

LACNIC's test is practical. Can a holder transfer, finance or restructure address space while preserving route-origin continuity? Can a buyer plan cloud and upstream acceptance before the final cutover? Can a lender model recovery without assuming a certificate cliff? If the answer is yes, RPKI supports market confidence. If the answer is no, RPKI becomes a hidden tax on transfer and finance.

Leasing and suballocation expose the custody gap

Leasing is the hard case because it separates legal holding, commercial use, routing operation, customer dependency and reputation. A holder may lease a block to a hosting firm. The hosting firm may route through its own AS. A managed provider may maintain ROAs. Customers may build services on top. Abuse complaints may hit the lessee. The registry record may still show the holder. RPKI must decide who may attest which origin for how long.

Pretending that leasing does not exist does not make the risk vanish. Scarce IPv4 has a rental market because operators need addresses faster than formal acquisition can supply them, and because holders may prefer recurring revenue to sale. The market can be messy, but opacity is worse. If private leasing remains disconnected from route-origin authority, each participant carries uncertainty: the lessee may lose validity without warning, the holder may remain exposed to a route it no longer watches, and customers may be caught between contract and certificate.

Suballocation adds another layer. A regional ISP may delegate address use to enterprise customers, resellers, content platforms or managed-security providers. Some will need their own origin AS. Some will use the provider's AS. Some will move during customer churn. A rigid certification model that recognizes only the top-level holder and one stable origin will not reflect commercial reality. A loose model that lets any claimed downstream user obtain authorization invites fraud. The governance challenge is to support controlled downstream route authority without turning the registry into a general leasing police force.

The right answer is evidence, scope and continuity. The holder should remain responsible for who may originate the prefix, but it should be able to grant time-bound, prefix-bound route-origin authority that corresponds to real operational use. The lessee or downstream operator should not need ownership theatre; it needs route validity that counterparties can verify. The holder should be able to revoke at contract end, but revocation should be timed to avoid surprising live customers where a cure period or migration window is commercially and technically possible.

This is especially important for smaller networks in the LACNIC region. Leasing and suballocation can be entry tools. They allow a new ISP, hosting firm, financial-technology platform or public-service supplier to obtain usable addresses before it can buy or transfer a larger block. If RPKI governance makes lease-based routing fragile, the burden falls on the networks least able to absorb it. Incumbents with deep address reserves avoid the problem. Entrants rent their way into the market and carry certificate risk.

RPKI should make divided control more legible, not more dangerous. It should show which origin is authorized, by whom, for what prefix and for what period, without pretending that the registry has become the commercial judge of the lease. That is thin coordination applied to a complex market.

Cloud, upstream and lender reliance make soft force hard

RPKI's market power does not come only from routers. It comes from institutions that convert route-origin status into admission, pricing and credit decisions. An upstream carrier may reject invalid routes. A route server may apply filtering. A cloud platform may require clean RPKI evidence for bring-your-own-address onboarding. A public buyer may include routing-security controls in procurement. A lender may ask whether pledged address assets can remain reachable after default. An insurer may treat invalid route risk as a control weakness.

Each actor has a reason. The upstream wants fewer customer-visible failures. The cloud platform wants to avoid onboarding disputed or hijacked space. The public buyer wants resilient service. The lender wants recoverable collateral. The insurer wants fewer unbounded operational losses. None of them has to endorse a registry's political story. They rely on the signal because it reduces their own uncertainty.

Reliance changes the registry's role. If the market treats RPKI status as evidence of usable control, the institution that affects RPKI status influences market access. This can happen even if LACNIC never says it has such power. Economic power often arrives through reliance before it is admitted in governance language. A recordkeeper becomes important because others need the record. A certification provider becomes powerful because others require the certificate.

Lenders are the clearest example. IPv4 collateral is not like a truck that can be seized, stored and auctioned with simple paperwork. Its value depends on recognized holder status, transferability, routing acceptance, reputation, reverse DNS, customer continuity and RPKI evidence. If a lender cannot be confident that route-origin validity will survive default, sale or restructuring, it will reduce advance rates or avoid the asset. Certificate governance therefore affects the cost of capital.

Cloud platforms create another pressure point. A regional company may hold valuable LACNIC-administered space but need a global cloud platform to serve customers efficiently. The cloud's onboarding team will not become a tribunal for Latin American registry facts. It wants clean evidence and clear authority. If the RPKI state is uncertain, the easiest answer is delay. That delay can move customers, revenue and bargaining power toward larger players with more mature custody.

Upstreams and exchange points add daily discipline. If they filter invalid routes, the holder must maintain valid state or accept degraded reachability. This is good when invalidity reflects a true false origin. It is costly when invalidity reflects administrative lag, a transfer timing gap or a lease ambiguity. Soft force becomes hard when enough counterparties apply it at once.

The governance answer is not to ask lenders, clouds or carriers to stop caring about RPKI. That would be perverse. The answer is to make the certificate layer reliable enough that their reliance does not become a channel for arbitrary institutional power. Trustworthy RPKI lowers market cost. Discretionary RPKI raises it.

LACNIC's regional setting makes discretion costly

LACNIC operates in a region where institutional adaptation is a constant fact of business life. Networks cross legal systems, currencies, languages, public-procurement cultures, banking constraints, cable geographies and cloud dependencies. Some markets have strong incumbent carriers. Others rely on small ISPs, cooperatives, campus networks, local hosting firms and managed-service providers. The same RPKI rule may land differently across that landscape.

This diversity does not justify a thicker regional authority. It argues for thinner common coordination. The common layer should protect uniqueness, registry accuracy, security assertions, transfer records, auditability and operational continuity. It should not decide the commercial meaning of every lease, every cloud migration, every corporate restructuring or every customer geography question. RPKI governance should therefore be strict where routing integrity requires it and modest where private contracts or public law should decide.

The danger in any RIR region is that security language becomes a shortcut to institutional expansion. A registry can always say that route-origin security matters. It does. It can say that fraud and hijacking are real. They are. It can say that holders must keep authority evidence current. They must. From those truths, however, it does not follow that the registry should gain broad discretion over how scarce resources are used, financed, leased or transferred. The certificate should protect routes, not enlarge the office.

Latin American and Caribbean markets make the cost of overreach visible because small networks often cannot carry prolonged uncertainty. A large multinational can maintain lawyers, compliance staff and routing specialists in several time zones. A smaller ISP or hosting firm may depend on a few engineers and a narrow cash buffer. If a certification question delays a cloud migration or blocks an upstream change, the smaller firm pays a larger proportion of its capital. Security rules that look equal on paper can be regressive in practice.

There is also a public-sector dimension. Governments in the region increasingly depend on digital services delivered through private networks, cloud platforms and outsourced suppliers. They may not control the number-resource layer directly, but citizens hold them responsible when tax, customs, education, health or identity systems fail. If a certificate dispute impairs reachability, the political cost lands locally even if the trust chain sits in a regional private institution and the relying decisions are made by global platforms.

This is the sovereignty inversion that registry debates often hide. Public actors carry the downside of interruption while private coordination bodies hold critical levers. The answer is not state takeover of RPKI. State control could fragment routing security and politicize validation. The answer is a thinner, reviewable, portable and continuity-preserving certificate layer that lets law, market contract and operator practice handle the issues that do not need to be centralized.

Notice, cure and appealability

The difference between security discipline and economic coercion often lies in cure. If a ROA is wrong, a holder should correct it. If authority is doubtful, evidence should be supplied. If a route-origin claim appears fraudulent, protective action may be needed. But when a certificate-affecting action can impair live reachability, the holder needs notice, reasons, a cure window and a meaningful way to challenge mistakes.

Cure windows should be tied to risk. A suspected hijack may require immediate narrowing or suspension if continuing validity would expose others to acute harm. A stale maximum-length entry or corporate-contact mismatch may allow a slower correction. A transfer transition may require overlap. A lease dispute may require preservation of established routes while parties migrate. Treating every defect as an emergency invites overreach. Treating every defect as harmless invites abuse. The rule must distinguish.

Reasons matter because they let the market understand the event. "RPKI invalid" is a state, not an explanation. Did the holder withdraw authority? Did a certificate expire? Did a repository fail? Did a transfer replace the origin? Did a registry refuse a change? Did a court order freeze authority? Did a suspected compromise require action? Each explanation has a different economic meaning. A lender, buyer, cloud provider or upstream cannot price risk without knowing the category.

Appealability matters because RPKI errors can move faster than human review. If an action was mistaken, the holder needs a channel that can restore validity or preserve reachability while the dispute is reviewed. Appeal does not have to mean a courtroom-style proceeding for every technical change. It means a separated review function, documented evidence, time targets, escalation during live outages and a record that can be shown to counterparties.

Logs are part of appealability. A holder should know who changed a ROA, when, from what to what, under which authority and with what notice. A delegated holder should know parent-certificate events. A hosted user should know account actions that affect publication. A buyer should be able to obtain enough history to verify that it is not inheriting a hidden route-origin defect. Without logs, the market replaces evidence with suspicion.

This is where the doctrine that registries may record but may not rule becomes concrete. A registry can maintain a security service and act against clear technical harm. It may not use certificate control as punishment for unrelated conduct, leverage in a commercial disagreement or a substitute for ordinary legal authority. Notice, reasons, cure and appeal are not bureaucratic luxuries. They are the safeguards that keep routing security from becoming private coercion.

Emergencies without seizure

Emergencies are real. Credentials can be compromised. Routes can be hijacked. A malicious actor can obtain access to a hosted account. A holder can disappear while customers remain live. A court order can require preservation. A natural disaster can force traffic to a different origin. A registry that cannot act quickly in such cases would be irresponsible. The question is how to design emergency exceptions without turning them into a general seizure tool.

The first limit is scope. Emergency action should address the route-origin danger, not every surrounding dispute. If an unauthorized AS is being validated, narrow the authorization. If a certificate publication point is compromised, suspend or replace the affected material. If a holder cannot access its account during a disaster, create a verified temporary correction channel. Do not use the emergency label to revisit resource entitlement, leasing morality, regional use or transfer politics.

The second limit is time. Emergency measures should expire or move into ordinary review quickly. A temporary ROA, a temporary freeze on destructive changes, a temporary restoration of last-known-valid state or a temporary delegated-certificate repair can protect customers while facts are checked. If the measure becomes indefinite, it is no longer an emergency exception. It is a new control regime.

The third limit is visibility. The affected holder, relevant counterparties and later reviewers should be able to see what happened. This does not require exposing sensitive security details to the world. It does require enough information for the holder to understand the action and for the market to distinguish fraud response from arbitrary disruption. A black box may be convenient in the moment; it is costly once lenders, clouds and customers ask what happened.

The fourth limit is reversibility. Emergency action should prefer preservation of last-known legitimate reachability over irreversible destruction. If there is uncertainty, the safer default is often to keep existing valid routes working while blocking new suspicious changes. This will not be correct in every hijack case, but it should be the default question: which option protects the most legitimate reliance while facts are verified?

Emergency authority is where institutions reveal their true theory of power. A narrow registry treats emergency action as a duty to preserve routing continuity and prevent fraud. A sovereign-style registry treats emergency action as proof that it can decide the fate of the resource. The first is compatible with the Internet's voluntary order. The second is not.

For LACNIC, the credibility of RPKI will depend partly on this boundary. If holders believe emergencies will be narrow, documented and reviewable, they will adopt and rely on the service. If they fear emergency labels can become discretionary control, they will price the risk, avoid reliance where possible or seek alternative structures. Security trust is not built by asking holders to trust the institution. It is built by limiting what the institution can do.

Routing continuity as the anchor rule

The central principle should be routing continuity. Not institutional convenience. Not policy theatre. Not symbolic authority. A live network using a recognized resource should not be made unreachable unless preserving reachability would create a clear and greater security harm. This does not mean every route must be accepted forever. It means that changes to certification state should be judged by their effect on legitimate traffic as well as by formal record status.

Routing continuity is the missing bridge between security and market economics. RPKI exists because false origin claims damage reachability. The cure should not create avoidable reachability failures of its own. A system that prevents hijacks but casually produces mistaken invalidity will lose confidence. A system that maintains continuity while correcting bad state will gain confidence. The market can price disciplined security. It heavily discounts arbitrary fragility.

Continuity requires evidence of the last stable state. Which ROAs were valid before the dispute? Which routes were visible? Which customers relied on them? Which origin AS was historically used? Which transfer or lease event is driving the change? Which validators saw what and when? This evidence should not be buried. It is the factual basis for deciding whether to preserve, narrow, overlap or withdraw authorization.

Continuity also requires separation between certificate state and unrelated disputes. Fee issues, paperwork gaps, policy disagreements and commercial conflicts should not automatically disturb live route-origin evidence. They may need notation. They may need review. They may even justify limits on future changes. But breaking existing validity is a severe act. In the economics of critical infrastructure, denial of continuity is not clerical. It is coercive unless justified by a clear routing-security threat or lawful command with safeguards.

Portability follows from the same principle. A holder trapped in one hosted environment, one parent certificate or one registry office has limited bargaining power. If the certification layer is portable under defined conditions, the holder can survive institutional failure, capture, dispute or service degradation. Portability does not mean duplicate global truth. It means that recognized holder state and related security assertions can move through a lawful transition without making customers pay for institutional conflict.

The narrow-ledger doctrine points to the same conclusion. The registry exists to protect uniqueness, accuracy, security assertions and continuity. It does not exist to control capital, customer geography, leasing models or moral narratives. RPKI should be the cleanest example of that restraint: a strong security service whose power is limited precisely because markets depend on it.

Number Resource Society and the post-gatekeeper model

The positive future model is the Number Resource Society. Its significance is not branding or institutional rivalry. It is the structural idea that a global number-resource system should reduce dependence on single points of discretion. NRS frames decentralization as systems engineering: exit instead of enforced permanence, portability instead of lock-in, redundancy instead of monopoly and mechanisms instead of moral language. RPKI governance risk shows why that model is necessary.

In a post-gatekeeper model, the holder's ability to maintain route-origin validity would not depend on a single office's broad discretion. The common layer would still protect uniqueness and security integrity. It would still prevent two incompatible claims from being treated as the same truth. It would still require evidence that the party making a route-origin assertion has lawful control. But the system would be designed so that custody can move, review can occur and continuity can survive institutional stress.

For RPKI, that means several practical commitments. Hosted custody should be convenient but not trapping. Delegated custody should be available without arbitrary parent-key interruption. ROA lifecycle rules should favor continuity during lawful change. Mistaken invalidity should be curable quickly. Transfers and leases should have time-bound overlap where operational reality requires it. Lenders, clouds and upstreams should be able to rely on the signal because the signal is disciplined, not because the registry is treated as an oracle.

This is not anti-security. It is pro-security because a security system that holders fear will not be fully trusted. If RPKI becomes associated with surprise invalidity, custodial lock-in or opaque suspension, operators will treat it as another registry risk to hedge. If it becomes associated with portable custody, audit trails, cure, appeal and continuity, operators will treat it as a bankable layer of infrastructure. Adoption and legitimacy follow architecture.

NRS is also a constructive answer because the old debate offers two bad choices. One bad choice is private gatekeeper sovereignty, where a registry office controls critical attestations while invoking community language to avoid liability. The other is state takeover, where governments may turn routing security into jurisdictional command. The Internet needs neither. It needs a thin common layer, local validation, voluntary counterparty acceptance and durable exit.

The cutover room from the opening is therefore the real constitutional chamber. Not because the engineers are writing high theory, but because they are where theory becomes cost. If one mistaken attestation can delay revenue, weaken collateral, pause a cloud migration and threaten customer reachability, then RPKI governance has crossed from routing hygiene into institutional economics. The certificate may be technical. The risk is not.

The correct test is simple. Does a rule protect the running Internet, or does it enlarge the gatekeeper? Does it preserve legitimate routes while correcting false ones, or does it turn uncertainty into leverage? Does it give holders a way to cure, appeal and exit, or does it ask them to trust an office whose decisions they cannot escape? LACNIC's RPKI future should be judged by those questions. A registry may record. It may coordinate. It may support security assertions. It may not let a certificate become a throne.

Sources and further reading

These references provide the article's public doctrine and background context. They are used for institutional-economic framing, not for adopting any registry or official-sector narrative.