Registry Lock: Stop Domain Hijacking at the Registrar

The account is the target, not the nameserver

For its SAC040 report, ICANN's Security and Stability Advisory Committee analysed a series of incidents between May 2008 and April 2009, looking for a common thread (ICANN SSAC, SAC040, 19 August 2009). The finding is uncomfortable precisely because it has so little to do with technology. For some of the registrars studied, the report states plainly: all an attacker needs to gain control of an organisation's entire domain name portfolio is a user account and a password. And further: attackers need only guess, phish or apply social engineering techniques to a single point of contact to gain control of a domain registration account (ICANN SSAC, SAC040).

The follow-up report SAC044 describes what happens next (ICANN SSAC, SAC044, 5 November 2010). The attacker alters the DNS configuration associated with the domain so that name resolution directs visitors to an impersonation site, a phishing site, a defacement page or to hosted malware. Equally, they may alter the DNS configuration to route the organisation's mail or web traffic through monitoring hosts and capture credentials there. That is what separates this from an ordinary website breach: whoever controls the delegation does not need your server at all.

• Nameservers and zone: the domain resolves to someone else's addresses. Your website is technically untouched and still not the website your visitors see.
• MX and mail delivery: inbound mail reaches the attacker. That includes the password reset messages of every service tied to your domain.
• Certificate issuance: whoever controls DNS passes DNS-based domain validation and can have valid certificates issued in your name.
• Recovery: getting the domain back runs through the registrar and the registry - not through a restore from your backup.

EPP status codes: the locking layer beneath DNS

Registrars and registries speak their own protocol: the Extensible Provisioning Protocol, standardised as RFC 5730 and carried as Internet Standard STD 69 since August 2009 (IETF, RFC 5730). The mapping onto domain names is defined by RFC 5731 from the same month (IETF, RFC 5731). The roles are hard-wired: the registrar is the client, the registry is the server. That split explains the entire naming logic of the status codes.

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".

— IETF, RFC 5731, Section 2.3 (Status Values)

ICANN documents the 17 standardised EPP domain status codes plus the grace periods from RFC 3915 in a reference of its own, and states the hierarchy unambiguously: client status codes are set by registrars, server status codes are set by registries - and the server codes take precedence over the client codes (ICANN, EPP Status Codes: What Do They Mean, and Why Should I Know?). That precedence is the whole point of the registry lock.

One detail from RFC 5731 is worth remembering because it helps when reading status queries: the ok status must not be combined with any other status (IETF, RFC 5731). A domain reporting ok therefore carries no lock at all. In modern RDAP output that value appears as active - more on that below.

The registrar lock: free, instant - and limited for exactly that reason

clientTransferProhibited is the status most registrars set automatically at registration. ICANN describes its effect matter-of-factly: it tells your domain's registry to reject requests to transfer the domain from your current registrar to another (ICANN, EPP Status Codes). That is sensible and it should be set. It simply is not what many people take it to be.

The reason sits in the ICANN Transfer Policy, the binding rulebook for registrar transfers in generic top-level domains (ICANN, Transfer Policy, updated 21 February 2024, mandatory implementation by 21 August 2025). Section I.A.5.1 obliges the registrar to remove the ClientTransferProhibited status within five calendar days of the holder's initial request if it does not provide a self-service facility for it (ICANN, Transfer Policy). Section I.A.5.2 requires the same for releasing the AuthInfo code.

The decisive passage, though, is Section I.A.5.3. It explicitly forbids registrars from employing any mechanism for removing ClientTransferProhibited or obtaining the AuthInfo code that is more restrictive than the mechanisms used for changing any aspect of the holder's contact or nameserver information (ICANN, Transfer Policy, Section I.A.5.3).

None of this is an argument against the registrar lock. It costs nothing, takes minutes to set and closes a real attack path. SAC044 explicitly recommends setting both clientTransferProhibited and clientUpdateProhibited, and points to an underrated side effect: many registrars issue notifications when client status codes are modified. Those notifications, it says, are extremely important because they may forewarn registrants of unauthorised registration account access (ICANN SSAC, SAC044). A lock whose removal triggers an email is useful even when it does not stop the attacker - it makes them visible.

Registry Lock: the lock your own account cannot lift

