A Xero organisation holds the ledger, supplier bank details, bank feeds and often payroll, so an invited adviser with more access than needed, a connected app with broad write scopes or an unverified change to a supplier's bank account can move real money. Xero gives organisations the controls to manage this: mandatory multi-factor authentication for everyone who logs in, a small set of user roles, OAuth 2.0 connections with granular scopes, and History and notes records on contacts and transactions. This guide explains how identity and access work in Xero, how to assign roles and keep the subscriber and adviser accounts under control, how to govern connected apps and custom connections, what to monitor, and a hardening baseline built around supplier payment fraud. It is for business owners, finance managers, accountants and bookkeepers who administer Xero, and the IT or security people who support them. Every setting here is on the customer side of the shared responsibility model.
This is an independent guide from NHI Mgmt Group, based on Xero's public documentation as of November 2026. It is not sponsored or reviewed by Xero. Product features change, so confirm settings against Xero's current documentation.
Key takeaways
- MFA is required for every user who logs in. Xero's MFA FAQ states that users must turn on MFA to keep using Xero, with Xero Verify push approval or a time-based code from an authenticator app, plus backup email and security questions for recovery.
- Roles are few, so assign them carefully. The Xero API lists the organisation roles Read only, Invoice only, Standard, Financial adviser, Managed client and Cashbook client; give each person the lowest one that fits their work.
- Connected apps are standing access. An OAuth 2.0 connection keeps a refresh token that rotates on every use and lapses after 60 days unused, so an app that syncs daily holds access indefinitely until someone disconnects it.
- Move integrations to granular scopes. Apps created from 2 March 2026 use granular scopes, and Xero has set September 2027 as the deadline for older apps to move from broad scopes.
- Verify every supplier bank change out of band. History and notes on the contact records who changed what; pair it with a call-back to a known number before any payment run. See the Invoice Redirection and Supplier Bank Detail Fraud Guide.
How identity and access work in Xero
A Xero login is a personal identity that can be invited into one or more organisations. Inside each organisation the user holds a role, and the user's identity, MFA and devices are managed in their own account settings rather than by the organisation. One user per organisation is the subscriber, who holds the billing relationship (the API exposes this as IsSubscriber). Because a single login often spans several organisations, particularly for accountants and bookkeepers, a compromised adviser account can reach every client organisation it has been invited into.
Multi-factor authentication
According to Xero's MFA FAQ, MFA is mandatory for users who log in: invited users must set it up, it is optional only during a trial, and users who never log in (such as payroll employees using a portal) are out of scope. The options are:
| Method | How it works | Operational notes |
|---|---|---|
| Xero Verify | Push notification to Xero's own app, approved or denied by the user | Needs an internet connection; works only for Xero logins; train users to deny pushes they did not start |
| Authenticator app (TOTP) | Time-based code typed at login, from apps such as Google Authenticator or FreeOTP | Works offline; requires accurate device time |
| Backup email | Recovery when the authenticator is unavailable | Protect this mailbox with its own MFA and a unique password, since it can unlock Xero |
| Security questions | Alternative recovery method | Use answers that are not discoverable, stored in a password manager |
| Remember this device | Skips MFA on that device for 30 days | Use only on managed, personal devices, never shared office machines |
Because the backup email can complete sign-in, it is part of the Xero attack surface. Push approval also invites fatigue attacks, so teach users that an unexpected Xero Verify prompt means their password is known and must be changed. See the MFA Fatigue and Bypass Guide.
Admin roles and privileged access
Xero's role model is compact. The organisation roles exposed by the Xero Accounting API are shown below with the security view of each; confirm the exact role names and add-on permissions in your organisation's Users settings, since the user interface groups some of them differently.
| API role value | Typical holder | Security view |
|---|---|---|
| READONLY | Auditors, investors, managers who only review | Lowest risk; still exposes customer, supplier and financial data |
| INVOICEONLY | Sales staff raising invoices or entering bills | Suited to front-office staff who only raise invoices or enter bills; confirm its scope in Xero Central |
| STANDARD | Bookkeepers and finance staff | Day-to-day accounting; decide deliberately whether user management is added |
| FINANCIALADVISER | Accountants and advisers | Broad access; check the exact permissions in Xero Central and limit to the people who need it |
| CASHBOOKCLIENT and MANAGEDCLIENT | Client users on partner-managed plans | Reduced feature sets defined by the plan |
- Protect the subscriber account: it controls billing and the organisation's existence, so hold it under a named owner with credentials in a password manager, a dedicated backup email and a documented succession plan.
- Keep user management narrow: grant the ability to manage users to at least two trusted people for continuity and no more, because whoever holds it can invite new users or raise roles.
- Review external advisers: accountants and bookkeepers often hold adviser access to many organisations. List them each quarter and remove those whose engagement has ended.
- Separate payment duties: the person who edits supplier contacts and bank details should not also approve and release payments. In small teams, add a second person's review of the payment batch instead. See the Segregation of Duties Guide.
- Remove leavers promptly: a removed user shows the role value REMOVED in the API, which gives a simple check that offboarding happened. See the Employee Offboarding Security Checklist.
Integrations, API tokens and service accounts
Every app that reads or writes Xero data, from payment platforms and receipt capture to reporting tools, connects through OAuth 2.0. These connections are non-human identities with standing access to the ledger, and they deserve the same review as human users. See the SaaS and OAuth App Governance Guide.
| Connection type | Grant | Token facts from Xero's developer docs | Governance point |
|---|---|---|---|
| Standard app (web or PKCE flow) | Authorisation code; a user consents | Access token 30 minutes; refresh token rotates on each use and expires after 60 days unused | Disconnect apps no longer in use; the authorising user's access bounds the app |
| Custom connection | Client credentials, one organisation | Access token 30 minutes; new tokens from client ID and secret alone | The client secret is the credential: store it in a vault and rotate it |
Scopes
Xero scopes take the form accounting.contacts (read-write) and accounting.contacts.read (read-only). Broad scopes such as accounting.transactions cover bank transactions, credit notes, invoices and repeating invoices together. Xero's granular scopes FAQ sets out the move to narrower scopes: apps created on or after 2 March 2026 use granular scopes, older apps could start requesting them from April 2026, and they have until September 2027 to complete the move, using a mix in the meantime. Xero's own example replaces accounting.transactions with accounting.invoices. When an app asks for consent, check whether it requests write access to contacts or settings and ask the vendor why if the use case is read-only reporting.
Custom connections
A custom connection is a premium option for a single organisation's own integration, available for organisations in Australia, New Zealand, the UK and the US. The integrator enters an authorising user's email, that user approves by email, and the integration then requests tokens with its client ID and secret, with no refresh token. That makes the client secret a long-lived credential equivalent to a password with the scopes chosen at setup. Keep it in a secrets manager, never in spreadsheets or scripts, and choose an authorising user whose role is appropriate for the integration. See the Machine-to-Machine OAuth (Client Credentials) Guide.
Refresh token handling for your own apps
If you build on Xero, store refresh tokens encrypted, replace the stored token with the new one returned on every refresh, and use the 30-minute retry window Xero describes only for a lost response. A refresh token that stops rotating as expected, or two systems refreshing the same token, is a sign it has been copied. See the How to detect use of a stolen OAuth refresh token guide.
Logging and detection
| Source | What it records | Detection use |
|---|---|---|
| History and notes on contacts | Changes to the contact record and the user who made them (also available through the API's Contacts History endpoint) | Supplier bank detail changes before a payment run |
| History and notes on transactions | Creation, edits, approval and payment of invoices, bills and batch payments | Bills edited after approval; payments to new or changed accounts |
| Users list and roles | Who has access and at which role, including REMOVED users | New adviser invitations, role increases, leavers still active |
| Connected apps list | Apps connected to the organisation | Unknown apps, apps connected by users who have left |
| User account settings | Each user's MFA device and backup methods | Device changes the user did not make |
Most Xero organisations are small and have no SIEM. The practical control is a weekly review routine: open History and notes for any supplier whose details changed, compare the users list with the staff list, and check the connected apps list. Larger finance teams can pull contact and transaction history through the API with a read-only integration and alert on changes to bank details. See the SaaS Audit Log Retention and Licensing Guide.
Metrics
- Bank change verification: supplier bank detail changes confirmed by call-back to a known number before payment, target 100 per cent.
- Adviser hygiene: external adviser users with a current engagement, target 100 per cent.
- App ownership: connected apps with a named business owner and a use in the last quarter, target 100 per cent.
- Broad scope apps: connections still using broad scopes, falling to zero before September 2027.
- Backup method health: users whose backup email is a company-controlled mailbox with MFA, trending to 100 per cent.
Hardening baseline
- Inventory: export the users list with roles and user management rights, identify the subscriber, list external advisers and the organisations they reach, and list every connected app and custom connection with its owner.
- Authentication: confirm every user has completed MFA, prefer authenticator codes or Xero Verify on a managed phone, check that backup emails are protected mailboxes, and switch off "remember this device" on shared computers.
- Roles: move each user to the lowest role that fits, limit user management to two people, and remove advisers who no longer work on the organisation.
- Supplier payments: write a rule that any change to supplier bank details is verified by phone to a number already on file, recorded in History and notes, and reviewed by a second person before the next payment batch. Treat emailed requests to change bank details as suspect by default. See the Business Email Compromise Awareness for Finance Teams Guide.
- Connected apps: disconnect apps with no owner or recent use, ask vendors of remaining apps for their granular scope plans, and record which user authorised each connection.
- Custom connections and your own apps: keep client secrets and refresh tokens in a secrets manager, rotate secrets when staff with access leave, and restrict scopes to what the integration needs.
- Phishing reporting: forward suspicious emails claiming to be from Xero to the address Xero publishes on its security page, and check Xero's security noticeboard for current scam themes.
Test role changes with one user first and confirm their daily tasks still work; roll back by restoring the previous role from the users list. Disconnecting an app is reversible by reauthorising it, so disconnect unknown apps first and investigate second.
Small and large organisations
A sole trader or small business can apply this baseline in an hour: MFA confirmed, one adviser, one or two apps, and a call-back rule for bank changes. A finance team running several organisations should assign roles per organisation, review advisers and connected apps quarterly, keep a register of integrations with owners, and pull History and notes through a read-only API connection for automated bank change alerts.
Common misconfigurations
- Everyone on the adviser role: staff given broad access because it was the quickest choice when inviting them.
- Shared logins: one Xero login shared by a team, which breaks accountability in History and notes and ties MFA to one person's phone.
- Unprotected backup email: a personal mailbox without MFA set as the Xero backup, giving a second route into the account.
- Bank details changed by email request: a supplier "update" email accepted and keyed in without a call-back, the core pattern of invoice redirection fraud.
- Forgotten connected apps: trial apps and apps authorised by former staff left connected with write scopes.
- Client secrets in spreadsheets: custom connection credentials stored where many people can read them.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | MITRE ATT&CK |
|---|---|---|---|---|
| User roles, user management, advisers | AC-2, AC-6 | PR.AA-05 | 5.15, 5.18, 8.2 | T1098 Account Manipulation |
| MFA and recovery methods | IA-2, IA-5 | PR.AA-01 | 5.17, 8.5 | T1078.004 Cloud Accounts |
| Connected apps, custom connections | IA-5, AC-6 | PR.AA-01 | 5.17 | T1528 Steal Application Access Token, T1550.001 Application Access Token |
| History and notes review | AU-2, AU-6 | PR.PS-04, DE.CM-03 | 8.15, 8.16 | T1213 Data from Information Repositories |
| Supplier bank change verification | AC-6, AU-6 | DE.CM-03 | 5.15, 8.16 | T1657 Financial Theft, T1566 Phishing |
Practitioner checklist
- Confirm every user has MFA set up and that backup emails are protected mailboxes with their own MFA.
- Identify the subscriber and document who owns that login and how it is handed over.
- Move each user to the lowest suitable role and limit user management rights to two named people.
- Remove external advisers and former staff who no longer need access.
- List connected apps and custom connections, assign owners and disconnect the rest.
- Track each integration's move to granular scopes ahead of September 2027.
- Require call-back verification and a second reviewer for every supplier bank detail change, recorded in History and notes.
- Store custom connection client secrets and refresh tokens in a secrets manager and rotate them when staff leave.
Standards and references
- Xero: Multi-factor authentication FAQ
- Xero: Introducing Xero Verify
- Xero: Security
- Xero Developer: Granular scopes FAQ
- Xero Developer: OAuth 2.0 FAQ
- Xero Developer: Custom integration FAQ
- Xero Developer Blog: Xero API Token Management: Best Practices and Troubleshooting
- Xero: Xero-OpenAPI specification (Accounting API users, roles and history)
Related NHI Mgmt Group resources: Invoice Redirection and Supplier Bank Detail Fraud Guide · SaaS and OAuth App Governance Guide · MFA Guide · Segregation of Duties Guide · SaaS Security Guide