NetSuite is retiring legacy authentication: What it means for portfolio company integrations

Article    September 02, 2026
NetSuite is retiring legacy authentication: What it means for portfolio company integrations
SHARE
BOTTOM LINE UPFRONT

NetSuite is retiring two legacy authentication methods and phasing out SOAP web services, putting many portfolio company integrations on a deadline to migrate. The technical fix is relatively simple; identifying every integration that relies on them is not. Finance and IT teams should inventory their exposure now to avoid broken integrations that disrupt procurement, reporting, and close.

Nobody thinks about how their NetSuite integrations authenticate until the morning one of them doesn’t. That’s the risk sitting inside two upcoming changes from NetSuite, landing as the platform pushes customers toward NetSuite Next, its next-generation interface and architecture.  

Neither change makes headlines on its own. Together, they touch a large share of the integrations portfolio companies depend on to move data between systems, run procurement, and keep close and reporting processes on schedule. 

What this means for PE-backed companies, broken down:  

What’s changing 

NetSuite integrations authenticate through one of several methods, and NetSuite is retiring the two oldest. 

  • NLAuth, the original authentication mechanism for RESTlet integrations, is expected to lose support as early as 2027. 
  • TBA (OAuth 1.0) follows with NetSuite’s 2028.1 release. This is the one that matters more: it remains common across integrations built in the past several years, well past NLAuth’s narrower footprint, even though its deadline lands second. 
  • SOAP web services are also being retired, with final disablement scheduled for the 2028.2 release in favor of SuiteTalk REST Web Services. 

Why this reaches further than it looks 

NLAuth touches a limited slice of the integration landscape. Portfolio companies using an iPaaS platform to connect NetSuite with other systems are, in nearly every case, not using NLAuth at all unless something custom was built on top of the standard setup. 

TBA is different. It’s a standard authentication method across many iPaaS platforms and appears throughout current integrations, custom builds included, that connect directly to NetSuite. A portfolio company relying on any of these integrations for procurement, reporting, or day-to-day finance operations has real exposure once TBA support ends, and identifying that exposure now is far cheaper than discovering it on the day the integration stops responding. 

And authentication isn’t the only structural change coming with NetSuite Next. NetSuite is also retiring SOAP web services by the 2028.2 release in favor of SuiteTalk REST Web Services, and this one matters more: it changes the underlying data format, not just how a system logs in. Third-party and iPaaS integrations will update on their own. IPaaS platforms will offer a REST connector, but existing flows need to be manually rebuilt or updated to use it. Custom SOAP integrations will need a full refactor.   

Why this is hard to see from NetSuite alone 

Authentication method isn’t something a NetSuite administrator can just look up in a single screen and check off a list. It lives on the external system making the request, not fully inside NetSuite itself, which makes it genuinely difficult for a lone NetSuite resource to map every integration’s authentication method without input from whoever manages the connecting system on the other end. 

So: two places are worth checking. From the NetSuite side, RESTlet deployments and their role restrictions can surface some exposure. The more reliable starting point is the outgoing request configuration on the system calling into NetSuite, since that’s where the authentication method sits. 

The lead time is real, but the discovery work isn’t trivial 

TBA’s retirement is a little under two years out, and once an integration’s authentication method is identified, updating and testing it typically takes a matter of hours, not weeks. The fix itself is not the bottleneck. 

Finding every integration that needs it is. Authentication method lives on the external system making the request, not inside NetSuite, so a single NetSuite resource often can’t produce a full list without pulling in whoever manages each connected system. For a portfolio company running several integrations across different providers and teams, that inventory work, done accurately, before the deadline, is where the real exposure sits. 

Where to start 

Portfolio company finance and IT teams should inventory which integrations connect to NetSuite RESTlets and confirm how each one authenticates. Third-party and iPaaS-built integrations can usually get that answer directly from the provider. Custom or homegrown integrations require a look at the outgoing request configuration itself.  

Custom SOAP integrations belong on that same roadmap, since the 2028.2 deadline only leaves enough runway if the refactor work starts early. 

Accordion’s Technology Team works with portfolio companies on exactly this kind of assessment, confirming which authentication method an integration currently uses, migrating it to OAuth 2.0, and planning SOAP-to-REST migrations before the deadline forces the issue. 

FAQ

What exactly is NetSuite retiring, and when?

Three things, on three different timelines: NLAuth (the original RESTlet authentication method) loses support as early as 2027, TBA/OAuth 1.0 follows with NetSuite’s 2028.1 release, and SOAP web services are fully disabled in the 2028.2 release in favor of SuiteTalk REST Web Services.

Which of these changes actually matters most for portfolio companies?

TBA, even though its deadline lands second. NLAuth touches a narrow slice of integrations — companies using an iPaaS platform typically aren’t using it at all unless something custom was built on top. TBA is different: it’s a standard authentication method across many iPaaS platforms and appears throughout current integrations, including custom builds, giving it far broader real-world exposure.

Why is it so hard to find out which integrations are affected?

Because authentication method lives on the external system making the request, not inside NetSuite itself — a NetSuite administrator can’t just check a single screen and get a full list. The more reliable starting point is the outgoing request configuration on the system calling into NetSuite, which usually means pulling in whoever manages each connected system.

Once an affected integration is identified, how hard is it to fix?

Not very — updating and testing an integration’s authentication method typically takes hours, not weeks. The real bottleneck isn’t the fix itself; it’s the discovery work of finding every integration that needs it, especially for a portfolio company running several integrations across different providers and teams.

Not sure which of your integrations are exposed? Let's talk.

Our contact form is currently blocked by your cookie preferences. Please change your preferences to continue.