The server status codes sit one layer deeper. They are set by the registry, not the registrar, and your customer account has no access to them. ICANN describes the offering like this: some registry operators offer a Registry Lock Service that allows registrants, through their registrars, to set this status as extra protection against unauthorised updates. Removing the status can take longer than it does for clientUpdateProhibited because the registrar has to forward the request to the registry and wait for it to lift the restriction (ICANN, EPP Status Codes).

SAC044 describes the sequence more precisely: registrars submit the lock requests for serverDeleteProhibited, serverUpdateProhibited and serverTransferProhibited at the registrant's request. Before setting the lock, the registry verifies that the submitting registrar is in fact the registrar-on-record. Once the locks are enabled, the registry uses a highly secure verification and authentication process to assure that change requests have been authorised by the registrant (ICANN SSAC, SAC044). This is the point at which verification leaves the channel an attacker controls.

The price is friction, and it cuts both ways. A nameserver migration then takes days rather than minutes, because every change has to pass the verification process. If you issue ACME certificates via the DNS-01 challenge, check whether the required TXT records live in a delegated zone the lock does not touch - otherwise the lock blocks your own automation. That friction is intentional: it is precisely what stops the attacker. It just has to be planned for.

What practice shows: an RDAP sample

The theory is unambiguous. What is actually set is more interesting. For this article we queried the domain statuses of 63 .com and .net domains belonging to large, predominantly DAX-listed German companies on 15 July 2026, directly against the official RDAP services of the responsible registries - plus seven .de domains from the same group of companies (own RDAP survey, 15 July 2026). The result comes down to four figures.

1. 90.5 % of the 63 domains (57) carry clientTransferProhibited - the registrar lock against transfers is effectively standard (own RDAP survey, 15 July 2026).
2. 33.3 % (21) carry at least one server* status, meaning a registry lock is active (own RDAP survey, 15 July 2026).
3. 9.5 % (6) carry clientUpdateProhibited - the lock that would block a nameserver change made from inside the account (own RDAP survey, 15 July 2026).
4. 3.2 % (2) report active only, meaning no lock whatsoever (own RDAP survey, 15 July 2026).

The telling figure is not the 33.3 %. It is the distance between 90.5 % and 9.5 %. The transfer lock is set because registrars ship it as a default - it costs the holder no decision. The update lock, which protects the nameserver record and therefore cuts off exactly the path the SSAC incident analyses describe as the normal case, is absent at nine out of ten of these companies. Because it does require a decision: it makes day-to-day work slightly less convenient.

The common lock protects against the scenario that rarely happens. The rare lock protects against the scenario the incident reports describe.

— Analysis of our own RDAP survey of 15 July 2026

The second observation: 42 of the 63 domains, that is 66.7 %, have no registry lock (own RDAP survey, 15 July 2026). The distribution is not random - the lock appears mostly among the largest corporates in the sample, while it is largely absent in the MDAX and SDAX range. That matches our project experience: registry lock is rarely a question of budget and almost always a question of whether anyone ever inventoried the domain as an asset in its own right (project experience).

Hardening the registrar account: separate role, MFA, external contact address

If the account is the target, the account is where the work starts. SAC044 lists measures that were formulated in 2010 and whose continued relevance is rather awkward (ICANN SSAC, SAC044). The most important, in order of impact:

• Partition sensitive domains: SAC044 recommends placing particularly important registrations in a separate account whose credentials are held by selected personnel (ICANN SSAC, SAC044). The marketing domain and the domain your payroll depends on do not belong in the same login.
• Enable multi-factor authentication wherever your registrar offers it - SAC040 describes it as the "something you have" added to the password and notes that it makes breaking into an account considerably harder (ICANN SSAC, SAC040).
• Use unique credentials per account and no reuse across system boundaries (ICANN SSAC, SAC044).
• Treat staff changes as a trigger: when authorised contacts change, new credentials should be created and old ones revoked (ICANN SSAC, SAC044).
• Assign notifications to a responsible party or have them raise a ticket so that no message goes unread - SAC044 even calls for a defined response target per event type (ICANN SSAC, SAC044).
• Define and audit a recovery process, including who is actually authorised to retrieve escrowed credentials in an emergency (ICANN SSAC, SAC044).

SAC040 adds a structural idea that goes beyond the single account. The report compares the common access model to a cabinet safe: once it is open, you can pretty much do as you please. Against that it sets the model of a bank vault with safety deposit boxes, where an intruder must not only get into the room but also obtain a key to each individual box. Registrars are encouraged to offer such a model - for instance as an opt-in feature controlling which contacts may change contact and DNS information or initiate a transfer (ICANN SSAC, SAC040). A registry lock delivers exactly that granularity when the registrar does not: it pulls the authority for the most critical operations out of the account.

