The API an integration can call after it moves to .NET 10

An integration rewritten for .NET 10 keeps its business logic and can lose the library it used to reach SharePoint, along with the sign-in that library relied on. What is left depends on the destination, and SharePoint Online and SharePoint Server Subscription Edition answer differently.

To SharePoint Online, a .NET 10 integration can call Microsoft Graph, SharePoint REST or the client-side object model (CSOM) for .NET Standard, each with an access token from Microsoft Entra ID. To Subscription Edition, it calls REST. The CSOM that Microsoft documents for on-premises SharePoint is the .NET Framework build, and the farm authenticates integrations by its own means. On the pages we read, none of those means is an Entra ID token issued to an application.

This analysis is for teams moving jobs, web APIs and services that read or write SharePoint from .NET Framework, or from an earlier .NET, to .NET 10. Microsoft's documentation was checked on 6 November 2026. No tenant or farm was accessed, and no code was run.

.NET 10, in dates

.NET 10 was released on 11 November 2025 as a Long Term Support release, and the .NET support policy ends its support on 14 November 2028. The Lifecycle page for .NET prints the end as "11/15/2028 6:59:59 AM", in Pacific time, the same one-day offset it shows for .NET 8; we use the policy's date. Support requires the latest patch, and the last six months of every release are maintenance support, with security fixes only. Both pages were checked on 6 November 2026.

For many integrations the move is forced: .NET 8 and .NET 9 reach end of support on 10 November 2026, as the end of support tracker records.

The farm's date is the longer one. Subscription Edition has no planned end of support, and Microsoft commits to it until at least 31 December 2035 (earliest end of support, checked on 6 November 2026). An integration written for it today will change runtime more than once before then, so the API it calls is the decision that lasts.

What each destination accepts

Sources: CSOM for .NET Standard, .NET Standard, Entra ID app-only access, access without a user, MSAL.NET, the SharePoint REST service, basic REST operations, authentication in SharePoint Server and the SharePoint Server connector, all checked on 6 November 2026. "Not documented" means that no page we read documents it, not that it cannot work.

The two destinations do not share an identity system for API calls. SharePoint Online authenticates applications through Entra ID. Subscription Edition's OpenID Connect support is "an OIDC-enabled SPTrustedIdentityTokenIssuer that works with a remote identity provider" (OIDC in SharePoint Server), a way of signing users in, and no farm page we read describes an application presenting an Entra ID token to REST. On that evidence, an app registration built for one destination does not carry over to the other.

SharePoint Online: Graph first, the SharePoint APIs where Graph stops

Microsoft gives the order: "For server-side code, use Microsoft Graph as a first choice; use SharePoint REST or CSOM for functionality that is not available in Microsoft Graph." The Add-in and ACS retirements do not retire CSOM, JSOM or SharePoint REST, but applications using them "must still use supported authentication" (Add-in and ACS retirement FAQ). Where Graph stops is a question for each operation. Its SharePoint API, for instance, gives read-only access to sites, with "no ability to create new sites" (SharePoint API in Microsoft Graph).

Where CSOM stays, it changes build. Microsoft recommends the .NET Standard version "for all your SharePoint Online CSOM developments", ships it in Microsoft.SharePointOnline.CSOM from version 16.1.20211.12000, and lists what it drops (CSOM for .NET Standard, above). SharePointOnlineCredentials goes, so "it's up to the developer using CSOM for .NET Standard to obtain an OAuth access token". SaveBinaryDirect and OpenBinaryDirect give way to the regular file APIs, and HttpUtility to .NET's own classes. The EventReceivers namespace goes too, and Microsoft points to webhooks: remote event receivers registered through ACS stopped working on 2 April 2026, and those registered with an Entra application "have a separate retirement date of July 1, 2027" (retirement FAQ, above).

The password should not come back through another flow. Microsoft's CSOM page imitates SharePointOnlineCredentials with the resource owner password credentials (ROPC) flow. The identity platform's page on that flow opens with a warning: "Microsoft recommends you do not use the ROPC flow; it's incompatible with multifactor authentication (MFA)" (ROPC, checked on 6 November 2026). For code without a user, the same page points to service principal authentication. Our reading: an unattended job becomes an application identity, and a tool that a person runs signs that person in through MSAL.

