2026.1 Authentication: OAuth 2.0 Expansion, TBA Sunset, PKCE Mandate, and DCR

NetSuite 2026.1 ships a dense batch of authentication changes that touch nearly every integration pattern. Several are immediate (2026.1), and two are hard deadlines you need to plan for now (2027.1). Here is what actually changes for developers and admins.

The two deadlines that matter (2027.1)

1. End of support for new TBA integrations

As part of the broader SOAP web services removal, as of 2027.1 you will no longer be able to create new integrations using Token-based Authentication — not just for SOAP, but also for REST web services and RESTlets. Existing TBA integrations continue to function, but no new ones can be created. The only forward path for new integrations is OAuth 2.0 (authorization code grant or client credentials/M2M).

2. PKCE becomes mandatory for the authorization code grant flow

Today, PKCE is optional for confidential clients and only required for public clients. As of 2027.1, every newly created integration using the OAuth 2.0 authorization code grant flow must send PKCE parameters (code_challenge/code_challenge_method on /app/login/oauth2/authorize.nl and code_verifier on the token endpoint) regardless of whether the client is public or confidential.

What changed in 2026.1

Login Notification

Administrators can configure a compliance message that every user must acknowledge at login (intended for NIST-style compliance banners). Acknowledgments — including timestamp — are recorded in the Login Audit Trail, so if you build SuiteAnalytics saved searches or workbooks against login audit data, expect new rows/columns related to acknowledgment events. The release notes do not specify the exact field IDs; verify those in the Records Browser once 2026.1 lands in your account.

Maximum 5 active certificates per integration record

Each integration record is now capped at five active certificates for the OAuth 2.0 client credentials (M2M) flow. Revoked certificates remain unlimited. If you have automation that pre-stages rollover certificates, make sure your rotation logic revokes old ones before pushing a sixth. The list is visible on the OAuth 2.0 Client Credentials (M2M) Setup page.

Multiple Redirect URIs on a single integration record

Integration records using the authorization code grant flow can now hold multiple Redirect URIs. This finally removes the long-standing pain of needing a separate integration record per environment (dev/stage/prod) or per tenant of a multi-tenant app.

Multiple sessions per user — now opt-in and 2FA-gated

The “three concurrent sessions per user” behavior introduced in 2025.2 was on by default. In 2026.1 it changes in two ways:

• An Administrator must explicitly enable it on the Enable Features page. It is no longer automatic.
• Only users whose roles are all 2FA-required can use it. If a user holds even one non-2FA role, multi-session is denied for that user.

If your support, integration, or service-account users currently rely on overlapping sessions, audit their role assignments before upgrading.

Client Credentials Certificate Rotation Endpoint

There is now a programmatic endpoint to list, create, and revoke certificates attached to OAuth 2.0 client credentials (M2M) integrations. This means certificate rotation can be fully automated — no more manual uploads through the UI on a 12-month cadence. The release notes do not publish the endpoint path or governance details inline; check the “Client Credentials Certificate Rotation Endpoint” topic in the OAuth 2.0 documentation for the exact URL, request schema, and required role/permissions before building against it.

Dynamic Client Registration (DCR) for OAuth 2.0

NetSuite now supports DCR, allowing a client application to register itself against a NetSuite account without an administrator pre-creating an integration record and handing back a client ID. After registration, the client ID is returned via the redirect URI, and the client can then run the standard OAuth 2.0 authorization code grant flow. This is a meaningful unlock for ISVs distributing apps — onboarding can be self-service rather than email-driven. The release notes do not specify the DCR metadata endpoint or whether NetSuite implements RFC 7591 strictly; verify against Create Integration Records for Applications to Use OAuth 2.0.

What to do

1. Inventory every TBA integration today. Tag each by transport (SOAP, REST, RESTlet), owner, and whether it can be migrated to OAuth 2.0 client credentials (server-to-server) or authorization code (user-context). Anything you cannot migrate before 2027.1 must at least exist as an integration record before that release — new ones cannot be created after.
2. Add PKCE to any auth-code integration you build from now on, even confidential clients. Generate a code_verifier (43–128 chars), derive code_challenge = BASE64URL(SHA256(verifier)), send code_challenge and code_challenge_method=S256 on the authorize call, and send code_verifier on the token call. Doing it now means no scramble in 2027.1.
3. Audit certificate counts on every M2M integration record. If any are at or near five active certs, revoke stale ones before 2026.1 hits, and update your rotation tooling to enforce the cap.
4. Consolidate integration records that exist only because you needed different redirect URIs per environment. Merge them onto one record using the new multiple-redirect-URI support, and rotate any leaked client secrets while you are at it.
5. Review users who depend on concurrent sessions. Make sure every role they hold is flagged 2FA-required, and decide whether to flip the Enable Features toggle on at upgrade or leave it off by default.
6. Plan certificate rotation automation against the new rotation endpoint once you have its exact URL and governance cost. This is a good opportunity to move M2M certs out of manual ops and into a scheduled script or external job.
7. If you ship an ISV app, evaluate DCR for onboarding. It can replace the current “customer admin manually creates an integration record and emails us the client ID” dance.
8. Update Login Audit Trail saved searches/workbooks after 2026.1 to capture the new login-notification acknowledgment fields if you have a compliance reporting requirement.

Caveats and things to verify

The source release note is light on the technical specifics developers actually need: it does not publish the rotation endpoint URL, the DCR metadata endpoint, the new Login Audit Trail field IDs, or governance unit costs for any of the new endpoints. Before building against any of this, confirm against the linked detail pages (OAuth 2.0, Create Integration Records for Applications to Use OAuth 2.0, and the SOAP Removal Plans FAQ) once 2026.1 documentation is fully published.