Your registrar account for every company domain sits with marketing — what do you require, and how do you win it?

## Why this is a principal's problem and not an engineer's Everything about name hijacking that a security engineer can influence is downstream: how a resolver randomises, what it forwards to, what it validates. The upstream root of trust is an account at a domain registrar, and in most organisations that account was opened years ago by whoever bought the first domain — typically marketing or an agency — with a personal email address as the recovery contact. The security function usually has no access to it, no inventory of what it holds, and no say in who can change it. That is a governance problem, and it cannot be solved by anyone who cannot spend money or change ownership. The asymmetry is stark. Winning a race against a resolver puts one wrong record into one resolver until it expires. Signing into the registrar account and repointing the delegation makes the attacker authoritative for the entire zone, on every resolver on the internet, until a human notices. The second is cheaper, quieter and larger, and it is reached with a credential rather than a packet. ## What to require Keep the list short enough that it can survive a negotiation: 1. **Registry-level change locks on the load-bearing domains.** Registries support status settings that refuse updates, transfers and deletions until the registrar removes them through an out-of-band process. This is the single highest-value control here, because it means a stolen login is not sufficient — the change has to pass through a human procedure outside the web session. 2. **Phishing-resistant multi-factor on the account**, not a code by SMS. The whole threat is somebody signing in as the account holder. 3. **A role account, not a person.** Individual logins leave with the individual, get shared during holidays, and end up with an agency. 4. **A recovery address inside a domain you control.** A recovery mailbox at a consumer provider is a route straight past every other control; a password reset lands there and the account is gone. This is the most commonly missed item and the cheapest to fix. 5. **Two-person approval for delegation changes**, so the person who requests a nameserver change is not the person who approves it. 6. **A named owner and funded auto-renewal.** An expired domain is a hijack with extra steps, and portfolios sprawl across accounts, agencies and expired payment cards. 7. **An inventory.** You cannot lock what nobody has listed. Expect the first pass to find domains nobody remembers buying. ## Winning the argument The requirements are easy; the adoption is not. Three moves make the difference. **Segment the portfolio.** Not every domain deserves a lock. The ones that carry sign-in, mail and payments do; a campaign microsite for a conference does not. Offering marketing a two-tier scheme — locked and slow for perhaps a dozen names, unlocked and instant for the rest — converts a total refusal into an easy yes, and it concentrates the protection where the loss would be existential. **Price their pain and pay it.** Marketing's objection is never "we like being insecure". It is that a vendor onboarding, an event page or an ad-verification record will now wait a day. So commit to a same-day approval path with named approvers and a deputy, and put the approval step inside the workflow they already use rather than a new queue of yours. If you cannot staff the approval, do not ask for the lock. **Frame the spend against the alternative.** The locks and the account hygiene cost a few hundred a year plus some process. The alternative programme — chasing resolver behaviour across every office, every forwarder and every NAT you do not own — is far more expensive and does not close this route at all. That framing is the argument a budget holder can act on. ## The tradeoffs to own honestly - **Locks slow legitimate change**, and one day you will need an emergency delegation change during an outage. Rehearse the unlock path before you need it, and know who at the registrar answers the phone. - **Ownership transfer is disruptive.** Moving a portfolio between accounts or registrars risks losing a domain mid-flight; sequence it, and never move the load-bearing names first. - **Two adversary classes, two effects.** A criminal buying or resetting the login is stopped dead by a registry lock plus a controlled recovery address. A well-resourced crew that can still run the resolver race is not — that route remains open, and its cost has not changed. So this is not a substitute for sensible resolver configuration; it is the removal of the *cheap* route, and cheap routes are the ones that get used. - **You may not get the account.** If ownership genuinely cannot move, settle for the locks, the recovery address and the approval rule, and write down who owns the residual risk. A named owner who declined is a better outcome than a security team quietly holding a risk it cannot control. ## The one-line version The registrar account outranks every downstream measure because it decides who is *legitimately* the answer for your names. Secure it as a root of trust, scope the friction to the names that matter, and pay for the approval path you are asking someone else to live with.