A finance manager got separated on a Friday. By Monday, IT disabled all her access: Microsoft Entra account, mailbox, Teams and SharePoint accesses are gone. Every dashboard shows her as fully offboarded.
Three weeks later, a quarterly access review tells a different story. Her user is still live in the on-premises S/4HANA system, still carrying authorizations to post journal entries and release vendor payments. Entra never knew that SAP account existed. SAP GRC Access Control never heard she had left the company.
Reason - The systems simply were not talking to each other. And that quiet gap between them is where a surprising amount of identity risk actually lives.
For most enterprises, identity governance does not live in one system.
A single user might be created and managed in Microsoft Entra, authenticate through Entra, reach SAP cloud applications like SuccessFactors, Ariba or Concur, and still hold sensitive authorizations deep inside an on-premises SAP ECC or S/4HANA environment. In many of these organizations, SAP GRC Access Control remains the center of gravity for segregation-of-duties (SoD) analysis, access reviews and risk management.
That is what makes hybrid identity governance more than an integration project. It is a governance problem.
Microsoft Entra has become the enterprise's default platform for identity, authentication and access management. SAP, in parallel, has kept building out its own cloud identity and access governance capabilities, including SAP Identity Access Governance (IAG). The question worth watching is what happens when the two stop working in isolation and start cooperating not only on single sign-on and provisioning, but on governance across the wider SAP landscape.
The latest roadmap points to a meaningful shift. The integration story is moving past cloud-native identity alone, with SAP IAG entering public preview and an emerging path toward connecting with on-premises SAP GRC Access Control.
If that direction holds, enterprises could get closer to governing identity consistently across SAP cloud applications and traditional on-premises SAP systems, without giving up the depth of control that SAP-specific access governance and SoD demand.
So where does this integration actually stand today?
What is available now, what is still in preview, and what could a working connection between Microsoft Entra, SAP IAG and on-premises SAP GRC Access Control mean for organizations running genuinely complex hybrid SAP landscapes?
This article looks at where SAP and Microsoft are heading, and what security and identity teams should be paying attention to now.
Microsoft Entra Is SAP's Preferred Identity Solution
SAP has designated Microsoft Entra as its preferred solution for customers who need secure identity management across a broad mix of on-premises and cloud SAP applications. That endorsement now spans SAP's full application portfolio:
- SAP S/4HANA and other core SAP solutions
- SAP Cloud Identity Services, SAP Identity Access Governance (IAG), and SAP Access Control for governance and provisioning
- SAP SuccessFactors
- Legacy SAP HCM and SAP ECC environments
For customers migrating off SAP Identity Management (SAP IDM), which is heading toward end of maintenance, Microsoft has published a dedicated migration guide at aka.ms/MigrateFromSAPIDM to help plan the move to Entra.
The Foundation: SAP Cloud Identity Services Integration
At the core of the partnership is a direct integration between Microsoft Entra ID and SAP Cloud Identity Services, running on SAP's Business Technology Platform (BTP). The architecture works as follows:
- An Enterprise App registered in Microsoft Entra establishes single sign-on (SSO) with the SAP Cloud Identity Services tenant's Identity Authentication service.
- SCIM-based user and group synchronization pushes identities from Entra ID Governance into the SAP Identity Directory, which feeds SAP's Identity Provisioning service.
- From there, SSO and user provisioning extend outward to SAP's cloud solutions Ariba, Concur, SuccessFactors, and S/4HANA and, via SAP's Connectivity Service and Cloud Connector, into on-premises ABAP systems.
This gives IT teams a single control plane in Entra for authentication and lifecycle management across both SAP's cloud portfolio and connected on-premises ABAP backends.
Identity Reconciliation and Account Discovery (Public Preview)
A newer capability, now in public preview, addresses one of the most persistent identity headaches in any hybrid landscape: accounts that exist in target applications but aren't properly reflected or governed in the identity provider.
Account Discovery currently:
- Discovers all identities inside connected applications
- Flags local or orphan accounts that don't exist in Entra
- Identifies accounts that are mapped to Entra but not assigned, as well as accounts that are correctly mapped and assigned
- Surfaces user attributes from the target application for comparison
- Operates in a visibility-only capacity today, it does not auto-create accounts
- Helps uncover unauthorized or unmanaged access paths
- Works with SAP Cloud Identity Services
The roadmap builds on this foundation in stages:
- Next: Group discovery, extending visibility into group memberships inside connected apps
- Future: Drift detection (comparing app access against Entra assignments and access packages) and enforcement - locking down groups so Entra becomes the authoritative source of truth, with automatic remediation of ungoverned access
Documentation is available at aka.ms/accountDiscoveryDocumentation.
Mandatory Requirement for SAP SuccessFactors Customers
Organizations connecting Entra to SuccessFactors have a mandatory deadline to plan around: SAP is removing Basic Authentication on November 20, 2026, and migration to OAuth/OIDC will be required to maintain connectivity.
To support this, Microsoft is delivering a new SAP SuccessFactors connector with OAuth Client Credential authentication:
- The updated connector entered public preview on May 1st
- Customers will get an in-place upgrade experience, there is no need to stand up a new application to move to the OAuth-based connector
Customers still relying on Basic Authentication for SuccessFactors integration should begin planning this migration well ahead of the November 2026 cutoff.
SAP Identity Access Governance (IAG): Public Preview
Beyond authentication and provisioning, Microsoft and SAP have extended the integration into governance specifically SAP Identity Access Governance (IAG), SAP's cloud-native successor to classic GRC Access Control, now in public preview.
Integration Scenario: Access Requests Through My Access
The initial integration scenario is framed around a simple but powerful IT admin story:
As an IT admin, I want to configure access packages containing SAP IAG business roles in Microsoft Entra that end users can request through My Access. Once approved in Microsoft Entra, the request is sent to SAP IAG for approval and provisioning. SAP IAG then notifies Microsoft Entra once provisioning is complete.
The flow moves through six stages:
- An IAG business role (BR) is represented and brought into Microsoft Entra
- Entra creates an Access Package containing that IAG business role
- A user requests the access package through My Access, which creates the request in Entra and forwards it to IAG
- IAG runs its approval workflow
- Upon approval, IAG provisions access in the relevant SAP applications
- Provisioning status is returned to Entra, updating the assignment and closing the loop for tracking
Architecture
The technical path adds a governance layer on top of the Cloud Identity Services foundation described earlier:
- Microsoft Entra ID Governance's Entitlement Management catalog holds the Access Package, connected via a Connector to the SAP side
- SSO and SCIM synchronization flow into the SAP Cloud Identity Services tenant (Identity Authentication, Identity Directory, Identity Provisioning) exactly as in the base architecture
- A new component, SAP Cloud Identity Access Governance, sits alongside Identity Provisioning inside BTP, handling role assignment and feeding governance decisions back out to SAP's cloud solutions (Ariba, Concur, SuccessFactors, S/4HANA)
Extending Governance to On-Premises: SAP Access Control Connector (Private Preview)
The most significant development for customers still running on-premises SAP GRC Access Control is a new connector, currently in private preview, that brings that same Entra-driven access request experience to on-premises GRC AC deployments, not just cloud-native IAG.
High-Level Architecture
Unlike the cloud-to-cloud IAG integration, this scenario must bridge Entra all the way down to a customer's on-premises environment:
- Microsoft Entra ID Governance's Entitlement Management (Catalog → Access Package → Connector) connects over REST to SAP Integration Suite running in BTP
- Integration Suite hands off to the Connectivity Service, which reaches a Cloud Connector deployed in the customer's on-premises environment
- The Cloud Connector connects locally to SAP Access Control (SAP AC), the on-premises GRC system of record
How Microsoft Entra Actually Talks to On-Premises GRC

