SAP Community - SAP Cloud Identity Access Governance

Kickstart your Cloud SAP GRC Learning Journey: Introduction to Cloud SAP GRC, its Submodules details

2025-06-05T10:56:56.081000+02:00

I would recommend referring my below earlier article on SAP GRC (On-premise) before you start your journey into Cloud SAP GRC. It helps you understand the basic concepts and how On-premise SAP GRC helps organization to achieve business goals.

https://community.sap.com/t5/technology-blog-posts-by-members/kickstart-your-sap-grc-learning-journey-introduction-to-sap-grc-submodules/ba-p/13997059

SAP Cloud GRC encompasses a range of robust solutions tailored to meet diverse organizational needs.

Below are some of the key offerings in the SAP GRC, public cloud solutions portfolio.

· SAP Cloud Identity Access Governance

· SAP Risk Assurance Management

· SAP Enterprise Threat Detection, Cloud Edition

· SAP Watchlist Screening

1. SAP Cloud Identity Access Governance

SAP Cloud Identity Access Governance is a comprehensive solution designed to simplify user access management in the cloud environment. While it offers similar functionality like on-premises SAP Access Control, it is not a cloud version of SAP Access Control (On-prem) or SAP Access Control hosted on cloud. Instead, it is a new SAAS solution from SAP, built on the SAP Business Technology Platform (BTP). It supports both on-premise and cloud systems.

Submodules/services:

· SAP Cloud Identity Access Governance, Access Analysis Service (like ARA)

· SAP Cloud Identity Access Governance, Access Request Service (like ARM)

· SAP Cloud Identity Access Governance, Role Design Service (like BRM)

· SAP Cloud Identity Access Governance, Privileged Access Management service (like EAM)

· SAP Cloud Identity Access Governance, access certification service (like UAR etc.)

Image Source: SAP

Common IAG and Access Control scenarios:

· SAP Cloud IAG only - supports only Cloud systems

· SAP Cloud IAG with Cloud Connector - supports both On-prem and cloud systems

· SAP Access Control with IAG integrated edition (as a bridge) - supports both On-prem and cloud systems

· SAP Access Control – supports only On-Prem and SuccessFactors EC.

Reference SAP hep portal:

https://help.sap.com/docs/SAP_CLOUD_IDENTITY_ACCESS_GOVERNANCE

2. SAP Risk and Assurance Management

SAP Risk Assurance Management (RAM) is a comprehensive solution designed to document risks and controls, automate controls to safeguard financial and nonfinancial data, policies, and processes in the cloud environment. This can be like on-prem SAP Process Control. However, it is not a cloud version of SAP Process Control (On-Prem) or either SAP Process Control (on-Prem) hosted on cloud.

Earlier it was called as “SAP Financial Compliance Management” solution.

It provides the predefined integration and content for SAP S/4HANA on premise and in the cloud.

Image Source: SAP

Reference SAP hep portal:

https://help.sap.com/docs/risk-and-assurance-management

3. SAP Enterprise Threat Detection, Cloud Edition

SAP Enterprise Threat Detection enables you to evaluate security threats in your IT landscapes in real time by leveraging SAP and non-SAP log data. It helps to identify, analyze, and neutralize cybersecurity threats with real-time SIEM intelligence in your SAP applications as they happen and before serious damage occurs.

This solution allows organizations to monitor and respond to potential threats in real-time, ensuring the security of your cloud operations.

Key features/modules:

· Log correlation and analysis

· Automated threat detection and alerting

· Straightforward integration

Image Source: SAP

Reference SAP hep portal:

https://help.sap.com/docs/SAP_ENTERPRISE_THREAT_DETECTION

4. SAP Watchlist Screening

SAP Watch List Screening enables enterprises across all industries to screen the names and addresses of their business partners against sanctioned party lists, thus ensuring their compliance with guidelines, regulations, and legislation. To facilitate this task, SAP Watch List Screening is integrated with SAP Business Partner.

It helps in assessing potential risks on an exception basis helps avoid high-risk businesses, individuals, and entities.

This can be integrated with SAP S/4HANA and SAP S/4HANA Cloud, as well as with APIs to extend to other systems.

A vital tool for screening against various watchlists to ensure compliance with legal and regulatory requirements.

Reference SAP hep portal:

https://help.sap.com/docs/SAP_WATCH_LIST_SCREENING

I hope this helps to start your journey into Cloud SAP GRC also if you're aiming to level up your skills in Cloud SAP GRC ! By diving deep into these modules, you'll gain the knowledge and skills needed to excel in the world of Governance, Risk, and Compliance.

Please connect and follow me for the next upcoming informative articles in SAP Security, GRC, BTP, Internal Controls and Risk & Controls area.

Share your thoughts in the comments below !

Streamlining Privileged Access in SAP: Practical Tips for Reliable Session Management

2025-06-11T04:38:01.776000+02:00

For enterprises running SAP at scale, privileged access is both a necessity and a significant risk. Whether responding to production incidents, executing sensitive financial transactions, or configuring core systems, elevated access must be tightly governed. Without robust controls, organizations risk compliance violations, audit gaps, and unauthorized exposure of sensitive data.

This post highlights how SAP Identity Access Governance (IAG) can help your organization secure, monitor, and audit privileged access, with practices tailored to meet the scrutiny of internal auditors, external regulators, and executive risk committees.

Common Use Cases

When to Assign Privileged Access

PAM IDs are not for routine tasks. They should be reserved for high-risk or time-sensitive operations such as:

Urgent Fixes – for example responding to production outages.

System Setup or Configuration Changes – including user management or master data updates.

Sensitive Transactions in Regulated Areas – such as finance or healthcare, where full traceability is required.

Where to Use PAM IDs

Not all systems require the same level of access control. Here’s how to prioritize:

Production Systems: Always enforce PAM to protect live data.

Development/Test Systems: Use PAM for high-impact changes, while allowing standard accounts for daily work.

Best Practices

Synchronizing PAM Logs

Reliable synchronization between SAP ABAP systems and SAP IAG ensures that every privileged session is logged, reviewed, and auditable.

Recommendations:

Sync Interval: Schedule synchronization jobs every 6 to 12 hours to achieve near real-time visibility without overburdening the system.

Avoid Over-Syncing: Running sync jobs too frequently (e.g., every 30 minutes) can lead to job overlaps and potential failures.

Optimize Timing: Execute jobs during off-peak hours (e.g., midnight) to reduce system load and avoid conflicts with business operations.

Proactive Monitoring: Regularly monitor sync jobs and review log files to detect errors or delays early and prevent data gaps.

Tip: In high-volume environments, a single sync job may take over an hour. Plan sync windows accordingly to avoid cascading delays.

The Privileged Access Log Sync job scans all sessions tied to PAM assignments across connected systems, including both active and expired sessions (within the last six months). This ensures continuity—even if a system was temporarily unavailable or if one system’s sync succeeded while another failed.

Note: As of the last release, the PAMLOGSYNC - LAST_SYNC_DATE_TIME setting has been removed from the Configuration app, simplifying setup and reducing sync inconsistencies.

Pitfalls in Session Handling: The “Unlock” Problem

A common issue in customer environments is improper session termination. Many users do not select "Unlock" button in the SIAG_PAM_LAUNCH_PAD after completing their task. This leads to:

Sessions remain open for hours—or even for days.

Overlapping sessions under the same PAM ID.

Inaccurate audit trails and failed sync jobs.

Quick Fix: Implement SAP Note 3604073 to fix missing logged off timestamps. This ensures sessions are properly closed, even when users forget to terminate them manually.

Additional Recommendations

For improved performance and session accuracy, we recommend applying the following SAP Notes:

3606297 – Configure sync intervals for better log preparation.

3586699 and 3586925 – Enable paging for PAM access logs to boost sync reliability.

Final Takeaway

When used effectively, Privileged Access Management in SAP IAG is more than a compliance checkbox—it’s a strategic layer of defense. With proper assignment policies, smart sync scheduling, and user discipline, you can ensure privileged sessions are secure, auditable, and well-managed.

Want to learn more about implementing PAM in your SAP landscape? Contact us or explore the latest updates in SAP Help Portal.

Author(s)

Yuliia Shpak

Swetta Singh

SAP Business Technology Platform(BTP) Security Best Practices: Expert Tips to Protect Your Platform

2025-06-13T16:10:20.147000+02:00

Heard about those big cyber-attacks recently? No names needed, but chances are, your weekly shop has been hit. The interesting thing is that they followed a familiar pattern. Security analysts found that over 52,000 new vulnerabilities were disclosed in 2024, indicating that outdated or misconfigured systems are a growing invitation to attackers (sentinelone.com). Hackers often slip in via a ‘side door’: an unpatched server, an ill-configured cloud service, or a tricked user giving up a password. Another analysis of supply-chain incidents found that about half were driven by stolen or weak credentials (securityinfowatch.com). In plain terms, cybercrooks lean on low-hanging fruit - phishing, reused passwords, forgotten updates , more than any sci-fi-style hack.

Naturally, this has SAP customers asking: “Are our own SAP BTP environments secure? Is our user management tight? Are we following cloud security best practices?” These are great questions, and we’ve been hearing them a lot. So in this blog post we tried to answer these burning questions. We will address everything from locking down user accounts to broader security best practices, and we promise it won’t be a parade of jargon or doom-and-gloom.

What can we learn from the recent cyber-attacks in the UK?

The recent cyber-attacks targeting major UK retailers mark a significant moment in cyber security as these are among the first Distributed Denial-of-Service (DDoS) attacks to penetrate networks that were protected by enterprise-grade firewalls. In many cases, these firewalls are managed by hyper scalars such as AWS, Microsoft Azure, or Google Cloud, who provide the foundational infrastructure.

However, it’s important to recognise that responsibility for security is shared. There’s a fine line between what the hyper scaler secures and what platform providers, like SAP BTP or Microsoft Power Platform, are responsible for. Most organisations today operate across multiple platforms, each with its own security model, tools, and SLAs, which can lead to gaps in the overall defence posture if not carefully managed.

It’s also a reminder of the real-world consequences of cybersecurity failures. When breaches occur, especially those involving customer data, organisations face not just supply chain or reputational damage, but significant financial penalties under regulations like GDPR. We’ve seen this play out repeatedly, including with major social media companies in recent years.

These all point to the importance of a well-coordinated, multi-layered security approach. It’s got to be holistic and span infrastructure, platforms, and application layers, with clear roles and responsibilities.

How secure is SAP BTP out of the box, and what are the most common gaps you see in customer configurations?

So, that’s the approach, but how is this carried out? The Business Technology Platform is designed with security and governance in mind across multiple layers. Out of the box, SAP BTP offers:

Built‑in Identity & Access Management (IAM) & Network Security: Native support for Single Sign On(SSO) /Multi-Factor Authentication (MFA), Role Based Access Control(RBAC), and the SAP Authorisation Management service. Only authorised users and roles can access each sub-account or application.
Encryption & Transport Security: All user traffic is TLS-encrypted , and SAP exclusively establishes encrypted communication channels by default.
Monitoring & Audit: SAP BTP automatically logs admin and user activities. The Cloud Foundry Audit Log Viewer service lets you review all operations (applications created, users added, etc.), and connect these logs as desired.
Secure Development Tools: SAP’s Cloud Application Programming Model (CAP) and other frameworks include built-in security guards (XSRF tokens, JWT checks, etc.), plus tools like the SAP Code Vulnerability Analyser (CVA) that statically scan ABAP code on SAP BTP before deployment.

However, despite this strong foundation, we often see gaps in how customers configure their environments. The most common issues include:

Bypassing SAP BTP Connectivity Guidelines Customers sometimes integrate third-party APIs or services directly, without using the secure connectivity mechanisms provided by SAP BTP. This can create vulnerabilities and reduce visibility over traffic flows.
Improper Credential Management Instead of using SAP BTP’s built-in credential stores, credentials are sometimes hardcoded or stored in less secure ways, leaving applications open to compromise.
Neglecting Secure App Design Principles Applications are not always developed using the security best practices. This can lead to poor access controls, exposure to common vulnerabilities, or lack of proper authorisation checks.

While SAP BTP provides a secure foundation, maintaining a strong security posture requires careful configuration and adherence to recommended best practices, particularly when it comes to connectivity, credential management, and application architecture.

How to prevent similar attacks when running business-critical workloads on SAP BTP?

To safeguard business-critical workloads on SAP BTP, a few key practices should be followed:

Use SAP Services for All Integrations: Ensure every integration and API call goes through SAP’s connectivity and security layers. Use the SAP Destination Service, API Management, and the Cloud Connector/Connectivity Service, rather than hard‑coding endpoints. This way, TLS is enforced and flows are logged and constrained. (Think of SAP BTP services like a secure gateway that you should not bypass.)
Enforce Multi-Factor Authentication Everywhere: Require MFA for all user logins – not just admins. SAP Cloud Identity Service (or your corporate IdP) can enforce MFA policies on every SAP BTP access. SAP’s TechEd guide even walks through configuring MFA for SAP BTP apps. This means stolen passwords alone won’t give attackers an easy in.
Harden IAM and Accounts: Follow the principle of least privilege. Regularly audit user roles and prune any unused or generic accounts. Disable any unused features like self-registration or social sign-on. Use roles and groups in your Identity Provider (IdP) to ensure people only get the permissions needed for their job.
Monitor and Respond to Logs: Subscribing to the SAP Audit Log Viewer (for Cloud Foundry (CF)) is critical. Review logs periodically for anomalies (e.g. logins from new locations, sudden privilege grants). Configure alerts or integrate these logs into your Security Information & Event Management(SIEM). Quick detection can stop an incident in its tracks.

Even doing just these steps drastically cuts risk. In effect, you’re closing the ‘side doors’: every inbound or outbound connection is tracked by SAP, every user action is logged, and strong authentication blocks the common tricks that took down those retailers.

What role does identity and access management play in defending against modern cyber threats in SAP environments?

Identity and Access Management (IAM) is the keystone of SAP BTP security. SAP BTP supports a full identity lifecycle and fine-grained authorisation model:

Role-Based Access Control (RBAC): You define roles or role collections in your SAP BTP sub-accounts (and business roles in the ABAP environment) that grant only needed permissions. Then you assign these roles to users/groups. This enforces least privilege, so even if a user’s credentials are compromised, the attacker’s access is limited.
Trusted Identity Providers: BTP can federate with SAP Cloud Identity (Identity Authentication Service) or any SAML/OAuth IdP. Once trust is set up, employees authenticate with corporate credentials (with MFA, if you’ve enforced it). This ensures a single point of control over user accounts and policies. IAM integrates with identity providers and defines roles and permissions to secure applications and data.
Principal Propagation: When a user calls between SAP systems (for example, a CF app calling an ABAP endpoint), their identity and roles “travel” with the request. This maintains security boundaries across services.

IAM practices help organisations enforce strict access boundaries, maintain compliance, and defend against unauthorised access—whether from external attackers or internal misconfigurations.

How can organisations balance innovation on SAP BTP with the need for robust security and compliance?

Innovation and security are not opposing forces—they must evolve together. As applications built on SAP BTP grow in complexity, the security measures surrounding them must also mature. The more advanced and interconnected your solutions become, the greater the need for enhanced controls, monitoring, and governance.

Organisations that fail to innovate risk becoming obsolete. But equally, those that innovate without embedding strong security and compliance practices expose themselves to serious vulnerabilities. Every new capability, integration, or user touchpoint introduces potential risks that must be addressed as part of the innovation lifecycle.

Training is also key. Ensure developers and admins know SAP BTP best practices. Ignorance may be bliss, but it also breeds vulnerabilities, since human error is often the weakest link. If all personal interacting with the platform are aware of the threats, they can help mitigate them but also spot them. Make security part of your culture and process – every innovation needs to come with corresponding security guardrails.

Sustainable innovation on SAP BTP requires a security-first mindset—where governance, compliance, and threat prevention are integrated into every phase of development and deployment.

Securing your innovation on SAP BTP

The recent cyber-attacks serve as a stark reminder that even the most well-defended systems are not immune to evolving and opportunistic threats. For organisations leveraging SAP BTP to drive innovation, the message is clear: security must be treated as a continuous discipline, not a one-time checklist.

While SAP BTP provides a strong out-of-the-box security framework, real resilience comes from how that framework is implemented, monitored, and adapted. From enforcing secure connectivity and managing access intelligently, to following coding best practices and monitoring audit logs—every detail matters.

To conclude, the balance between innovation and security is not a compromise; it’s a partnership. With the right governance, identity management, and adherence to best practices, organisations can confidently build and scale on SAP BTP—without sacrificing trust, compliance, or control.

Please feel free to share your experiences and thoughts on the similar approaches you might have taken securing your applications on SAP BTP in the comments section.

What’s New in SAP Cloud Identity Access Governance: Q2 2025

2025-07-08T23:52:00.006000+02:00

Welcome to the Q2 2025 release highlights for SAP Cloud Identity Access Governance (IAG), where we unveil the new features designed to enhance security, streamline access governance, and empower your teams. This quarter’s release brings refined role-based risk controls, seamless system integrations, and powerful in-app analysis tools designed to keep your security posture both robust and agile. Whether you’re aiming to automate provisioning tasks or tighten privileged-access reviews, these updates deliver practical improvements you can implement today. Dive into the details below to see how each enhancement makes your day-to-day access governance faster, smarter, and more reliable.

Mitigation Control Assignment to Business Roles

Mitigation controls can now be assigned directly to Business Roles through the Business Role UI or the Mitigation Assignment application, which includes a new Business Roles–specific category. All assignments are recorded in the audit log, and risk assessments for Business Roles inherit any access-level mitigations.

Secure Storage of Reports on a Customer-Owned Document Server

Analyze User Access downloads can now be directed straight to your organization’s Document Management Service (DMS). Each report is stored in accordance with your retention and classification policies, removing the need for manual file handling and keeping sensitive data securely within your content repository. Keep an eye on the roadmap as this feature will be extended to include other report types in future releases.

Enhanced Access Analysis App

The Access Analysis detail view now includes a built-in smart filter bar for both Access and Risk lists, letting you search, sort, and filter your dataset without ever leaving the interface. This one-pane experience replaces spreadsheet workarounds and speeds up investigations by keeping all controls at your fingertips.

Ariba Integration

Additional Ariba user attributes stored in IdDS are automatically provisioned to newly created Ariba accounts. This capability is available in both standalone Cloud Identity Access Governance and SAP Access Control via Bridge integration for IdDS customers. By sourcing attributes directly from the central IdDS, it eliminates manual updates in Ariba and ensures provisioning remains compliant with corporate standards across systems.

Updated Rulesets for Concur & BTP Financial Applications

This release adds new segregation-of-duties rulesets for Concur (Expense, Invoice, Request), SAP S/4HANA and SuccessFactors core transactions, and BTP’s advanced financial-closing processes, so you can detect and manage cross-system risks with greater precision and enforce compliance consistently across your finance and HR applications.

Forward Privileged Access Review Requests

The forward functionality in the Privileged Access Monitoring Report enables PAM administrators to efficiently reassign log-review requests to additional reviewers without altering the current workflow stage. This feature enhances resource flexibility by allowing easy redistribution of reviewer responsibilities while maintaining the integrity of existing review processes.

Looking Ahead!

With Q2 2025’s release, SAP Cloud Identity Access Governance continues its march toward more intuitive, integrated, and audit-ready access management. These updates deliver targeted improvements that reduce administrative overhead and bolster compliance. Stay tuned for even more innovations next quarter as we refine workflows and expand capabilities based on your feedback.

For more information, to view detailed feature lists, or to get started with SAP Cloud Identity Access Governance, please visit SAP Cloud Identity Access Governance Product Page and Documentation.

What’s Next for SAP Access Control 12.0?

2025-08-11T12:09:08.939000+02:00

What’s Next for SAP Access Control 12.0? This is one of the common questions to most of the Organizations, Leaders, IT Directors, Managers, SMEs, Consultants and Vendors who are currently using IAM solution - SAP Access Control 12.0 on any Data Base (Non-HANA DB or HANA DB).

First let’s explore the possible applicable scenarios of the Organizations who are using SAP GRC Access Control 12.0 solution.

Hub Model on HANA DB: SAP GRC Access Control 12.0 on standalone SAP NetWeaver system on HANA Database, connected side-by-side with SAP S/4HANA, ECC, ECP, SuccessFactors or other ABAP systems.
Hub Model on Non-HANA DB: SAP GRC Access Control 12.0 on standalone SAP NetWeaver system on Oracle, MYSQL or another non-HANA database and connected side-by-side with SAP S/4HANA, ECC, SAP ECP, SuccessFactors or other ABAP systems.
Embedded Model on HANA DB: SAP GRC Access Control 12.0 installed on business systems (SAP S/4HANA or SAP ECC etc.) running on HANA database.
Embedded Model on Non-HANA DB: Embedded Model - SAP GRC Access Control 12.0 installed on business systems (SAP ECC, etc.) running on a non-HANA database.

As SAP continues its strategic pivot toward cloud-first solutions, many Organizations using On-Prem SAP Access Control are asking: What’s next? With SAP Access Control 12.0 nearing the end of its innovation cycle and the emergence of new GRC platforms, it’s time to evaluate the future roadmap and available options.

SAP has announced that it will sunset innovation for GRC 12.0, however SAP Access Control and GRC solutions for SAP are NOT end-of-life! SAP is actively developing a next-generation GRC platform: SAP GRC Edition for SAP HANA, expected in Q1 2026. Along with SAP also has cloud-based product called SAP Cloud Identity Access Governance (IAG).

Also, the existing SAP Access Control 12.0 mainstream support ends by 2027 and extended support ends by 2030.

For more information, refer to SAP Product Availability Matrix

For compatibility of SAP Access Control 12.0 with all the target on-premise SAP Applications, please refer to KBA: 1352498 - Support Pack Numbering - GRC Access Control

Now let’s explore the possible upgrade/migrate/future roadmap options in SAP for existing Organizations who are using SAP Access Control 12.0 solution.

Option 1: Upgrade to SAP GRC for HANA 2026

SAP GRC for HANA 2026 is a new version (not a new product) for any SAP GRC on HANA Organizations. This 2026 release is planned for both on-premises and private cloud deployments. Organizations wanting to stay on-prem or private cloud with long-term GRC needs and have existing /future needs of other SAP GRC modules like SAP Process Control or SAP Risk Management can upgrade to this.

Image Source: SAP

For more information, refer to

SAP GRC for HANA 2026 requires below 2 prerequisites

SAP NetWeaver should be minimum SAP S/4HANA Foundation. S/4HANA Foundation is just an upgraded version for SAP NetWeaver. This is not SAP S/4HANA full version. Organizations who are using SAP Fiori 2.0 would have already migrated their SAP NetWeaver to SAP S/4HANA Foundation. Incase if you are having lower version of GRC Support pack or still on Fiori 1.0 or using SAP NetWeaver as a base component for SAP GRC, then this is a mandatory step. In case for an Embedded GRC model, SAP GRC for HANA 2026 can be installed on S4Core.
Databased as HANA DB: As HANA 2026 only supports SAP HANA DB, Organizations are forced to migrate their Non-HANA Database to HANA DB.

Organizations can choose the “Hub Model” or “Embedded Model” for their SAP GRC for HANA 2026 upgrade/migration. In case if an existing Hub Model setup customer wants to move to Embedded model, it is like a new implementation of SAP GRC for HANA 2026 but can reuse existing GRC design.

