Transfer Lock Removed: The Warning Sign Before a Domain Hijack
Before a domain is stolen, one field changes: clientTransferProhibited disappears. Your site stays up, DNS is untouched, and nothing tells you. ICANN gives you 60 days to notice, and expects you to notice on your own.
September 21, 20267 min readSecurity · Hijacking · EPP status codes
The short answer. A domain hijack does not begin with your website going down. It begins with a status code disappearing. When clientTransferProhibited is removed from a domain you own and you did not remove it, someone is preparing to move it. At that moment nothing else on your infrastructure has changed, which is exactly why almost nobody notices.
Here is the uncomfortable structure of the problem. ICANN's transfer rules deliberately build in a delay so that the rightful owner has time to object. The policy assumes you will find out. Nothing in the system is responsible for telling you.
What the transfer lock actually is
Every domain carries status codes set by your registrar and held at the registry. One of them is clientTransferProhibited.
ICANN's own EPP status codes reference describes it plainly: it "tells your domain's registry to reject requests to transfer the domain from your current registrar to another", and exists to protect "against unauthorized transfers as a result of hijacking and/or fraud".
It is usually free. It is often not on by default. And it has to come off before a domain can move.
That last point is what makes it valuable as a signal. The lock is not one security control among many. It is a gate that must be opened first, and opening it is visible in public registry data the moment it happens.
How a hijack actually unfolds
The website is the last thing to change, not the first.
| Stage | What happens | What you can observe |
|---|---|---|
| 1 | Registrar account is compromised, usually by phishing or a reused password | Nothing, unless you monitor logins |
| 2 | Contact email on the domain is changed | Registry contact data changes |
| 3 | clientTransferProhibited is removed | Status codes change in RDAP |
| 4 | Transfer authorisation code is requested | Nothing public |
| 5 | Transfer to the attacker's registrar completes | Registrar name changes in RDAP |
| 6 | Nameservers are repointed | DNS changes, site and email move |
Stages 1 through 5 are invisible to everything most people run. Your site returns 200 the entire time. Your certificate is valid. Your DNS answers correctly, because it has not been touched yet.
By stage 6 the domain is already at another registrar under someone else's account, and you are no longer making a support request. You are filing a dispute.
Stage 3 is the earliest point that appears in public data, and it is the last point at which fixing it is simply a matter of logging in and switching the lock back on.
Why nothing you run catches it
Uptime monitors ask whether your site responds. During stages 1 through 5 it responds perfectly. An uptime monitor is structurally incapable of reporting this.
DNS monitors watch records. Nothing in your zone changes until stage 6, which is the end of the story rather than a warning about it.
Certificate monitors watch expiry and issuance. A hijacker has no reason to touch your certificate until they control the domain.
Registrar email notifications are sent to the contact address on the account, which the attacker changed at stage 2. That notification arrives in their inbox, not yours.
The only place stage 3 is visible is the registry record, which means something has to query RDAP on a schedule and compare the answer with the last one.
What ICANN gives you, and what it assumes
ICANN's Transfer Policy imposes a 60-day transfer lock in three situations: within 60 days of initial registration, within 60 days of a previous transfer, and within 60 days of a change of registrant, unless the registrant opts out.
The stated purpose is to make hijacking harder by creating a window in which the original registrant is likely to discover the change and alert their registrar.
Read that again, because it is the whole point. The policy is built around you noticing. The 60 days are not a safety net that catches anything by itself. They are time, and time only helps if something is watching.
If the window closes, the remaining route is the Transfer Dispute Resolution Policy. TDRP complaints are filed by registrars with ICANN-approved dispute providers, and the statute of limitations is 12 months. It works, but it is slow, it happens between registrars rather than on your behalf, and your domain is pointing somewhere else throughout.
What to do if the lock comes off
If you see clientTransferProhibited disappear and nobody on your team removed it, treat it as an active incident.
1. Log in to the registrar immediately and check whether you still can. If your password no longer works, call them. Do not use the email reset flow, because the email on file may no longer be yours.
2. Re-apply the lock if you still have access, and add clientUpdateProhibited and clientDeleteProhibited while you are there.
3. Check the contact email on the domain. If it has changed, that is confirmation rather than suspicion.
4. Rotate the registrar password and enable two-factor authentication. The registrar account is the actual asset. Everything else is downstream of it.
5. Contact the registrar's security team in writing. Ask them to place the domain under registry lock and to record the incident. If a transfer is already in flight, the registrar can attempt to reverse it far more easily before it completes than after.
6. Review every other domain in the account, because whoever got in can see all of them.
Preventing it
Turn on the three client locks. Transfer, delete and update. Free at most registrars, off by default at many, documented by ICANN as anti-hijacking measures.
Two-factor authentication on the registrar account. Not optional for anything with revenue attached.
A role-based contact email, not a personal one. Stage 2 of the hijack works because the attacker changes an address nobody else reads. An address several people monitor is much harder to quietly replace.
Registry lock for critical domains. Applied at the registry rather than the registrar, and lifting it requires out-of-band verification with a human. It costs money and it is worth it for the handful of names your business genuinely depends on.
Monitor the status codes. This is the part that is usually missing. Domain Hub refreshes registry data on a schedule, stores the EPP status codes for every domain you track, and raises an event when the registrar or nameservers change. You can see the current codes for any domain right now with our checker.
Common questions
What does clientTransferProhibited mean?
It is an EPP status code that instructs the registry to reject requests to transfer your domain to another registrar. ICANN documents it as protection against unauthorized transfers from hijacking or fraud. It is set by your registrar and you can normally toggle it yourself.
Is it bad if clientTransferProhibited is missing?
It means nothing is stopping a transfer. If you never enabled it, turn it on. If it was on and is now gone and nobody on your team removed it, treat that as a security incident.
What is the difference between clientTransferProhibited and serverTransferProhibited?
The client code is set by your registrar and you control it. The server code is set by the registry itself, usually because of a legal dispute or a serious problem with the domain, and lifting it requires the registry to act.
How long does a domain transfer take?
Typically five to seven days, during which the losing registrar can be asked to cancel it. That window is the practical opportunity to stop an unauthorized transfer, which is why early detection matters more than any later remedy.
Can I get a stolen domain back?
Often, but it is a process rather than a support ticket. Inside 60 days your registrar has the strongest options. Beyond that, recovery runs through the Transfer Dispute Resolution Policy, which has a 12-month limit and is handled between registrars.
Does an uptime monitor detect domain hijacking?
No. During the stages where a hijack can still be stopped, your website responds normally, DNS is unchanged and certificates are valid. Uptime monitoring measures none of the things that change.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain