Oracle NetSuite Security: Roles, 2FA, TBA and OAuth 2.0

An Oracle NetSuite account holds the general ledger, vendor bank details, customer records and payment runs, so a shared Administrator login, a forgotten integration token or a script running with administrator rights can change money flows as easily as it can read data. NetSuite is a SaaS ERP with its own role and permission model, mandatory two-factor authentication for privileged roles, and several API authentication methods that are in the middle of a planned transition: Oracle has announced that no new token-based authentication (TBA) integrations can be created from release 2027.1 and that TBA support ends in 2028.2. This guide explains how identity and access work in NetSuite, how to control administrators, how to secure integration records, TBA tokens and OAuth 2.0 clients, what SuiteScript and SuiteApps add to the attack surface, and what to log. It is written for NetSuite administrators, finance systems teams and the security engineers who review them. For Oracle's on-premises and Fusion applications see the Oracle E-Business Suite and Fusion Security Guide.

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

Key takeaways

Build roles, do not share Administrator. The standard Administrator role cannot be customised, so hold it for a small number of named people (Oracle suggests at least two) and use custom roles with Core Administration Permissions for delegated work.
2FA is mandatory for privileged roles, optional for the rest. Administrator and other highly privileged roles require 2FA in every account type and the requirement cannot be removed; Require 2FA for All Roles extends it to employees, vendors and partners.
Plan the TBA retirement now. According to Oracle's documentation, from 2027.1 no new TBA integrations can be created and support ends in 2028.2, so every TBA integration needs an owner and an OAuth 2.0 migration date.
Integration records are your kill switch. Setting an integration record's State to Blocked stops new authentication with its consumer key, which makes an accurate integration inventory part of incident response.
Scripts carry their deployment role. A script deployed with Execute as Role set to a powerful role runs with that role's rights whoever triggers it, so script deployments belong in your privileged access review.

How identity and access work in Oracle NetSuite

A NetSuite user is an entity record (employee, vendor, partner or customer) with one or more roles. Users pick a role at login, and the role decides what they can see and do. Authentication options for the user interface, according to Oracle's Authentication Overview, are email and password, passkeys (available to all users), two-factor authentication, inbound SAML 2.0 single sign-on and inbound OpenID Connect single sign-on. NetSuite can also act as an OpenID Connect provider for outbound sign-on to other applications.

Roles and permissions

Roles combine permissions across the Transactions, Reports, Lists, Setup and Custom Record subtabs with restrictions. In OneWorld accounts a role can be limited to specific subsidiaries, and roles can be restricted by department, class or location. The Global Permissions feature lets you grant permissions to an employee record directly, on top of their roles, which is convenient and easy to miss in a role-only review. The legacy Full Access role is deprecated.

Building block	What it does	Review question
Standard Administrator role	Full functionality; cannot be customised	Who holds it, and does each holder need full functionality?
Custom administrator role with Core Administration Permissions	Administrator-like rights that can be restricted, for example without financial data	Does it exclude what the holder does not need?
Custom functional roles	Permissions per subtab with subsidiary, department, class and location restrictions	Are restrictions set, or does the role see all subsidiaries?
Global permissions	Permissions on the employee record that apply whatever role is used	Which employees hold global permissions, and why?
Integration roles	Roles used by TBA tokens and OAuth 2.0 mappings	Is each integration on its own minimal role?
Script deployment Execute as Role	Role a script runs with at runtime	Which deployments run with administrator-level roles?

Two-factor authentication

Oracle states that NetSuite requires 2FA for all Administrator and other highly privileged roles in production, sandbox, development and Release Preview accounts, and that this requirement cannot be removed. Some highly privileged permissions also make a role 2FA-required by default; the Two-Factor Authentication Required column on the Two-Factor Authentication Roles page shows which roles are affected. The Require 2FA for All Roles feature extends the requirement to every Employee, Vendor and Partner role. 2FA-required roles cannot use user credentials for API authentication, which pushes integrations towards TBA or OAuth 2.0. Where SSO is used, enforce phishing-resistant multi-factor authentication in the identity provider as well. See the MFA Guide.

IP Address Rules

The IP Address Rules feature limits which public IPv4 addresses can reach the account (IPv6 is not supported). Oracle's own documentation describes 2FA as the preferred alternative and warns that IP addresses were not designed as an authentication factor, because of carrier-grade NAT, dynamic leases and spoofing. SOAP web services, SAML and OIDC sign-on respect the rules, but SuiteAnalytics Connect does not, so a user can reach data over Connect from an address blocked in the application. Use IP rules as a supplementary control for a few high-risk roles, not as the main defence.

Admin roles and privileged access

Keep Administrator small: Oracle's guidance is that the role should go only to people who need full functionality, usually a small number, with at least two holders for continuity. Every other administrative task should use a custom role.
Use Core Administration Permissions: these mimic Administrator capabilities and can be restricted, so a systems administrator can manage setup without seeing payroll or bank data.
Separate setup from money: the person who edits roles, scripts or integration records should not also approve vendor bank detail changes or payment runs.
Watch global permissions: list employees with global permissions at every review, because they bypass the role model.
Review administrator activity: Oracle recommends checking Administrator users' transactions through system notes audit trails. Make that a scheduled saved search rather than an occasional manual task.
Govern sandbox and Release Preview: 2FA applies there too, and sandbox refreshes copy production data, so restrict who can log in to non-production accounts.