If you have to answer these questions systematically for external providers, the matching evidence logic is in our article on vetting service providers in the NIS2 supply chain - from the directive's point of view, the registrar is a service provider like any other.

Auth code hygiene and the Transfer Policy waiting periods

The AuthInfo code is the key to a transfer. The Transfer Policy still calls it that, even though the final report of the Transfer Policy Review proposed renaming it "Transfer Authorization Code" (ICANN, Transfer Policy). In practice it is a password and should be treated as one.

• Generate it only when needed. A code that has been sitting in the account for three years is a password without rotation.
• Regenerate after every aborted transfer. The code is compromised from the moment it is handed over - regardless of whether the transfer happened.
• Do not park it in tickets, wikis or mail archives. That is exactly where attackers look first after taking over an account.
• For .de there is a hard deadline: the AuthInfo expires automatically after 30 days and must then be requested again (DENIC, provider transfer).

The Transfer Policy also defines several waiting periods that act as brakes. A transfer may be denied if it is requested within 60 days of the domain's creation date, and likewise within 60 days of a previous transfer (ICANN, Transfer Policy, Sections 3.7.5 and 3.7.6). After a change of registrant a 60-day transfer lock applies; if a registrar uses clientTransferProhibited for it, it must lock the name in a way that prohibits the holder from removing the lock themselves (ICANN, Transfer Policy, Section II.C.2). That is notable because it shows a client lock the holder cannot switch off is technically possible - it is simply not the default arrangement.

These periods help against transfers. They do not help against the nameserver change - that is bound to no waiting time and takes effect within minutes. If you want to understand the difference between a takeover at registry level and a manipulation of the zone itself, the distinction is covered in our article on detecting and preventing DNS hijacking.

.de at DENIC: its own rules, its own registry lock

For the most important domain of many German companies, much of the above does not apply - at least not in this form. .de is not a generic top-level domain, DENIC is not subject to the ICANN Transfer Policy and runs a registration system of its own. Its centrepiece is the Realtime Registry Interface (RRI), not EPP (DENIC, overview of the .de registration system). There is a corresponding vocabulary of its own: free, connect, failed, invalid and redemptionPeriod (DENIC, domain status). clientTransferProhibited and its relatives do not appear in it.

That is immediately visible in public RDAP. All seven .de domains checked in our sample returned active as their only status - regardless of which protective measures are actually in place (own RDAP survey, 15 July 2026). If you want to verify from the outside whether a lock is active on a .de domain, you cannot.

A registry lock does exist nonetheless, and it is built with remarkable rigour. DENIC offers the .de Registry Lock as a paid product that members arrange for their domain holders; it protects holder data, nameservers and provider settings against unwanted manipulation - both through external attacks and through accidental misconfiguration (DENIC, .de Registry Lock).

One detail underlines how seriously DENIC takes the procedure: change requests for locked domains are not submitted through the regular interface but sent by email or in key-value format directly to DENIC, where they are processed manually (DENIC, .de Registry Lock). The lock state itself is visible via a domain INFO query as RegistryLock: true - though through the provider interface, not in public RDAP (DENIC, .de Registry Lock).

For a sense of scale: as of 30 June 2026, 17,998,588 .de domains were registered (DENIC, .de domain statistics). Of those, 437,728 were DNSSEC-signed - around 2.4 % (DENIC, DNSSEC statistics for .de, as of 30 June 2026). That ratio says a great deal about the adoption of domain hardening overall: the protective layers have existed for years and are documented, they are simply barely used. Why the signature alone is not enough and what monitoring its validation has to cover is a topic of its own.

The RDAP status as an early indicator

Registration data lookup changed supplier in 2025 - or rather, protocol. ICANN declared RDAP the definitive source for generic top-level domain registration information as of 28 January 2025 and sunset WHOIS (ICANN, ICANN Update: Launching RDAP; Sunsetting WHOIS, 27 January 2025). Registries and registrars must provide RDAP using the gTLD RDAP Profile, but since that date are no longer required to provide WHOIS - except for .com, .name and .post (ICANN, Registration Data Access Protocol). The scale is considerable: for December 2024, ICANN estimates query volume across all RDAP servers at over 10 billion queries per month, with over 40 known client and over 15 known server implementations (ICANN, Registration Data Access Protocol).

