Registrar Lock: What clientTransferProhibited Does

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

What Registrar Lock Is

Registrar lock is the free, usually default protection your registrar applies to a domain: a set of client* status codes written into the registry database that tell the registry to refuse transfer, update or delete requests. The registry enforces the flag faithfully. The sponsoring registrar — the registrar that currently holds the domain in the registry — owns the flag absolutely.

That asymmetry is the whole story of this control. The registry will reject an unauthorized transfer all day while clientTransferProhibited is set, and will just as faithfully accept your registrar's command to remove it a second later. Registrar lock is therefore real protection against one specific thing: a transfer request submitted by someone who does not control your registrar account. It is not protection against someone who does. Every serious registrar-lock failure I have looked at reduces to that sentence.

Client Codes, Server Codes, and Who Holds the Key

Registrars talk to registries over EPP, the Extensible Provisioning Protocol, and the status codes on a domain are just flags in that protocol permitting or forbidding an operation. RFC 5731 (August 2009), which defines the EPP domain object, states the rule in section 2.3: "Status values that can be added or removed by a client are prefixed with 'client'. Corresponding status values that can be added or removed by a server are prefixed with 'server'."

The registrar is the client. The registry is the server. So every code discussed on this page begins with client precisely because the registrar can add and remove it at will, and the codes that begin with server — serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited — belong to the registry and are what registry lock is made of. ICANN's status-code reference states the same division and adds that server codes take precedence over client codes.

If you take one thing from this page, take the prefix. It tells you, on sight, which party you have to defeat to change a domain — and therefore which party has to be attacked, socially engineered or subpoenaed.

The Five Codes a Registrar Can Set

ICANN's EPP status code reference defines the client-side set:

clientTransferProhibited — tells the registry to reject requests to transfer the domain to another registrar.
clientUpdateProhibited — tells the registry to reject requests to update the domain.
clientDeleteProhibited — tells the registry to reject requests to delete the domain.
clientRenewProhibited — tells the registry to reject requests to renew the domain.
clientHold — tells the registry not to activate the domain in the DNS, with the consequence that it will not resolve.

Most retail registrars expose a single toggle labeled "Domain Lock" or "Transfer Lock" that maps to clientTransferProhibited, and sometimes to clientUpdateProhibited as well. SSAC recommended in SAC044 (5 November 2010) enabling clientTransferProhibited to prevent unauthorized transfers and clientUpdateProhibited to block configuration changes. Where the registrar exposes it, add clientDeleteProhibited.

Two of these are not security controls at all. clientRenewProhibited blocks renewal. clientHold means the registrar has pulled the domain out of DNS entirely, usually over non-payment or an abuse complaint, and a domain in clientHold does not resolve. Reading either as "my domain is protected" gets the diagnosis exactly backward.

The Five-Day Rule

Registrar lock is not a wall a registrar can hide behind. The ICANN Transfer Policy, current text dated 21 February 2024 and mandatory for registrars from 21 August 2025, requires the registrar to remove clientTransferProhibited or provide the authorization code within five calendar days of the registered name holder's request. A registrar that stalls a departing customer indefinitely is not enforcing a security control; it is out of compliance with the policy it is accredited under.

One wrinkle worth knowing before you argue about it. The policy text says "five (5) calendar days." ICANN's registrant-facing explainer says registrars must either let you create your own code or provide it "within five business days of request." Those are not the same deadline, and the discrepancy sits in ICANN's own published material rather than in any registrar's interpretation. Cite the policy text, and expect a support desk to quote the other version.

The 60-Day Windows Are Not Status Codes

Three separate 60-day windows in the Transfer Policy get confused with registrar lock constantly, including by people who work with domains professionally:

60 days from the domain's creation date, during which the registrar may deny a transfer request;
60 days after a prior inter-registrar transfer, another permitted ground for denial;
60 days after a Change of Registrant — a change to the registrant's identifying details — which triggers its own inter-registrar transfer lock, though registrars may allow the holder to opt out in advance.

None of these is a client* status code, and none of them is something your registrar can simply switch off in the control panel because you asked nicely. They are permitted denial grounds and policy locks, which is why "my registrar unlocked the domain but the transfer still failed" is such a common complaint.

The practical consequence is an ordering problem. If you intend to update the registrant details and then move the domain, opt out of the Change of Registrant lock before you make the change, where your registrar offers that option. Doing it in the other order costs two months you will not get back.

Where Registrar Lock Fails

It fails in four recurring ways.

The attacker is in the account. If someone has your credentials, the lock is a checkbox they also control. This is the failure mode, not an edge case.

The attacker never touches the account. In the e-hawk.net theft of December 2019 the attackers contacted the registrar over a messaging app claiming to have bought the domain; it was moved to a reseller account on 23 December and to another registrar on 26 December, and the owners discovered it on 13 January 2020 only when the DNS changed. The domain had registrar lock. Registrar lock does not constrain the registrar.

