Registrar lock is a status at the domain registrar that blocks routine transfers, while registry lock is a stronger control at the domain registry that prevents changes such as transfer, deletion, or nameserver updates until out-of-band verification. Registry lock usually protects against registrar account compromise as well as direct registrar misuse.
How registrar lock and registry lock differ in practice
Registrar lock is usually the lighter control. It tells the registrar not to process a standard transfer request unless the lock is removed first. That makes it useful for routine protection, but it still depends on the registrar account and its own support workflow.
Registry lock sits deeper in the domain control chain. It is enforced at the registry level, so it can block high-impact actions such as transfer, deletion, and nameserver changes until the request is verified out of band. That makes it materially stronger against account compromise and malicious support misuse.
For a practical view of the distinction, think of registrar lock as a transfer barrier and registry lock as a change-control barrier. The latter is typically used for high-value domains where the cost of an unauthorized change is much higher than the inconvenience of manual verification.
Why the difference matters for domain security
The security gap is not just about who can click “unlock.” Registrar lock mainly slows ordinary transfer abuse. Registry lock is designed to resist deeper takeover paths, including cases where an attacker gets into the registrar account or persuades support to make an unsafe change.
That is why many teams treat registry lock as part of a broader anti-hijack posture, not just as a transfer setting. It reduces the chance that a single compromised credential, ticket, or admin workflow can redirect the domain, break resolution, or interfere with renewal and DNS integrity.
If the domain supports customer login, email, or public trust, the operational consequence of a bad change is often larger than the technical change itself. A nameserver swap or transfer can cascade into mail outage, certificate issuance issues, and traffic interception opportunities.
When to use each control
Registrar lock is appropriate when you need a baseline guardrail against accidental transfer or low-effort abuse. It is common for ordinary domains, but it should not be mistaken for a strong hijack defense on its own.
Registry lock is the better choice when the domain is business-critical, externally trusted, or hard to replace. It is especially relevant when the domain anchors email delivery, SSO, certificate issuance, customer portals, or brand reputation.
The control choice should follow the impact of domain compromise, not the size of the portfolio. A small number of high-value domains often justify stronger handling than a large number of low-risk holdings. See the Domain Registrar Compromise Playbook for the response pattern when a domain is already at risk.
Risk and Threat Considerations
The main risk is assuming that a registrar-side setting and a registry-side control provide the same protection. If the registrar account is compromised, a weak transfer-only lock may still leave room for destructive changes through support, workflow abuse, or adjacent DNS management paths.
Failure mechanism: An attacker or careless insider abuses registrar access, support processes, or DNS change authority to remove protection, shift nameservers, or initiate a transfer before defenders notice.
Impact: The domain can be hijacked, redirected, or taken offline, with downstream effects on email, authentication flows, certificate issuance, and customer trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Domain locks depend on controlled account access and recovery paths. |
| Recommendation — Restrict and review registrar account access before relying on domain locks. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Registrar and registry protection depends on secure credential lifecycle and recovery handling. |
| AC-6 — Least Privilege | Registry lock is about limiting who can approve or execute high-impact domain changes. | |
| Recommendation — Rotate and protect registrar credentials and recovery factors for critical domains. Limit domain change authority to the smallest set of approved administrators. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Protecting domain control requires access governance over registrar and support workflows. |
| Recommendation — Control registrar access and approval workflows for domain changes. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Compromise often involves altering account or support state to change domain settings. |
| Recommendation — Monitor for unauthorized changes to registrar accounts and related recovery settings. | ||
Practitioner Guidance
What to verify: Confirm whether the domain is protected by registrar lock only, or by a true registry lock that requires out-of-band verification for material changes. Check which actions are blocked, because different providers use different terminology and service models.
What to prioritise: Put registry lock on domains whose compromise would affect mail, login, payment, or brand trust. For the rest, keep registrar lock enabled, but do not treat it as a substitute for registrar account hardening and change monitoring.
Common mistake: Teams often rely on a single lock state and skip review of registrar account recovery settings, support escalation paths, and nameserver monitoring. Those are the places attackers target when they cannot simply transfer the domain.
Practitioner takeaway: Use registrar lock as a basic safeguard, but reserve registry lock for domains where an unauthorized change would create real business or security impact, and verify the control path end to end rather than trusting the label.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org