How to Migrate to SAP GRC for HANA 2026 from SAP GRC Access Control 12.0?

Once the above prerequisites are complete, SAP Access Control 12.0 can be upgraded to SAP GRC for HANA 2026 release as part of their standard maintenance program, meaning no new SKU or additional purchase is required.

End-of-maintenance (EOM) dates for the 2026 version will be updated to align with HANA EOM dates, extending support until 2040.

Option 2: Migrate to SAP Cloud Identity Access Governance (IAG) – Standard Edition

SAP Cloud Identity Access Governance (IAG), a cloud-based solution designed to manage and govern user access across SAP and non-SAP systems. It's part of SAP’s broader GRC (Governance, Risk, and Compliance) strategy and is hosted on the SAP Business Technology Platform (BTP). It can be considered as cloud Access Control in layman terms. It is best for Cloud-first organizations or those adopting SAP S/4HANA Cloud.

This is ideal for the customer who are looking for a standalone cloud governance solution with full lifecycle capabilities.

In case if an existing SAP GRC Access Control 12.0 customer wants to move to Cloud IAG solution, it is like a new implementation of SAP Cloud IAG with reference to existing GRC design.

With SAP Cloud IAG Standard Edition, customer can integrate to Cloud system like SAP S/4HANA Public cloud, SAP SuccessFactors, SAP Ariba etc.
With Cloud Connector, custom can integrate to On-Prem system like SAP S/4HANA (On-Prem), SAP ECC and other On-Prem systems.

Similar Access Control features, SAP Cloud IAG offers below features:

Access Analysis: Real-time insights into user access to detect violations and risks. This is like Access Risk Analysis (ARA).
Role Design: Create and optimize business roles for cloud and on-premises systems. This is like Business Role Management (BRM)
Access Request: Self-service access provisioning for users across systems. This is like Access Request Management (ARM).
Access Certification: Periodic reviews and certifications of user access. This is like User Access Review (UAR) or other certifications reviews.
Privileged Access Management: Emergency access handling and monitoring for sensitive operations. This is like Emergency Access Management (EAM).

Will be creating a new blog on “SAP Cloud Identity Access Governance (IAG) with different options, Pros and Cons, possible options”, stay tuned for this.

Option 3: Stay on SAP Access Control 12.0 (Short-Term)

Staying on SAP Access Control 12.0 isn’t a long-term strategy, but it’s a valid short-term option for organizations that need more time to prepare. As SAP prepares to sunset support for Access Control 12.0 by December 31, 2027 (extended support runs until 2030), many Organizations are evaluating their next move. While cloud-first strategies and the upcoming SAP GRC Edition for HANA (2026) are gaining momentum, some organizations may choose to stay on Access Control 12.0—at least for now so Organizations can get more time for budgeting, complex landscape planning, or team training.

For organizations with complex landscapes, regulatory constraints, or budgetary limitations, staying on Access Control 12.0 offers a stable, compliant, and familiar environment while they prepare for the future. Meanwhile, Organizations can prepare internal teams for the shift to SAP GRC for HANA or SAP Cloud IAG.

In case if an existing SAP GRC Access Control 12.0 customer wants to connect to Cloud systems using Access Control 12.0, SAP Cloud IAG – Integration Edition can be used,

SAP Cloud IAG – Integration Edition is a specialized deployment model designed to extend SAP Access Control (on-premise) to manage access governance for cloud applications also like SAP S/4HANA Cloud, Ariba, SAP SuccessFactors etc.
It uses the IAG Bridge to connect your existing Access Control system to SAP Cloud IAG, enabling centralized governance across hybrid landscapes.
Like SAP Cloud IAG standard edition, SAP Cloud IAG Integration offers Access Control features, however this has limited features than Standard Edition. For example, PAM and Access Certification features are available with Integration Edition. Use IAG Bridge now, then migrate to unified GRC 2026 platform for future-proofing.

#	Scenario	Recommended Solution	Why It Works
1	Long-term on-prem/private-cloud GRC modernization	SAP GRC for HANA 2026	Unified, AI-powered platform; support to 2040
2	Cloud-first strategy (SAP RISE, SuccessFactors, Ariba, etc.)	SAP Cloud IAG – Standard Edition	End-to-end cloud governance with full lifecycle capabilities
3	Using SAP Access Control 12.0. Hybrid landscape with both cloud and on-premises systems	Short-term: IAG Integration Edition Long-term: GRC for HANA 2026	Leverage current investment, add cloud governance, buy time

Summary

Option 1: Upgrade to SAP GRC for HANA 2026
Ideal for on-premise or private-cloud customers using multiple GRC modules. Also with complex landscape, heavy customization and workflows. Provides a unified, AI-powered platform on SAP HANA with support extended to 2040.
Option 2: Migrate to SAP Cloud Identity Access Governance (IAG)
Suits cloud-first organizations on RISE, S/4HANA Cloud, SuccessFactors, Ariba, or other BTP scenarios. Delivers full lifecycle access governance across SAP and non-SAP systems.
Option 3: Stay on SAP Access Control 12.0 (Short-Term)
Gives organizations extra time for budgeting, complex landscape planning, and team training. Pair Access Control 12.0 with IAG Integration Edition and the IAG Bridge for hybrid visibility.

Conclusion

Choosing the right path from SAP Access Control 12.0 depends on your organization’s strategy, timeline, and risk profile. If you’re committed to on-premise GRC and need long-term stability, upgrading to GRC for HANA 2026 keeps you covered through 2040. For those accelerating cloud adoption, migrating to SAP Cloud IAG delivers a scalable, unified governance experience with less customization options than on-premise. And if you need breathing room to prepare, extending Access Control 12.0 in the short term—combined with IAG Integration—offers continuity without sacrificing compliance.

Whichever route you take, start by mapping your current landscape, aligning stakeholders on priorities, and building a clear project roadmap. Weigh the long-term benefits against immediate constraints to make an informed decision that drives both security and innovation.

What option works best for your organization? Tell us your GRC challenge in the comments. Like this post if it helped and subscribe for more SAP GRC blogs, news, tips!

SAP Access Control SAP Access Control for SAP S/4HANA SAP Cloud Identity Access Governance

SAP Cloud Identity Access Governance: 2506 Adoption Campaign Series – A Reflective Recap

2025-08-19T18:48:08.208000+02:00

Over the past few weeks, we have had the pleasure of connecting with customers through our SAP Cloud Identity Access Governance (IAG) Adoption Campaign Series. These sessions brought together our community to share best practices, explore new capabilities, and maximize the value of IAG in enabling secure, compliant, and efficient access governance.

A Look Back at the Series

Throughout the campaign, we hosted targeted feature adoption sessions and deep dives, designed to equip participants with both strategic insights and practical know-how. These weren’t just presentations; they were conversations, enriched by your questions, feedback, and shared experiences.

Your engagement helped shape the discussions and even influenced future considerations for enhancements, reinforcing the collaborative nature of ourSAP Cloud Identity Access Governance community.

Introduction & Solution Overview (6/18/2025)

We began with a foundational overview of why identity governance remains a critical pillar for today’s enterprises. The session explored SAP Cloud Identity Access Governance’s role in streamlining access management, reducing risk, and supporting compliance through design, automated workflows, and actionable insights.
We showcased a live demo, walked through key workflows, and shared real-world examples of how organizations are using SAP Cloud Identity Access Governance to boost efficiency and security.

Feature Set Adoption: Access Analysis (7/2/2025)

This session highlighted how Access Analysis delivers deep visibility into user permissions, revealing hidden risks and unusual access patterns. Attendees learned how data-driven analysis strengthens risk assessments and guides remediation strategies.
The discussion emphasized how improved visibility leads to proactive governance, allowing organizations to act before risks become incidents.

Feature Set Adoption: Privileged Access Management (7/9/2025)

We explored the importance of centralizing privileged account management to minimize insider threats and maintain compliance. The session demonstrated howSAP Cloud Identity Access Governance unifies privileged access controls without adding complexity, increasing transparency, and enhancing governance over sensitive permissions.

Feature Set Adoption: Access Request (7/16/2025)

This session focused on streamlining approval workflows through Access Request. Attendees saw how automation eliminates bottlenecks, accelerates access provisioning, and boosts productivity while ensuring compliance.
We discussed how efficient request handling directly impacts operational agility and user satisfaction.

Feature Set Adoption: User Certification (7/23/2025)

We examined the importance of User Certification campaigns in maintaining governance, ensuring audit readiness, and building trust within the organization. The session demonstrated how IAG automates and simplifies these campaigns, cutting down on manual effort.

Feature Set Adoption: Business Role Management (7/30/2025)

This session provided best practices for creating and managing business roles that align with organizational needs while reducing permission sprawl. We showcased how IAG’s role-based approach supports scalability and enforces least-privilege principles as the organization evolves.

Integration: Access Control & CIAG Integration (8/6/2025)

We concluded with a deep dive into hybrid governance strategies, demonstrating how SAP Access Control andSAP Cloud Identity Access Governance can work together for consistent policy enforcement across cloud and on-premise environments. The session covered data synchronization, risk sharing, and role management in integrated scenarios, offering a low-disruption pathway to cloud adoption.

Resources

Here are key resources to help you continue exploring and optimizing SAP Cloud Identity Access Governance:

KBA: Complete Q&A from the Adoption Campaign Series
Influence Channel – Submit enhancement ideas and vote on requests from the SAP community
SAP Cloud Identity Access Governance Product Page - High-level overview with features, benefits, pricing, customer stories, and more.
SAP Cloud Identity Access Governance Documentation - Detailed guides on modules, integrations, setup, new updates, and more.

Thank You for Joining Us

We are incredibly grateful to every attendee who participated in this campaign. Your insights and questions were invaluable in making the sessions rich, interactive, and directly relevant to real-world challenges.

This campaign reaffirmed the power of our user community, not just as consumers of technology but as active contributors to shaping its evolution. We look forward to continuing this journey together with more sessions, resources, and opportunities to connect.

🚀 Introducing SCIM API for SAP Sales & Service Cloud v2: Seamless User Sync between Source & Target

2025-08-30T10:53:18.129000+02:00

Note : Please note that the SCIM feature is in General Availability.
https://api.sap.com/package/SAPSalesServiceCloudV2/rest

SAP Sales & Service Cloud v2 now supports SCIM (System for Cross-domain Identity Management) APIs, enabling seamless and secure user provisioning from SAP Identity Authentication Service (IAS) or Customer Identity Directory via SAP Identity Provisioning Service (IPS).

This integration simplifies identity lifecycle management, ensures compliance, and eliminates manual user creation in the target system (SAP Sales & Service Cloud v2).

SCIM API in SAP Sales & Service Cloud v2 is available by default.

SSC v2 SCIM API (Official API Documentation)

### Tenant Details but you need to pass the tenant id in the URL

GET {{SSCv2url}}/scim/v2/Users
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}



PUT {{SSCv2url}}/scim/v2/Users/<id>
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}

<payload of the user>


PATCH {{SSCv2url}}/scim/v2/Users/<id>
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}

<payload of the user>

🚫Important Notes to keep in mind before enabling:

No Manual User Creation Allowed

This ensures that all user data is centrally managed and synchronized, maintaining consistency and reducing the risk of identity mismatches or unauthorized access.

Once SCIM-based provisioning is enabled in SAP Sales & Service Cloud V2:

Manual user creation in SAP Sales & Service Cloud v2 is disabled.

When using IPS (SCIM 2.0 based API), only users of type Employee are provisioned. This version introduces an enhanced SCIM API that no longer requires SAP Cloud Integration. It supports patch operations and provisioning of application-specific groups(Business Roles). In addition to pagination using startIndex and count, cursor-based pagination is also supported.

Why SCIM API Matters

SCIM is an open standard designed to automate the exchange of user identity information between identity providers and service providers. With SCIM support in SAP Sales & Service Cloud v2, organizations can:

