How to implement Secure Transfer Authorisation Codes (TAC)

We announced on the 24th February 2026 that all registries on Nominet’s Dragon platform are upgrading to Secure Transfer Authorisation Codes (TAC) as defined by RFC9154. The changes will come into effect on 22nd July 2026 at 09:00 UTC+1.

---

RFC9154 (“Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer”) establishes best practices for handling object authorisation information to prevent unauthorised inter-registrar transfers.

In the EPP ecosystem, the registrar acts as the client. To achieve compliance with RFC 9154, a registrar must implement the following key operational and technical shifts:

1. Shift from Long-Lived to Short-Lived Transfer Authorisation Codes

• Do Not Assign on Creation: Traditionally, TACs is generated when an object is created and lasts indefinitely. Registrars must support leaving the authorisation information empty/unset upon object creation.
• On-Demand Generation: Only generate or set the TAC when an actual transfer process is actively requested by the registrant.
• Automatic Unsetting: Nominet’s Dragon registry systems will ensure the TAC is cleared/unset immediately after a transfer is completed (either approved or automatically approved) or when its Time-To-Live (TTL) expires.

2. Implementation of Strong, Random Values

• High Entropy: When generating an TAC value for an outbound transfer, the registrar must use a cryptographically secure random number generator. Registrars should generate their Transfer Authorisation Codes using the complexity requirements set out here.
• Do Not Reuse: Treat each generated TAC as a single-use token specifically for that transfer window.

3. Zero Long-Term Storage Policy

• Client-Side (Registrar) Storage: The registrar MUST NOT store the plain-text or encrypted TAC long-term in their database or local registry caching layers. It should only exist transiently to pass to the registry and the registrant.
• Safe Reseller Channels: If the registrar uses a reseller channel, this strict ephemeral handling policy must extend through the APIs/interfaces provided to those resellers.

Summary of Registrar Workflow Changes

For Gaining Registrar: Collect the TAC from the registrant, submit the EPP <transfer> request to the registry immediately, and ensure the TAC is discarded once the command is sent.

For Sponsoring (Losing) Registrar: When a registrant requests a transfer out, generate a secure random TAC, send it to the registry via an EPP <update> command, provide it to the registrant, and do not save it locally.

For Registrar’s only using Dragon Domain Manager (DDM) to manage domains, all the technical integration requirements will be handled by DDM meaning you only need adhere to the storage and handling requirements set out in the RFC.

For Registrar’s who have their own EPP technical integration then the key upgrades to EPP under RFC9154 are as follows:

1. EPP Login command should declare the secure-authinfo extension – example here.
2. EPP Create commands must set an empty auth info code – examples: domain or contact.
3. The Transfer Authorisation Codes that are generated must always meet the complexity requirements documented here.