Run a WHOIS lookup on your credit union's domain and you will probably see a status line that reads clientTransferProhibited. Most IT teams read that as "our domain is locked" and move on. During a domain hijacking we worked this summer, that exact status was present, correctly configured, the entire time. Here is what it actually prevented: nothing that mattered.
What a transfer lock actually locks
Two things about clientTransferProhibited that the name doesn't tell you.
First, it only restricts transfers. Moving your domain to a different registrar. It says nothing about the far more dangerous change: editing the nameserver delegation. An attacker who reaches your registrar account can repoint your entire domain, every subdomain, your email, your online banking redirect, to infrastructure they control, without touching the transfer lock at all. In our incident, that is exactly what happened. The lock sat there, technically intact, while the delegation moved.
Second, the client prefix means it is set and removable at the registrar level. Whoever controls the registrar account can simply switch it off. Which the attacker eventually did, before transferring the domain to an overseas registrar entirely. The lock protects you from an attacker who has nothing. Against an attacker who has your registrar account, it is a checkbox they untick.
The status codes that actually mean something
Domain statuses come in two families. client* codes are set by the registrar and controlled by whoever holds the registrar account. server* codes (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) are set at the registry, the operator of the top-level domain itself, and no registrar account takeover can remove them. Getting them removed requires an out-of-band verification ceremony with the registry, which is precisely the point.
This is what the industry calls a registry lock. It is a paid product, typically offered through enterprise registrars or as a premium add-on, usually a few hundred dollars a year. For a financial institution, it converts "anyone who phishes our registrar password owns our domain" into "changing our delegation requires a human verification process that an attacker cannot complete." We know of no cheaper control anywhere in security with that much leverage.
What recovery taught us about durability
Once a hijacked domain is being fought over, the difference between registrar-level and registry-level action shows up again. In our incident, registrar-level interventions were repeatedly reversed within hours: holds lifted, locks re-added by the attacker, delegation flipped back. Every control that lived at the registrar level was a revolving door, because the account layer itself was contested. The interventions that held were the ones made at the registry layer. If you remember one sentence from this article: in a fight for your domain, only registry-level statuses are ground truth.
Check your domain in the next ten minutes
1. Look up your domain's RDAP record (your registrar's WHOIS page works too) and read the status lines. If you see only client* codes, you have consumer-grade protection.
2. Ask your registrar, in writing: "Do you offer registry lock for our TLD, what does it cost, and what is the verification ceremony to remove it?" If the answer is no, that is a reason to change registrars, and the migration itself is a half-day of work. Treat the registrar like the tier-one vendor it is.
3. While you are in the account: hardware-key MFA, unique credential, and an inventory of every person who can log in, including the marketing agency that registered the domain twelve years ago. Pair it with the CAA and DNSSEC records covered next in this series.
4. Know that after any registrar transfer, ICANN policy imposes a 60-day lock before the domain can move again. That cuts both ways: it also slows you down when recovering a stolen domain, which is one more reason to make the theft impossible rather than recoverable.
A transfer lock is a seatbelt sticker. A registry lock is the seatbelt. Your examiner will not ask the difference this year. Your incident responder will. If nobody in the building owns questions like these, that is the gap a vCISO exists to close.