App-only access to SharePoint REST and CSOM needs a certificate. Azure ACS stopped working for existing tenants on 2 April 2026, with "no option to extend" (ACS retirement). With Entra ID, "when doing app-only you must use a certificate to request access to SharePoint CSOM/REST API's", and every other option is "blocked by SharePoint Online" (Entra ID app-only access, above). Graph also accepts a client secret or a federated identity credential (access without a user, above). An integration that calls both app-only therefore needs the certificate anyway, and two tokens: one for https://graph.microsoft.com/.default, one for the tenant's SharePoint host followed by /.default. Our Knowledge answer on certificates and secrets shows the same split in PnP PowerShell.

On managed identities, Microsoft's pages disagree. Microsoft's webhooks template for Azure Functions authenticates to SharePoint with the function app's managed identity, granted the SharePoint API permission Sites.Selected, and Entra's guidance for code without a user lists a managed identity first (ROPC, above). The SharePoint app-only page names only the certificate. We have not tested either case. Until Microsoft reconciles them, the certificate is the credential the app-only page documents, and the client secret is the one it says SharePoint Online blocks.

We recommend scoping the identity to what it touches. Graph's Selected permissions, Sites.Selected and the newer scopes for lists, list items and files, "now support delegated and application modes", and an application consented for one of them "would initially have no access" until it is granted a specific resource (Selected permissions). Our Knowledge answer on app-only reads records how far the tenant-wide Sites.Read.All reaches instead.

Subscription Edition: REST, with the farm's own authentication

Microsoft's CSOM table settles the library question in one row. Under "On-Premises SharePoint support", the .NET Framework version says yes and the .NET Standard version says no, with the advice: "The CSOM .NET Framework versions are still fully supported and being updated, so use those for on-premises SharePoint development." That version runs on .NET Framework 4.5 and later (CSOM for .NET Standard, above). Choose the right API set describes it as the object model "used in .NET Framework applications that run on a non-phone Windows client", and offers REST to clients "not built on the .NET Framework". A .NET 10 integration is the second kind.

REST needs nothing from SharePoint on the client: "you don't have to add references to any SharePoint libraries or client assemblies" (basic REST operations, above), and on premises it accepts $batch requests from SharePoint 2016 (the SharePoint REST service, above). Its coverage of CSOM is stated twice, differently. One page says REST "exposes all the SharePoint entities and operations that are available in the other SharePoint client APIs"; the other says "almost every API in the client object models has a corresponding REST endpoint". We plan with the weaker sentence: list every CSOM call the integration makes, and find its endpoint, before the rewrite starts.

Loading the .NET Framework CSOM into .NET 10 is a path no SharePoint page documents. .NET's compatibility mode lets a .NET project reference a .NET Framework library, but "referencing .NET Framework libraries doesn't work for all projects", and NuGet flags such a package with NU1701, "This package may not be fully compatible with your project", on every build (compatibility mode, checked on 6 November 2026). A project that compiles proves that the compiler found the types, not that the integration works or is supported. Where an operation exists only in CSOM, we would keep that operation alone in a component on .NET Framework 4.8 or 4.8.1. That is the build Microsoft documents on premises, on a runtime that follows the lifecycle of the Windows version it runs on (.NET Framework lifecycle).

With a user or a service account, the integration uses Windows authentication. The farm authenticates users with Windows, forms-based, SAML or OIDC claims (authentication in SharePoint Server, above). Our reading: for code with no browser, that means Windows authentication as a service account. .NET's HttpClient speaks Negotiate and NTLM, but on Unix, NTLM "may require installing the NTLM plugin for the GSSAPI layer", gss-ntlmssp on Ubuntu, unless the application opts into the managed implementation in .NET 9 and later (NetworkCredential). Microsoft calls NTLM "a legacy authentication protocol" and says Negotiate "prefers Kerberos when available" (NTLM and Kerberos), so we recommend planning Kerberos for an integration that leaves Windows hosting. A write that is not authorised with OAuth also carries the farm's form digest in the X-RequestDigest header, read with an empty POST to /_api/contextinfo (basic REST operations, above).

