Whoever controls your registrar account controls your domains, and with them your website, email and the certificates issued for both. CISA's Emergency Directive 19-01 described the pattern plainly: attackers stole credentials for accounts that could change DNS, repointed A, MX and NS records to their own infrastructure, and then obtained valid certificates for the hijacked names. Most organisations picked their registrar years ago for price or convenience, and many hold domains at several registrars bought by different teams. This vendor-neutral buyer's guide helps security, IT and brand teams choose a corporate registrar on security grounds: account protection, locking, portfolio management, takedown support and DNS hosting. Configuration of the registrar you already have is covered in the Authoritative DNS and Registrar Account Security Guide.
Key takeaways
- Registry lock is the deciding feature. Registrar-set locks can be removed by anyone who takes over the account; registry-level locks need the registry to act and survive an account compromise.
- Phishing-resistant MFA and role separation on the portal and API matter more than any other account control. CISA advises against SMS as the second factor for DNS accounts.
- Consolidation reduces risk only if the chosen registrar supports per-domain permissions, audit logs and alerts; otherwise it concentrates it.
- Support quality is a security control. Test how the registrar verifies callers, handles a hijack report and recovers a domain before you need it.
- Decide separately on DNS hosting. Bundled DNS is convenient but puts registration and resolution behind one set of credentials.
Define requirements
Start with an inventory, not a vendor list. The NCSC recommends that a single internal group registers and manages all public domains so that contacts, renewals and payment are consistent, and that domains are owned by the organisation rather than a web host or an individual.
- Portfolio: how many domains, which TLDs (generic and country code), which registrars hold them today, and which are critical (primary web, mail, SSO, API, certificate validation).
- Tiers: which domains justify registry lock, which need defensive registration only, and which can lapse. See the Domain Portfolio and Lookalike Domain Management Guide.
- People and roles: who may change name servers, contacts and locks, who approves, and who only reads. ICANN's SSAC (SAC044) advises role-based contacts rather than named employees, with contact mailboxes hosted on a domain outside the account being managed.
- Automation: whether DNS changes, renewals or certificate validation run through an API, and therefore through tokens that need the same protection as admin accounts.
- Brand protection: whether you need lookalike monitoring, dispute (UDRP) support and takedown handling from the same provider.
- Jurisdiction and ccTLDs: local presence requirements for country code domains, and where registrant data is held.
Capability areas
| Area | What to look for | Why it matters |
|---|---|---|
| Account authentication | Enforced MFA for every user, FIDO2 or passkey support, SSO via SAML or OIDC with your identity provider, no SMS fallback for admins | ED 19-01 hijacks began with stolen DNS and registrar credentials |
| Authorisation | Roles (admin, technical, billing, read-only), per-domain or per-group permissions, dual approval for name server and contact changes | Limits what one compromised user can change |
| Locking | clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited by default; access to registry lock (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) for each TLD you hold | ICANN notes server codes take precedence and take longer to remove |
| Unlock process | Documented out-of-band verification with named contacts, callback to pre-registered numbers, time delays | A lock is only as strong as the process that removes it |
| Audit and alerting | Immutable logs of logins, changes and API calls; real-time alerts on name server, contact, lock and payment changes, sent through more than one channel; SIEM export | SAC044 lists activity logs and out-of-band notification among its registrar questions |
| API security | Scoped tokens, IP allowlisting, expiry, per-token logging | Automation tokens are non-human identities with admin reach. See the Authoritative DNS and Registrar Account Security Guide |
| Portfolio management | Consolidated view across TLDs, auto-renew, renewal reporting, corporate billing, transfer-in support | Lapsed domains can be registered by anyone |
| DNS hosting | Anycast authoritative DNS, DNSSEC signing and DS management, change history, secondary DNS support | Optional; see decision guidance below |
| Brand and takedown | Lookalike monitoring, dispute support, abuse reporting to other registrars and hosts | See the Brand Impersonation and Lookalike Domain Takedown Playbook |
| Incident support | 24x7 security contact, documented hijack recovery, account manager who knows your verification rules | The NCSC advises knowing the reclaim process before an incident |
Bundled or separate DNS hosting
Bundling registration and authoritative DNS with one provider simplifies DNSSEC key rollovers and support. Separating them means a compromise of one account cannot both change your records and move the domain, and lets you run two DNS providers for resilience. Large organisations with in-house DNS teams usually separate; smaller organisations often bundle and compensate with registry lock and strict roles. Either way, the registrar must support DNSSEC DS record management for every TLD you hold. See the DNSSEC Deployment Guide.
Evaluation criteria
| Criterion | Weight (suggested) | Minimum acceptable | Strong |
|---|---|---|---|
| MFA and SSO | High | MFA enforceable for all users | SSO plus phishing-resistant MFA, admin step-up for sensitive changes |
| Registry lock coverage | High | Available for your primary TLDs | Available for every TLD held, with tested unlock SLAs |
| Change controls | High | Role-based access | Per-domain permissions and dual approval for NS, contact and lock changes |
| Logging and alerts | High | Portal change history | Exportable logs, API logs, multi-channel alerts |
| Support verification | High | Caller verification against account data | Pre-agreed verification phrases or callbacks, named account team |
| Portfolio coverage | Medium | Your current gTLDs | All gTLDs and ccTLDs held, with local presence services |
| API | Medium | Token-based API | Scoped, expiring tokens with IP restriction |
| Brand protection | Medium or low | Abuse reporting | Monitoring, dispute and takedown services |
| Assurance | Medium | ICANN accreditation for gTLDs | Independent security attestation and clean compliance history |
Questions to ask vendors
- Which of our TLDs support registry lock through you, and what exactly happens, step by step, when we ask to unlock?
- Can MFA be enforced for every user and API client, which factors are supported, and can SMS be disabled?
- Do you support SSO with our identity provider, and does disabling a user there revoke registrar access immediately?
- Can permissions be restricted per domain, and can name server or contact changes require a second approver?
- Which events trigger alerts, through which channels, and can logs be streamed to our SIEM?
- How does your support team verify that a caller is authorised, and can we add stricter verification for our account?
- What is your process when we report a hijack of a domain held with you, and when we report abuse of a domain held elsewhere?
- How do you handle transfers in from our existing registrars without a lapse in locks or DNS?
- What independent security assessment covers your registrar platform, and when was it last done?
Red flags
- MFA that is optional, or that falls back to SMS or email for account recovery.
- No registry lock, or registry lock described as a portal toggle that the account holder can remove alone.
- Support staff who can change name servers or contacts after a phone call with no pre-agreed verification.
- No exportable audit log, or alerts sent only to the email address on the domain being changed.
- API keys that never expire and carry full account rights.
- Default wildcard redirects or parking on non-existent subdomains with no opt-out, which SAC044 flags as a question to ask.
- Pressure to move all domains at once without a transfer plan.
Proof of concept
- Transfer two or three low-value domains, including one ccTLD, and confirm locks, contacts and DNS survive the move.
- Configure SSO and phishing-resistant MFA, then disable a test user in your identity provider and confirm access ends.
- Set up roles and dual approval, then attempt a name server change as a technical user and check that it waits for approval.
- Apply registry lock to one test domain, then run the unlock procedure and time it end to end.
- Make a change through the API with a scoped token and confirm it appears in the log and raises an alert.
- Call support from an unregistered number and request a contact change. The correct outcome is refusal.
- Report a simulated hijack and a lookalike domain, and record response times and quality. Use the Domain Registrar Compromise Playbook as the test script.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for identity, access and infrastructure security programmes, including the API tokens and service accounts that manage DNS. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Authoritative DNS and Registrar Account Security Guide · DNS Hijack Playbook · Domain Portfolio and Lookalike Domain Management Guide · DNS Security Guide