Integrations, API tokens and service accounts

NetSuite integrations authenticate in one of three ways: user credentials (being retired for APIs), token-based authentication (TBA) or OAuth 2.0. Each integration is represented by an integration record that holds its application ID and, for TBA, a consumer key and secret. The table summarises Oracle's documentation as checked on 8 November 2026.

Method	Where it works	Status in Oracle's documentation	Security notes
User credentials	UI; legacy API use	Oracle says not to use them for SOAP web services, REST or RESTlets; RESTlet support ends in 2027.1	Cannot be used by 2FA-required roles for API access
Token-based authentication (TBA)	SOAP web services, REST web services, RESTlets	No new TBA integrations from 2027.1; support ends 2028.2	Consumer and token secrets are long-lived; password rotation does not apply to tokens
OAuth 2.0 authorization code grant	REST web services, RESTlets (not SOAP)	Recommended for new integrations	User consent per role; refresh tokens to protect
OAuth 2.0 client credentials (M2M)	REST web services, RESTlets (not SOAP)	Recommended for new server-to-server integrations	Certificate-based; maximum five active certificates per integration, entity and role

Oracle also states that SOAP web services support is ending in 2028.2 alongside TBA, so SOAP integrations need a move to REST web services with OAuth 2.0 rather than just a change of credential. These are vendor release targets and can move, so recheck Oracle's notes each release.

OAuth 2.0 client credentials

For machine-to-machine integrations, an administrator or a user with the OAuth 2.0 Authorized Applications Management permission opens Setup > Integration > Manage Authentication > OAuth 2.0 Client Credentials (M2M) Setup, selects the entity, role and application, and uploads the public part of the integration's certificate. The application appears only if the Client Credentials (Machine to Machine) Grant box is ticked on its integration record. Each combination of integration, entity and role can have at most five active certificates, a revoked certificate cannot be reused in a different integration, and a user with Manage own OAuth 2.0 Client Credentials certificates can rotate certificates through a rotation endpoint. Mappings are not copied to sandbox, Release Preview or other accounts, and a sandbox refresh clears them. Generate the key pair in your own key management system, keep the private key out of code and set certificate expiry to force rotation. See the SaaS API Token Security Guide.

TBA tokens

A TBA token is bound to a user, a role and an integration record, and tokens in production are not copied to sandbox or Release Preview. Because tokens do not expire with password rotation, a token issued to an employee who leaves, or created on a powerful role for a pilot, stays valid until someone revokes it. Inventory tokens through the Access Tokens list, issue them to dedicated integration users rather than people, and revoke tokens whose integration record has no current owner.

Blocking an integration

Setting an integration record's State to Blocked under Setup > Integration > Manage Integrations stops the application authenticating with that record's consumer key and blocks SOAP requests that reference its application ID. Oracle notes two limits: blocking does not stop RESTlet calls that use the NLAuth method, and it does not end sessions that already exist. Include both in your containment runbook. See the Multi-Tenant SaaS App Credential Compromise Playbook.

SuiteScript and SuiteApps

SuiteScript is server-side and client-side JavaScript that runs inside the account, and SuiteApps and bundles install scripts, custom records, roles and integration records written by third parties. Oracle's SuiteScript security guidance includes these points:

Execute as Role: a script deployment's Execute as Role field sets the role used at runtime. A fixed role applies even if an Administrator triggers the script, and a script triggered by another script runs with the first script's role. Deploy scripts to run as administrator only if necessary.
No hard-coded credentials: do not place passwords in scripts, prefer OAuth 2.0 for outbound calls, and use the encrypted credential (GUID) options NetSuite provides for SFTP and certificates.
No secrets in script parameters: Oracle warns that parameter values can be indexed by search engines and become publicly viewable.
Login-free Suitelets: deploy Suitelets as "Available without Login" only when there is no alternative, because they are reachable by anyone with the URL.
Testing status: set new deployments to Testing so they run only for the owner while being validated.

Before installing a SuiteApp, review the roles, permissions and integration records it adds and the external endpoints its scripts call. Treat its publisher as a third party with access to your ledger. See the OAuth and SaaS integration breaches lessons guide.

Logging and detection

Source	Where	What it shows	Detection use
Login Audit Trail	Setup > Users/Roles > View Login Audit Trail	Session start time, user, role and IP address at session start, drill-down to transactions in the session	Logins from new addresses or outside working hours; Administrator role use
System Notes	System Notes subtab, system note searches	Field changes with a Context value (UI, web services, SuiteScript and others)	Vendor bank detail changes, role and permission edits, changes made by integrations
Audit trails and History subtab	List pages; Transactions > Management > View Audit Trail	Predefined searches of system notes, line-level record history	Transaction edits after approval
Roles, features and customisation tracking	Linked audit topics in Oracle's help	Changes to roles and permissions, enabled features, scripts and custom objects	New script deployments, Execute as Role changes
Deleted record search	Search	Details of deleted records	Evidence removal

