SuccessFactors basic auth is going away: moving Entra HR provisioning to workload identity

If Microsoft Entra creates and removes accounts from SAP SuccessFactors, that feed still logs in to SuccessFactors with a stored username and password, and both vendors want it gone. Switch each SuccessFactors provisioning app to workload identity now, while you can still flip back if something breaks. This guide explains the two deadlines, what you need in place first, and the order we'd do the switch in.

There are two dates, and they don't agree. Microsoft's "What's new" page says customers on basic authentication must move to workload identity before November 2026 to keep the integrations running. SAP's release information now says basic auth for its APIs is deleted on 12 November 2027. SAP pushed that date back on 12 June 2026; until then it was 20 November 2026, which is the date Microsoft was planning around. Don't read the later date as a year of slack. SAP says basic auth goes off by default for every customer in the first half of 2027, with an opt-in to keep it during migration, and it doesn't give a day.

The business risk is a joiner and leaver process that quietly stops. Entra's provisioning service usually runs every 20 to 40 minutes, and each run has to sign in. If it can't, the job can end up in quarantinedefinitionWhat Entra does to a provisioning job that keeps failing, for example on bad credentials. Cycles gradually slow to once a day, and after four weeks the job is disabled.; Microsoft's own example of a cause is invalid admin credentials. From there the runs get gradually further apart until there's one a day, and after four weeks Entra disables the job. You get one email when quarantine starts, and another only if the reason changes. It goes to whatever notification address someone typed in at go-live.

So the first sign is often a new starter with no login on day one. The worse case is the one nobody reports: a leaver whose account is never disabled because the termination never reached the directory. That is exactly the gap an access audit looks for.

For engineers: Microsoft's integration reference still describes the provisioning service calling Employee Central OData endpoints with basic authentication, and the inbound tutorial still asks for an admin username in the form username@companyID plus a password. That's the credential this change removes. Microsoft frames the new method around removing the stored password and using short-lived tokens that SAP's supported model accepts.

Here's how the new sign-in works. Entra issues a short-lived token for your tenant, and its subject is a Microsoft service principal called the SyncFabric Workload Identity ISV Integration Client. SAP Cloud Identity Services checks that token against a trust rule you set up, then swaps it for its own access token scoped to the SuccessFactors API. The provisioning service uses that second token to call OData. Microsoft's how-to calls the two tokens AT1 and AT2, which helps when you read its troubleshooting table.

Two things catch people out. Entra's method doesn't use the SAML bearer or X.509 certificate options you'll see in SAP's list of alternatives; it uses OpenID Connect through SAP Cloud Identity Services. And SAP only supports that OIDC route on instances that already use SAP Cloud Identity Services for user sign-in. If your SuccessFactors still trusts a corporate identity provider directly, sort that out first. SAP has a separate deletion date for direct third-party IdP integration: 13 November 2026.

The real decision is about timing, because the end state is the same for everyone on Entra. Microsoft hasn't said what, if anything, it switches off on its side in November, and the how-to it updated in October doesn't give a date. We'd still plan for now. The rollback only exists while SAP supports basic auth, and a quiet quarter is a better time to find a permissions gap than whatever week SAP picks in 2027.

• SuccessFactors signs users in through SAP Cloud Identity Services, not straight through your corporate IdP.
• You know which SuccessFactors apps you run in Entra: inbound to AD, inbound to Entra ID, writeback, or several of each.
• You know the API user each app signs in as, and its role-based permissions are written down somewhere other than the old admin's head.
• Someone has admin rights in all three consoles: Entra (at least Application Administrator), SAP Cloud Identity Services and SuccessFactors.
• The provisioning app's notification email goes to a team mailbox that someone actually reads.
• You've picked a test user and noted their personIdExternal. Provision on demand needs it to prove each switch worked.
• You've listed every other tool that calls SuccessFactors APIs with a password, because SAP's deletion hits those too.

Entra is rarely the only thing reading SuccessFactors with a password. SAP's KBA 3796078 says every basic-auth integration can be affected, and HR estates tend to collect them: an IGA connector, a middleware flow, a payroll link, a reporting extract someone built for finance. Start with SuccessFactors' OData API audit log. Microsoft's how-to uses it to confirm the switch, because each call's HTTP message shows either authorization: Basic or authorization: Bearer. Every API user still showing Basic is something to move.

# example: workload identity fields
Authentication method   Workload identity
Client identifier       <SAP client ID>
OAuth token endpoint
https://<ias-server>.accounts.ondemand.com/oauth2/token
Application API URL     <SF API host>
App Dependency Name     <prefix + name>
# OData API audit log, before and after
authorization: Basic **********
authorization: Bearer **********

SAP's deletion isn't about Entra, so anything else calling SuccessFactors APIs with a password has the same 2027 problem. Each vendor has its own replacement, and they aren't the same method. Okta's SuccessFactors integration uses OAuth 2.0 with SAML, signed with an Okta certificate that you register in SuccessFactors, and Okta's page already quotes the 12 November 2027 date. Oracle Integration removed the basic-auth Custom Policy from its SuccessFactors adapter in Release 26.10. It points customers to SAML bearer, SAML with SAP Identity Authentication Service, or SAP OpenID Connect for OData-only integrations.

SailPoint's connector documentation lists the Manage OAuth2 Client Application permission among its prerequisites but doesn't spell out the auth types. On SailPoint's developer forum, a practitioner moving an Identity Security Cloud web services integration found the built-in OAuth grant types can't do the two-step token exchange through SAP Cloud Identity Services, and that the API user has to exist in both systems. If you run SailPoint, Saviynt or a homegrown script against SuccessFactors, confirm the method with that vendor before you plan dates around it.

We start from the OData audit log and your Entra provisioning apps, list every password still reading SuccessFactors, and agree an order with you. Then we do the switch app by app, with a leaver reconciliation before and after so audit has evidence. If SAP Cloud Identity Services isn't in front of SuccessFactors yet, we plan that first. Our Microsoft Entra ID page covers the wider identity work, and you can bring in Entra engineers for the cutover. If other tools read HR too, our SailPoint and Okta pages cover those platforms. If you'd like a second opinion first, ask for an assessment.