Treat a domain transfer authorization code like a password. Generate it when you are about to transfer, not before, send it through a private channel, never by ordinary email or chat history, and confirm it expires or is cleared afterwards. Anyone who has the code and the right moment can try to move your domain.
What the code is
When you move a domain between registrars, the new registrar needs proof that you agreed. In the Extensible Provisioning Protocol, that proof is called authorization information, and in everyday language it is the auth code or EPP code. RFC 9154, an operational practice document, describes it as commonly used password based authorization for transferring an object such as a domain, and notes that it raises issues of security, storage and lifetime.
The code alone does not complete a transfer. Your domain must also be unlocked, and the other conditions of the transfer must be met. That is why a registrar lock matters: it blocks the transfer even if the code leaks.
What good handling looks like in the standard
RFC 9154 sets out how registrars should treat these codes. The key points:
- The value must be generated using a secure random value. The RFC says implementations should use at least 128 bits of entropy.
- It should have a short time to live. The registrar defines a TTL, must tell the registrant what it is, and the value is cleared when the TTL expires.
- Registrars should support setting the code just while a transfer is in process, instead of leaving one in place all year.
You cannot control how your registrar implements this, but you can ask. A registrar that stores a permanent, guessable code is a risk to every domain it holds.
A safe transfer routine
- Prepare the destination. Open the account at the new registrar, with MFA on, before touching the old one. See the registrar checklist.
- Lower DNS lifetimes ahead of any nameserver change, per DNS TTL planning.
- Check contacts. The confirmation messages go to the registrant email, so make sure someone you trust can read them.
- Unlock and request the code at the old registrar, from a clean device, in a signed in session with MFA.
- Share it carefully. Paste it into the new registrar yourself, or use a password manager sharing feature if someone else does the work. Avoid screenshots, shared chat rooms and email threads that many people can read.
- Complete the transfer and approve confirmation emails promptly.
- Verify afterwards. Look up the domain, confirm the new registrar, check nameservers and records are unchanged, and re-apply the lock.
- Clear or rotate any code still shown in the old account, if the registrar allows.
Warning signs
- A transfer confirmation email you did not ask for. Treat as an attack until proven otherwise, and contact your registrar through its emergency channel.
- The domain shows as unlocked and you did not do it.
- Changes to the registrant email shortly before a transfer request.
Our post on what recovery looks like after domain compromise covers the response.
After the transfer
Update your inventory, renewal dates and billing owner. Remove the old registrar's API tokens and user accounts. If you have a registry lock, set it up again with the new registrar.
Safeguard focuses on software supply chain security rather than registrar accounts. If you want to review your code dependencies, the free scan is at gold.safeguard.sh/scan.
Quick check
Is the auth code the same as the registrar password?
No. It is a separate value created for moving one domain. Protect both, since either can lead to loss of the domain.
Should I keep the auth code saved for later?
No. Generate a fresh one when you need it, and delete any copy after the transfer completes.
Sources
Last reviewed: 19 October 2026.
