Sage Intacct Security: Roles, Web Services Users, Audit

Sage Intacct runs the general ledger, accounts payable and payment runs for many mid-sized organisations, so a full administrator without MFA, a Web Services user with broad rights or an unapproved change to a vendor's payment details can redirect funds or alter the books. Sage Intacct gives administrators a strong set of controls to prevent this: company-level session, password, IP filter, two-step verification and passkey settings, role-based permissions, dedicated Web Services users bound to authorised sender IDs, vendor approvals, an object audit trail and Smart events for alerting. This guide explains how identity and access work in Sage Intacct, how to run full and limited administrators, how to govern Web Services users and sender IDs, what to log and alert on, and a hardening baseline aligned with Sage's own best practices. It is written for Sage Intacct administrators, finance systems owners, controllers and the security engineers who review them. These are customer-side settings under the shared responsibility model.

This is an independent guide from NHI Mgmt Group, based on Sage Intacct's public documentation as of November 2026. It is not sponsored or reviewed by Sage. Product features change, so confirm settings against Sage Intacct's current documentation.

Key takeaways

Turn on two-step verification for all users. Sage Intacct offers 2-step verification for selected users or all users, with a Do not allow trusted devices option that Sage recommends for admins and users with access to sensitive data.
Keep at least two full admins, and few more. Full admins can create other admins and are granted sensitive permissions automatically; limited admins cover most administration without creating admins.
Every integration gets its own Web Services user. Web Services users cannot sign in to the UI, have SSO and MFA disabled and passwords that never expire automatically, so pair each with IP address filters, a narrow role and an owner.
Authorise only the sender IDs you use. Requests from sender IDs missing from Web Services authorizations fail, and the API Usage Detail report shows which sender IDs called the company in the last 63 days.
Put vendor changes behind approval. With vendor approval enabled, new and updated vendors stay pending until approved and cannot be selected for payment, which directly addresses vendor bank detail fraud. See the Invoice Redirection and Supplier Bank Detail Fraud Guide.

How identity and access work in Sage Intacct

A Sage Intacct company has standard users, who sign in to the UI, and Web Services users, who call the API only. Each user has a user type (such as Business user), optional admin privileges (Off, Limited or Full) and permissions, assigned either directly to the user or through roles. Sage's best practices recommend role-based permissions: create a role for each function, including integrations, and give each role only the permissions it needs.

Company sign-in settings

Company login settings sit under Company > Setup > Configuration > Company > Security. The table combines the options from Sage's Company login settings page with the values Sage recommends in its Best practices for privacy and security.

Setting	Options per Sage docs	Sage recommended value
Default inactivity duration	Hours and minutes, with an optional Maximum users cannot exceed	One hour or less company-wide; 15 minutes for admins
Default session duration	Hours and minutes regardless of activity, optional Maximum	5 to 10 hours
Reset password	Weekly to yearly; per-user "Keep my password until I reset it" for integration accounts	Quarterly
Minimum length	8 characters minimum; complexity fixed (number, lowercase, uppercase, special character)	9 or more characters
Prevent reuse of previous passwords	3 to 20	12
Maximum login attempts per day	1 to 20; only an admin can unlock a locked-out user	5 or fewer
Enforce IP address filters	None; company level; company level with user override; user level	For admins and Web Services users; consider for users with sensitive financial access
Enable 2-step verification	Selected users or All users; Do not allow trusted devices; codes by authenticator app, text or phone call	On; no trusted devices for admins and sensitive users
Enable passkey authentication	Lets non-SSO users sign in with a passkey registered under My preferences	Consider for admins as a phishing-resistant option

Single sign-on, MFA and passkeys

Sage's documentation notes that SSO users skip 2-step verification and users who sign in with a passkey are not prompted for a code. That makes the identity provider responsible for MFA for SSO users, and Sage's best practices say exactly that: if you use SSO, enable MFA on the SSO login. Choose phishing-resistant methods where finance staff can approve payments. See the Identity Provider and SSO Security Guide and the Phishing-Resistant MFA Guide.

If you enable IP address filtering with no filters defined, Sage states it behaves like None, so add the filter ranges in the same change. Test a new filter on one user at user level before enforcing it company-wide, and keep a full admin able to sign in from an allowed address so you can roll back.

Admin roles and privileged access