The Login Audit Trail records the IP address at the start of each session only, so a mid-session VPN change is not captured. Saved searches can be scheduled and emailed, which is the simplest way to forward evidence to a SIEM if you have no connector: a daily saved search of Administrator and integration role logins, and a daily system notes search on vendor bank fields and role records. See the SaaS Audit Log Retention and Licensing Guide.

Metrics

Administrator holders: number of users with the standard Administrator role, kept at the agreed small number.
TBA integrations remaining: count of active TBA integrations, falling to zero before 2028.2.
Ownerless tokens: tokens or OAuth mappings whose integration record has no named owner, target zero.
Administrator-run scripts: deployments whose Execute as Role is Administrator or a Core Administration role, trending down.
Bank change confirmation: share of vendor bank detail changes confirmed out of band before the next payment run, target 100 per cent.

Hardening baseline

Inventory: export roles and holders, global permissions, integration records, Access Tokens, OAuth 2.0 mappings, script deployments with their Execute as Role, and installed SuiteApps. Give each integration and token an owner.
Authentication: connect SAML or OIDC single sign-on with phishing-resistant MFA, decide whether to turn on Require 2FA for All Roles, and keep two monitored Administrator accounts for continuity.
Roles: move delegated administrators to custom roles with Core Administration Permissions, set subsidiary restrictions, and remove unnecessary global permissions.
Integrations: give each integration its own user and minimal role, block unused integration records, and revoke tokens on unused or over-privileged roles.
Migrate TBA to OAuth 2.0: for each integration, register an OAuth 2.0 client credentials mapping in sandbox, test with the same role, run both in parallel for one business cycle, then revoke the TBA token. Keep the old token revoked rather than deleted in records so you have evidence, and roll back by issuing a new token only if the OAuth path fails.
Scripts: review deployments that run as administrator, remove secrets from parameters, and restrict "Available without Login" Suitelets.
Payments: require approval and out-of-band confirmation for vendor bank detail changes, and alert on changes made with a web services or SuiteScript context.

Small and large organisations

A small business with one administrator should still add a second Administrator holder for continuity, use saved search emails to a finance lead as an independent check, and prefer one or two well-understood integrations over many. A large OneWorld deployment should define roles per subsidiary, run quarterly access reviews through an identity governance tool, manage scripts through SuiteCloud Development Framework with code review, and treat the TBA retirement as a programme with a tracked backlog.

Common misconfigurations

Shared Administrator logins: one Administrator account used by several people or a consultancy, which defeats 2FA accountability and audit trails.
Integrations on the Administrator role: TBA tokens created on Administrator or a broad custom role because it was quicker, giving any holder of the token secrets full control. Long-lived integration tokens are a recurring target in SaaS breaches.
Tokens that outlive their purpose: pilot or contractor tokens never revoked, since password rotation does not touch them.
Relying on IP rules: treating IP Address Rules as the main control while SuiteAnalytics Connect bypasses them and 2FA is not enforced for all roles.
Secrets in scripts: API keys and passwords in script parameters or code, which Oracle warns can become publicly viewable.
No migration owner: nobody tracking which integrations still use TBA or SOAP, leaving the 2028.2 retirement to surprise the finance team.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	MITRE ATT&CK
Roles, global permissions, subsidiary restrictions	AC-2, AC-3, AC-6	PR.AA-05	5.15, 5.18, 8.2	T1098 Account Manipulation
2FA, SSO, passkeys	IA-2	PR.AA-01	8.5	T1078.004 Cloud Accounts
TBA tokens, OAuth 2.0 certificates	IA-5, SC-12	PR.AA-01	5.17, 8.24	T1528 Steal Application Access Token, T1550.001 Application Access Token
Login Audit Trail, System Notes	AU-2, AU-6	PR.PS-04, DE.CM-03	8.15, 8.16	T1213 Data from Information Repositories
Vendor bank and payment controls	AC-6, AU-6	DE.CM-03	5.15, 8.16	T1657 Financial Theft

Practitioner checklist

List every holder of the standard Administrator role and move anyone who does not need full functionality to a custom role.
Confirm 2FA or SSO with phishing-resistant MFA for all privileged roles and decide on Require 2FA for All Roles.
Export global permissions and remove those that bypass the role model without a reason.
Inventory integration records, TBA tokens and OAuth 2.0 mappings, assign an owner to each, and block or revoke the rest.
Build a TBA and SOAP migration plan with dates ahead of 2027.1 and 2028.2, using OAuth 2.0 client credentials for server-to-server integrations.
Review script deployments that run as administrator and remove secrets from script parameters.
Schedule saved searches on the Login Audit Trail and on system notes for vendor bank and role changes, emailed to a reviewer or forwarded to the SIEM.
Add "set integration record to Blocked and revoke tokens" to the incident response runbook, noting the NLAuth and existing-session limits.

Oracle NetSuite Security: Roles, 2FA, integrations and the TBA to OAuth move