Why the Account Is the Whole Game
Two-factor authentication means a login requires something beyond the password — a rotating code from an authenticator app, a push notification, or ideally a hardware security key — so that a stolen or phished password on its own is not enough to move, delete or repoint your domains.
On a registrar account that matters more than almost anywhere else, because everything below the registry layer collapses into that one login. Registrar lock is a toggle inside it. The transfer authorization code is retrievable from inside it. The nameservers are changed from inside it. The registrant contact email, where every confirmation and every reset link is delivered, is edited from inside it. An attacker who holds the account does not have to defeat those controls one by one; they inherit all of them at once.
The boundary of what that account can reach is drawn by a single convention. In EPP, the protocol registrars use to talk to registries, the registrar is the client and the registry is the server, and ICANN's status-code reference follows RFC 5731 section 2.3 in reserving client-prefixed statuses to registrars and server-prefixed statuses to registries. Your login governs the first set — clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited — and cannot touch the second. That is the exact line where account security stops mattering and registry-level protection starts.
This is exactly why security analysis of domain theft keeps landing on the same conclusion: any registrar-level control can be disabled by whoever reaches the registrar account. The login is not one control among several. It is the control plane.
What the Policy Record Actually Says
There is no ICANN consensus policy requiring registrars to offer two-factor authentication to registrants that I have been able to locate. Two-factor authentication is a registrar product decision, not a contractual guarantee, and that has consequences: it means availability, factor types and enforcement vary by registrar, and it means nobody is obliged to support the strong options.
The strongest statement from the ICANN community is a recommendation, not a requirement. SSAC SAC074 (3 November 2015), on credential management, states in its Recommendation 3 that future Registrar Accreditation Agreement deliberations "should encourage stronger authentication practices, specifically the use of multi-factor authentication," and notes that single-factor passwords are no longer considered sufficient protection. Read the verb. It encourages a future negotiation; it does not bind a registrar today.
The registrant-facing guidance is older and blunter. SAC044 (5 November 2010) tells registrants to use multi-factor authentication where the registrar supports it, and to keep the token safe from loss, damage or unauthorized use. Fifteen years later that is still the operative advice, which tells you something about the pace of change here.
The Factors Are Not Equivalent
Having two-factor authentication switched on is not by itself a security posture. Which factor you use decides which attacks you survive.
SMS one-time codes. Vulnerable to SIM swap — an attacker takes over your phone number and receives your codes — and to real-time relay by phishing kits. Better than a password alone. The worst of the three by a wide margin, and a poor choice for anything valuable.
TOTP authenticator apps. TOTP is a time-based one-time password, the rotating six-digit code in an authenticator app. It removes the SIM-swap exposure entirely, which is a genuine improvement. It does not remove adversary-in-the-middle phishing, where a lookalike login page relays your password and your six-digit code to the real site in real time. Commercial phishing kits built specifically to defeat one-time-code authentication are documented and sold as a service; this is a commodity attack, not a theoretical one.
FIDO2 and WebAuthn security keys. The credential is cryptographically bound to the site's origin, so a lookalike domain cannot obtain a usable assertion no matter how convincing the page is. This is the only widely available factor that resists real-time relay. Whether your particular registrar supports hardware keys rather than TOTP only is a question to answer before you move a portfolio there, not after.
Where Two-Factor Authentication Does Not Help
Knowing the ceiling on a control is as useful as knowing what it does.
- Support-desk social engineering. In the e-hawk.net theft of December 2019 the attackers never touched the owner's login. They persuaded registrar staff over a messaging app that they had bought the domain. No amount of authentication on the registrant's account defends against a registrar being convinced to act; only an out-of-band process at the registry does.
- Account recovery paths. If the password reset goes to an email account with weaker protection, that weaker account is your real credential and the second factor is decorative.
- Resellers and sub-accounts. A domain held through a reseller inherits the reseller's account security, not yours.
- API credentials. Registrar API keys typically bypass interactive authentication altogether. A key committed to a repository is a full-access credential with no second factor attached.
- DNS hosting. Strong authentication at the registrar does nothing for a separate DNS provider account, where the zone contents actually live.
The Contact Email Is Part of the Control
SAC044 makes a recommendation that sounds like housekeeping and is not: host the domain's contact email outside the domain being protected and outside the registration account. The reasoning is mechanical. Every notification a registrar sends about a lock removal, a transfer request or a password reset goes to that address. If the address lives on the domain under attack, an attacker who repoints DNS captures the warnings along with the domain, and the first thing you learn about the theft is that your site is gone.
The same logic applies to the second factor itself. Recovery codes stored in the mailbox that is the recovery channel, or in the same password manager entry as the password, do not add a factor — they add a longer password. And a registrar account protected by a hardware key whose reset path is an unprotected personal webmail account is protected to the strength of that webmail account.
Map the recovery chain before congratulating yourself on the login. It is almost always the weakest link and almost never the thing that gets reviewed.
Common Mistakes
The patterns repeat across portfolios of every size:
- SMS as the only second factor on names the business cannot operate without.
- Two-factor authentication on the registrar account but not on the email address receiving every registrar confirmation and reset link.
- The company's primary domain registered to an individual employee's personal email account, which leaves when they do.
- The contact email hosted at the domain being protected, the specific failure SAC044 warns about.
- One shared login for the whole team, with no per-user attribution and no way to revoke one person's access after they leave.
- Recovery codes stored in the same place as the password, or in the mailbox that is itself the recovery channel.
- API keys treated as configuration rather than as credentials, scoped broadly and never rotated.
The shared-login habit is the one I would break first. SAC074 specifically recommends individual user accounts rather than shared credentials, and without per-user accounts there is no audit trail — which means that after an incident you cannot even establish who made the change, let alone prove it to a registrar or to counsel.
What Good Practice Looks Like
For a portfolio that matters:
- Hardware security keys for every account holder at the registrar, with at least two keys enrolled so that losing one is an inconvenience rather than a lockout.
- A dedicated, monitored email address for registrar correspondence, hosted on a different domain and itself protected with hardware keys, per SAC044.
- Separate accounts per person rather than a shared login, and separate registrant, technical, administrative and billing contacts, per SAC044.
- API keys scoped narrowly and rotated on a schedule; treat every key as a password with authentication disabled, because that is what it is.
- Account credentials and recovery codes escrowed with a defined recovery process that has actually been tested.
- Continuous monitoring of RDAP or WHOIS status codes and nameserver records, which SAC044 lists as a core registrant practice.
SAC074 goes further and treats the whole credential lifecycle — creation, distribution, storage, change, renewal, transfer, revocation, recovery and destruction — as the unit of analysis, pointing to established frameworks such as ISO 27000 and PCI DSS and recommending encrypted credential transmission, brute-force detection, and change procedures with validation and logging. For an organization already running a security program, the domain registrar account should be inside it, not an exception managed by whoever set it up.
The Ceiling on Account Security
Two-factor authentication is the single most effective change most registrants can make in an afternoon, and it should be on every registrar and DNS account you hold. It also has a hard ceiling, and the ceiling is structural rather than a matter of doing it better: every control it protects is still a registrar-level control, and registrar-level controls can be removed by the registrar.
That is why the layering advice keeps ending in the same place. Strong authentication protects the account. clientTransferProhibited and clientUpdateProhibited protect the record against outsiders. Neither survives a registrar acting on a convincing request from someone who is not you. Only serverTransferProhibited and its companions — set by the registry, unclearable by any registrar — force a change through a human being at the registry with a phone and a security phrase.
Do the account hygiene first, because it is free and it stops the common attacks. Then, for the names whose loss would end the argument about budgets, buy the lock that does not depend on your account at all.