Summary

  • ARIN’s 9 October password reminder says it was not prompted by an incident or suspicious activity, and asks users who have not changed a password “recently” to update it without defining a period.
  • The post combines password reuse, entry on an untrusted device or network, and an older, weaker password. Those conditions are not interchangeable: suspected exposure, evidence of compromise and a strength upgrade have different triggers.

An advisory is not an expiry rule

The sentence at the centre of ARIN’s October cybersecurity post is a request, not a countdown. Christian Johnson, ARIN’s chief information security officer, asks users who have not changed their ARIN Online password “recently” to take a moment to update it. He also says plainly that the message is not a response to an incident or suspicious activity. The post names no date threshold, no account cohort that must act, and no lockout deadline.

That distinction matters. A security team can recommend a low-cost precaution without announcing that a control has failed. But a reader cannot tell from “recently” whether the intended horizon is months, years or simply “long enough that you no longer trust the secret.” ARIN’s public account guide explains how individual users manage records, resource requests and transfers, and reach functions such as DNSSEC and RPKI. It says all ARIN Online accounts must use multifactor authentication and that each person managing organisational or resource records should have an individual account.

The guide does not give a password-age interval for customers.

The evidence therefore supports a narrow description: ARIN has issued a voluntary password-refresh reminder with no public time threshold in the materials reviewed. It does not support saying that ARIN forces customers to rotate passwords, that the account system is overdue for a change, or that an account was compromised.

Three risks do not share one clock

Johnson gives three reasons a password might deserve attention. A different website may have been breached while the user reused the same secret. A user may have typed the password on a device or network they did not trust. Or the password may be old and weaker than a longer one chosen today. Each is plausible; none is a reported event at ARIN.

The first two are exposure questions. If the same password was used at a breached site, every account using it is at risk; changing only the ARIN copy does not repair the other reuse. If a password was entered on a device that may have captured it, the relevant question is whether the secret and session could have been observed. A time-based reminder can prompt action, but it cannot tell a user which other accounts need attention or whether an active session should be reviewed.

The third example is different. A password can be weak without being known to an attacker. That calls for replacing it with a strong, unique secret—ideally one generated and stored by a password manager—not for treating age itself as proof of compromise. ARIN’s post makes this strength case too: it recommends a long password, warns against recycling an old one with a small variation, and suggests password-manager use.

ARIN Online is more than a newsletter account. The public guide describes record management, requests for Internet number resources, transfer requests, and access to DNSSEC and RPKI functions. Users link personal accounts to Points of Contact associated with an organisation; those links determine the access needed to manage records. That makes the integrity of the account consequential for operators and members. It does not mean that a stolen password automatically changes routing, nor that any such misuse has occurred.

A benchmark, not a compliance verdict

NIST’s final SP 800-63B-4 offers a useful comparison. For verifiers and credential service providers within its scope, it says not to require subscribers to change passwords periodically, while requiring a change when there is evidence that an authenticator has been compromised. Its customer-experience guidance likewise discourages arbitrary periodic changes and emphasises distinct passwords and support for password managers.

That is a design benchmark, not a claim that NIST rules govern ARIN. More importantly, ARIN’s post is advice. A voluntary reminder does not by itself contradict a rule against forced periodic changes. The difference becomes material if an organisation turns a general recommendation into a mandatory deadline, or treats elapsed time as evidence that an account is compromised. The public materials reviewed show neither at ARIN.

The better question is not whether every user should ignore a refresh reminder. It is whether the reason for action is clear. A person who suspects exposure should change the secret promptly and check the relevant account’s recovery and session controls. A person whose password is merely old should upgrade it to a long, unique one. ARIN already supports MFA through an authenticator app, SMS and a security key or passkey; its CISO ranks the security key/passkey option strongest. The MFA FAQ also documents one active method per account and recovery through a one-time code or an assisted identity check.

Recovery deserves attention when a user changes an authenticator, because the ability to regain access is part of the control.

Sources