Summary

  • ARIN’s 28 July release says the restriction on creating non-human service accounts was removed and that ARIN now accepts them, closing Suggestion 2022.11.
  • The suggestion record preserves the original accountability question: individual API-key ownership made it easier to determine which user changed the registry, while role or service accounts made automation practical.
  • Current public guidance still tells every manager to create an individual account with an individual email, and the MFA FAQ says accounts cannot be shared. The API-key guide adds that keys do not expire automatically and inherit authority from a linked POC.
  • ARIN should publish a service-account operating profile covering the principal’s purpose, accountable custody, POC linkage, MFA and recovery, API-key lifecycle, action attribution and deactivation—without exposing credentials or private operator identities.

One product state, two instruction states

The release note is unambiguous about the product event. On 28 July 2026, ARIN removed the account-creation restriction that had prevented non-human service accounts and began accepting them. A day later, the page for ACSP Suggestion 2022.11 marked the request closed because the work was complete.

For an operator, that change matters. A scheduled system that updates registration records or retrieves restricted reports should not have to impersonate an employee whose name, mailbox and job tenure belong to a human employment cycle. A machine principal can survive a shift change. It can be named for one automation purpose, recorded in a credential inventory and disabled without closing a person’s ordinary account.

Yet a reader following ARIN’s current instructions reaches a different operating picture. The Account Management guide says each and every individual who manages organisation or resource records should create an ARIN Online account. It says all accounts should use an individual email address, not a role or group email. It then describes a one-to-one relationship between an account and a personal Point of Contact, with many accounts able to link to a role POC.

The MFA FAQ is even more explicit about the existing human model. ARIN Online accounts are intended for individual users, it says. With MFA enabled, sharing is not possible; every user must create a separate account. Linking each user to a role POC is the recommended way to provide organisational access without sharing login credentials.

Neither page mentions the new service-account class. That omission does not prove the feature is defective. The live account-creation flow may apply a separate rule. Instructions may appear after login. ARIN support may have an operating procedure that is not public. A non-human principal may also be perfectly compatible with the no-sharing rule: a machine identity is not the same thing as several people using one interactive login.

The problem is documentary and operational. The implementation state changed, while the public account model still has only one described subject—the individual user. An organisation cannot tell from those pages which old instructions remain binding for the new class and which have been superseded.

The original suggestion did not erase attribution

Suggestion 2022.11 was submitted in April 2022 to support non-human service-account users for programmatic RESTful API integrations. ARIN’s first response recorded the central design trade-off unusually clearly.

When the RESTful APIs were introduced, ARIN considered whether API keys should be managed by individuals or assigned to potentially shared role accounts. The earlier consensus favoured individual management because ARIN needed to determine which users made changes if problems occurred. ARIN nevertheless agreed that role or service accounts would help customers and said relatively little work was needed to remove the system restriction.

That history matters because the 2026 closure resolves the admission question, not the entire attribution question. Accepted says a non-human account may now exist. It does not say how ARIN represents the responsible organisation behind it, how a customer distinguishes an automated action from a human action, or which protected record joins the machine principal to the people authorised to maintain it.

There is no contradiction in wanting both automation and attribution. The accountable actor need not be one employee’s name embedded in every API request. The record can distinguish at least three things: the service-account principal that authenticated, the organisation or role that authorised it, and the operation that was performed. Human custody can be protected within ARIN and the customer organisation rather than exposed in Whois or a public event feed.

The dangerous shortcut would be to treat a service account as a shared nickname. If five engineers all know the same interactive password and recovery answers, the account’s stability has been bought by weakening individual traceability. But the checked sources do not show that ARIN permits that design, and the MFA FAQ says account sharing is not possible. The safer reading is that the new class needs its own custody instructions precisely so customers do not confuse a durable machine principal with a communal login.

An API key is not the whole principal

