Registry Lock: The registry-level control to protect domains

A domain hijacking rarely announces itself, which is exactly why a Registry Lock exists. One moment your primary domain resolves your website, routes your corporate email, and anchors the TLS/SSL certificates your customers trust. The next, an attacker who phished a single set of registrar credentials has repointed all of it. A Registry Lock is the strongest, registry-level control available for business-critical domains, and unlike the account-level protections most organizations rely on, it holds even when your registrar login has already been compromised.

This guide explains what a Registry Lock is, how it works through server-side EPP status codes, how it differs from a Registrar or Transfer Lock, and how it fits into a layered domain security strategy. Where implementation matters, we describe how we handle it at InterNetX.

What a Registry Lock actually is

A Registry Lock is a security control applied directly at the registry, the organization that operates a top-level domain. It blocks any change to a domain until the request has been manually verified through a separate, out-of-band channel.

To see why it matters, it helps to be precise about the three parties in the domain chain:

• The registrant is you, the organization or person who holds the rights to the domain.
• The registrar is the accredited company through which you register and manage the domain. This is where you log in, edit nameservers, and initiate transfers.
• The registry is the operator of the TLD itself. Verisign operates .com and .net, nic.at operates .at, and other registries run .de, .org, and all other TLDs.

Most controls you already know live at the registrar level, inside your account: passwords, multi-factor authentication, and the default Registrar Lock. A Registry Lock lives one level higher, at the registry. That placement is the entire security proposition: because the lock sits above the registrar, it holds even if someone gets into your registrar account.

In concrete terms, a Registry Lock prevents unauthorized nameserver and DNS delegation changes, transfers to another registrar, changes to registrant or contact data, and deletion of the domain. Nothing can be altered until a pre-designated authorized person confirms the change through a manual process outside the normal automated workflow.

A Registry Lock is not a default you switch on for every domain you own. It is a deliberate, higher-assurance control for the small number of domains a business cannot afford to lose.

When account-level protection is not enough

The value of a Registry Lock becomes obvious the moment you look at how modern domain hijackings actually unfold.

The business impact of losing a primary domain is why this belongs in front of a board. Losing control of one domain can simultaneously take down your website, redirect your corporate email, break the TLS trust chain that secures customer connections, and hand your brand to whoever now controls the DNS. Customer data can be intercepted. Payment flows can be diverted. Recovery, as anyone who has lived through it knows, is slow and public. Our own guide on domain hijacking and what to do if it happens walks through just how difficult reclaiming a stolen domain can be.

And this is not a rare, anecdotal risk. The most recent IDC Global DNS Threat Report found that around 90% of organizations had experienced a DNS attack, at an average cost of roughly $1.1 million per incident. The threat is systemic, and the reason so many of these attacks succeed is that they target the one gap account-level security cannot close. The control that closes that gap is out-of-band verification at the registry. Exactly what a Registry Lock provides.

How does a Registry Lock work?

To understand the mechanics, you need to know a little about how registrars and registries talk to each other.

They communicate using EPP, the Extensible Provisioning Protocol. EPP is the standardized language, defined in IETF RFC 5731 for domain-name mapping, that a registrar uses to tell a registry to register, update, transfer, or delete a domain. When you change your nameservers in your control panel, your registrar translates that action into an EPP command and sends it to the registry. The registry checks the domain’s status codes and either executes the command or rejects it.

Those status codes are the key. EPP status codes come in two families, and the difference between them is the difference between a Registrar Lock and a Registry Lock.

Because the registrar controls these codes, the registrar can add or remove them automatically, often without any human in the loop. That is convenient, and it is exactly why they cannot stop an attacker who is already inside your registrar account.

The verification step is where the security lives. When a legitimate change is needed, the request does not simply flow through the automated EPP pipeline. Instead, it triggers a manual authentication process. The registry, or the registrar acting under the registry’s authorization procedure, contacts a pre-designated authorized person through a separate channel. That contact is confirmed by callback, passphrase, or another agreed method before the lock is temporarily lifted so the change can be applied. Once the change is complete, the lock is reinstated.

