NetSuite TBA End of Support: Which Integrations Are Affected and What to Do Before 2027.1

Oracle has set a date for the next step in retiring an older NetSuite authentication method. From NetSuite 2027.1, you can no longer build a new integration using Token-Based Authentication (TBA), and a separate method called NLAuth stops working entirely. That is the part with a firm date attached.

What does not happen in 2027.1 is any disruption to integrations you already have running. Existing TBA integrations keep authenticating past that release. Oracle has also named a later, tentative release, 2028.1, for TBA’s full retirement, but that date is explicitly described as tentative rather than confirmed.

For a NetSuite administrator, IT manager or finance-system owner, the practical question is not “is this urgent.” It is “do we actually know which of our integrations use which authentication method, and who owns fixing that.” Most companies cannot answer that with confidence, and that gap, not the 2027.1 date itself, is what tends to turn a routine platform change into a scramble later.

What Is Changing, and Why It Matters to Your Business

NetSuite integrations authenticate in one of three ways: NLAuth, TBA, or OAuth 2.0. Oracle is moving the platform toward OAuth 2.0 as the standard, and NLAuth and TBA are being phased out on different, specific schedules.

The business risk is not that your systems stop talking to each other tomorrow. It is that responsibility for this change is often unclear internally, and several of your integrations were probably built by a vendor, partner or developer who is no longer engaged.

The deadline that actually matters (new integrations blocked) is also easy to confuse with a deadline that does not exist yet (existing integrations stopping). Getting that distinction right is what keeps this a planned project instead of an incident.

What Happens in NetSuite 2027.1

Three things change in the same release, and Oracle documents them precisely in its 2026.2 authentication release notes.

• NLAuth stops working. Any integration still using NLAuth as its authentication method will stop functioning as of 2027.1. This does not include existing integrations on the IssueToken endpoint, which follow the separate TBA timeline below.
• New TBA integrations can no longer be created. This covers both the IssueToken endpoint and the three-step TBA authorization flow. Existing TBA integrations are not affected by this specific change and continue running past 2027.1.
• PKCE becomes mandatory for new OAuth 2.0 integrations that use the authorization code grant flow. Existing integrations built without it keep working; the requirement applies going forward only.

Oracle has also named a tentative later release, 2028.1, for the TBA feature’s full end of support, with an explicit exception for SuiteAnalytics Connect (ODBC/JDBC), which is excluded from that retirement. Treat 2028.1 as a planning horizon, not a confirmed cutover date.

Which Integrations Are Affected, and When

Not every integration needs the same response. This is the situation most companies actually need mapped against their own estate.

NLAuth, TBA and OAuth 2.0 in Plain Terms

These three methods are often discussed as if they are versions of the same thing. They are not, and the difference affects both security posture and how much rework a migration involves.

Both TBA and OAuth 2.0 avoid storing a user’s actual login credentials inside an integration, which is the security property that matters most either way. OAuth 2.0’s real advantage is that it removes the request-signing work TBA requires, while adding token refresh and scopes.

If You Still Run SOAP Integrations

Oracle’s SOAP removal plan is more specific than most teams expect: new integrations should already be built on REST since 2026.1, no new SOAP integrations can be built from 2027.1 (SOAP requires TBA, and TBA is what closes), only the newest SOAP endpoint stays supported from 2027.2, and every SOAP endpoint is disabled with the 2028.2 release. If SOAP shows up anywhere in your estate, treat it as its own scoped project.

Who Should Act Now

Not every reader of this article needs to act this quarter. The companies that do share one or more of these traits.

• You have any integration still using NLAuth. This is the one deadline with no extension.
• You have SOAP integrations anywhere in your estate.
• You are planning a new integration and would otherwise default to whatever authentication method your last one used.
• Nobody in your organization can currently produce an accurate list of what integrates with NetSuite and how each one authenticates.
• A role that requires two-factor authentication is used for any integration built on plain username-and-password access. Oracle does not support that combination for web services or SuiteAnalytics Connect; TBA and OAuth 2.0 are both compatible workarounds.

If none of those apply and your integrations already run on OAuth 2.0 or a vendor-managed TBA connection with a confirmed migration timeline, this is a lower-priority item for your roadmap, not an emergency.

How to Inventory and Prioritise Your Integrations

The work itself is rarely difficult. Knowing what actually needs it is where companies lose time, because most estates cannot produce an accurate list from memory.

Once the inventory exists, prioritise in this order: NLAuth first (no continuation path), then SOAP integrations and anything a critical process depends on, then TBA integrations on the IssueToken endpoint (Oracle already recommends considering a move to the authorization flow independent of this deprecation), then everything else on TBA, migrated ahead of the tentative 2028.1 date.

A Practical Migration and Testing Plan

Engage vendors and partners early. A large share of most estates’ integrations, EDI providers, SuiteApp vendors, banking connections, iPaaS platforms and partner-built tools, are not yours to migrate directly. Ask each one for their OAuth 2.0 timeline and whether it meets the PKCE requirement for new authorization code grant integrations.

Build the OAuth 2.0 version alongside the existing integration in sandbox, validate it fully, then cut over, rather than migrating in place. In-place migration removes your rollback path, and authentication failures tend to be immediate rather than partial.

One environment detail catches teams out: OAuth 2.0 authorizations do not carry over from production. Per Oracle’s own guide to managing OAuth 2.0 authorized applications, you have to authorize each application explicitly in Release Preview or sandbox, and again every time the sandbox is refreshed. Build that step into your standard sandbox refresh process rather than discovering it the first time a post-refresh test fails to authenticate.

If you use the OAuth 2.0 client credentials flow for unattended, server-to-server integrations, note that its certificates are valid for up to two years and NetSuite reminds administrators by email as expiry approaches. Put rotation on a calendar regardless; a certificate quietly expiring is one of the more avoidable outages in this whole migration. Once a migration completes, revoke the old tokens rather than leaving them live.

What to Do Next

Set an internal target of 2027.1 rather than the tentative 2028.1, so ordinary project slippage still lands inside a buffer instead of past a deadline.

• Confirm your account’s upgrade date from the New Release portlet on your dashboard.
• Run the authentication inventory across integration records, scheduled scripts, your iPaaS platform and SuiteAnalytics Connect.
• Identify every NLAuth usage specifically; it has no extension.
• Scope any SOAP integrations as a separate REST rebuild project.
• Send the OAuth 2.0 timeline question to every vendor and partner in your register.

Related ERP Peers Resources

This article covers the authentication layer specifically, one part of the wider NetSuite 2026.2 release. For how an integration is architected in the first place, see our NetSuite integration architecture guide, and for REST API design specifically, our guide to NetSuite API integration.

Teams running integrations through an iPaaS should also check with their platform directly; our Celigo NetSuite integration page covers what that looks like on one common platform. And if integrations are already failing intermittently for reasons unrelated to authentication, our guide to NetSuite integration monitoring and error handling covers catching that before it costs you.