A dedicated end-to-end architecture clarifies exactly how the pieces fit together, since the connection is not a direct line from Entra to SAP AC:
Microsoft Entra (Entitlement Management) → SAP Integration Suite (iFlows) → SAP Cloud Connector (secure tunnel) → SAP GRC Access Control (on-premises)
A few important technical details:
- Entra calls the Integration Suite endpoint - not SAP AC directly. SAP Integration Suite acts as the intermediary.
- Integration Suite translates REST to SOAP through custom iFlows, since SAP AC's SOAP services expect that protocol.
- SAP Cloud Connector provides the secure tunnel into the on-premises SAP AC system.
- Authentication is handled at SAP BTP level using OAuth Client Credentials - not directly by Entra.
- Critically, the "Access Control URL" configured in the Entra connector is the Integration Suite URL, not the SAP Access Control URL itself. This is a common point of misconfiguration worth flagging to implementation teams.
Setup Walkthrough
Standing up this integration requires coordinated configuration across five areas - three on the SAP side and two on the Microsoft side.
SAP-side setup:
A. SAP GRC Access Control
- Verify SAP AC (GRC) is installed
- In SOA Manager, configure the six required SOAP services with exact binding names
- Create a service user in SU01 with the SAP_GRAC_ALL role
- Run a Repository Sync via SPRO
B. SAP Cloud Connector
- Install and connect the Cloud Connector to the BTP subaccount
- Add the ABAP backend system, specifying internal host and virtual host
- Expose the necessary paths - /sap/* for POC environments, or specific GRAC paths only for production
- Verify the tunnel shows as Connected (a missing Location ID surfaces as a 503 error)
C. SAP Integration Suite
- Activate the Integration Suite subscription in BTP
- Import the iFlow ZIP package (provided by Microsoft)
- Configure host and port to match the Cloud Connector's virtual host
- Deploy the iFlows and create a BTP service key (client ID, secret, token URL, and URL)
Microsoft-side setup:
D. Create the SAP GRC/Access Control Connector
Navigate to https://aka.ms/elm-sap → Identity Governance → Entitlement Management → Control Configurations → View Connectors → New Connector → select SAP GRC/AC.
Connector fields required:
- Client ID (from the BTP service key)
- Access Token URL (the service key's token URL plus /oauth/token)
- Access Control URL — this is the Integration Suite URL, not SAP AC's own URL
- SAP System ID (e.g., PMCLNT400)
- Key Vault reference, used to store the client secret
User mapping can be configured against email alias, UPN, employee ID, or an on-premises extension attribute (note the 12-character limit).
E. Create Catalog and Access Package
- 1. Create a new catalog
- 2. Add SAP GRC/AC as a resource, selecting the connector created in step D
- 3. Create the access package: select SAP business roles, set the request policy, configure approvals, and set the lifecycle duration
Once configured, end users request access through the My Access portal, approvals run through SAP AC's NWBC (a two-level approval process), Entra automatically polls for status, and cancellations initiated from Entra are supported.
Why This Matters
For organizations running SAP across both cloud and on-premises environments, identity governance has usually been a patchwork.
Microsoft Entra handles the enterprise identity layer. SAP GRC Access Control, meanwhile, keeps doing the heavy lifting for access governance and SoD inside the on-premises SAP landscape. And in between sits a team quietly connecting the dots, usually through a mix of integrations, manual steps and periodic reconciliation. It works, but it is held together by effort rather than design.
That is the gap this roadmap could start to close.
SCIM-based provisioning for SAP Cloud Identity Services is already well established. SAP Identity Access Governance (IAG) is now in public preview, and the SAP Access Control connector is working its way through private preview toward general availability. Taken together, these point toward a more connected way of governing identity across the whole SAP estate, rather than treating cloud and on-premises SAP as two separate problems that happen to share users.
For organizations still running SAP IDM, or managing SAP GRC Access Control largely on its own island, this one is worth watching closely.
There is also a practical reason not to wait. Teams can begin reviewing the SAP-side prerequisites now, including SOA Manager services, service users and Cloud Connector configuration, and look into the private preview program where it makes sense. Getting comfortable with the architecture today could make the eventual move to general availability far less painful.
Key resources:
- Migration guide (SAP IDM to Entra): aka.ms/MigrateFromSAPIDM
- Account Discovery documentation: aka.ms/accountDiscoveryDocumentation
- Entitlement Management connector configuration: aka.ms/elm-sap