There is no automated, credential-based path to change a registry-locked domain. Stolen credentials alone get an attacker nowhere, because the last gate is a human confirmation over a channel the attacker does not control.

Differences between Registry Lock, Registrar Lock, and Transfer Lock

Because the terminology overlaps, these controls are easy to confuse, so it is worth drawing the distinctions.

A Registrar Lock is the general term for the client-side status codes a registrar can set on your domain to prevent unwanted or accidental changes. A Transfer Lock is the most familiar of these, corresponding to clientTransferProhibited, which specifically blocks a domain from being transferred to another registrar. Both are applied at the registrar level, inside your account, and both can be set and removed by the registrar, on default and at no extra cost. They are useful and should always be enabled. But they are account-level protections, and they are reversible by the registrar, which means they are reversible by anyone who controls the account.

A Registry Lock is applied at the registry level using server-side codes that only the registry can remove, and only after manual out-of-band verification. This is the decisive distinction. Registrar and Transfer Locks are automated and account-bound. A Registry Lock introduces a deliberate human checkpoint that no credential can shortcut.

The practical takeaway is that these are layers, not alternatives. Keep your Registrar and Transfer Locks on for every domain. Add Registry Lock on top for the domains you cannot afford to lose. The Registrar Lock is your baseline hygiene, and the Registry Lock is your last line of defense when everything else has been bypassed.

What a Registry Lock protects, and what it does not

Setting accurate expectations matters, because a Registry Lock is powerful within a defined boundary, and misunderstanding that boundary leads to a false sense of security.

The boundary worth internalizing is the line between the registry-level record and the DNS zone your provider hosts. The registry knows which nameservers are authoritative for your domain, and that delegation is what a Registry Lock protects. The actual A/ AAAA, MX, TXT, and other DNS records that direct traffic live in the zone your DNS provider manages, and those are governed by the security of that account and platform. If you want to understand exactly what lives where, our reference on the DNS records behind domains maps it out in detail.

Which domains deserve a Registry Lock?

Not every domain needs this level of protection, and locking everything would create needless operational overhead. The right approach is triage.

In practice: corporate primary domains, banking and financial services domains, e-commerce transaction domains, public-sector and critical-infrastructure domains, and high-value assets held by domain investors. These are the domains where an hour of downtime is a crisis.

Equally, be deliberate about what you leave out. Parked domains, redirect-only registrations, defensive registrations, and low-value assets rarely justify the operational friction. Locking them adds cost and slows routine housekeeping without meaningfully reducing risk. If your portfolio is spread across registrars and spreadsheets, our guide to domain management tools shows how to bring it under centralized control first, because you cannot protect what you cannot see. For the broader strategic picture, our overview of domain management as a discipline frames how Registry Lock fits into a mature portfolio.

Which TLDs support Registry Lock

Because Registry Lock is a registry-side feature, its availability depends on the TLD operator, not on the registrar alone. A registrar can only offer Registry Lock for a given TLD if the registry behind that TLD supports it.

The most widely referenced implementation is Verisign Registry Lock Service for .com and .net, which is the reference point many organizations know first. Beyond that, a growing number of ccTLDs and new gTLDs offer equivalent services, sometimes under different names such as Domain Lock.

Two consequences follow for anyone managing a mixed portfolio. First, terminology, pricing, and the exact verification workflow differ from one registry to the next, so support has to be confirmed per TLD rather than assumed across the board. A domain on .com, one on .at, and one on .de may each have a different process. Second, this variability is precisely where a provider that aggregates many registries earns its keep. At InterNetX, our AutoDNS platform connects to hundreds of registries, which lets you check Registry Lock availability and provision it across a heterogeneous portfolio from one place.

How to enable a Registry Lock step by step

Putting a Registry Lock in place is straightforward when you follow a defined sequence. Here is the process, in order.

