The event the Transfer Policy exists to police
An unauthorized domain transfer is a domain moved from one registrar to another, or from one account to another, without the real registrant's authorization. Of all the ways a domain can be taken, this is the one ICANN built a specific adjudication route for — which makes it, paradoxically, both the best-documented scenario and the one where registrants most often reach for the wrong instrument.
The route is the Registrar Transfer Dispute Resolution Policy (TDRP), updated 21 February 2024, and its remedies are deliberately narrow. A panel may approve the transfer, or deny it — potentially ordering the return of already-transferred domains. That is the whole menu. No damages, no findings about ownership in the abstract, no order against the person who took the name. The question before the panel is whether the transfer complied with policy.
Understanding that limit early saves a great deal of wasted motion. The TDRP settles where a registration should sit. It does not settle who someone is or what they owe.
How a legitimate transfer is supposed to work
You cannot see where the process was subverted without knowing what it looks like intact. Under the ICANN Transfer Policy, three steps:
One. The registrant requests the AuthInfo code — the password-like string that authorizes moving a domain to another registrar — from the losing registrar, and asks for removal of clientTransferProhibited, the EPP status flag that blocks outbound transfers. Where the registrar has no self-service facility, it must provide the code and remove the ClientTransferProhibited status within five calendar days.
Two. The registrant asks the gaining registrar, the one the domain is moving to, to start the transfer. The gaining registrar must obtain express authorization from either the Registered Name Holder or the Administrative Contact, using the Standardized Form for Gaining Registrars — the Form of Authorization, or FOA. That authorization is valid for sixty days.
Three. The registry notifies the Registrar of Record — the losing registrar — which must respond within 24 hours. The registry responds within five calendar days. And if the Registrar of Record does not respond at all, the transfer is approved by default after five days.
Read that last clause again. The system's failure mode is completion, not refusal.
Where the chain breaks
Every step above is an attack surface, and thieves work whichever one is softest at a given registrar.
- Obtaining the AuthInfo code. Through registrar-account compromise, through support-desk social engineering, or simply because the code was left set on the object permanently — contrary to RFC 9154's guidance that authorization information should only be set when a transfer is in process.
- Intercepting or forging the FOA confirmation. Email account compromise does this directly. So does the older, quieter pattern SSAC documented in 2005: waiting for the domain used in the administrative contact address to expire, registering it, and receiving the confirmation mail as the legitimate holder of that mailbox.
- Running out the default-approval clock. Where the losing registrar is inattentive, nobody has to defeat anything. Five days of silence completes the transfer.
The third case is the one that most offends registrants after the fact, because there is no moment of intrusion to point at. The transfer succeeded because a process ran to its scheduled conclusion.
When a registrar may deny, and when it must
The Transfer Policy distinguishes discretionary denial grounds from mandatory ones, and the distinction is worth knowing because it tells you what a registrar can be asked to do.
A registrar may deny a transfer for: evidence of fraud; a dispute over the identity of the Registered Name Holder; non-payment on an expired name; express written objection by the transfer contact; the name being under a lock status; or the name being within 60 days of creation or of a prior transfer.
A registrar must deny a transfer where there are UDRP proceedings, a court order, TDRP proceedings, a Uniform Rapid Suspension — the fast trademark-based suspension procedure — or a 60-Day Change of Registrant lock in effect. A Change of Registrant is a change to the registered owner's identifying details, and the registrar must impose a 60-day inter-registrar transfer lock following one, with an opt-out available beforehand where the registrar offers one.
That opt-out deserves a plain verdict: taking it for convenience is a bad trade. It removes a control that would otherwise stall a thief for two months at the exact moment the registrant record is being altered, which is the moment attackers care about most.
Who can actually file, and where
The most persistent misconception in this area is that the registrant files a TDRP. Under the published policy, the parties are registrars: a losing registrar alleging a fraudulent or otherwise improper transfer, or a gaining registrar contesting a denial it considers wrongful. A registrant's route runs through the losing registrar, or — for a transfer that was wrongly denied — through ICANN's transfer complaint process.
ICANN's approved-providers page lists two TDRP providers, both listed as effective until further notice: the Asian Domain Name Dispute Resolution Centre, effective 28 February 2002, and the National Arbitration Forum, effective 23 December 1999. ICANN announced provider approval on 8 November 2004. The same page notes a route that is easy to miss: complaints under the TDRP may be submitted either to the appropriate registry operator or to an approved dispute-resolution service provider. For a first-level dispute, the registry operator is a legitimate destination.
The filing deadline is twelve months, running from the transfer completion date or from the receipt of a NACK — a transfer denial by the losing registrar — depending on the type of complaint. Letting that clock expire is the single most consequential unforced error in this area, and it usually happens because a matter felt like it was still being negotiated.
The transfer code is a password, and deserves to be treated like one
RFC 9154, Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer, published as a Proposed Standard on 30 December 2021, is the closest thing to a specification for how the transfer secret should behave. Its requirements are unambiguous and worth quoting in substance.
- Authorization information should only be set when a transfer is in process, and unset values must be stored as a NULL value.
- The registrar must inform the registrant of the time-to-live when the authorization information is provided — it is a credential with an expiry, not a permanent property of the domain.
- Implementations should use at least 128 bits of entropy, which is roughly 20 printable-ASCII or 25 alphanumeric characters. A memorable code is a failed code.
- The registry must store it hashed, using a strong one-way cryptographic hash with at least a 256-bit hash function such as SHA-256, plus a per-value random salt of at least 128 bits.
Set against that standard, the common practice of generating a transfer code once and leaving it live on the object for years is indefensible. It converts a transient credential into a standing one, and it is the reason some unauthorized transfers require no account compromise at all — only a copy of something that should have been discarded.
The clocks
Consolidated, because these decide outcomes more often than arguments do:
- 5 calendar days — the losing registrar must supply the AuthInfo code and lift
clientTransferProhibited. - 24 hours — the Registrar of Record's response requirement.
- 5 calendar days — the registry response window, and the point of default approval where the Registrar of Record is silent.
- 4 hours — the Transfer Emergency Action Contact response window, the fastest registrar-to-registrar escalation available.
- 60 days — FOA validity; the post-transfer lock; the post-Change-of-Registrant lock; and a denial ground within 60 days of initial registration.
- 12 months — the TDRP filing deadline.
On discovering an unauthorized transfer, the practical sequence is to contact the losing registrar immediately, ask it to escalate through the TEAC with its 4-hour obligation, and preserve everything that evidences prior control before accounts and records are further altered. Where litigation or a court order becomes the realistic path, that is a determination for counsel.
Reform, and what not to plan around
The transfer rules described here are being rewritten. ICANN's Public Comment Summary Report of 2 July 2025 records that the Transfer Policy Review Working Group's Final Report contained 47 policy recommendations, among them reducing the 60-day post-creation and post-transfer restrictions to 30 days, and eliminating the 60-day post-Change-of-Registrant transfer restriction outright. Trade coverage has also described changes to the handling of transfer authorization codes, including a rename of the AuthInfo code, though that terminology is associated with recommendations that are not yet in force.
Board adoption and implementation dates are both listed as TBD on ICANN's project page. There is therefore no effective date to work toward, and no reason to build internal procedure on the reformed numbers. The operative text remains the Transfer Policy as updated 21 February 2024, whose implementation window for contracted parties ran from 21 August 2024 to 21 August 2025, itself succeeding the version effective 1 June 2016.
My advice on all of it is the same advice that survives any policy cycle: keep the lock on, keep the code unset, and keep the contact mailbox somewhere the thief cannot reach.