Automatically provision and de-provision users
Sync user attributes and roles
Ensure consistent identity governance
Reduce administrative overhead

Benefits of SCIM Integration

Automated User Lifecycle Management
Improved Security & Compliance
Centralized Identity Governance
Reduced Manual Effort
Scalable for Large Enterprises

Integration Flow: SAP IAS or Microsoft Active Directory to SAP Sales & Service Cloud v2

Below is the flow diagram illustrating how users are synced from Microsoft Active Directory or/both SAP Identity Authentication IAS to SAP Sales & Service Cloud v2 using IAS and IPS:

Flow Breakdown:

Microsoft Active Directory (AD): Acts as the source of truth for user identities.
SAP Identity Authentication Service (IAS): Connects to AD via LDAP or Azure AD and serves as the identity provider.
SAP Identity Provisioning Service (IPS): Pulls user data from IAS and pushes it to SAP Sales & Service Cloud v2 using SCIM APIs.
SAP Sales & Service Cloud v2: Receives user data via SCIM and provisions users automatically.

Identity Provisioning (IPS) Documentation - Target System

https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/target-sap-sales-cloud-and-sap-service-cloud

Final Thoughts

The introduction of SCIM API support in SAP Sales & Service Cloud v2 marks a significant step toward modern identity management. By leveraging IAS and IPS, organizations can streamline user provisioning, enhance security, and ensure a consistent user experience across systems.

CREATE AND ASSIGN AUTHORIZATION POLICIES IN IAS

2025-09-17T12:37:51.141000+02:00

Introduction

SAP Identity Authentication Services (IAS) provides secure access management for SAP cloud applications. One of the core features in IAS is Authorization Policies, which allow administrators to control access to applications and resources based on defined rules.

In this blog, we’ll go through the steps to create and assign authorization policies in IAS, ensuring only the right users have the right level of access.

Why Authorization Policies Matter

Control user access based on attributes like group, role, or user ID
Enforce compliance and security requirements
Provide flexibility for hybrid or multi-application scenarios
Simplify administration by centralizing access control in IAS

Please follow the step by step process to create authorization policies in IAS :

HOW THE IAS SUPER ADMIN CAN CREATE AND ASSIGN AUTHORIZATION POLICIES IN IAS

CREATION OF AUTHORIZATION POLICIES

This document tells you how you can assign the authorization policies or give admin access to Granular level to HR managing their own HR Organization and division. This will help to give granular access to HR admin in IAS by creating the authorization policies in IAS so that they can see only the employees belonging to their organization unit and reset the password for them.

We are creating the custom Policies for customers as we have different divisions and organization, and we would like to give access to the HR managers to their respective divisions accordingly.

The screen shots below are for your reference from the test system, and you can use the same step for production as well.

Prerequisite: You have SUPER ADMIN access to IAS tenants in which you are going to create the authorization policy.

IAS Tenants:

For Test: https://XXXXXXX.accounts.ondemand.com/admin/

Give the URL https://XXXXXXX.accounts.ondemand.com/admin/ in the browser and the below window will open.

Give your Email or Username and password to login to IAS an ADMIN and click on continue.

You will see the login screen of IAS as shown below:

Not go to the “Application Resources” and click on the tenant settings :

Here , you can go the policy-based authorization and enabled the option in the right context window.

Now go to the “Application Resources” section and click on the SuccessFactors application.

Click on the applications and it will show you the screen below.
Go the Administration console as shown below under the System Application. You can see below highlighted one:

Now you can see to the right-side pane of the screen with Authorization policies. Click on that and you will see the screen below.

Click on the create button and give a name for which you want to create a new policy. It will ask for the Policy name and the Base Policies. We have given a name as IMAS_AUT_USER as an example to show and giving access to Read the users and update the users’ details in IAS (Identity Authentication services).

Now click on the create button and it will take you to the screen below:

Here click on the + sign and it will take you to the screen below where you can choose the user. Division and assign the division according to the employee export file.

Choose for both the restrictions + Sign and choose user. division for both the places because we would like to give admin access to HR to see and update only the users belonging to those division.

13. Now we need to find the value from the SF export file as attached here to see what the value is coming from the SuccessFactors for the organization/division and use the exact same field value here.

PFA.

Check the column AS and field name custom06 value and use the same value in the above user.division field. In our case we have set up rules for AUT, so we need to filter column06 from the exported file from SF and search for AUT. We go custom06 value as AUT(AUT). This value needs to be updated in the user. Division value . ( Please note you need to fill this custom06 values from Successfactors to each user in IAS by using the source and target transformation) .

Source transformation code :

{

"sourcePath": "$['urn:ietf:params:scim:schemas:extension:successfactors:2.0:User']['customFields'][?(@.customFieldName == 'custom06')]['value']",

"targetPath": "$.custom06",

"optional": true

}

Target transformation code :

{

"sourcePath": "$.custom06",

"optional": true,

"targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['division']"

}

The same value we need to update in the user. Division field as shown below.
At the end you can add the below authorization as well USE schemas.READ_SCIM_SCHEMAS click on ADD USE and select from the dropdown the authorization as USE schemas.READ_SCIM_SCHEMAS. This is also required READ_SCIM_SCHEMAS authorization policies. Otherwise, you won't be able to see and access the Export Users’ title.

Click on confirmation and it will be added.

First click on SAVE and then click on the Assignments tab and add the user you would like to give this authorization.

Assign/click on ADD to add the users whom you want to give granular authorization. Please note that the user should exist in the IAS User directory. Now I am giving access to one user for example Mohana@gmail.com

I can click on add and search the user using the email address and add the user. After that the user is assigned to the new authorization policy and the user can access the employees belongs to AUT organization.

Search for the user whom you want to give access to.

Click on the ADD. The user is added successfully.

The above steps complete the creation of the new Authorization policies and assignment of users.

HOW TO ASSING AUTHORIZATION TO HR ADMIN/ ANY USERS USING THE EXISTING AUTHORIZATION POLICIES

Follow the steps from 1 to 7 and complete the steps as mentioned above. ( The above example shows the process , now you want to assign other users in the same authorization policies)
Now you are in the authorization policies tab, and you need to click on the filter to easily access the custom packages created and choose the one required for you to be updated. Please note that IMSA_AUT_USER is the test Authorization policy. I have created many authorizations policy for each division, that is why you can see many customer packages but here I am assigning the user to only IMSA_AUT_USER authorization policy.

Click on the filter and choose customer packages.

Click ok to see all the customer packages filtered and you can choose the one required for you. I am choosing the IMSA_AUT_USER and would like to assign one existing user.

Now open the customer authorization policies named IMSA_AUT_USER. You can choose the package as per your requirements. I would like to give access to the below user for the authorization policies IMSA_AUT_USER.

You must click on the IMSA_AUT_USER authorization policy as shown in the above step. It will show you the screen below. Go to the assignments tab and assign/add the above user.

Click on the ADD and search for the user with username as BHR.

Now the user has assigned the authorization policies created by you. You can reset the password for this user in IAS and try to login and you will see that this user will be able to see only a few users who are belonging to the division AUT(AUT).

Please note : You must remove the user from Administrator group if it is assigned as an administrator otherwise the Administrator group in IAS under user & Authorizations->administrator will give more permissions to the administrator.

Deprecation of API Basic Authentication & Configuring Open ID Connect

2025-09-18T13:03:24.954000+02:00

Understanding OpenID Connect (OIDC) in SuccessFactors with Identity Authentication Service (IAS)

In SuccessFactors and IAS (Identity Authentication Service), OIDC has replaced the older Basic Authentication model. With Basic Authentication, every API call carried a username and password. It was simple but highly insecure because those credentials could be intercepted or reused indefinitely. OIDC, by contrast, replaces static credentials with short-lived, digitally signed tokens. These tokens, usually in the form of JSON Web Tokens (JWT), are generated by IAS after a proper authentication flow and then used to prove both identity and authorization when calling SuccessFactors APIs.

The way this works is that any application or middleware that needs to call SuccessFactors first registers itself in IAS as a trusted client. IAS then issues that application a client ID and a client secret. When the application needs to call an API, it does not directly pass usernames or passwords. Instead, it requests a token from IAS using its client credentials. IAS verifies this request and returns an access token, and in many cases an ID token as well. The access token is then attached to the API call in the authorization header. SuccessFactors checks the validity of this token against IAS, and if the token is still valid and has the right scope, the API call is processed.

The security advantage here is that the tokens are short-lived, often valid only for minutes or hours. Even if someone managed to intercept them, their usefulness would be very limited. On top of that, IAS can enforce security policies like multifactor authentication, conditional access, or centralized identity checks before it ever issues a token. All of this dramatically reduces the risk of unauthorized access compared to Basic Authentication.

Pre-Requisites For Configuring OIDC

Admin access of Security Centre to configure OIDC Client Application in Manage OIDC OAuth Client Application on SuccessFactors.
Admin access of Identity Authentication Services for configuring OIDC on IAS end in Applications under Applications & Resources.
OIDC must be enabled in IAS tenant and propagated to the SuccessFactors tenant that is linked to IAS, we can verify this by clicking SuccessFactors tenant. The protocol type shall be SAML 2.0 & OpenID Connect and it should display a message above, like in the picture below.

Configuration Steps of Open ID Connect In Identity Authentication Services (IAS):

For the very first step, login to IAS tenant and select Applications under Applications & Resources. Register OIDC Application by selecting Create. Select a display name of application and select OpenID Connect in the protocol type, rest of the selections are optional.
Now go to Provided APIs under Application APIs of recently created OIDC Application and enable the check for Allow all APIs for principal propagation.
Now navigate to Trust>Single Sign-On and under that option access OpenID Connect Configuration.
• Provide Name for a configuration as this is the mandatory field.
• Scroll down to Grant Types and enable the check for Token Exchange (RFC 8693)
• The checked boxes enabled here will be the required attributes during API authentication.
We can further alter the validity of access tokens, refresh tokens and even control the maximum sessions per user from Token Policy (Custom) in OpenID Configuration.
Now under Advanced Settings select JSON Web Token in Access Token Format.
Now navigate to Dependencies under Application APIs. (The dependency name described here will be used later in the API call)
• For Application, select SuccessFactors Tenant and the rest of the configuration will remain the same as below.
Now go to Client Authentication under Application APIs to get the Client ID and Client Secret for using it in API authentication later.
Upon saving a pop-up will appear with a system generated Client ID and Client Secret, copy and save for using it later.
We can also copy our Client ID by scrolling top on the same screen.

Configuration Steps of Open ID Connect In SuccessFactors:

Access Security Centre on SuccessFactors and navigate to Manage OIDC OAuth Client Application.
Register an application in Application Type by entering the name of application.
Now map the newly created application on SuccessFactors with the one configured on Identity Authentication Services by navigating to Application Map screen.
• Click on Register on the top right corner of the screen.
• Provide an Application Map Name.
• Provide a Client ID that we copied in step 6 in IAS.
• Choose an Application Type from dropdown. (It will appear with the same name as we created in Step 2 above in SuccessFactors)
• Click Save.
We have now successfully configured OpenID Connect application on IAS and mapped it to SuccessFactors Tenant. Now we can run our test API through postman (in our case).

Initiating An API Call Using Postman:

