Back to blog

Securing Integration Records in NetSuite: Reviewing User and Role Access

Why Restrict Access to Set Up Integration Records

Integration setup in NetSuite is one of the most sensitive system configurations. The Integration Application permission is what enables a user to create and maintain integration records. These records define authentication methods, token usage, and OAuth secrets that external applications and services use to connect with NetSuite. Because integration records can store keys, client secrets, and endpoint URLs, tampering with or misusing this access could allow an attacker—or even a well-intentioned but over-provisioned user—to exfiltrate sensitive data or reroute how data flows between ERP / IT systems.

To minimize these risks, access to maintain integration records should be restricted exclusively to IT or Integration Management roles. Granting this access to business users introduces unnecessary risk and creates opportunities for fraud, data leakage, and compliance failures.

How Integrations Are Set Up in NetSuite

In NetSuite, integrations are managed through integration records, which act as the bridge between NetSuite and external systems. Setting up an integration involves:

  1. Creating an Integration Record – Administrators define the integration name, application details, and choose the authentication method (commonly token-based authentication using consumer keys and secrets).
  2. Defining Authentication Credentials – Depending on how the integration is configured, authentication may use OAuth 2.0, token-based authentication (TBA), or standard user credentials. When TBA is enabled, creating an integration record automatically generates an application ID along with a consumer key and consumer secret. These credentials are displayed only once—immediately after the record is created—and must be securely stored offline. If the consumer key or secret is lost, they cannot be retrieved, but you can generate a new set by selecting the Reset Credentials button within the existing integration record.
  3. Assigning Roles & Permissions – The integration user (often a dedicated “svc_” account) is assigned a minimal role with only the API and data access needed for its purpose. The role should be set up as a Web Services Only role so it can’t access the UI. If token-based authentication is the method of authentication used, the role set up to process the integration will need specific permissions such User Access Tokens or Log in using Access Tokens in order to leverage access tokens from NetSuite and exchange information.
  4. Endpoint Configuration – The integration may specify callback URLs or endpoints, enabling NetSuite to securely exchange information with external systems.

Integration records in NetSuite can also be auto-installed when users download and run applications provided by partners that include an existing integration ID. This feature exists to streamline adoption of partner applications or migrations from sandbox to production. By allowing automatic installation, NetSuite reduces administrative overhead and ensures that integrations tied to partner apps can be easily set up or refreshed environments can be quickly restored.

Because these records establish how external systems authenticate and exchange data with NetSuite, any unauthorized modification could redirect data, compromise authentication, or disable critical processes.

NetSuite Integration Record:

Assessment Approach

To identify who can access and maintain integration records, as well as what roles can exchange information from other systems via token-based authentication, organizations should:

  • Review roles that have access to the Integration Application permission – This permission is the key gatekeeper for maintaining integration records.
  • Leverage ERP Armor: Rules for NetSuite – ERP Armor can scan your environment and generate details that pinpoint exactly which users and roles have access to sensitive permissions tied to integrations.
  • Validate Custom Roles – Many organizations clone Administrator or over provisioned standard roles when creating custom roles. This can unintentionally leave integration access enabled. Regular review helps uncover such risks.

Risks of Over-Provisioning

Granting the Integration Application permission beyond IT/Integration teams carries significant risks:

  • Rogue Endpoints – A business user could create unauthorized integrations, exfiltrating financial or personal data.
  • Secrets Exposure – Consumer keys and secrets could be reset in an unauthorized manner, enabling impersonation of legitimate applications.
  • Compliance Gaps – SOX, GDPR, and other frameworks require strict control over authentication and system-to-system data flows. Over-provisioning breaks this principle of least privilege.

Recommended Controls

To reduce risk and improve compliance:

  • Restrict Integration Application permission to IT or integration-focused service accounts only.
  • Enforce quarterly reviews of all roles/users with Integration Application permission.
  • Periodically review System Notes / audit logs of all key integration records.

Closing

Tight governance over who can maintain integration records in NetSuite is essential to protect data flowing from external systems, preventing unauthorized system connections. By restricting access to maintain integration and authenticate via integrations, monitoring access with ERP Armor: Rules for NetSuite, and instituting regular reviews, organizations can ensure their integration landscape remains secure, reliable, and audit-ready.