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.

Key takeaways

• A Registry Lock is a security control applied directly at the registry, the operator of the TLD, that blocks any change to a domain until the request is manually verified out-of-band.
• Because it lives above your registrar, it stays in place even if your registrar account credentials are stolen.
• It prevents unauthorized nameserver changes, transfers, contact edits, and deletion.
• It is set using server-side EPP status codes that only the registry can remove, not the registrar.
• It is deliberately for your handful of business-critical domains, not your whole portfolio.

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.

A lesson from the cow.fi domain

The 2026 hijack of the cow.fi domain followed a pattern that should worry anyone responsible for a primary domain. The attackers did not defeat cryptography or breach the registry’s systems. They used social engineering and forged identity documents to push an unauthorized change through the domain’s registration process. They then redirected the domain to a look-alike phishing site for several hours, and drained roughly $1.2 million from users who believed they were on the legitimate site. The platform’s own application and backend were never touched. The domain was the single point of failure, and once control of it changed hands, everything downstream went with it. In the aftermath, the operator secured the domain with a Registry Lock.

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.

Client-side codes are set and removed by the registrar. The most common are:

• clientTransferProhibited: blocks transfers to another registrar
• clientUpdateProhibited: blocks updates to domain data
• clientDeleteProhibited: blocks deletion of the domain

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.

Server-side codes are set at the registry’s request and, crucially, can only be removed by the registry. A Registry Lock applies these three:

• serverUpdateProhibited: no updates to nameservers, DNS delegation, or domain data
• serverTransferProhibited: no transfer to another registrar
• serverDeleteProhibited: no deletion of the domain

Your registrar cannot lift these codes on its own. It will not lift them just because an attacker has logged in and asked. Only the registry can, and only after the out-of-band verification step.

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.

	Registrar / Transfer Lock	Registry Lock
Where it is applied	At the registrar, inside your account	At the registry, above the registrar
Who can remove it	The registrar, often automatically	Only the registry, after manual verification
Verification to change	None beyond account access	Out-of-band confirmation by a named contact
EPP status codes	clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited	serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited
Holds if the account is compromised	No	Yes
Best suited for	Every domain, as a baseline	Business-critical domains

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.

DNSSEC vs. Registry Lock

DNSSEC belongs in this conversation as context, but it is not an equivalent control. DNSSEC uses cryptographic signatures to guarantee that DNS answers have not been tampered with in transit, protecting the integrity of resolution. It does nothing to stop someone from legitimately changing your domain’s records at the registry. Only the Registry Lock stops unauthorized changes. DNSSEC protects the authenticity of the records once they are set. They solve different problems and belong together, not one instead of the other. Our deep dive on DNS spoofing and how to prevent it explains where DNSSEC fits in that picture.

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.

A Registry Lock protects against:

• Unauthorized nameserver and DNS delegation changes at the registry
• Unwanted transfers to another registrar
• Tampering with registrant or contact information
• Accidental or malicious deletion of the domain
• Social-engineering-driven changes, because the out-of-band verification catches requests that would otherwise slip through on stolen credentials alone

A Registry Lock does not protect against:

• Compromises inside your own DNS zone once resolution is delegated to your hosting or DNS provider. The lock protects the delegation record at the registry, not the individual records you manage inside the zone.
• Expired domains because they were not renewed. A lock does not pay the invoice.
• TLS/SSL certificate mis-issuance, phishing that uses look-alike domains, or application-level breaches on your servers.

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.

Run each domain through a short checklist. Is the domain tied to any of the following?

• Revenue, directly or through a transactional or storefront function
• Your primary corporate email
• Login, single sign-on, or federated authentication for staff or customers
• Customer trust and brand recognition
• A regulated or compliance-sensitive service

If the answer to any of these is yes, the domain is a candidate for Registry Lock.

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.

For resellers and MSPs

For anyone whose business is domain reselling, there is a clear opportunity here. Registry Lock is a genuine value-added service worth putting on a retainer: a concrete, defensible security measure you can offer clients whose domains are business-critical, backed by a documented verification and change process.

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 Registry Lock works at InterNetX

The Registry Lock at InterNetX is handled via AutoDNS. The exact process depends on the registry behind each extension, so the steps vary from one TLD to the next. Here is how activation, changes, and removal work for .com, .net, and .de.

How does Registry Lock work for .com and .net?

For .com and .net, our Domain Services team activates the lock on your behalf. When you need to make a change, we lift the lock, you update the domain, and we re-apply the lock once the update is complete. Deactivation runs through our team as well.

How does Registry Lock work for .de?

For .de, activation starts with a written lock form. You submit the form and our team activates the lock. On the form, you name a contact, the person who is notified of any requested change to the domain and who authorizes it. Because the process begins with your form, the domain holder has to take the first step.

Once the lock is in place, you can still update the domain, but every change has to be confirmed separately by your contact, who must be reachable by SMS and email. If you need to change the contact, that request is handled in writing. To lift the lock, you submit a written unlock form and our team takes care of the rest.

We also offer other TLDs. To find out more, see Registry Lock in our Help Center.

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