Open postman and using POST method paste the below API call.
• https://<<Your IAS Tenant Here>>/oauth2/token
In Header Section add following keys,
• Accept - application/json
• Content-Type - application/x-www-form-urlencoded
In Body Select x-www-form-urlencoded and enter below keys,
• client_id - The one we saved in Step 6 in IAS.
• client_secret - The one we saved in Step 6 in IAS.
• grant_type - password
• username - The admin account of IAS (It should be synced in IAS and login name must be used)
• password - Password of that user account in IAS
Upon clicking Send an Access Token will be generated which will be used to authenticate an another API call. That API call will be used to connect SF.
For the next API call, use the same API as step 1 using POST method with same headers keys but additional keys in Body (Assertion & Resource)
• client_id - Same as step 3 above.
• client_secret - Same as step 3 above.
• grant_type - urn:ietf:params:oauth:grant-type:jwt-bearer
• assertion - the access token that was generated in the previous API call.
• resource - urn:sap:identity:application:provider:name:<<Dependency Name in OIDC Application>>
Upon pressing Send another access token will be generated which will be the final token for fetching results from SuccessFactors through an API.
For the last step, use the GET commamd with your actual API (created through OData dictionary on SuccessFactors) along with Authorization as a Headers key and upon pressing Send API will generate the result.
• Authorization - Bearer <<access token generated in previous step>>
Incase we faced a Invalid Client or Client Locked error during any step in API calls, make sure to check the Client ID status in OIDC Client Authentication under Application APIs in IAS as the client might have been locked due to wrong login attempts through Postman.
Change the status to unlock and attempt API call again.

Ending Note:

With the introduction of multiple access tokens alongside traditional username and password authentication, SAP has significantly strengthened the security framework for API interactions. This enhancement not only adds an extra layer of protection against unauthorized access but also streamlines the user experience for those accessing a wide range of data across systems.

Previously, maintaining secure API access often required manual intervention such as regularly updating passwords for technical users. This process was both time-consuming and prone to errors. Now, SAP’s approach allows for automatic management of token lifecycles, intelligently selecting expiry durations based on system needs and user roles. This reduces administrative overhead and ensures continuous, secure connectivity without disrupting workflows.

By automating token renewal and offering flexible authentication options, SAP has made it easier for developers and integration teams to maintain secure, scalable connections to enterprise data while adhering to modern security standards and compliance requirements.

SAP GRC for SAP HANA - Early Adopter Care Program is Open!

2025-10-02T00:21:59.824000+02:00

Ready to Shape the Future of SAP GRC for SAP HANA?

The Early Adopter Care (EAC) Program for SAP GRC for SAP HANA (GRC 2026) is now open!

This is an opportunity to gain early access to SAP’s latest innovations in governance, risk, and compliance (GRC), which include:

SAP Access Control
SAP Process Control
SAP Risk Management
SAP Audit Management
SAP Business Integrity Screening
SAP Tax Compliance
SAP UI Data Protection Masking
SAP UI Data Protection Logging

As a participant, you’ll be among the first to implement and provide feedback on SAP GRC for SAP HANA before general availability.

This program is run in close collaboration with SAP experts, giving you direct access to development teams and dedicated support as you modernize compliance processes on SAP S/4HANA.

What’s in it for you?

Early access to SAP GRC for SAP HANA innovations
Close collaboration with SAP Development to minimize risks and safeguard projects
Dedicated feedback channel with product experts and project coaches
Visibility into who is adopting the newest GRC capabilities
Opportunity to influence the direction of future releases with your feedback

When is it happening and how to register?

Registration: October 1 - November 15, 2025
Program Start: March 9, 2026

Customers can apply directly on the Influence Platform and become part of a select group helping shape the future of SAP GRC capabilities.

Who should join?

This program is ideal for organizations:

Already running SAP GRC solutions and planning to transition to SAP GRC for SAP HANA
Looking to modernize governance, risk, and compliance processes on SAP S/4HANA

Why it matters

The Early Adopter Care Program is more than an early access, it’s a partnership. By joining, you’ll:

Shape SAP GRC for SAP HANA with your real-world use cases
Gain first-hand support from SAP’s development organization
Establish your organization as a thought leader in modern GRC adoption

Take the next step

Don’t miss the chance to be part of the future of SAP GRC. Join the Early Adopter Care Program today and secure your seat at the forefront of innovation.

Apply now via the Influence Platform.

Streamlining Access Governance or Crave Infotech and SAP Session Overview

2025-10-07T13:23:10.190000+02:00

Why it is important to streamline Access Governance?

SAP ERP is a comprehensive system for managing various business processes. Integrating it with other non-SAP systems can yield significant benefits, such as enhanced user experience, and access to specialized features. This integration creates a more robust and flexible IT landscape, which better supports complex and dynamic business needs by leveraging the strengths of multiple systems.

However, the benefits of a flexible IT landscape require stringent security controls across all systems. It's crucial to conduct detailed risk analyses and implement segregation of duties for roles and authorizations in both SAP and non-SAP systems. This prevents unauthorized access and potential fraud, ensuring that no single individual can complete critical processes or transactions without oversight. This approach helps mitigate risks like unauthorized data modification, financial misstatements, and operational disruptions, ultimately helping enhance overall organizational security and compliance.

What are the possible use cases and benefits for our customers:

1. Identity Management systems

Use Case:

Identity Management and Governance: Identity management systems help manage user identities, access rights, and compliance across multiple systems, including SAP ERP. It provides a centralized view for identity governance and ensures that only authorized users have access to critical business data.

Value:

Enhanced security by managing and governing identities.
Help with regulatory requirements like GDPR, SOX, etc.
Streamlined access management processes, reducing manual errors and increasing efficiency.

2. IT Service Management

Use Case:

IT Service Request and Incident Management: Service Management can handle IT service requests, incidents, and changes, integrating with SAP ERP for tasks like asset management, purchasing, and financial tracking.
Automation Workflows: Automates IT processes that may not be covered by SAP, such as incident management workflows.

Value:

Improved IT service delivery and efficiency.
Enhanced visibility and control over IT operations.
Better integration of IT processes with business processes managed in SAP.

3. Other ERP Systems

Use Case:

Subsidiaries or Specific Departments: Some businesses may use different ERP systems for specific departments, subsidiaries, or geographic regions. This can be due to historical reasons, specialization, or specific functional requirements.
Integration and Data Exchange: Using middleware and integration platforms to sync data between multiple ERP systems.

Value:

Flexibility in meeting diverse business needs.
Ability to leverage best-of-breed solutions for specific areas.

4. Non-SAP HR Systems

Use Case:

Specialized HR Functions: integration with non-SAP HR for event management process. Authorization are in place when changes are needed from HR perspective.
Integration for Employee Data: Syncing HR data with centralized authorization process.

Value:

Enhanced HR capabilities and user experiences.
Better alignment of HR information with user authorizations.

With the value of integration now clear, let's delve deeper into the insights from our webinar, 'Simplifying SAP GRC Access Governance Deployments: Extending IAG Standard and Bridge Edition to Cover the Enterprise'.

Date: September 17, 2025

Key Speakers:

Swetta Singh, Chief Product Expert, Product Management at SAP Governance, Risk & Compliance
Vishal Verma, Global Vice President - AccessHub, Crave Infotech

Session Content

Swetta Singh (SAP)

Overview of Identity and Access Governance Solutions: Swetta provided a comprehensive overview of SAP's identity and access governance solutions, highlighting their capabilities and benefits.
Differences Between Standard and Integration Editions: She explained the distinctions between the standard and integration editions of SAP IAG. This included features, functionalities, and scenarios where each is most beneficial.
Hybrid Landscape: Swetta discussed the implications and differences in moving towards a hybrid landscape. This involved detailing how SAP's solutions can be effectively deployed and managed in both cloud and on-premise environments.

Vishal Verma (Crave Infotech)

Extending SAP Access Governance Solutions to Non-SAP Apps: Vishal introduced four scenarios for extending SAP access governance solutions to non-SAP applications. These scenarios illustrate different integration strategies and use cases.

Four Access Governance Scenarios

Enterprise-wide Access Governance with SAP IAG

Description: Extending SAP's landscape to other applications where AccessHub provides integration and content. This includes seamlessly integrating non-SAP applications into the existing SAP IAG framework for consistent governance.

Enterprise-wide Access Governance with SAP Access Control

Description: AccessHub integrates with SAP Access Control solutions to enable comprehensive governance. This scenario ensures that all access requests and compliance checks are managed centrally through SAP Access Control.

Automate HR-Driven Access Across SAP & Enterprise Apps

Description: AccessHub integrates with HR applications to automate access requests based on HR processes and changes. This includes scenarios where employee access is automatically updated based on HR records.

Embed Access Governance into Workflows

Description: Third-party tools perform the role of a ServiceDesk, and AccessHub connects these tools with provisioning systems like SAP IAG. This integration allows access governance functions to be directly embedded within ServiceDesk workflows.

Conclusion

Vishal concluded the session by highlighting a success story:

70% Reduction in Provisioning Time: At a large utility company, Crave connected Access Hub with SAP Access Control solutions to achieve significant improvements in provisioning time. This setup enabled cross-system risk analysis, streamlined access requests, efficient user access reviews, and robust audit reporting.

Summary

The webinar emphasized the benefits of extending SAP's access governance solutions to non-SAP applications. Real-world success stories were presented to underscore the critical role of seamless integration in delivering comprehensive access governance across the enterprise landscape. The session highlighted the significant improvements in efficiency, compliance, and overall security provided by these integrations.

Follow-Up

If you are interested in reviewing the session, follow these links to access the slides and recording:

Identity Access Governance - Understanding Authorization Policies

2025-11-15T13:02:47.618000+01:00

We have often seen business scenarios where requirement is to restrict the Access/Role search in IAG Access Request to specific list of roles for defined set of users. For e.g. Users in country/company code X should only see the roles for country/company code X in the Access request form to request.

In GRC Access Controls, we achieve this requirement from traditional authorizations/roles concept and role search functionality

IAG offers the concept of defining Authorization Policies to achieve this goal

Overview

Authorization policies determine which roles, applications, or business roles end users can search and request in the Access Request application. Administrators can configure these policies in the Authorization Policy app to control search visibility and request capability

Authorizations for Access Request

When performing a role search in the Access Request app, results may be restricted based on authorization policies. Administrators define which Access objects, Business Roles, or Applications/Systems users can search and request.

Policy Types for Role Search

Access

Action: Request Access
Description: Allows assigned users to request access for all Access items defined by the authorization object attributes.
Authorization Object Attributes:

Name
Application
Application Type
Access Type
Business Process
Business Subprocess

Business Role

Action: Request Access
Description: Allows assigned users to request access for all Business Roles defined by the authorization object attributes.
Authorization Object Attributes:

Name
Business Process
Business Subprocess
Criticality

Application/System

Action: Request Access
Description: Allows assigned users to request access for all Applications/Systems defined by the authorization object attributes.
Authorization Object Attributes:

Application
Application Type

Application - Authorization Policy under Administration section

Flowchart

Policy Set - Container of multiple policies of a specific Policy type (for e,g, Access/Access Risk/Business Role etc.). Users are assigned to Policy sets based on User attributes.
Policies - Policies are maintained within policy set and can be activated/deactivated based on need. Each policy contains Authorizations which further contains
1. "Actions" (for e,g, Request Access in policy set type Access and Business Role)
2. "Access/Business Roles" based on attributes.

Screenshots

Authorization Policy App

Creation of Policy Set

Creation of Policy

Configuration of Authorizations and Access/Business role based on attributes

Defining Access

Defining Users based on attributes

Conclusion

Once policy is activated, Access and Business roles will be filtered based on defined authorization policies.

Standard SAP documentation - Authorization Policies in Identity Access Governance

SAP Cloud Identity Access Governance License Counting Logic

2025-11-18T18:10:08.301000+01:00

For Expired Users in SAP ERP, understand it should not counted for IAG licenses, correct? When a SAP S4 User is deemed to be expired, will IAG automatically stop monitoring? Thanks.

SAP User Access Management in a Hybrid Landscape – Architecture and Key Concepts (Part 1)

2025-12-22T18:05:01.288000+01:00

This blog is Part 1 of a 3-part series on SAP User Access Management in a Hybrid Landscape.

• Part 1 – Architecture and Key Concepts (this post)
• Part 2 – Business Roles and Provisioning Models
• Part 3 – SAP IAG Two-Tenant Model: Challenges and Mitigation Strategies

