One decision faces every UK accountancy practice before HM Revenue and Customs (HMRC) turns on multifactor authentication (MFA) for HMRC agent accounts: who signs in, under which credentials, and how each person receives an access code.
Voluntary activation ran through July and August 2026. HMRC activates the remaining accounts between 28 September and 15 October 2026, without confirming a date per firm. The preparation is mostly administrative: confirming the accounts in scope, settling the access model, and recording a backup method for everyone who signs in.
Who is affected: Every agent service and online services for agents' accounts under a Government Gateway identifier, plus every credential linked to it.
What changes at sign-in: User ID and password, then a six-digit HMRC access code from an authenticator app, text message, or voice call.
The access model decision: Individual credentials give per-person accountability. Shared credentials remain permitted and depend on an authenticator app.
Recovery planning: Two administrators per account and a recorded backup method keep the practice moving if someone loses access.
HMRC continues to update the rollout details, so check the current position in the HMRC guidance for online services for agents.
MFA adds a second step to agent sign-in. After the user ID and password, HMRC asks for a six-digit access code that is valid for up to 15 minutes and can be used once.
Activation attaches to the Government Gateway identifier, sometimes called the HMRC agent identifier, rather than to a single service. Every service under that identifier, and every administrator and user credential linked to it, switches on together.
The HMRC authentication policy separates a firm requirement from a recommendation, and the difference shapes the plan:
Mandatory: MFA on agent services accounts and online services for agent accounts, with at least one registered method for every credential that signs in directly.
Recommended by HMRC: An authenticator app as the primary method, at least one backup method per user, individual credentials for each staff member, and a second administrator on every account.
Those requirements land differently depending on how a firm is set up. Many carry several Government Gateway identifiers across legacy and current services, and Government Gateway MFA reaches every account sharing an identifier at the same time.
Account or workflow | MFA impact | What to confirm | Gap to close |
Agent services account | Access code required at every sign-in | Method registered for each user credential | Register a method for every user |
Online services for agents | Same code requirement across self assessment, corporation tax, and Pay As You Earn | Which identifier the account sits under | Map linked accounts before opting in |
Linked staff accounts | Administrator and assistant credentials activate together | Current phone numbers and app enrollment | Refresh contact details and remove leavers |
Direct browser sign-in | Code prompt on each session | Who holds the credential day to day | Name a code owner for every credential |
Third-party tax software | Unchanged for Making Tax Digital, code prompt appears where the product opens a direct sign-in | Vendor confirmation per product | Confirm each vendor position in writing |
Existing software authorizations follow separate rules. Filing authorization under Making Tax Digital renews on its own 18-month cycle, unchanged by this rollout, so the code prompt appears only where a product opens a direct sign-in.
From there, a central register of identifiers and the accounts beneath each one turn activation into a scheduled task rather than a last-minute effort. That register keeps earning its place after the rollout, too, as the foundation for wider identity access management decisions.
With accounts mapped and registered, four patterns account for most of what firms ran into after early activation, and each one has a fix that fits inside a normal working week. Handling these before activation, rather than during it, keeps filing on schedule.
One credential passed around a tax team leaves no record of who submitted a return. Individual credentials fix that: the audit trail returns, and no single person becomes a bottleneck when they're on annual leave. HMRC-shared credentials remain permitted too, when paired with an app-based code, since a code delivered to one mobile number depends on that person being reachable.
Clear naming closes the remaining gap. Labeling one token "HMRC," another "Gateway," and a third by a colleague's initials costs the person covering a filing deadline the first ten minutes working out which is which. Consistent naming saves that time back.
A second administrator keeps HMRC account recovery in-house and files on schedule. An administrator resets MFA for other users, not for themselves, so with only one administrator, a lost handset routes recovery to HMRC technical support for online services rather than staying in-house.
Reviewing saved contact details and registering a second method for every user gives each access code somewhere reliable to land. Some accounts already have MFA settings from earlier services, tied to a phone number that predates a handset upgrade or a staff change; a quick review can catch this. This step in HMRC lockout prevention takes an afternoon and removes the most common cause of an activation-day support call.
Products that open a browser session against HMRC pick up the code prompt with everything else. A brief check with each supplier confirms which filing routes require a person to be present to approve a code. Wider guidance sits with the National Cyber Security Centre (NCSC), whose cybersecurity advice for UK businesses covers the rest of the software estate.
Three of these four gaps trace back to the same question: how each person receives a code.
Three HMRC authentication methods deliver access codes, and a practice can register for all three. The choice comes down to how a team works across offices, home setups, and switchboards.
Authenticator app: Strongest of the three, generates codes on a phone, tablet, or computer without a mobile signal, and suits both individual and shared access models.
Text message: Codes arrive from 60551 and serve one user at a time, and they are less reliable on non-UK numbers.
Voice call: An automated call delivers the code, which rules out switchboards and shared reception lines.
HMRC ranks them by strength, and that order holds for most practices.
HMRC recommends an authenticator app for most practices. Codes are generated offline, so poor reception in a client meeting room doesn't stop anything, and enrollment transfers cleanly when a handset changes. A dedicated authenticator app for HMRC keeps sign-in codes separate from personal accounts.
HMRC recommends at least one backup so that a code always reaches the user, and both fill that role well. As a primary method for the whole team, each member depends on one person to answer one handset.
Account scope, access model, method choice, and recovery all resolve in the same preparation window. The list below runs once per identifier, and anything unticked is a gap worth closing before activation.
Account review
Compile a central list of every Government Gateway identifier the practice holds.
Map which agent services and online services accounts sit under each identifier.
Access model
Decide per account between individual credentials and a shared credential paired with an authenticator app.
De-provision credentials for people who have moved on or changed roles.
Backup coverage
Register a primary method and one backup for every credential that signs in.
Refresh saved phone numbers so codes reach the person doing the work.
Recovery ownership
Appoint two administrators per account so resets stay in-house.
Software dependencies
Confirm with each vendor that filing and authorization flows continue to work.
The integrated authenticator for verification codes stores a code and its corresponding credential in a single record.
HMRC sets the requirements. Bitwarden supports the access model and record-keeping behind it. Bitwarden Password Manager stores agent credentials and generates verification codes through the integrated authenticator, so the credentials and their codes live in a single record. Access travels through collections and groups, which turns a staff transition into a single deprovisioning step. Bitwarden Authenticator handles code generation on its own for teams that prefer a separate app. Both align with recognized cybersecurity compliance standards, and the setup steps sit in the MFA configuration guide.
The activation window runs from 28 September to 15 October 2026, which leaves room to deliberately settle the access model rather than during a filing week. Three ways to start:
Start a free 14-day business trial and set individual credentials, groups, and recovery ownership across the practice.
Get started with a free Bitwarden individual account and test code generation against one HMRC credential today.
Contact the Bitwarden sales team to plan a rollout across multiple offices and identifiers.
Yes. Voluntary activation ran from 15 July through 19 August 2026, and HMRC is set to complete the rollout for every remaining agent account from the 28 September to 15 October 2026 window, with no confirmed date set for each individual firm.
No. HMRC recommends individual credentials for per-person accountability, but shared credentials remain an option for firms that pair them with an authenticator app rather than text messages or voice calls.
A registered backup method covers most cases. A second administrator resets the user's MFA if that doesn't resolve it. If all administrators are locked out of their own credentials at the same time, they would need to contact HMRC technical support for online services.