NetSuite's TBA to OAuth 2.0 Shift: The Complete 2027.1 Migration Guide
Token-Based Authentication has quietly done its job for years, connecting NetSuite to Shopify carts, EDI networks, banking feeds, and custom finance tools. That quiet period is ending. Starting with NetSuite 2027.1, no new integration will be allowed to use TBA, and the window to rebuild the right way is shorter than most teams realize.
- Starting with NetSuite 2027.1, new integrations can no longer use Token-Based Authentication (TBA). OAuth 2.0 becomes mandatory for all new builds.
- Existing TBA integrations keep working past 2027.1, but Oracle has signaled that support for them will eventually end, too.
- New OAuth 2.0 authorization code integrations will also require PKCE, an added security check, for every client type.
- The safest approach is a phased migration starting now: inventory your integrations, prioritize by risk, and rebuild in parallel rather than all at once.
Most NetSuite administrators have never had to think much about how their integrations log in. Token-Based Authentication has quietly done its job in the background for years, connecting NetSuite to Shopify carts, EDI networks, banking feeds, and custom finance tools without much fanfare. That quiet period is ending. Oracle has set a firm marker on the calendar: starting with NetSuite 2027.1, no new integration will be allowed to use Token-Based Authentication. Existing integrations keep running for now, but the window to rebuild them the right way is shorter than most teams realize.
What Is Actually Changing
Token-Based Authentication, usually shortened to TBA, is the older method NetSuite integrations use to prove they are allowed to access an account. It works using a consumer key and a token pair, and once issued, that token does not expire on its own. It stays valid indefinitely, until someone manually revokes it. OAuth 2.0 is the newer standard, already used across most modern platforms, and it issues short-lived tokens that expire automatically and are refreshed through a controlled process.
As of NetSuite 2027.1, administrators will no longer be able to create new integrations using TBA for REST web services or RESTlets. Integrations that already exist will continue to work past that date, but any new build or any meaningful refresh of an existing one will need to use OAuth 2.0 instead. Oracle has also confirmed that OAuth 2.0's authorization code flow will require PKCE, an additional verification step that closes a known interception risk, and this requirement applies to every client type, not just public-facing apps.
Nothing breaks the day 2027.1 arrives. But from that release forward, TBA becomes a dead end for anything new. Any integration work planned for 2027 or later needs to be built, or rebuilt, on OAuth 2.0.
Why Oracle Is Making This Change Now
This is not NetSuite tightening the screws for its own sake. It is catching up to where enterprise security standards already are. TBA tokens that never expire are a known weak point, quietly sitting in scripts, middleware configs, and old integration records long after the person who set them up has left the company. Long-lived credentials are one of the most common threads running through recent API-related security incidents across the industry, and NetSuite is far from the only platform making this shift. QuickBooks moved away from a similar OAuth 1.0-style token model years ago, and most major SaaS platforms have already standardized on OAuth 2.0.
23.5% of reported API vulnerabilities in 2026 trace back to broken or weak authentication, more than any other single cause. 30%+ of all data breaches now involve an API in some form, up sharply from just a couple of years ago.
Neither of these figures is specific to NetSuite. They describe the broader environment every ERP vendor is responding to. Systems that hold financial, customer, and inventory data are attractive targets, and the credentials protecting the connections into those systems are frequently the weakest link, not the application itself.
The Full Timeline, Without the Jargon
| Milestone | What it means for you |
|---|---|
| NetSuite 2026.1 (already live) | Oracle laid the groundwork: multiple redirect URIs for OAuth apps, a certificate rotation endpoint for client credentials flows, dynamic client registration, and the formal announcement that TBA support for new integrations ends at 2027.1. |
| NetSuite 2027.1 (the real deadline) | No new TBA-based integrations can be created for REST or RESTlets. New OAuth 2.0 authorization code integrations must use PKCE. Existing TBA integrations keep running. |
| Beyond 2027.1 (tentative, watch for confirmation) | Oracle has signaled that support for existing TBA integrations will eventually end as well, and SOAP-based access is being phased out on a longer horizon. Treat this as a reason to migrate proactively rather than wait for a forced cutover. |
Once Oracle turns off support for existing TBA integrations, any that have not been migrated will stop functioning with no grace period to rebuild them under pressure. Migrating on your own timeline, while systems are still stable, is far less disruptive than migrating during a forced cutover.
TBA vs. OAuth 2.0, Side by Side
A quick reference for anyone who needs to explain this internally without diving into the technical weeds.
| Token-Based Authentication (TBA) | OAuth 2.0 | |
|---|---|---|
| How long a credential lasts | Indefinitely, until someone manually revokes it | Minutes to hours, then it automatically refreshes or expires |
| Works with two-factor authentication | No | Yes |
| Can be scoped to only what's needed | Limited, tied to the assigned role | Yes, permissions can be scoped more precisely |
| Setup complexity | Simple, one-time token generation | Slightly more setup, but manageable with a clear process |
| New integrations after NetSuite 2027.1 | Not allowed | Required |
| Industry direction | Legacy, being phased out across most SaaS platforms | Current standard |
OAuth 2.0 is not just "what Oracle wants now." It is the same standard your bank, your CRM, and most modern platforms already run on. NetSuite is simply catching up to its own ecosystem.
Who Does This Actually Affect?
If your NetSuite instance runs quietly with no outside connections, this change barely touches you. Almost nobody is in that position. In practice, this affects any organization with outside systems talking to NetSuite, and the impact looks a little different depending on which part of the business you sit in.
Finance & Accounting
Bank feed connections, AP automation tools, and financial reporting integrations often rely on older RESTlet or SuiteTalk connections set up years ago.
Operations & Supply Chain
EDI connections through providers like SPS Commerce, warehouse management integrations, and shipping platform links are frequently TBA-based.
E-commerce & Sales
Shopify, Amazon, and BigCommerce connectors, along with CRM syncs, are common candidates, especially where a third-party app handles the connection.
IT & Development
Custom scripts, internal tools, and middleware platforms such as Celigo, Boomi, or Workato are usually where the oldest and least-documented TBA tokens live.
Most mid-market NetSuite environments have several of these running at once, often set up at different times by different people, which is exactly why an inventory step matters before any rebuilding starts.
Common Mistakes Teams Make With This Kind of Migration
Assuming "existing integrations keep working" means "no action needed"
It buys time, not immunity. Support for existing TBA integrations is expected to end eventually, and waiting until that happens turns a planned project into an emergency one.
Migrating everything at once
Trying to rebuild every integration in a single sprint increases the chance of breaking something in a live financial system. A phased, risk-ranked approach is safer and easier to test.
Disabling the old credential before confirming the new one works
The safest pattern is running both in parallel briefly, confirming identical behavior, then switching over and retiring the old token.
Forgetting sandbox and Release Preview accounts
Tokens created in production are not copied to sandbox or preview environments. Each of those needs its own credentials created and tested separately.
Not accounting for two-factor authentication conflicts
TBA does not work with roles that require 2FA. If your organization tightens 2FA policy as part of a broader security push, TBA integrations tied to those roles can silently stop functioning.
Losing institutional knowledge
A surprising number of integrations were configured by a contractor or employee who is no longer available to explain how they work. Documenting each connection during the inventory step avoids rebuilding blind later.
Running Integrations You Did Not Build?
EPIQ Infotech maps every connection into your NetSuite account, flags which ones run on TBA, and gives you a risk-ranked migration order. No obligation.
A Practical, Non-Technical Migration Plan
You do not need to migrate everything this quarter. You do need a plan, and the plan is more about organization than heavy engineering.
Take Stock
List every system currently connected to NetSuite, and note whether each one uses TBA. Most teams are surprised by how many connections exist once someone actually writes them all down.
- Check integration records under Setup, and review any middleware platform's connection list
- Note who owns or maintains each connection internally, if anyone still does
Classify by Risk and Effort
Some integrations are simple and low-risk to rebuild. Others touch financial data, run on old custom code, or were built by a vendor who is no longer active. Sort accordingly.
- High risk: anything touching revenue, payroll, or customer financial data
- Low risk: read-only reporting connections or internal dashboards
Prioritize What Changes Soon Anyway
Any integration you already planned to touch, upgrade, or replace in the next 12 to 18 months is your natural starting point. Build it on OAuth 2.0 the first time, rather than migrating it twice.
Rebuild in Parallel, Not in Place
Set up the new OAuth 2.0 connection alongside the existing TBA one, confirm it behaves identically in a sandbox or Release Preview account, then switch over in production.
- Test with real transaction volume where possible, not just a handful of sample records
- Confirm the new integration's assigned role has exactly the permissions it needs, no more
Retire TBA Credentials Once Confirmed
Once everything is verified, revoke the old tokens. This closes the exact security gap the migration was meant to address, rather than leaving an unused but still-valid credential sitting active indefinitely.
The Two OAuth 2.0 Flows Explained
Once you start planning the rebuild, you will run into a choice between two OAuth 2.0 "flows." Here is what each one actually means, without the developer jargon.
- Used when a person needs to log in and approve the connection, similar to clicking "Sign in with Google" on a website
- The right choice for integrations tied to an individual user's access
- This is the flow that now requires PKCE for extra protection
- Used for system-to-system connections where no person is involved in the moment, such as an overnight data sync between NetSuite and a warehouse system
- Relies on a certificate rather than a login step
- NetSuite added a certificate rotation tool in the 2026.1 release to make managing these easier
If a human is approving the connection, use the authorization code flow. If it is two systems talking to each other automatically, use client credentials. Getting this choice right early avoids rework later.
A Simple Readiness Checklist
- We have a complete, written list of every system connected to NetSuite
- We know which of those connections currently use TBA
- We have ranked each one by business risk if it were to fail
- We have identified which integrations are already due for changes in the next year
- We have a plan to test new OAuth 2.0 connections in the sandbox before touching production
- We know who is responsible for each integration, internally or externally
Frequently Asked Questions
Will my existing NetSuite integrations stop working at 2027.1?
No. Existing TBA-based integrations continue to function after NetSuite 2027.1. The restriction applies to creating new integrations, not to shutting down ones that already exist. That said, Oracle has indicated that support for existing TBA integrations will eventually end as well, so treating 2027.1 as a soft deadline rather than ignoring it is the safer approach.
What is PKCE, in simple terms?
PKCE is an extra verification step added to the OAuth 2.0 login process. It makes sure that even if someone intercepts part of the authentication exchange, they cannot complete it and gain access. As of NetSuite 2027.1, it will be required for all new OAuth 2.0 authorization code integrations, regardless of the type of application.
Do I need to migrate everything before 2027.1?
Not necessarily all at once. The immediate requirement is that any new integration built from 2027.1 onward must use OAuth 2.0. Existing integrations can be migrated on a rolling basis, prioritized by risk and by which systems are due for changes anyway.
Why is NetSuite making this change?
TBA tokens do not expire on their own, which makes them a lingering security risk if they are ever exposed or forgotten. OAuth 2.0 uses short-lived, automatically refreshing tokens and supports modern controls like two-factor authentication, aligning NetSuite with the authentication standards already used across most current platforms.
Can TBA and two-factor authentication be used together?
No. TBA is not compatible with roles that require two-factor authentication. If a role tied to an integration has 2FA enforced, that integration needs to use OAuth 2.0 instead, since OAuth 2.0 supports 2FA-required roles.
Does this affect reporting tools connected through SuiteAnalytics Connect?
Based on Oracle's current guidance, SuiteAnalytics Connect, which uses ODBC and JDBC connections, has been treated separately from the broader TBA changes affecting SOAP, REST, and RESTlets. If your organization relies on it for reporting, it is still worth confirming its status directly with Oracle or your NetSuite partner as the 2027.1 rollout approaches.
Not Sure Where Your Integrations Stand?
EPIQ Infotech helps NetSuite teams inventory existing integrations, prioritize what needs attention first, and migrate to OAuth 2.0 without disrupting day-to-day operations.

Santosh Krishnamoorthy is a Principal ERP Consultant at EPIQ Infotech, with extensive experience in NetSuite and enterprise systems. He works with finance and operations teams to improve reporting accuracy, streamline workflows, and build ERP environments that support sustainable growth. His writing focuses on practical insights drawn from real implementation and support experience.
Free Consultation
Talk to a NetSuite Expert
Response within 1 hour
Message Sent!
We'll be in touch within 1 hour.