Purpose

As organizations continue to adopt SAP cloud solutions, hybrid SAP landscapes—combining SAP S/4HANA in on-premise or private cloud environments with SAP SaaS applications and SAP BTP—have become increasingly common. While this model enables flexibility and innovation, it also introduces new challenges in managing user access consistently across systems.

This blog focuses on the architecture and key concepts behind managing user access in a hybrid SAP landscape using SAP GRC Access Control and SAP Identity and Access Governance (IAG) via the IAG Access Control Bridge. It outlines how these components work together with SAP Cloud Identity Services to provide centralized governance, controlled provisioning, and audit-ready access management across both on-premise and cloud applications.

Rather than providing step-by-step configuration instructions, this blog shares practical architectural guidance and implementation insights based on real-world project experience, complementing SAP’s official documentation and helping practitioners understand how to design an effective hybrid access management framework.

Scope and Landscape Overview

The scope of this blog is to outline an integrated user access management approach for a hybrid SAP landscape, covering both on-premise/private cloud ERP systems and SAP public cloud and SaaS applications.

In-Scope Systems

SAP S/4HANA (On-Premise or RISE Private Cloud)
SAP GRC Access Control 12
SAP Cloud Identity Access Governance – Integration Edition (IAG AC Bridge)
SAP Cloud Identity Services (IAS & IPS)
SAP Cloud Connector
SAP SaaS Applications
SAP BTP Applications

Target Architecture

High-Level Architecture Overview

The target architecture defines the end-to-end user access governance and provisioning model for a hybrid SAP landscape. This model integrates on-premise and private cloud SAP systems with SAP Public Cloud and SaaS applications, ensuring cohesive and centralized oversight. The solution leverages several key SAP technologies—SAP GRC Access Control, SAP Identity and Access Governance (IAG – Integration Edition), SAP Cloud Identity Services, and SAP Cloud Connector—to deliver consistent approval workflows, centralized governance, and automated provisioning across the entire SAP environment.

The following diagram illustrates the reference architecture for SAP user access management in a hybrid landscape, highlighting the interaction between SAP GRC Access Control, SAP IAG AC Bridge, SAP Cloud Identity Services, and SAP SaaS applications.

SAP GRC Access Control: Central Governance for Hybrid SAP Landscapes

Overview

SAP GRC Access Control operates as the primary governance and control layer for user access management across the hybrid SAP landscape. It provides a unified framework supporting both on-premise/private cloud and public cloud SAP applications, enabling organizations to maintain comprehensive oversight and streamlined processes for provisioning and managing user access.

Key Functional Capabilities

Access Request Management (ARM): Provides a centralized platform for intake and processing of access requests. Structured approval workflows ensure that every request is systematically reviewed and authorized according to organizational policies.
Access Risk Analysis: Performs real-time Segregation of Duties (SoD) analysis for on-premise systems and supported cloud environments, enabling proactive identification and mitigation of user access risks.
Business Role Management: Facilitates the design, maintenance, and lifecycle management of business roles, supporting the evolving access requirements of the organization.

Integration with On-Premise and Private Cloud SAP Systems

SAP GRC Access Control is directly integrated with core on-premise and private cloud SAP systems, such as SAP S/4HANA, SAP MDG, and SAP BW/4HANA. This integration is achieved through RFC-based communication, enabling essential functions including user provisioning and management, risk analysis and reporting, and business role management. All provisioning and governance activities for these systems are managed from SAP GRC Access Control, ensuring thorough audit traceability and alignment with internal control requirements.

Cloud Integration via SAP Cloud Connector and SAP IAG

The SAP Cloud Connector establishes a secure communication channel between the SAP cloud environment and the on-premise SAP landscape. Within the architecture, the SAP IAG subaccount on the Cloud Connector serves as an integration bridge, connecting SAP GRC Access Control with SAP Cloud Identity and Access Governance (IAG). This configuration enables cloud-to-on-premise RFC communication with GRC Access Control, supports SoD authorization checks, and allows approved access requests in GRC to be extended to SAP SaaS applications. This approach ensures organizations can apply their established GRC processes consistently across both on-premise and cloud environments.

SAP Cloud Identity and Access Governance (IAG) Integration for SAP SaaS Applications

Integration with SAP SaaS applications is facilitated through SAP Cloud Identity and Access Governance (IAG), which operates on the SAP Business Technology Platform (BTP). For clarity and security, IAG is deployed in a dedicated BTP subaccount, using the integration edition known as the IAG AC Bridge. Within this subaccount, a destination is configured to connect SAP GRC Access Control to the SAP Cloud environment via the Cloud Connector, ensuring secure and efficient access management. The IAG application is accessed through a dedicated URL, allowing administrators to manage configurations as required.

During the initial setup of IAG, administrators create an application entry for each SAP SaaS application that will be managed. This ensures that every application is properly integrated and governed within the overall access management framework. IAG utilizes SAP Cloud Identity Services for user provisioning, leveraging the Identity Provisioning Service to automate and monitor user access. For SaaS applications supporting direct provisioning through SCIM, a proxy system is configured for each application in Identity Provisioning, enabling secure and seamless user provisioning across the SAP SaaS ecosystem.

Summary and Next Steps

This first part of the series establishes the architectural foundation for SAP user access management in a hybrid landscape. By combining SAP GRC Access Control with SAP IAG AC Bridge and SAP Cloud Identity Services, organizations can extend centralized governance into SAP cloud applications while maintaining strong security and compliance controls.

In Part 2, we will focus on GRC Business Roles and provisioning models, including direct and federated access patterns across SAP S/4HANA and SAP SaaS applications.

SAP User Access Management in a Hybrid Landscape – Business Roles and Provisioning Models (Part 2)

2025-12-22T18:06:45.115000+01:00

Introduction

In Part 1 of this series, we explored the reference architecture for managing user access in a hybrid SAP landscape using SAP GRC Access Control, SAP Identity and Access Governance (IAG) via the IAG AC Bridge, and SAP Cloud Identity Services.

With the architectural foundation in place, this second part shifts focus to how access is actually designed and provisioned across on-premise and SAP cloud applications. In particular, it highlights the role of GRC Business Roles and explains the different provisioning models used for SAP S/4HANA and SAP SaaS applications.

Understanding these concepts is essential for building scalable, auditable, and maintainable access management processes in hybrid SAP environments.

Access Control: Business Role Management

Overview of GRC Business Roles

In SAP GRC, a Business Role comprises a set of access rights, permissions, and authorizations that can be assigned to multiple users who perform similar functions. Unlike traditional technical roles, Business Roles are designed to be system-independent, allowing organizations to streamline access management across various SAP applications. In a typical SAP Greenfield implementation, these Business Roles are crafted to reflect users' job functions or positions, ensuring both consistency and security for access to on-premise and cloud-based SAP solutions such as SAP S/4HANA, SAP Ariba, and SAP Sales Cloud.

Significance of GRC Business Roles in a Hybrid Landscape

The adoption of GRC Business Roles is especially crucial in a hybrid SAP landscape that encompasses both on-premise and cloud applications. By centralizing access provisioning and abstracting user permissions from the underlying technical roles, GRC Business Roles provide a unified structure for user access management. This approach ensures that users have consistent and appropriate access regardless of whether their work takes place in S/4HANA, Ariba, Sales Cloud, or a combination of these platforms. As organizations transition toward hybrid and cloud-centric architectures, GRC Business Roles facilitate secure, scalable, and efficient user access management—reducing complexity for administrators and minimizing risk by aligning permissions with business needs. This unified approach directly supports the document’s objectives of robust SAP User Access Management and governance across disparate systems.

Structure of GRC Business Roles

A GRC Business Role aggregates one or more technical roles from different systems into a single logical unit, simplifying the assignment process and ensuring users have access to the necessary tools and applications for their roles. Each Business Role consists of Technical Roles specific to individual applications or systems. These Technical Roles grant permissions for distinct modules or applications (e.g., "Accounts Payable Manager" in S/4HANA or "Requestor" in Ariba). GRC Business Roles are mapped to Technical Roles spanning multiple systems, such as:

