Summary

  • The 2013 Registrar Accreditation Agreement, the current Registration Data Policy and the 2025 escrow specification preserve a specified set of domain, registrar and registrant fields. They do not preserve a registrar's whole commercial or technical operation.
  • The escrow agent validates and holds the deposit. ICANN can direct release under defined conditions and receives a transitional-use licence. A registry and an operational gaining registrar must still execute the handoff.
  • Weekly-only deposits may be up to six days old. High-volume registrars submit daily differential deposits and weekly full deposits, but a fresh valid file still contains no required passwords, payment authorisations, support tickets, hosted content or mailboxes.
  • A selected 2024 audit found a privacy/proxy underlying-customer escrow deficiency at five of 58 final auditees. Complaint volumes are not breach counts: ICANN said most of 645 April 2025 data-escrow complaints were invalid because deposits had been completed.
  • Escrow should be judged by an end-to-end restoration test—release, decryption, import, registry reconciliation and usable customer access—not merely by receipt of an encrypted file.

The record that survives

The authority begins with section 3.6 of the 2013 Registrar Accreditation Agreement. An accredited registrar must submit an electronic copy of specified registration data on the schedule, terms and format set by ICANN. It may use an ICANN-designated data escrow agent without charge or an approved agent at its own expense.

The current Registrar Data Escrow programme page points to the 2025 specification, effective since 21 August 2025. That specification turns the obligation into a production routine.

Every registrar makes a full deposit once a week. A registrar at or above 100,000 registration-years in an ICANN fiscal quarter also makes a differential deposit every day except the full-deposit day. Weekly-only data may be no more than six days old; daily data may be no more than 23 hours old.

The agent does not merely store whatever arrives. It checks the SHA-256 hash, signature, encryption, encoding, filenames, CSV structure and required values. One erroneous escrow record makes the whole deposit fail. Missing, valid and failed deposits are reported to ICANN within 24 hours, and manual review is available to help resolve validation failures.

These are substantial controls. They reduce the risk that a failed registrar leaves behind an unreadable proprietary export, an unverified archive or no independent copy at all.

They also answer only one question: is the defined recovery object present and conformant?

The current Registration Data Policy supplies the answer field by field. Registrar escrow must include the domain name, registrar registration-expiration date, registrar IANA ID, and the registrant's name, street, city, state or province where applicable, postal code where applicable, country, telephone number and email address. Registrant organisation is mandatory if collected or generated. A reseller and certain telephone, fax and technical-contact fields may be included if collected or generated.

Privacy and proxy services offered by the registrar or its affiliates have an additional safeguard: the underlying customer's name, address, email and telephone number must be deposited. That prevents the visible proxy record from being the only identity trail available after failure.

The same specification says no additional data beyond its described scope should be included. That exclusion matters. The registrar deposit does not require a password, multifactor credential, session token, payment authorisation, prepaid balance, support ticket, hosted website or mailbox.

The policy also eliminated requirements for administrative and billing contacts, including escrow of those contacts. A billing contact is not the same thing as a stored card, but the removal helps make the boundary visible: the escrow file is not an accounts-receivable system.

Nameservers, DNSSEC elements and nameserver IP addresses appear elsewhere in the policy—in the registry operator's escrow provisions. They do not appear in the registrar field list. Registry escrow and registrar escrow are related continuity mechanisms, not interchangeable copies. A registry may possess technical state that the registrar escrow package does not, and a transition may need both sources to be reconciled.

Custody, release and operation belong to different actors

Escrow rhetoric can make the file sound as though it waits behind glass for a registrant to collect. The contract says something narrower.

Until release, the data is held for completeness, consistency and format verification. The RAA provides for release when the accreditation agreement expires without renewal or is terminated. The 2025 specification requires the agent to release records within 24 hours of the prescribed electronically signed ICANN notice, subject to any additional notice required by applicable law. A mutually agreed release can also be made to ICANN, the registrar or another designated party.

After release, ICANN or its assignee receives a non-exclusive, irrevocable, royalty-free licence to exercise the rights needed to provide registrar services, but only for transitional purposes. That licence is the executable bridge. It does not transfer ownership of the domain name. It does not purchase the failed registrar's company. It does not decide a disputed claim between two people who both say they control the account.

Nor does the escrow agent become a registrar. Its authority is to receive, test, protect and release the records under the agreement. Ordinary registration changes remain actions for registrars and registries.

