Three different controls protect a domain from being taken over, and people often mix them up. A registrar lock stops transfers at the registrar. A registry lock adds a second lock at the registry, which is harder to change. Multi-factor authentication protects the account that can change either of them. You want all three for a domain you cannot afford to lose.
The door, the deadbolt and the alarm
Your front door has a lock. It is the first thing a visitor meets, and you open it every day. Then there is the deadbolt, which you use only when it matters, and which takes an extra step to open. And there is the alarm, which does not stop anyone from trying the handle, but makes sure somebody notices the one who gets inside with a stolen key.
Registrar lock is the lock on the door. Registry lock is the deadbolt. MFA is the alarm and the key check.
Registrar lock
A registrar lock is set by you, or by your registrar on your behalf, in the account. In registry data it appears as a status such as clientTransferProhibited. While it is on, the domain cannot be transferred to another registrar.
It is easy to switch on, and easy to switch off, and that is both its strength and its weakness. Anyone who controls your account can turn it off. It is the lock on the door, and it works against casual mistakes and simple attacks. It does not stop someone who has your login.
Registry lock
A registry lock is applied at the registry, which is the organization that runs the TLD. In registry data it appears as statuses such as serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited. To change the domain, the lock has to be lifted first, and lifting it usually requires a check outside the normal account login, such as a call back or another form of verification.
That extra step is the point. Even someone who gets into your registrar account cannot quickly move or change the domain. Registry lock is offered by some registries, through some registrars, and often for a fee. Not every TLD has it. Ask.
Multi-factor authentication
MFA protects the account itself, so that a stolen password is not enough. It is the control that decides who can reach the other two. It should cover the registrar account, the email address that receives account recovery messages, and any API keys.
For automated access, the idea is the same, in a different form. Give each script or agent the smallest key that does the job. AiVikings.ai supports read-only API access, which lets a script or an agent look at your account and your domains without being able to change anything. See the MCP tools reference for details.
What each one is for
| Control | What it stops | What it does not stop |
|---|---|---|
| Registrar lock | Transfers by mistake or by a simple attack | Someone who can log in and unlock it |
| Registry lock | Quick changes even with a stolen login | A slow, determined attack on the verification step |
| MFA | A stolen or guessed password | Someone who steals your device or tricks you |
No single control is enough. They work together.
Why it matters: three old cases
These are well-known cases, and they are old on purpose. They show the same pattern: the attack went through the registrar side, not through the website.
- panix.com, January 2005. The domain of a New York internet provider was moved to another registrar without proper authorization. ICANN’s later review focused on the missing authorization.
- nytimes.com, August 2013. The Syrian Electronic Army phished the credentials of a reseller in the registrar chain and changed the DNS records for several well-known domains, including the New York Times, taking the site down for hours.
- perl.com, January 2021. A long-standing community domain was taken over through a registrar account compromise, moved to another registrar, and listed for sale. It was later recovered.
I will not claim that a particular lock would have prevented a particular case. Details differ, and I would be guessing. But in each case, the attack targeted the account or the transfer process, which is exactly where these controls work.
What to ask your registrar
- Do you offer MFA on the account? On every login?
- Can I limit API keys to read-only, or to specific actions?
- Do you offer a registrar lock, and who can turn it off?
- Do you offer registry lock for my TLDs? What does it cost, and how is a change verified?
- How do you verify a change request that comes from support and not from the account?
- What is the recovery path if I lose access?
Write down the answers. The post on defensive domain administration shows where these questions fit, and the domain transfer checklist covers the normal, legitimate transfer. If you work with agencies, registrant of record is part of the same picture, and how defensive registration works in the Fortune 500 shows what large companies protect. For unused names, the email records that stop spoofing are the next step. The page for brand protection teams has more.
Questions people ask
What is the difference between registrar lock and registry lock? A registrar lock is set at the registrar and is easy to change. A registry lock is set at the registry and needs an extra verification to lift.
Do I need registry lock? For a domain that would hurt you badly if it were taken over, it is worth asking about.
Is MFA enough? It protects the account, which is essential. It does not replace the locks.
Does every TLD offer registry lock? No. It depends on the registry and on your registrar.
Sources
- ICANN, Registrant benefits and responsibilities
- Registry documentation on registry lock for your TLD (check the registry’s own site)
- Incident reports for panix.com (2005), nytimes.com (2013) and perl.com (2021)
If your registrar answers these six questions better than I expect, tell me who it is, in the chat on the website.
/Thomas