Technically RDAP rests on two documents, both from June 2021 and both part of STD 95: RFC 9082 defines the query format, RFC 9083 the JSON response structure (IETF, RFC 9082 and RFC 9083). The translation between the two worlds is handled by RFC 8056: it maps the EPP statuses onto the RDAP statuses and closes the gaps in the registry along the way (IETF, RFC 8056, January 2017). In practice that means serverUpdateProhibited becomes server update prohibited and ok becomes active. Searching an RDAP response for the camel-case spelling finds nothing.

{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": [
    "client transfer prohibited",
    "server delete prohibited",
    "server transfer prohibited",
    "server update prohibited"
  ],
  "nameservers": [
    { "objectClassName": "nameserver", "ldhName": "NS1.EXAMPLE.NET" },
    { "objectClassName": "nameserver", "ldhName": "NS2.EXAMPLE.NET" }
  ],
  "events": [
    { "eventAction": "expiration",  "eventDate": "2028-12-07T17:04:26Z" },
    { "eventAction": "last changed", "eventDate": "2025-01-31T20:19:44Z" }
  ],
  "secureDNS": { "delegationSigned": true }
}

This response contains four values that lend themselves to monitoring, because they change rarely and for nameable reasons:

• status: if server update prohibited disappears from the array, the registry lock has been lifted. That is either your own change - or an incident.
• nameservers: the actual early indicator. A new nameserver set is the signature of a takeover, long before the website looks different.
• events: expiration guards against a silent lapse, while last changed and transfer date every alteration to the registry object.
• secureDNS: if delegationSigned drops to false, the DNSSEC chain has been cut - a typical preparatory step for keeping a redirection inconspicuous.

Naming the limits honestly

Registry Lock is an effective measure, but no panacea. Four limitations belong in every decision paper:

1. Not every registry and not every registrar offers it. ICANN describes registry lock explicitly as an offering of "some" registry operators, not as an obligation (ICANN, EPP Status Codes). Whether your combination of TLD and registrar supports it is a case-by-case question.
2. It protects the registry object, not your zone. If the nameserver records at the registry stay correct while your DNS host's account is taken over, the zone contents change regardless. Registry lock does not reach there - that is a different attack with a different countermeasure.
3. It does not renew a domain. Expiry remains a separate risk that hangs on payment methods and reminders, not on a status code. Why companies keep failing at this is covered in our article on preventing domain expiration.
4. Detection has latency. RDAP responses carry their own field for the state of the database; between a change and its visibility there are typically minutes to hours, not seconds. An early indicator is not real-time protection.

And one qualification that belongs to honesty: registry lock prevents no vulnerability in your application, no compromised dependency and no insecure server. It addresses exactly one class of attack. If you want to assess your position beyond the domain systematically, you work with the public EUVD and CVE vulnerability feeds and a regular security scan of your own attack surface.

Making domain status a monitored value

In almost every company the domain is the asset with the worst ratio of importance to attention. It carries the website, the mail and the trust relationship with every customer - and it is typically managed in an account whose credentials nobody can quite account for any more. The protective layer beneath it has been documented for over fifteen years: EPP status codes since RFC 5730 in 2009, the recommendation for registry lock since SAC044 in 2010. None of this is new. Only the implementation is missing on two thirds of the domains we checked (own RDAP survey, 15 July 2026).

The order of work is manageable. First harden the account - a separate role, multi-factor authentication, a contact address outside your own domain. Then set the free client locks, clientTransferProhibited and clientUpdateProhibited, and assign their notifications to a responsible person. Then, for the two or three domains whose failure stops the business, request the registry lock through your registrar. And finally the step that makes the first three verifiable at all: read the status regularly.

That is exactly where DNS and domain monitoring from XICTRAQ comes in. It watches the nameserver records, the domain status and the expiry date of your domains, compares every retrieval against the last known state and raises an alarm on unauthorised changes - through the notification channels your team already uses. Protection against the takeover stays with the registrar and the registry. Whether it is still active is something you can monitor.

Getting started needs no grand initiative. Add the domains whose failure would hurt, check their status codes once against the table above, and let the rest run. It is also worth looking at monitoring for brand and spelling variants and at availability monitoring, which reports the outage if something does tip over in the delegation after all. Which modules are included at what scope is shown in the pricing overview; a free account is enough to add your first domain.