The lock is never restored. A legitimate transfer requires unlocking, and the gaining registrar does not always re-apply the codes automatically. Checking the day after a transfer completes takes a minute.

The lock is misread. clientUpdateProhibited blocks changes to the registry record. It does not stop anyone from editing zone contents inside your DNS hosting account, which is where most traffic-stealing attacks actually happen.

Read the Codes, Not the Label

Trusting a control panel label is how people discover months later that the lock was off. Look the domain up in RDAP — the modern successor to WHOIS for registration data — or in WHOIS, and read the status codes on the record. That is the registry's view, and the registry's view is the one that decides what happens to a transfer request.

Then monitor it. A clientTransferProhibited that disappears without a change request from you is one of the earliest reliable indicators of registrar account compromise, and it precedes pendingTransfer — which ICANN defines as a transfer request received and being processed, not a lock. By the time you see pendingTransfer, the clock is running against you and the response is a dispute rather than a click.

Alert on status-code changes and on nameserver changes together. Either alone produces noise; both together, on a domain nobody touched, is an incident.

The Floor, Not the Ceiling

Registrar lock should be on, on every domain, in all three prohibitions where the registrar allows it. It is free, it costs nothing operationally, and it stops the entire class of unauthorized transfer attempts that originate outside your account. Not all top-level domains have supported it identically over the years, so verify rather than assume for anything outside the common gTLDs.

But treat it as the floor. For any domain whose loss would be material — the name your email and customer logins depend on — the honest position is that registrar lock protects you against strangers and registry lock protects you against everything else, including a compromise of the registrar account and a socially engineered support agent. SSAC has recommended that layering since SAC044 in 2010.

The trade-off is real: registry lock costs money and adds friction to every legitimate change. Registrar lock is free and adds none. That is exactly why it defends less.

Frequently Asked Questions

What does clientTransferProhibited mean?

It is an EPP status code set by your sponsoring registrar that, in ICANN's words, tells your domain's registry to reject requests to transfer the domain to another registrar. The client prefix is the important part: RFC 5731 section 2.3 reserves client-prefixed statuses for values the registrar can add or remove, so your registrar can clear it in a single command and anyone with access to your registrar account can usually clear it through the control panel. It blocks outside transfer attempts. It does not block anyone who already holds your credentials.

How long can my registrar take to unlock my domain?

The ICANN Transfer Policy requires the registrar to remove clientTransferProhibited or provide the authorization code within five calendar days of the registered name holder's request. Note a discrepancy in ICANN's own material: the policy text says five calendar days, while ICANN's registrant-facing explainer says five business days. Cite the policy text. If a registrar refuses outright, ICANN Compliance is the escalation path, and the registrar's obligation exists regardless of how the request is framed in the support ticket.

Is registrar lock enough to prevent domain theft?

It is enough to stop transfer requests submitted by people who cannot reach your registrar account, which is a real category of attack. It is not enough against the two that matter most. An attacker inside your account can remove the lock the same way you would. An attacker who social-engineers the registrar's support desk never needs your account at all, which is what happened in the e-hawk.net case in December 2019 to a domain that had registrar lock. For names whose loss would be material, add registry lock on top.

Why can't I transfer my domain 60 days after registering it?

Because the ICANN Transfer Policy lets a registrar deny a transfer requested within 60 days of the domain's creation date. Two similar windows exist: 60 days after a prior inter-registrar transfer, and a 60-day inter-registrar transfer lock following a Change of Registrant, which is a change to the registrant's identifying details. None of these is a client* status code and none can be cleared by unlocking the domain. Registrars may allow you to opt out of the Change of Registrant lock in advance, so make that election before you edit the registrant data.

Does clientUpdateProhibited stop someone changing my nameservers?

It stops changes to the nameserver delegation recorded at the registry, which is the pointer saying which nameservers are authoritative for your domain. It does nothing to the contents of the zone those nameservers serve. If your DNS hosting account is compromised, an attacker can rewrite your web and mail records while the registry record stays untouched and correctly locked. The two live at different layers and need separate protection: status codes at the registry, and account security plus monitoring at the DNS provider.

How do I check whether registrar lock is actually on?

Look the domain up in RDAP or WHOIS and read the status codes on the record rather than trusting the padlock icon in your registrar's control panel. You are looking for clientTransferProhibited at minimum, and ideally clientUpdateProhibited and clientDeleteProhibited as well, which is what SSAC recommended in SAC044. If you see server-prefixed versions of those codes, the domain also carries a registry lock. If you see pendingTransfer, a transfer is already in flight and you have an incident rather than a configuration question.

Does clientHold mean my domain is locked and safe?

No. ICANN defines clientHold as telling the registry not to activate the domain in the DNS, with the consequence that it will not resolve. It is normally set by a registrar over non-payment or an abuse complaint, and it means your site and email are already down. People find it while investigating an outage and misread it as a security lock because it looks like the other client codes. The security codes are clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited; clientHold is a suspension.

Registrar Lock