Summary

  • ARIN’s 28 July 2026 release added API-key authentication through an Authorization header. The next day, ARIN closed ACSP Suggestion 2022.5, while explicitly continuing to accept tokens in URL parameters.
  • The public record reviewed here confirms the safer option and a recommendation to switch, but does not state a sunset date, migration milestone, legacy-call count or adoption rate. Closing the request therefore records feature delivery; it does not show that the old transport has been retired or that clients have migrated.

One request, two different lifecycles

A routine registry call asks the server to do two things: identify the record being requested and establish that the caller is authorized to reach it. Reg-RWS can automate work that includes RPKI and IRR management, reassignments and reallocations, and net-block updates. For years, the documented request could carry an API token in the URL query. In July 2026, ARIN added a second route: the request can identify the resource in the URL and carry the key separately in an Authorization header.

The functional result may be the same. The exposure surface is not. A URL is routinely copied into browser history, request logs, proxy records and diagnostic material. ARIN’s own August explanation identifies browser history, server logs and proxy logs as places where a URL-carried key could persist. Moving the key to a header reduces the chance of that accidental spread. It does not make credentials magically invisible: an application, proxy, trace collector or support bundle can still record an Authorization value if its operators configure logging carelessly.

The practical gain is narrower default exposure, not the end of credential management.

The dates make the distinction unusually clear. ACSP Suggestion 2022.5 was submitted on 11 February 2022. It asked for an alternative to a token in REST URLs and warned that systems which log full URLs could expose a valid token to people with access to those logs, potentially enabling unauthorized access. The suggested timeframe was “Not specified.” On 23 February, ARIN said an HTTP header was the best solution, put the work forward for prioritization on the 2023 Engineering Roadmap, and said the suggestion would remain open until implementation.

On 28 July 2026, ARIN announced that RESTful calls could use an Authorization header with the ApiKey scheme. On 29 July, its closeout for 2022.5 said the favored alternative had been deployed and that ARIN would continue accepting API tokens as URL parameters. The closeout treated implementation of the requested alternative as completion. It did not say that URL support had ended. The distinction is confirmed in the 11 August explainer and again in ARIN Bits on 29 September: URL transport remains acceptable for now, will eventually be retired, and should be replaced.

That sequence contains two clocks. The first measures delivery: a suggestion is recorded, evaluated, implemented and closed. The second measures migration: clients discover the change, update their software, validate the new request form, move credentials out of URLs, and eventually stop using the old path. The first clock has a clear endpoint in the public record. The second does not yet have a published date or a reported measure.

This is not a criticism of closing the suggestion. A request to add an alternative can be complete when that alternative works, even if existing clients need time to use it. The governance question begins after that closure. If the old method is still supported, the transition is no longer just a code change; it is an operating contract between ARIN and the organizations whose scripts, automation platforms and service providers call the registry.

Why the location of a key matters

An API key is not ordinary request data. ARIN describes it as a secret used to identify a caller and says some RESTful actions require the account to be linked to a Point of Contact with the relevant authority. If a token appears in the query component, it travels with the resource address. Systems that keep or copy URLs can preserve it beyond the process that made the request. ARIN’s account of browser history and server and proxy logs describes precisely this path of accidental retention.

The header method changes where the caller places the credential, not the resource being requested. ARIN’s documented form uses the Authorization field and the ApiKey scheme. The operator’s client, automation tool or provisioning service must send that field reliably while preserving the endpoint and request semantics. The URL no longer has to include the secret as an additional query parameter.

There is a useful standards parallel, with a boundary that matters. The IETF’s RFC 6750 concerns OAuth bearer tokens, not ARIN’s ApiKey scheme. It recommends an Authorization header and discourages putting bearer tokens in URI query parameters because URLs are likely to be logged. That is not a claim that Reg-RWS uses OAuth or is governed by that RFC. It shows that the exposure distinction is a known property of HTTP operations: sensitive values embedded in a URI are more likely to enter general-purpose records than request credentials placed in a dedicated field.

A header is not a complete security policy. An administrator can log all request headers; a tracing product can capture them; a debugging dump can preserve them; a client can put a secret back into a URL before handing off a redirect. Header adoption should therefore be paired with filtering of Authorization values from logs, protected storage of keys, certificate validation, and a way to replace a key if it is exposed. Those are operator controls, not new ARIN features asserted by this article.

The migration burden is uneven. A team with one maintained client may change a configuration field and test a few calls. A network operator with older scripts, vendor software, scheduled jobs, outsourced operations and a separate RPKI or IRR toolchain may need to find every place where the query form is assembled. That work is invisible to the registry unless ARIN measures it. It is also a reason not to interpret continued compatibility as proof that a customer has chosen the less secure method after being informed.

What the public record establishes