ARIN’s API-key page fills in another part of the operating surface. A key is created inside an ARIN Online account and is used to identify the account in interactions outside the portal. One key can support repeated interactions, or a customer can create multiple keys to track different requests or retrieve reports. The full secret is displayed only at creation; afterwards ARIN shows its prefix and creation date.

The key does not expire automatically, although it can be deactivated. RESTful requests also require the underlying account to be linked to a POC with authority over the object or request. These are important controls. They show that possession of a string is not the complete authorisation model and that deactivation is available.

They also make the missing service-account profile more consequential. If the account is non-human, whose email is used for creation and notices? Is a unique role mailbox acceptable even though the general guide tells all accounts to avoid one? Does the service account link directly to a personal POC, a role POC, or a specifically constrained combination? Who holds the MFA method and recovery codes? Does ARIN expect a human to use the interactive portal only for setup and recovery? Which event record distinguishes the service account from the person who last changed its custody?

Public documentation need not reveal customer answers. It should define the allowed model. Without that distinction, a conscientious operator faces two bad options: treat the new release note as overriding older security guidance by implication, or obey the individual-account wording so literally that the new service-account feature has no stable organisational identity.

Automatic expiry is a similar example. A non-expiring key is not necessarily a neglected key. Long-lived automation may need continuity, and an operator can rotate or deactivate keys on a shorter local schedule. The evidence does not show that any ARIN customer leaves keys unchanged or that ARIN lacks event logs. The missing public instruction is the responsibility boundary: what ARIN enforces, what the customer must inventory, and which staff-change or incident events should force review.

A service-account operating profile would close the handoff

The repair should not be a long security policy drafted in response to every imaginable customer architecture. A compact, versioned account-class profile would be more useful.

It should first name the principal. Non-human service account should have a canonical meaning, a list of intended programmatic uses and a list of actions that remain human-only. It should state whether interactive login is allowed for setup or recovery and repeat, without ambiguity, whether multiple humans may ever share that login.

It should then reconcile the email and POC rules. If a unique service mailbox is allowed, ARIN should say so and distinguish it from a public role contact or a shared human login. If the account still needs a personal POC link, the profile should state why and how that link survives a staff departure. If authority comes through a role POC, it should explain the linkage without implying that everyone behind the role holds the credential.

MFA and recovery need an organisational custody model. A service account may use a passkey, authenticator, protected vault or another supported method, but the public profile should say what property matters: controlled access, named responsibility inside the organisation, recoverability, prompt removal when responsibility changes, and a record of the recovery event. It need not publish which person or device performs those functions.

The profile should also join the API-key lifecycle. Key name or prefix, creation time, intended automation, accountable owner, last review, rotation trigger, deactivation state and affected integration can form a customer-visible inventory without exposing the key itself. ARIN can label which fields it records and which must remain in the customer’s system.

Finally, the profile should preserve attribution and termination. An action record can identify the service-account class and operation while keeping human custody private. A disablement procedure can specify whether keys are deactivated before or with the account, how an organisation confirms that no automated path remains, and how an erroneous shutdown is corrected. None of this requires a public approval before every API call.

Documentation is part of the feature

It would be easy to dismiss the remaining pages as stale help text. That understates their function. An account guide is where a small network learns what kind of identity it is allowed to create. An MFA FAQ defines what no sharing means. An API-key page tells an operator which secret persists and where authority comes from. Together they are the public operating contract around a feature that can alter registry records and reach routing-security services.

The correct standard is not that every page changes in the same minute as a release. It is that a consequential new account class carries an explicit transition. A temporary banner could say which individual-user rules do not apply to service accounts. A linked profile could show the new model. The old paragraphs could remain for human accounts if they are accurately scoped.

ARIN has already supplied the most important fact: non-human service accounts are accepted. It has also preserved the reason the earlier restriction existed. Joining those two states would make the release safer to adopt because operators would not have to invent the missing custody model from scattered sentences.

Sources