Without a user, the integration signs its own token. An application obtains "an access token either from the Microsoft Azure Access Control Service (ACS) or by self-signing an access token using a certificate that SharePoint Server trusts" (authentication in SharePoint Server, above). The second is the high-trust model, part of the Server add-in model that Microsoft has not retired on premises. Its server-to-server option "only works in on-premises SharePoint environments" (app-only and elevated privileges), and the trust is set up on the farm with PowerShell cmdlets and the certificate (create high-trust add-ins). Microsoft documents the token field by field, mainly for remote components not written in .NET: a JSON Web Token signed with the certificate's private key, under the MS-SPS2SAUTH protocol, in which the actor token serves as the access token for an app-only call (high-trust access tokens). Our reading: a .NET 10 integration can build that token from the same page. Microsoft's walkthrough generates TokenHelper inside an ASP.NET Web Forms project, and whether that helper builds on .NET 10 is not documented.

Two limits apply on premises. App-only does not reach everything: Microsoft lists search on premises, User Profile operations through CSOM and writes to the taxonomy service among the cases that need a specific service account (app-only and elevated privileges, above). And ACS, the other token source, is unaffected on premises where a farm was configured to use it: its retirement "is not impacting any of the SharePoint on-premises use cases" (ACS retirement, above).

Call by call

The third column is our recommendation, not Microsoft's; each fact it rests on is cited above. Three steps come before it and one after:

1. List every SharePoint call before choosing a library: destination, API, identity, credential, and whether it reads or writes. A call missing from the list is the one that fails after the move.
2. Decide whose authority each call acts with, then the credential. An application identity acts with its own grants, a service account with the account's, a delegated token with the user's. Our analysis of privileged server-side code sets out the questions each choice must answer.
3. Test with the identity the integration will run as: one allowed and one refused operation for each. A successful connection proves who the identity is, not what it may do.
4. Put the next runtime move in the plan. .NET 10 support ends on 14 November 2028, at least seven years before the farm's can.

The counter-check

We looked for three findings that would change the answer for Subscription Edition.

• A CSOM for SharePoint Server that targets .NET Standard or .NET. We found none on Microsoft's documentation pages. A Microsoft Q&A answer recommends the CSOM package for SharePoint 2019 for Subscription Edition and names Microsoft.SharePointOnline.CSOM as that package. A forum is not the authority, and in a .NET 10 project that package supplies the .NET Standard build, which Microsoft's own table marks as not supporting on-premises SharePoint.
• The farm accepting an Entra ID token from an application. The OIDC pages describe signing users in through a trusted identity token issuer, and none describes an application calling REST with an Entra ID token.
• Microsoft Graph reaching the farm. What Microsoft documents is the SharePoint Server connector, which crawls documents and site pages from SharePoint Server 2016, 2019 and Subscription Edition farms so that Microsoft Search and Copilot can find them, through an agent with "outbound-only connections to Microsoft 365" (SharePoint Server connector, above). Indexing content into Microsoft 365 is not an API that changes it.

None of the three changed the conclusion.

What this does not settle

• Whether the .NET Framework CSOM works inside a .NET 10 process against Subscription Edition. Microsoft does not document it, and we did not test it.
• Which CSOM package Microsoft supports for Subscription Edition. The pages we read say to use the .NET Framework versions on premises, without naming a package for this edition.
• Whether TokenHelper builds on .NET 10. Not documented.
• Whether SharePoint Online accepts a managed identity for app-only REST and CSOM in general. Two Microsoft pages point different ways.
• Which CSOM operations have no REST endpoint. Microsoft says "all" on one page and "almost every" on another; only the integration's own list of calls settles it.

Where this fits

• Farm solution, SharePoint Framework or external service decides which customisations of a Subscription Edition farm become external services. This article is about the API those services call.
• Migrating privileged SharePoint server-side code sets out the authorisation design that an app-only identity or a service account needs.
• The state of SharePoint in 2026 records the Add-in and ACS retirements in SharePoint Online.
• Certificate or client secret and the permission an app-only read needs record observed behaviour of the SharePoint Online app-only model.
• Sending email from an application, without a single password shows an application calling Graph with a managed identity.
• The Microsoft lifecycle tool carries the .NET dates beside the other products a SharePoint estate depends on.

Tags#dotnet#sharepoint#graph#identity#migration