SAP S/4HANA: Business process roles (e.g., Accounts Payable Manager, Maintenance Technician).
SAP Ariba: Groups or functional roles (e.g., Procurement Manager, Requestor).
SAP Sales Cloud: Sales-related roles (e.g., Sales Manager, Operations

Key Benefits of GRC Business Roles in Project Implementation

Unified access provisioning across SAP S/4HANA and SAP SaaS applications, reducing complexity.
Consistent access mapping aligned with Segregation of Duties (SoD) requirements and regulatory compliance.
Centralized role definition and assignment in GRC simplifies access management for administrators.
Automatic updates to technical roles when business roles change, ensuring accuracy.
Comprehensive access provisioning for users' job functions across multiple systems via a single Business Role.

Business Role Design Approach

The design of GRC Business Roles follows a structured process to ensure alignment with organizational job roles and access requirements:

Technical Role Design

The Security Team develops Technical Roles for each application, guided by detailed access requirements from:
- Process Design Documents: Identify transactions, applications, and authorizations required for each business process.
- User Stories: Outline access needs based on end-user roles and responsibilities.
- Workshops and Discussions: Collaborate with process teams to specify operational transactions and applications for each role.

Alignment with Organizational Job Roles

GRC Business Roles are structured according to users’ jobs and responsibilities as defined by the Organizational Change Management (OCM) Team.
User job roles are defined based on L3 Processes, representing detailed activities within each business process.
L3 Processes linked to each job role are reviewed to determine the necessary technical roles and access rights.
The Security Team creates GRC Business Roles based on these definitions, consolidating required technical roles across applications to ensure consistent and accurate access provisioning.

Detailed Provisioning Flows by Application Type

This section will provide an overview of the provisioning workflows for various applications within a hybrid environment.

SAP S/4HANA (On-Premise / Private Cloud)

Provisioning for SAP S/4HANA, whether deployed on-premise or in a private cloud environment, is facilitated through SAP GRC Access Control. The process is initiated when a user submits an access request using the GRC Access Request Management (ARM) module. Once the access request is submitted, it progresses through an approval workflow. This workflow typically involves the user's manager, the role owner, or the security team, depending on the organization's structure and policies.

During the approval process, a Segregation of Duties (SoD) risk analysis is conducted within GRC. This analysis ensures compliance with internal control requirements and helps minimize potential risks associated with conflicting access privileges. Upon successful approval, SAP GRC automatically assigns the designated roles directly to the S/4HANA system. The user's master record is subsequently updated through standard SAP connectors, enabling seamless integration and ensuring the accuracy of user data.

All audit logs generated during these provisioning activities are maintained within GRC. This comprehensive logging supports compliance requirements and enhances traceability. Notable characteristics of this provisioning flow include real-time SoD checks and immediate role assignment.

Direct Provisioning to SAP SaaS Applications (Ariba, SuccessFactors, SAC) via SCIM API

Provisioning for SAP SaaS applications that support the SCIM API, including Ariba, SuccessFactors, and SAP Analytics Cloud (SAC), is managed through SAP IAG leveraging the Identity Provisioning Service (IPS). The access request process is initiated using GRC Access Request, and the subsequent approval workflow follows a structure similar to the S/4HANA scenario. Once the access request is approved, GRC communicates the request to IAG using the Access Control Bridge (AC Bridge).

A scheduled provisioning job then runs at regular intervals to grant the requested access directly within the relevant SaaS applications. This automated process helps streamline user access management for cloud-based SAP solutions and ensures timely provisioning of roles.

Indirect Provisioning to SAP SaaS Applications (FSM, BTP)

For applications such as SAP Business Technology Platform (BTP) or Field Service Management (FSM), provisioning is managed by SAP IAG through the assignment of IAS Groups associated with these applications. Users submit access requests for specific IAS Groups, and these requests are routed through the required approval workflow. Upon approval, SAP IAG provisions the relevant IAS groups to the users.

For BTP, the IAS groups that are set up are linked to BTP role collections. When users next log in, they receive access to these specific collections. For applications such as FSM, which can interpret the assigned FSM IAS groups and map them to user policy groups within a company’s FSM environment, a scheduled read job on IPS will assign the appropriate user policy group and company automatically.

Please note: While Field Service Management (FSM) may not be explicitly included under an integration scenario for IAG, it is identified as both a source and target system within Identity Provisioning. Consequently, it is appropriate to utilize a combination of provisioning processes in order to provision end user access to FSM in such circumstances.

Summary and What’s Next

In this part of the series, we explored how GRC Business Roles and provisioning models enable scalable and controlled user access across hybrid SAP landscapes. By abstracting technical roles into business-aligned constructs and leveraging both direct and federated provisioning models, organizations can maintain strong governance while supporting diverse SAP applications.

In Part 3, we will focus on the SAP IAG two-tenant model, examining why it presents challenges in real-world implementations and how project teams can mitigate associated risks.

SAP User Access Management in a Hybrid Landscape – Challenges and Mitigation Strategies (Part 3)

2025-12-22T18:08:07.815000+01:00

Introduction

In the first two parts of this series, we covered the architecture and execution model for managing user access in hybrid SAP landscapes using SAP GRC Access Control and SAP Identity and Access Governance (IAG) via the IAG Access Control Bridge.

In this final part, we focus on a topic that frequently surfaces during implementations but is often underestimated during planning—the SAP IAG tenant model. Specifically, we examine why the standard two-tenant model introduces challenges when integrated with a typical three-tier SAP GRC Access Control landscape, and how project teams can mitigate these challenges in practice.

Challenges and Considerations with the SAP IAG Two-Tenant Model

Overview of SAP IAG Tenant Mapping

SAP Identity and Access Governance (IAG) enforces a strict tenant-to-system mapping model when integrated with SAP GRC Access Control through the IAG AC Bridge. According to SAP Note 3389374, only one SAP Access Control system can be mapped to one IAG tenant. SAP advises against connecting multiple Access Control systems to the same IAG tenant to avoid potential data inconsistencies. The guidance further highlights that after an Access Control system has been connected and data synchronized with an IAG tenant, no other Access Control system should be connected to that tenant, even if the previous system has been disconnected. SAP explicitly states that they may not take responsibility for any resulting data inconsistencies. Therefore, the number of IAG tenants should align with the number of Access Control systems.

Typical Landscape Mismatch

In practice, most SAP customers operate a three-tier SAP GRC Access Control landscape, consisting of Development (DEV), Quality/Test (QAS), and Production (PRD) systems. However, SAP typically provisions only two IAG tenants per customer: one for Test and one for Production. This two-tenant limit also applies to several SAP SaaS solutions, such as Ariba, Fieldglass, and FSM, as well as SAP Cloud Identity Services. This creates a structural mismatch between the number of SAP Access Control systems and the available IAG tenants.

Figure: Typical mismatch between SAP GRC Access Control landscapes and IAG tenant availability

Challenges During Project Implementation

Note: While this discussion refers to the SAP GRC Access Control system, it is important to note that in most Greenfield implementations today, GRC Access Control is deployed as an embedded component within the SAP S/4HANA system. The overall three-to-six-month implementation timeline in the development system typically reflects the broader S/4HANA program, encompassing multiple business processes, and not GRC in isolation.

During project implementations, especially in Greenfield scenarios, the SAP GRC Access Control Development system is usually implemented first and is available early in the project lifecycle. At this stage, configuration and development activities take place in the DEV system, and the Realize and Build phases can extend over three to six months. Early integration of the IAG AC Bridge is often required to support access request testing, role design validation, and initial cloud provisioning scenarios. However, the Quality (QAS) Access Control system—which ideally should connect to the IAG test tenant—may not be available until just before formal testing begins.

This situation presents a dilemma. While SAP recommends a one-to-one mapping between Access Control systems and IAG tenants, most customers do not have more than the standard two IAG tenants. Procuring an additional IAG tenant is often cost-prohibitive, not planned in the initial contract, and operationally challenging.

Practical Implications for IAG AC Bridge Setup

With only two IAG tenants, setting up the IAG AC Bridge can be particularly complex when the GRC QAS system is not yet available, but integration testing needs to start during the development phase. Early validation of cloud provisioning scenarios is also impacted. As a result, project teams are often forced to make architectural and sequencing decisions that are not directly addressed in SAP's official documentation.

Recommended Mitigation Approach

Early Availability of GRC QAS: If possible, teams should bring up the GRC Quality system earlier than originally planned, aligning its availability with the IAG Test tenant timeline. This enables completion of IAG AC Bridge integration in a supported manner, provides sufficient time for end-to-end testing without rework, and reduces last-minute risks during formal testing.
Adequate Time for Production Deployment: When deploying the integration in Production, ample lead time should be allowed. It should not be assumed that configurations can be transported end-to-end. Approximately 60% of the IAG AC Bridge integration steps performed in Test must be repeated manually in Production, as these steps are tenant-specific, involve cloud-side configurations, and cannot be transported using SAP CTS.

Disconnecting and Reconnecting Access Control Systems

Although SAP does not recommend disconnecting an Access Control system from an IAG tenant to connect a new one, in some controlled project scenarios, teams have executed this approach without observing significant functional or data consistency issues, provided strict procedural discipline was followed. However, this approach should be clearly documented, approved by the customer, and understood as a pragmatic workaround rather than an SAP-endorsed best practice.

Additional Functional Considerations in IAG AC Bridge Scenarios

User Access Review

User Access Reviews can continue to be performed within Access Control, following the established process. Upon completion of the review, a provisioning or deprovisioning request is automatically generated in IAG for the corresponding SaaS application related to the review request. For S/4HANA roles, these are removed automatically once the review request is submitted.

SOD Review Process

The SOD (Segregation of Duties) Review Process is not supported within the GRC IAG AC Bridge environment.

Workflow Limitations in GRC

Function, Risk, and Mitigating Control workflows are no longer available in GRC, as ruleset maintenance must now be conducted within IAG.

Mitigating Controls Monitoring

Mitigating controls monitoring can be performed within IAG. Additionally, test results for these controls can be uploaded directly to IAG.

User and Role Simulation

User and role level simulations for S/4HANA risks are not supported in IAG but may still be carried out in GRC AC. If simulations are performed, customers should validate this approach with SAP and ensure alignment with supported usage scenarios.

Conclusion

Across this three-part series, we explored how SAP user access management can be effectively designed and implemented in modern hybrid SAP landscapes.

Part 1 established the architectural foundation, explaining how SAP GRC Access Control, SAP Identity and Access Governance (IAG), and SAP Cloud Identity Services work together to extend centralized governance into SAP cloud applications.
Part 2 focused on execution, highlighting the importance of GRC Business Roles and outlining direct and federated provisioning models across SAP S/4HANA and SAP SaaS applications.
Part 3 examined the practical challenges introduced by the SAP IAG tenant model and shared mitigation strategies based on real-world implementation experience.

Together, these perspectives demonstrate that while SAP provides a robust framework for hybrid access management, successful implementations require early planning, architectural clarity, and pragmatic decision-making—particularly when navigating tenant constraints and project timelines.

By combining strong role design, well-defined provisioning models, and a clear understanding of platform limitations, organizations can achieve secure, scalable, and auditable user access management across both on-premise and cloud SAP environments.

Push UUID from IAS to S4HANA - Tasks list on BTP task Center is empty for S4HANA

2026-01-01T05:41:20.344000+01:00

Introduction:

After completing all prerequisites and following the SAP documentation to configure the Task Center for an SAP S/4HANA system, it is quite common to encounter a situation where no tasks are displayed in the Task Center—even though task creation appears to be working correctly in the backend.

This blog addresses one of the most frequently overlooked root causes behind this issue: the absence of a Global User ID (UUID) in the SAP S/4HANA system. Even when the Task Center is correctly configured on SAP BTP and tasks are visible in the pull cache, missing UUID mapping can prevent the Task Center from resolving the processor correctly, resulting in an empty Task Center UI.

In this blog, I will walk you through a critical but often missed step required to ensure tasks are displayed correctly in the Task Center. The focus is on establishing a one-way synchronization from SAP Identity Authentication Service (IAS) to SAP S/4HANA to push the UUIDs for existing users, without performing a full user provisioning or re-synchronization.

Solution:

Even after configuring the Task Center on HANA on-premise and completing all required steps on BTP, the Task Center may appear empty, as shown in the screenshot below.

When you check the Task Center pull cache, you can see that the task exists; however, it is still not displayed in the Task Center app. As shown in the screenshot below, the task appears with the processor name set to the SAP user ID. This situation occurs when a GUID (UUID) is not available in the SAP HANA system. In such cases, the system falls back to using the SAP user ID instead of the UUID. As a result, the Task Center is unable to correctly resolve the processor, and the task is not displayed in the Task Center app.

To resolve this issue, we need to ensure that a UUID is available in the SAP system. The steps to achieve this are explained below. Before updating the UUID in the SAP HANA system, the user profile in the SU01 screen appears as shown in the screenshot below.
SU01-->Goto-->External User ID(UID)

Please note that in this scenario, we are not synchronizing SAP users to IAS and then syncing the UUID back to the HANA system. Since the UUIDs and users already exist in IAS as a result of the SuccessFactors integration, we will establish a one-way synchronization from IAS to SAP S/4HANA solely to push the UUID into the system

To push the UUID (Global User ID) to SAP system please follow below steps.

Prerequisite:
1. Login to your Cloud Connector: Make sure your Cloud connectors connection from BTP to HANA has access to below BAPI/FM

PRGN_ROLE_GETLIST
BAPI_USER_GETLIST
BAPI_USER_GET_DETAIL
BAPI_USER_CREATE1
BAPI_USER_ACTGROUPS_ASSIGN
IDENTITY_MODIFY
BAPI_USER_DELETE
PRGN_ACTIVITY_GROUPS_LOAD_RFC

2. Create a technical user in SAP HANA, or reuse an existing technical user that is used to pull tasks for the Task Center. Ensure that this user is assigned the required role listed below. This technical user will be used to create the RFC destination in the BTP subaccount, which will later be used to create the target system in IAS

SAP_BC_JSF_COMMUNICATION

3. Create a RFC destination on the BTP account where your IAS is hosted by referring to below SAP guide.
https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/create-rfc-destinations

Note: If you prefer to create the RFC destination in a different subaccount - perhaps within the same sub account as SAP Work Zone or the Task Center- ensure that you create an Identity Access Management (IAM) service instance in that subaccount. This is required so that the RFC destination you create is visible in the IAS administration console.

After completing the prerequisites, log in to IAS and create the source and destination systems to perform the push.

Creating Source system: Because the users are already available in IAS, select Local Identity Directory as the source system.
Creating the Source system is straightforward.

{
    "user": {
        "mappings": [
            {
                "sourcePath": "$.id",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']['userId']",
                "targetVariable": "entityIdSourceSystem"
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']"
            },
            {
                "sourcePath": "$.schemas",
                "targetPath": "$.schemas",
                "preserveArrayWithSingleElement": true
            },
            {
                "sourcePath": "$.userName",
                "targetPath": "$.userName",
                "optional": true,
                "correlationAttribute": true
            },
            {
                "sourcePath": "$.displayName",
                "targetPath": "$.displayName",
                "optional": true
            },
            {
                "sourcePath": "$.groups",
                "targetPath": "$.groups",
                "optional": true,
                "preserveArrayWithSingleElement": true
            },
            {
                "sourcePath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystem']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystem']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystemId']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystemId']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userId']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userId']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']",
                "optional": true
            }
        ]
    },
    "group": {
        "ignore": true,
        "mappings": [
            {
                "sourcePath": "$.id",
                "targetVariable": "entityIdSourceSystem",
                "correlationAttribute": true
            },
            {
                "sourcePath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:Group']['name']",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:Group']['name']"
            },
            {
                "sourcePath": "$.displayName",
                "targetPath": "$.displayName"
            },
            {
                "sourcePath": "$.members",
                "targetPath": "$.members",
                "optional": true,
                "preserveArrayWithSingleElement": true
            }
        ]
    }
}

Create Target system: Here our target is SAP HANA. below refer below screenshots and code snippet to create the same. here the target system type is SAP Application Server ABAP. and please select the destination which you created in prerequisite step 3.
Make sure you skip operations for delete and create as we trying to do update only and you can also update the alias(email), groups roles to S4HANA along with UUID but here i am only focusing on UUID.

{
    "user": {
        "skipOperations": [
            "create",
            "delete"
        ],
        "mappings": [
            {
                "sourceVariable": "entityIdTargetSystem",
                "targetPath": "$.USERNAME"
            },
            {
                "sourcePath": "$.userName",
                "targetPath": "$.USERNAME"
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']",
                "targetPath": "$.SAPUSER_UUID.SAP_UID"
            },
            {
                "constant": "updateEntity",
                "targetVariable": "operationTypeVariable"
            },
            {
                "constant": "createEntity",
                "targetVariable": "operationTypeVariable",
                "scope": "createEntity"
            },
            {
                "condition": "$.active == false && '${operationTypeVariable}' == 'createEntity'",
                "constant": "X",
                "targetPath": "$.LOCK_LOCALLY"
            },
            {
                "condition": "'${operationTypeVariable}' == 'updateEntity'",
                "constant": "U",
                "targetPath": "$.LOCK"
            },
            {
                "condition": "$.active == false && '${operationTypeVariable}' == 'updateEntity'",
                "constant": "L",
                "targetPath": "$.LOCK"
            }
        ]
    }
}

Once the source and target systems are created, open the source system and perform a test run for a single user to ensure that everything is working correctly. After successful validation, you can remove the user filter and perform a mass update for all users in the system.

Once the update is completed you will be able to see UUID in SU01 user profile as below.

Also, The Task Center pull cache will have UUID for the processor field instead of the SAP user name and Tasks will be shown in the Task center as below.

Conclusion:

An empty Task Center—despite correct backend task creation and successful pull cache entries—can be misleading and time-consuming to troubleshoot. As demonstrated in this blog, the root cause is often the absence of a UUID in the SAP S/4HANA user master, which prevents the Task Center from resolving the task processor correctly.

By ensuring that the Global User ID (UUID) is pushed from IAS to SAP S/4HANA through a one-way synchronization, this issue can be resolved effectively without impacting existing user provisioning or SuccessFactors integrations. Once the UUID is updated in the SU01 user profile, the Task Center pull cache correctly reflects the UUID, and tasks become visible in the Task Center application as expected.

I hope this blog helps you avoid common pitfalls during Task Center setup and saves valuable troubleshooting time. Feel free to share your feedback or experiences, and happy learning!

Thanks and Regards,
Navyashree

Understanding GOS Attachments and Their Backend Tables in SAP ABAP

2026-01-11T23:43:57.119000+01:00

Introduction

Generic Object Services (GOS) play a crucial role in SAP by allowing users to attach documents, notes, and URLs to business objects such as Purchase Orders, Accounting Documents, Materials, and Customer Masters.
For ABAP developers and functional consultants, understanding how these attachments are stored and retrieved at the database level is essential for reporting, audits, migrations, and enhancements.

This article explains the core tables, object relationships, and practical ABAP insights related to GOS attachments.

What Are GOS Attachments?

GOS (Generic Object Services) enables users to:

Attach files (PDF, Excel, etc.)
Create notes
Link external documents

These attachments are visible via Services for Object in SAP GUI transactions like:

ME23N (Purchase Order)
FB03 (Accounting Document)
MM03 (Material Master)

Key Tables Used for GOS Attachments

1. SRGBTBREL – Relationship Table

This is the most important table for GOS.

Stores the relationship between:
- Business Object (e.g., BUS2012, BKPF, KNA1)
- Attachment or note
Common fields:
- TYPEID_A – Business object type
- INSTID_A – Object key (e.g., PO number, document number)
- RELTYPE – ATTA (Attachment), NOTE, URL

✅ Used to check whether an attachment exists.

2. SOOD / SOFM / SOC3 (SAPoffice Documents)

Stores SAPoffice document metadata and content
Often used when attachments are created as SAPoffice objects
Can be read using:
- SO_OBJECT_READ
- SO_DOCUMENT_READ_API1

3. DRAD (DMS-Based Attachments)

If attachments are stored using Document Management System (DMS):

Table: DRAD
Object key may contain:
- Material Number
- Equipment
- Other master data keys

How to Identify Attachments for a Business Object

Example: Purchase Order (ME23N)

Business Object: BUS2012
Table: SRGBTBREL
Filter:
- TYPEID_A = 'BUS2012'
- INSTID_A = <PO Number>

If an entry exists → attachment is present.

Common Use Cases

Audit reports to find documents without attachments
Mass download of attachments
Migration from Content Server / FileNet / SharePoint
Custom reports showing attachment count
Enhancing attachment list display

Important Notes

There is no direct T-code to attachment mapping
Attachments are linked to Business Objects, not transactions
Same attachment can be visible in multiple transactions

Conclusion

Understanding GOS attachment architecture helps SAP professionals build robust reports, support audits, and design scalable document solutions.
Tables like SRGBTBREL, SOOD, and DRAD are essential tools in every ABAP developer’s toolkit.

If you frequently work with attachments, mastering these relationships will save significant time and effort.

Configure Role Owner Stage Auto Approval in SAP IAG

2026-01-23T06:15:25.857000+01:00

Introduction

This blog explains how to configure Role Owner Stage Auto Approval in IAG. focusing on setting up the required data objects, business rules, and workflow configuration to automate approvals.

Step 1: Create Data Object

Create a data object called RoleOwnerAttributes. This object holds the input values used to determine whether the Role Owner stage should be automatically approved.

Add the following attributes to the data object:

roleName (String)
roleCriticality (String)
roleApprover (String)
roleBusinessProcess (String)
roleSubprocess (String)
roleRiskCount (Number)

Step 2: Create another Data Object

Create another data object called AutoApproveRoleOwnerStage. This object stores the output of the rule.

Add the following attributes to the data object:

roleName (String)
roleOwnerAutoStage (Boolean)

Step 3: Create Local Rule
Create a local rule called RoleOwnerStageAutoRule

decision table settings:

Use the fields from RoleOwnerAttributes (Step 1) as the conditions.
Use AutoApproveRoleOwnerStage (Step 2) as the result.

Result Attributes:

Role Owner Auto Stage → Access: Editable
Role Name → Access: Hidden
Set the hardcoded value as the roleName from RoleOwnerAttributes.

In this scenario, the condition is defined based on the Role Name.

Step 4: Create Rule Set

Create a rule set called RoleOwnerRuleSet and add the local rule RoleOwnerStageAutoRule (from Step 3) to it.

Step 5: Create Rule Service

Create a rule service called AutoApproveRoleOwnerStage.

Input → RoleOwnerAttributes (from Step 1)
Result → AutoApproveRoleOwnerStage (from Step 2)

Step 6: Assign Rule Service

Assign the rule service AutoApproveRoleOwnerStage (from Step 5) to the rule set RoleOwnerRuleSet (from Step 4).

Step 7: Activate and Deploy

Activate all the created objects and deploy the business rule service. If any changes are made, the service must be deployed again.

Existing Workflow Setup

In the current existing workflow, the access request is configured to follow the Role Owner approval path as the stage 1 during the approval process.

Testing Scenario

The following test scenario was performed to validate the configuration:

An access request was raised for the role PR_approver_0_1M.
The audit log shows that the request was automatically approved by the system.
The Access request status shows that it moved to the Risk Owner stage, confirming that the Role Owner stage was automatically approved successfully.

Conclusion

Role Owner stage auto approval reduces manual effort and speeds up the approval process for eligible access requests. Using rule-based conditions, organizations can automatically approve condition based requests while keeping manual approvals for critical cases.

What’s New in SAP Cloud Identity Access Governance

2026-02-03T23:52:32.042000+01:00

Strengthening Access Visibility, Automation, and Governance

As organizations continue to modernize their system landscapes, access governance must adapt to increasing complexity. Managing users, roles, groups, and entitlements across hybrid and cloud environments calls for clearer visibility, smarter integration options, and dependable audit support.

The Q4 2025 updates to SAP Cloud Identity Access Governance (IAG) introduce a fresh set of enhancements spanning application integrations, APIs, job management, and reporting. These additions bring more flexibility, improved insight into access data, and expanded options for governing access. As a result, this helps teams work more efficiently as their environments grow and evolve.

Let’s take a closer look at what’s new in this release!

Seamless Application Integration with SAP HANA Cloud

SAP Cloud Identity Access Governance now supports deeper integration with SAP HANA Cloud, enabling synchronization of users, groups, and group authorizations. This integration lays the foundation for consistent access governance by supporting risk assessment, user provisioning with group assignments, and certification processes, all from a centralized governance layer.

Please refer to the following for more information: Help Portal Documentation

User Filter Support Across All Applications

User filter functionality is now extended to all SAP Cloud Identity Access Governance integration scenarios. This enhancement allows customers to exclude users who do not need to be governed, ensuring governance efforts remain focused and effective.

Please refer to the following for more information: Help Portal Documentation

Enhanced Access Request API for Greater Flexibility

The Access Request API has been enhanced by removing the mandatory domain field and introducing flexible user identification options. Users can now be retrieved using identifiers such as email, global user ID, or a universal search parameter.

Please refer to the following for more information: Help Portal Documentation

Manage Jobs - Change History Visibility

A new change history capability has been introduced in the Manage Jobs application. Administrators can now view updates made to jobs, including pause and resume actions, as well as the users responsible for those changes.

Please refer to the following for more information: Help Portal Documentation

Business Role Coverage Report

The new Business Role Coverage Report provides clear insights into how user roles are mapped within business roles. With smart filters, intuitive selection tools, and easy download options, administrators can quickly identify gaps and ensure proper role coverage.

Please refer to the following for more information: Help Portal Documentation

Unassociated Access Report

Embedded within the Business Coverage Report, the Unassociated Access Report helps administrators identify roles and groups that are not linked to any business roles. Users can drill down into details and refine searches using smart filters to pinpoint specific unassociated accesses.

Please refer to the following for more information: Help Portal Documentation

Access Report

The Access Report provides a comprehensive view of all users along with their assigned and unassigned accesses. It also shows how accesses relate to business roles, making it easier to validate access origins and appropriateness.

Please refer to the following for more information: Help Portal Documentation

Access Usage Report

The new Access Usage Report combines the functionality of the previously separate Unused Access and Actively Used Access reports into a single unified view. It supports on-premise and ABAP-based systems, including SAP HANA on-premise and SAP ERP.

Please refer to the following for more information: Help Portal Documentation

Closing Thoughts

These enhancements mark another strong step forward for SAP Cloud Identity Access Governance, bringing greater clarity, flexibility, and control to how organizations manage access across increasingly complex landscapes. From deeper integrations and APIs to unified reporting and stronger audit transparency, this release is designed to help teams govern access with confidence, efficiency, and precision.

As access governance continues to evolve alongside cloud and hybrid environments, SAP Cloud Identity Access Governance remains committed to delivering practical, scalable innovations that reduce risk, simplify operations, and support compliance at every stage. We’re excited to see how these capabilities help you strengthen your governance processes, and we look forward to continuing this journey with you as even more improvements arrive in upcoming releases.

For more details and configuration guidance, please refer to the SAP Help Portal documentation for SAP Cloud Identity Access Governance.