1. Identify and prioritize your business-critical domains. Work from your tiered inventory and select the domains that failed the “Can we afford to lose this?” test in the triage step above.
2. Confirm Registry Lock support for each relevant TLD. Verify per extension, because availability and terminology vary by registry. Do not assume that support for one TLD implies support for another.
3. Designate authorized contacts and define the out-of-band verification channel. Name the specific people permitted to authorize changes, and agree the verification method with your provider, for example a callback to a known number plus a shared passphrase. This is the human anchor of the whole system, so choose it carefully.
4. Request the lock through your registrar or provider. The provider arranges for the three server-side codes (serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited) to be applied at the registry.
5. Document the unlock procedure and expected turnaround. Record exactly how a legitimate change is requested, who must approve it, and how long verification takes, so that a necessary change during an incident is not accidentally blocked by your own protection.
6. Test the process on a non-critical locked domain first. Run a full unlock-change-relock cycle on a non-critical domain before you rely on the procedure for the ones that do. You want to discover any friction in a rehearsal, not during a real emergency.

How to confirm a domain is registry-locked

You can verify a Registry Lock independently by reading the domain’s public status record. Both WHOIS and its successor RDAP (Registration Data Access Protocol) expose the EPP status codes attached to a domain. Look for the three server-side codes. The presence of all three is the practical signal of an active Registry Lock. If you see only the client-side equivalents, the domain has a Registrar Lock, not a Registry Lock. For your own domain portfolio, the authoritative internal view is your provider’s dashboard, which shows lock status across all your domains at once rather than requiring a lookup per domain.

A quick caution: status display can vary slightly between registries and between WHOIS and RDAP output, so if the codes are absent from one source, check the RDAP record or your provider’s dashboard before concluding a lock is not in place.

The cost of a Registry Lock, and whether it pays off

A Registry Lock is a premium, manually operated service, and its pricing reflects that. It is typically charged per domain per year, and the exact figure varies by registry and provider. Because the numbers differ across TLDs, it is best to confirm current pricing for the specific domains you want to protect.

The more useful question is whether it is worth it, and that is a matter of comparing the fee to the downside. Weigh a modest annual cost per domain against what losing a primary domain actually costs: interrupted revenue, a corporate email outage, the expense and disruption of incident response, potential data exposure, and lasting brand damage. For a critical domain, that comparison is not close.

There is a second cost worth naming honestly, and it is not financial. It is operational friction. Changes to a registry-locked domain take longer by design, because they route through manual verification. For the right domains, that is a price well worth paying. For the wrong ones, it is needless drag.

Registry Lock as one layer in a wider domain security strategy

Registry Lock is not a silver bullet. It is the strongest single layer for your most important domains, but it works best inside a defense-in-depth approach, where each control covers a different failure mode:

• Strong registrar-account hygiene and MFA as the baseline, to keep casual attackers out of the account.
• Registrar and transfer locks on every domain, to stop accidental and low-effort changes.
• Registry Lock on your business-critical domains, so they survive even a full account compromise.
• DNSSEC to protect the integrity of DNS resolution, so correct records cannot be spoofed in transit.
• Continuous monitoring across the domain portfolio, so attempted changes and anomalies are caught early, including on domains without a full lock.

Locking and monitoring complement each other. A lock prevents a change. Monitoring tells you an attempt was made, and it catches drift before it becomes an incident. None of this is exotic: the ICANN Security and Stability Advisory Committee has long backed registry-level controls, and CISA’s guidance on mitigating DNS infrastructure tampering points the same way. For a practitioner’s view, our interview with Klaus Darilion of nic.at is worth reading, and our Domain Security hub pulls the wider picture together.

Do not neglect the human layer. Documented change procedures, named authorized contacts, and a rehearsed incident playbook are what make out-of-band verification meaningful. For business-critical domains, a Registry Lock is the deliberate choice: the control that keeps holding at the registry even when everything at the account level has already failed.

Protect your domains in AutoDNS