The evidence supports four separate status statements:

  1. Header authentication is available for Reg-RWS calls. ARIN’s July release and current method documentation describe it.
  2. ARIN prefers that method and recommends migration. Its August technical explainer and September roundup say so.
  3. URL-token calls remain accepted in the public documentation reviewed. The 29 July closeout says this directly; the current RESTful Methods page repeats it.
  4. The reviewed material does not publish a retirement date, a sequence of migration milestones, a count of calls still using URL parameters, or a rate of header adoption.

The fourth statement is deliberately bounded. It means those measures were not found in the cited public sources; it does not establish that ARIN has no internal data, no private plan, or no customer conversations. Nor does the source record describe a compromise. The 2022 suggestion explains a plausible exposure mechanism. ARIN’s 2026 materials explain why it prefers the alternative. Neither reports that a token was actually disclosed or that an unauthorized registry action occurred.

That distinction protects the analysis from two opposite mistakes. One would be to call the four-year interval proof of failure. The suggestion itself gave no timeframe, and the public record shows a deployed alternative. The other would be to treat closure as proof that the risk has disappeared. The closeout explicitly preserves URL support, and the September recommendation describes a future retirement without a date. A safer option can exist while a risky compatibility path remains live.

Compatibility is a service commitment

Keeping the old method temporarily is often the responsible choice. An immediate cutoff could break an unattended process that is important to resource administration. Failed automation may delay changes to registry records, RPKI or IRR operations, reassignment work, or other tasks that customers have built around Reg-RWS. The public sources establish those broad uses, but do not quantify the harm of a particular interruption. The relevant point is that a registry API is part of operators’ working infrastructure, not a disposable demonstration endpoint.

Compatibility also has a cost. Each accepted request shape creates a state that documentation, support staff, client maintainers and customers must understand. If one method is recommended and another remains functional indefinitely, “preferred” can become an instruction without a decision date. New integrations may continue to copy old examples; dormant scripts may never be revisited; internal security reviews may mark the issue as addressed merely because a header option exists.

The correct response is not to assume that ARIN should publish customer-level telemetry or expose usage data that could itself be sensitive. A public transition can be made observable without publishing identities or credentials. At a minimum, ARIN could state the phases it intends to use, the event that would start a deprecation clock, how much notice it plans to provide, how it will announce compatibility changes, and what evidence would cause it to extend the window. If a date has not been chosen, saying that no date has been set is more useful than leaving customers to infer one from “eventually.”

The public evidence reviewed here does not show that ARIN has committed to any such milestones. They are recommendations for making a future transition predictable, not descriptions of a current ARIN plan. The distinction matters because announcing a date can create an obligation. If ARIN has not made that decision, an analyst should not write as though it has.

A deprecation record needs more than a feature note

A technically complete migration is not simply a working header example. Operators need to know which endpoints and tools accept it, whether any client library has a known incompatibility, how errors appear when the header is missing or malformed, and whether a request can accidentally send both the header and a URL token. ARIN’s public guides answer the core syntax question. The material reviewed for this article does not provide a public client-by-client inventory or an adoption dashboard.

Such a dashboard need not reveal a customer’s identity. Aggregate counts can show whether calls using the new field are replacing calls using the query parameter, whether a long tail remains, and whether migration is concentrated among a small number of clients. A deprecation notice can pair those measures with dates: announcement, end of new-client examples, start of warnings, a final compatibility review, and a proposed retirement window. If a measure cannot be published without exposing operational data, ARIN could instead state the decision criteria and publish whether each phase has been met.

For customers, waiting for a universal date is not a security strategy. The recommendation is already clear: remove the API key from URLs where the client supports header authentication. Teams can search code and configuration for query-string assembly, update shared libraries first, ensure that the Authorization field is redacted in logs, test representative read and write operations under their own change controls, and rotate exposed keys. These are prudent steps regardless of when ARIN retires the old path. The key is to test the migration rather than simply replace a string and assume every client behaves identically.

The registry should also avoid turning the end date into a surprise. A staged process gives operators a chance to surface clients they do not own, contact vendors, update runbooks and verify monitoring. Warnings can precede rejection; rejection can be scoped to a later milestone; a documented exception process can handle a genuine dependency without quietly making a temporary path permanent. The source material does not say ARIN has selected these controls. They are the usual ingredients of a change whose compatibility consequences extend beyond the organization implementing it.

The meaning of “closed”

The 2022 suggestion asked for a safer way to authenticate REST calls. ARIN supplied one, then closed the item. In that narrow sense, “closed” is accurate. But a tracking status is not a migration metric. It tells readers that the requested alternative was implemented; it does not answer how many callers still use the old form, what notice period will apply, or when continued acceptance ends.

For ARIN customers, the practical conclusion is uncomplicated: use the header path in new and maintained clients, and treat URL support as compatibility rather than as a security-equivalent option. For ARIN, the remaining governance task is to make the eventual retirement legible enough that a recommendation can become a coordinated migration. The evidence does not justify alleging a breach or assigning blame. It does justify asking what public signal will mark the point when the second clock starts.

Sources