ICANN's De-Accredited Registrar Transition Procedure, adopted in 2008 and therefore used here with its date visible, supplies the next stages. ICANN assesses whether usable registration data exists and works with registries to help prevent deletions. The affected registrations then need a competent gaining registrar that is accredited and operational for the relevant TLDs.

The procedure asks whether that firm can import the records quickly, manage a comparable portfolio, staff customer service, resolve disputes over control and report progress. If the data is unavailable or unreliable, it lists uncomfortable alternatives: obtain other records, litigate or arbitrate, negotiate cooperation, permit limited operation, let registrations expire or devise another arrangement.

A 2023 transition bid form makes the separation even harder to miss. It asks a candidate about telephone support, email or ticket response, real-time support, renewal prices, experience and good standing. It asks how many days the registrar needs after registration data is made available before a registry can initiate the bulk transfer. It also warns that a selected registrar may receive an escrowed deposit and must protect it.

If access to the data were equivalent to operating continuity, those questions would be redundant. They are not. The gaining registrar supplies the systems, staff, registry connections and customer relationship that the escrow file deliberately does not contain.

A valid file can still leave a difficult handoff

The difference between data continuity and service continuity appears first in authentication. A successor may know the registrant's email and telephone number but still need a defensible process to decide who may control the account. An old password should not simply be transferable even if it existed; carrying credentials from a failed or compromised provider could reproduce the compromise. Identity proof and account recovery must be rebuilt under the successor's controls.

Commercial state creates a second gap. A registrar may have collected several years of fees, sold a bundled hosting plan or recorded a chargeback. The escrow field set does not resolve who owes what, whether a prepaid term will be honoured or how a refund claim should be handled. The 2023 bid form's questions about renewal pricing show that the successor's commercial terms are a live transition issue.

Resellers create a third. The current policy permits a reseller field if collected or generated, but a label in a CSV is not a reseller ledger. It does not necessarily reproduce subaccount permissions, support routing, branded portals or contractual balances.

Dependent services create the largest visible gap. A registrar can also sell authoritative DNS hosting, email, certificates, web hosting or site-building tools. Preserving the registration does not preserve those products. The registry can maintain sponsorship state or delegation data while the nameservers themselves stop answering. A successor registrar can process a renewal without possessing the website that depended on the former provider.

This is where language about stability becomes dangerous if it is not attached to an object. The continuity of a registration record, the continuity of DNS resolution, the continuity of hosted content and the continuity of a business are four different claims. The RAA supports the first. Other contracts and operators support the rest.

The strongest defence of the narrow design is persuasive. Copying an entire commercial platform into escrow would create a vast concentration of credentials, payments, content and personal information. It would be harder to validate, more dangerous to breach and more difficult to hand to a successor lawfully. A standard core record is usable precisely because its purpose is limited.

The correct accountability question is therefore not, Why doesn't escrow contain everything? It is, Can the bounded package be released and used for the purpose ICANN says it serves?

Audit numbers show activity, not a universal recovery rate

ICANN's January–July 2024 registrar audit selected 62 registrars under stated criteria. Four did not complete the audit phase for different reported reasons, leaving 58 in the final audit population. Five of those 58 had a deficiency involving failure to place the underlying privacy or proxy customer's information in escrow.

That finding is useful because it tests a specific field obligation. It is not a census. Registrars in the selected set were chosen partly according to audit history and family treatment. The 9% figure cannot be projected to every accredited registrar.

The March 2025–February 2026 compliance dashboard supplies another bounded number. Registrar data escrow accounted for 10% of received registrar complaints in the top-five table. These are submissions, not adjudicated violations.

April demonstrates the distinction. ICANN reported 645 data-escrow complaints, more than twice the prior 12-month average, but said most were invalid and closed because the registrars had completed their deposits.

Metrics that count incoming complaints can reveal monitoring workload or reporting anomalies. They cannot by themselves tell a registrant how often a deposit was unusable at the moment of failure.

A 2013 breach notice to Xin Net shows that ICANN has used its contractual escalation power after repeated missing or invalid weekly deposits. It is a documented historical case, not evidence of the current failure rate.

The public record is strongest on input compliance: was a deposit due, received and valid? It is much weaker on recovery output: could a successor decrypt it, import it, reconcile it and restore usable customer access, and how long did each step take?