Privilege	What Sage documents	How to govern it
Full administrator	Complete administration, can create full admins, access Platform Services to create and change pages, use Try role, automatically granted tasks such as creating users and managing payment information	At least two, as Sage recommends; named people; no trusted devices; IP filtered
Limited administrator	Most admin privileges; cannot create full admins, edit page layouts or use Try role; may need permissions such as creating users assigned	Use for day-to-day administration instead of full admin
Both admin types	Access private financial reports, reset passwords and unlock users	Include in quarterly access review
Business user with roles	Permissions from function roles	One role per function; separate vendor maintenance from payment

Admin privileges need a Business user: Sage allows admin privileges only on the Business user type, which helps scope who can ever hold them.
Document cover: Sage advises telling users who their admins are and having a process for when admins are away or leave, because only admins can reset passwords and unlock users.
Use Try role: in role-based companies, full admins can preview what a role can do before assigning it; use it when changing payment-related roles.
Separate duties: the person who creates or edits vendors should not approve vendor changes or release payments, and approvers for vendors should be distinct from bill approvers where headcount allows. See the Segregation of Duties Guide.
Restrict sensitive objects: Sage recommends being selective with permissions on vendors, customers, employees, contacts, credit cards, bank accounts and bank feeds, and using the restrict-to-related-contacts options in AP and AR.
Mask SSNs: turn on Employee Social Security Number masking in Company settings where US employee data is held.

Integrations, API tokens and service accounts

API access to Sage Intacct needs two things: a Web Services user in the company, and a sender ID (obtained from Sage) that the company has authorised under Web Services authorizations. Sage's best practices are direct: create Web Services users for API-only accounts and authorise only approved sender IDs, keeping the list current. Every bill payment platform, expense tool or data warehouse connector is therefore a non-human identity made of a sender ID plus a Web Services user. See the NHI Ownership Guide.

Property of a Web Services user (per Sage)	Security consequence	Compensating control
Cannot sign in to the UI	Credential is useful only for API calls	Store it only in the integration and a secrets manager
SSO and MFA disabled	The password is the whole credential	User-level IP address filters to the integration's egress addresses; store the password in a secrets manager
Password never expires automatically; admin reset generates a new one	Long-lived secret; a reset can break the integration	Planned rotation with the integration owner, coordinated with an update to the integration
Can hold the same user types and admin privileges as standard users	An integration can be over-privileged	Admin privileges Off; a dedicated integration role with only needed permissions
Inactivating blocks its Web Services requests	Fast containment	Add "inactivate the Web Services user" to incident runbooks

Sender ID authorizations

Each sender ID on the authorization list is Active or Inactive. Inactive blocks requests but keeps the record, so deactivate rather than delete when unsure. Sender IDs are case sensitive and cannot be changed after adding. Two entries have special uses that Sage documents: ajax for Platform Services page scripts using the AJAX gateway and cdocs_v2 for the Printed Document Toolbar. Sage advises reviewing the list against your known integrations, using the API Usage Detail report to see which sender IDs made requests in the last 63 days, and opening a support case before removing an entry you do not recognise, since some may come from past support actions.

Integration practice

One Web Services user per integration: Sage recommends a separate Web Services user for each integration and never sharing standard user credentials with external applications.
Roles for integrations: give each integration its own role, as Sage's best practices suggest for tools such as bill payment platforms.
Payment platforms are tier one: an integration that can create bills or update vendors can redirect money; review its role as carefully as an AP manager's.
Vendor approval through the API: Sage provides an API for vendor approval, and CSV vendor imports for visibility and account number templates now submit vendors for approval, so integrations do not bypass the approval step for those paths.

See the SaaS API Token Security Guide for storing and rotating integration credentials.

Logging and detection

Source	What it shows (per Sage)	Detection use
Audit trail (More actions > View audit trail)	Create, Modify, Delete, Access, Login, Activity, User action and Workflow entries, with Before and After values for modifications	Vendor payment field changes, edits after approval
Audit History data source and AUDITHISTORY object	Custom reports by time, user or object; API access with readByQuery and getAuditTrail	Export to a SIEM; Access and Delete entries appear only here
User access report	Users who attempted to access the company	Failed and unusual sign-ins
Permissions reports	Permissions company-wide, per user and changes over time	Privilege creep, new admin grants
API Usage Detail report	Sender IDs that made requests in the last 63 days	Unknown or unused integrations
Approval history reports	Bill, purchasing and timesheet approval history	Approvals by unexpected users
Vendor History tab and State field	Approval status, who acted, field changes	Vendors approved by the same person who edited them

Sage notes that recent changes can show Pending in the audit trail for up to two hours, and that whole-company Audit History reports can run slowly and cut off past 1,000 lines, so build focused reports per object. Sage recommends reviewing these reports quarterly; for vendor and permission changes, weekly is more useful.

