There Are Two Locks, and Most People Only Have the Outer One
Domain transfer locking exists at two levels with confusingly similar names and very different strength. The toggle in a normal registrar dashboard is **clientTransferProhibited**, set and removed by the registrar. The other is a **registry lock**, enforced by the registry that runs the top-level domain.
The difference is who can remove it. The first can be removed from inside your account; the second cannot. An attacker holding your registrar credentials can switch off clientTransferProhibited themselves, whereas lifting a registry lock requires registrar staff to request it from the registry and pass out-of-band verification — in practice often a phone call with a passphrase.
| Measure | Stops | Doesn't stop |
|---|---|---|
| Transfer lock (registrar level) | Unauthorised transfer requests | Removal by whoever holds the account |
| Two-factor authentication | Direct login from a leaked password | Social engineering against support staff |
| DNSSEC | Tampering with DNS responses in transit | Account-level changes (no help at all) |
| Registry lock | Changes even when the account is breached | (manual unlock; usually enterprise registrars only) |
The table lays out four common measures. The third column is the point — what each one **fails to stop** is where the breach actually happens.
Three Early Signs People Miss
A hijack is rarely instantaneous — there's usually an interval where it can be stopped. Three signals worth verifying immediately:
- Password reset emails you didn't request A reset notification from your registrar that you didn't trigger means someone is attempting to take the account. The email alone doesn't mean they've succeeded, but it's the earliest signal. Check at the same time whether the account's contact address has been changed — attackers often swap the email first, after which no further notifications reach you.
- Contact details or nameservers changed WHOIS contact data or nameserver settings changing without your action is clear evidence of compromise. Nameserver changes are especially dangerous, since they redirect traffic while the domain remains registered to you — which is why people often assume "the domain is still mine, so it must be fine".
- Auth codes or transfer notices you didn't initiate A notification that an EPP auth code was issued, or a transfer confirmation you didn't request, means a transfer is already in motion. Timing is critical here — if the losing registrar takes no action, the transfer auto-approves after five days, and those five days are your window to stop it.
Why Registrar-Level Protection Isn't Enough
Those three signs share a property: **they all occur after the attacker is already inside the account**. And once the account is lost, every setting within it is changeable — transfer lock, contact address, nameservers, all of it. That's why "I have the lock enabled" isn't a security guarantee.
Two-factor authentication genuinely raises the bar and belongs on every domain. But it defends against leaked passwords, not social engineering — an attacker impersonating the registrant to support staff bypasses people, not systems. In hijacks of corporate domains, that path is far from rare.
As for registry lock, it's the only measure that survives account compromise — at the cost of flexibility. Unlocking is a manual process taking hours to a business day, which suits domains that rarely change but absolutely cannot fail. **Note that this service is typically offered by enterprise or corporate registrars; most consumer registrars don't provide it**, so confirm availability before relying on it.
What DNSSEC Is Commonly Mistaken For
DNSSEC appears on nearly every domain security checklist, but the problem it solves isn't hijacking. Its purpose is to let resolvers verify that a DNS response genuinely came from the domain's authoritative servers and wasn't altered in transit — it defends against cache poisoning and man-in-the-middle tampering.
But if an attacker logs into your registrar account and openly changes the NS records, those new records get signed correctly too. **DNSSEC raises no alarm, because from the protocol's perspective that was a legitimate change made by the domain owner**. So enable DNSSEC, but don't count it as part of your anti-hijacking defence — they address different threats.
Three Layers of Defence
By cost and effectiveness, build in this order:
1. Treat the registrar account as critical
This is the most basic and most effective layer, because it's the actual attack surface. Enable two-factor authentication, use a unique password, and **make sure the account's contact address isn't hosted on the domain itself** — otherwise a problem with the domain leaves you unable to receive the verification email, a deadlock.
2. Enable every available lock, and re-check regularly
Transfer lock doesn't stop account compromise, but it does stop unauthorised transfer requests, and it costs nothing. The key is **re-checking** — locks get "temporarily" removed during a migration and never restored. Put it on a quarterly checklist.
3. Evaluate registry lock for critical domains
If losing a domain would halt operations, registry lock is worth evaluating. It makes routine changes cumbersome, which is precisely the point. If this matters to you, confirm your registrar offers it before committing.
Three Things to Check Right Now
No tooling required — a registrar login is enough:
- Whether domain status includes clientTransferProhibited Visible in the Domain Status field of a WHOIS lookup. Its absence means transfer lock is off, and anyone obtaining an auth code can initiate a transfer.
- Whether the account email is independent of this domain If the registrar account uses `admin@your-domain`, and that domain is what you're protecting, you have a circular dependency. Moving to an independent address costs nothing and matters enormously.
- Whether two-factor authentication is on Check **both** the registrar account and the email account it's tied to. Protecting the registrar while leaving the mailbox on a password alone leaves a password-reset bypass wide open.
In Summary
The real weak point in domain security isn't the domain — it's **the account that manages it**. Transfer lock and DNSSEC each have value, but neither defends against account takeover, and account takeover is the actual route in the overwhelming majority of hijacks.
So the priority is: protect the registrar account as you would any critical credential (2FA, independent email, unique password), then consider the rest. If you're evaluating registrars, support for these options is worth comparing — our domain registration guide covers the other criteria worth weighing.