Smart events

Smart events send alerts when something happens. Sage's own examples include new vendors, transactions over a set amount, admin privilege grants and new Web Services users. Route them to a monitored mailbox or ticket queue, and add one for changes to vendor payment details. See the SaaS Audit Log Retention and Licensing Guide.

Metrics

2-step coverage: standard non-SSO users with 2-step verification, target 100 per cent, with no trusted devices for admins.
Full admin count: held at the agreed number, at least two.
Integration hygiene: Web Services users with an owner, a dedicated role, admin privileges Off and IP filters, target 100 per cent.
Sender ID drift: authorised sender IDs with no requests in the API Usage Detail report window, target zero.
Vendor approval integrity: vendor changes approved by someone other than the editor, target 100 per cent.

Hardening baseline

Inventory: export users with user type and admin privilege, roles and permissions reports, Web Services users, authorised sender IDs with the API Usage Detail report, and existing Smart events.
Sign-in settings: apply Sage's recommended inactivity, session, password and lockout values, then enable 2-step verification for all users with Do not allow trusted devices for admins. Pilot with selected users first, then switch to all users.
SSO: if using SSO, enforce phishing-resistant MFA in the identity provider, and keep at least one full admin able to sign in without SSO for recovery.
IP filters: add user-level filters for admins and every Web Services user, tested on one account before enforcement.
Admins and roles: keep two or three full admins, move others to limited admin or role-based access, and split vendor maintenance, vendor approval and payment roles.
Integrations: one Web Services user per integration with admin privileges Off, its own role, a stored password with a rotation plan, and only active sender IDs on the authorization list.
Vendor approval: enable vendor approval in Accounts Payable, assign approvers through vendor approval permissions, configure approver notifications, and pair approval with call-back verification of bank detail changes to a known contact. See the Business Email Compromise Awareness for Finance Teams Guide.
Alerting: create Smart events for new vendors, vendor changes, admin privilege grants, new Web Services users and large transactions, and schedule focused Audit History reports.

Small and large organisations

A finance team of five can reach this baseline in a few days: two full admins on passkeys or authenticator codes with no trusted devices, one Web Services user per integration with IP filters, vendor approval enabled, and three Smart events. A multi-entity organisation should manage roles per entity and function, export Audit History to a SIEM through the AUDITHISTORY object, review permissions reports monthly, and treat sender ID authorizations as part of change management.

Common misconfigurations

Integrations on a person's login: standard user credentials shared with an external application, against Sage's guidance, so the integration inherits that person's rights and breaks when they leave.
Web Services users with admin privileges: granted Full admin because it made setup easier.
No IP filter on Web Services users: a password-only credential, with MFA disabled by design, usable from anywhere.
Stale sender IDs: authorizations left Active for integrations retired years ago.
Trusted devices for admins: 2-step verification enabled but admins skipping codes on remembered devices.
Vendor approval off: vendor payment details editable and payable in the same day by the same person.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	MITRE ATT&CK
Admin privileges, roles, permissions reports	AC-2, AC-3, AC-6	PR.AA-05	5.15, 5.18, 8.2	T1098 Account Manipulation
2-step verification, passkeys, SSO, sign-in settings	IA-2, IA-5	PR.AA-01	5.17, 8.5	T1078.004 Cloud Accounts
Web Services users, sender IDs, IP filters	IA-5, AC-6	PR.AA-01	5.17, 8.5	T1078.004 Cloud Accounts
Audit trail, Audit History, Smart events	AU-2, AU-6	PR.PS-04, DE.CM-03	8.15, 8.16	T1213 Data from Information Repositories
Vendor approval and payment controls	AC-6, AU-6	DE.CM-03	5.15, 8.16	T1657 Financial Theft

Practitioner checklist

Apply Sage's recommended session, password and lockout values in Company login settings.
Enable 2-step verification for all users, with Do not allow trusted devices for admins and sensitive users.
Enforce MFA in the identity provider for SSO users, and consider passkeys for admins.
Keep at least two full admins, move others to limited admin, and review admin grants monthly.
Give each integration its own Web Services user, role and user-level IP filter, with admin privileges Off.
Reconcile Web Services authorizations against the API Usage Detail report and deactivate unused sender IDs.
Enable vendor approval and require call-back verification of vendor bank detail changes.
Create Smart events for new vendors, admin grants, new Web Services users and large transactions.

Sage Intacct Security: Hardening admins, integrations, vendor changes and audit