What is the primary security boundary in an SAP cloud landscape?

Identity. Because SAP S/4HANA Cloud, SAP BAIP, and SAP SuccessFactors are accessed from devices and networks the organization does not control, authentication and authorization decisions replace network segmentation as the principal control.

What are the components of SAP Cloud Identity Services?

Four: Identity Authentication Service for authentication, SSO, and MFA; Identity Provisioning Service for lifecycle synchronisation; Identity Directory as the cloud identity store; and Authorization Management for policy-based authorization.

How does role design differ in SAP S/4HANA Cloud Public Edition?

PFCG and SU01 are no more available. Roles are built in the Maintain Business Roles app from delivered business catalogs and business role templates, with read, write, and value-help restriction types controlling access to organizational data.

Which governance tool replaces SAP Access Control for public-cloud SAP?

SAP Cloud Identity Access Governance provides access analysis, role design, access request, access certification, and privileged access management for cloud-based SAP applications. Hybrid estates typically operate both IAG and SAP Access Control during transition.

Which accounts should receive multifactor authentication first?

Privileged administrators, emergency access identities, and technical or service principals with broad authorization, because they represent the highest-value targets and the smallest enrolment population.

How is segregation of duties monitored in SAP S/4HANA Cloud?

Through continuous access analysis in SAP Cloud Identity Access Governance, evaluated against a documented rule set, supplemented by business role design that avoids combining conflicting business catalogs in the first place.

Do AI agents need their own identities in SAP?

Yes. Agents that read data and execute transactions authenticate as principals and require the same lifecycle management, least-privilege design, and audit evidence applied to human and technical users.

SAP S/4HANA Cloud Security: The IAM Pillars That Matter

Identity and Access Management as the Real Perimeter of the SAP Cloud Landscape

Goodbye to the traditional model where the access points, firewall used to be the first perimeter when a user/intruder is trying to login to SAP landscape from an unmanaged laptop on a hotel or a public network. Identity took that place now. For SAP S/4HANA Cloud, SAP SuccessFactors, SAP Ariba, and SAP Business AI Platform (earlier known as SAP BTP) , the identity presenting itself at the door is the only control that consistently stands between an attacker and the general ledger.

This article walks through the pillars of cloud identity and access management and translates each one into the SAP services, configuration objects, and governance practices that actually carry the control.

Key Takeaways

• SAP S/4HANA Cloud and SAP BAIP landscapes will utilize identity segmentation as the primary security boundary.

• SAP CIS (Identity Authentication, Identity Provisioning, Identity Directory, Authorization Management) is the core operational centre of SAP cloud IAM.

• There is no PFCG and SU01 in SAP S/4HANA Cloud, Public Edition. It uses business roles, business catalogs, and restriction types - the new authorization model.

• MFA belongs on privileged and technical identities first, not last.

• Access certification, segregation-of-duties analysis, and privileged access for public-cloud SAP are delivered through SAP Cloud Identity Access Governance rather than on-premise SAP Access Control.

• AI agents are becoming principals in their own right and inherit every weakness in the identity model beneath them.

Why the Perimeter Moved

SAP security used to be a data-centre discipline. SAP Systems are inside the corporate network, external users login through the LAN or a VPN connection, and the authorizations are completely controlled with authorizations, and network segmentation carried most of the risk. Auditors were looking at the firewall diagram and were satisfied with the network architecture.

That model is no longer valid. SAP S/4HANA Cloud, SAP BTP/BAIP services, SAP SuccessFactors, SAP Ariba, and SAP Concur have moved from typical corporate networks to cloud. Users now can access it from anywhere - from corporate laptops, personal phones, contractor machines, to public networks, across a dozen jurisdictions. It doesn’t any more passes through infrastructure the organization owns.

What remains constant is the identity making the request. Getting identity and access management right has stopped being an administrative task delegated to the basis team and has become the primary line of defence.

IAM Fundamentals in an SAP Context

Every identity and access management discussion rests on five concepts. In an SAP landscape they map to concrete artefacts.

Concept

Definition

SAP Implementation

Identity

Who a person or system is

User record originating in SAP SuccessFactors, Active Directory, or Microsoft Entra ID

Access

What the identity is attempting to reach

An SAP Fiori app, a BTP subaccount, an OData service, an SAP HANA Cloud instance

Authentication

Verification that the identity is genuine

Authorization

Confirmation that the identity may perform the action

Business roles and business catalogs in SAP S/4HANA Cloud; role collections in SAP BTP

Auditing

The record of what happened

Security audit log, read access logging, BTP audit log, retained for compliance reporting

Auditors rarely challenge the first four in isolation. They challenge whether the fifth can prove the other four were working on a specific date.

Three Levels of IAM Maturity

Most SAP estates fall somewhere along the following progression.

Maturity

Characteristics

Typical Position

Traditional

Identities exist only in the corporate directory; no single sign-on between cloud and on-premise; minimal visibility into identity risk

Legacy ECC-centric estates

Advanced

On-premise identity federated to the cloud; MFA enforced; conditional access policies react to risk signals

Most SAP customers running S/4HANA Cloud today

Optimal

Continuous evaluation of user, device, location, and behavioural signals; passwordless authentication in production

Early adopters, usually financial services and regulated manufacturing

The honest assessment for most SAP customers is that they sit between advanced and optimal, using SAP Cloud Identity Services to bridge an existing Active Directory or Entra ID tenant to cloud-based SAP applications, with passwordless still confined to pilot populations.

From Legacy IAM to Centralised Cloud Identity

Legacy IAM was installed and operated on the organization's own infrastructure and had no centralizing layer. Each application authenticated its own users, and provisioning meant creating a separate account in every application's own database. Anyone who has reconciled a leaver list against six SAP clients, a BW system, and a Solution Manager instance knows what that costs.

Modern IAM inverts the model by centralising identity in a cloud identity provider. For SAP customers that provider is SAP Cloud Identity Services, made up of four components:

Identity Authentication Service (IAS) - authentication, single sign-on, MFA, risk-based policies, and self-service password reset.
Identity Provisioning Service (IPS) - connector-based synchronisation of identities and role assignments between source and target systems.
Identity Directory - the cloud-side store of users, groups, and attributes.
Authorization Management - policy-based authorization for applications built on the platform.

SAP Cloud Identity Services components: Identity Authentication, Identity Provisioning, Identity Directory, and Authorization Management.

Figure — SAP Cloud Identity Services components: Identity Authentication, Identity Provisioning, Identity Directory, and Authorization Management.

Together these give every SAP cloud application a shared set of identity capabilities while leaving the organization free to keep an on-premise directory or a third-party identity provider as the ultimate source of truth. That distinction matters in design workshops: SAP Cloud Identity Services is usually a proxy identity provider, not a replacement for the corporate one.

Source: SAP Help Portal · SAP Cloud Identity Services documentation.

Identity Lifecycle Governance

Authenticating a user correctly at 09:00 is worth very little if that user changed departments three months ago and kept both sets of authorizations.

Lifecycle governance is where most access findings originate. When an employee moves, SAP authorizations must move with them. When an employee leaves, every access right needs removal within a defined and evidenced window. SAP Cloud Identity Services automates a large part of this through provisioning connectors that push user creation, attribute changes, role assignment, and deactivation from source systems such as SAP SuccessFactors into targets including SAP S/4HANA Cloud, BTP and BAIP subaccounts, Cloud Foundry, and ABAP environments.

Two failure patterns recur in practice. The first is a provisioning job that runs successfully but silently skips records that fail validation. The second is a target system where deactivation removes the login but leaves role assignments intact, which produces a clean user list and a dirty authorization report.

Principal Types in an SAP Cloud Landscape

Not every identity reaching an SAP cloud tenant belongs to a person at a keyboard. A complete IAM strategy accounts for five categories of principal.

Users - standard, non-privileged business identities working in SAP Fiori apps, SAP Analytics Cloud, or SuccessFactors.
Administrators - escalated identities holding administrative access to BTP subaccounts, SAP HANA Cloud instances, or tenant administration in SAP S/4HANA Cloud.
Service principals - technical identities such as BTP service instances, OAuth clients, and communication users that authenticate system-to-system integration rather than human logins.
Managed identities - predefined roles and permissions bound to a specific resource, which removes the need to embed long-lived credentials in application code.
External identities - partner, supplier, or customer accounts granted deliberately narrow access for scenarios such as supplier onboarding in SAP Ariba.

Within SAP BTP/BAIP, these principals are typically assigned into broad tiers: readers who view and report, users and guests who work inside an application, contributors who create resources within a subaccount, and owners or global account administrators holding full control. Mapping every human and technical identity to the correct tier is a prerequisite for any credible least-privilege programme, and the technical identities are usually the ones nobody has reviewed.

Role-Based Access Control Across Two Layers

Role-based access control defines precisely which actions a role may perform against which resources. In a cloud landscape it operates on two distinct layers, and treating them as one is a common design error.

The application layer - SAP's authorization concept remains a mature implementation of RBAC, built from roles, authorization objects, and authorization fields that together determine which transactions, fields, and data records a user can reach.
The platform layer - SAP BTP/BAIP add platform-level roles and role collections - owner, contributor, reader, and resource-scoped equivalents that govern who can create, modify, or view subaccounts, service instances, destinations, and connectivity configuration.

Two-layer RBAC in SAP: application authorization in SAP S/4HANA Cloud and platform authorization in SAP BAIP.

Two-layer RBAC in SAP: application authorization in SAP S/4HANA Cloud and platform authorization in SAP BTP.

An administrator with no business authorization at all can still create a destination that exposes production data. Combining the classical SAP authorization concept with disciplined role collection design is what closes that gap.

What Changes Specifically in SAP S/4HANA Cloud Public Edition

The public edition deserves separate treatment, because the familiar toolset is not present.

No PFCG, no SU01. Role design happens in the Maintain Business Roles app, built from delivered business catalogs and business role templates rather than manually assembled authorization objects.
Restriction types replace manual field-level maintenance. Read, write, and value-help restrictions on organizational fields such as company code, cost centre, and sales organization are the primary instrument of data-level least privilege.
Delivered content is generous by default. Business role templates prefixed SAP_BR_ are convenient starting points and are almost always broader than a single job requires. Copying a template into production without restriction analysis is the fastest route to an audit finding.
Technical identities are explicit. Communication users and communication arrangements govern integration access and need the same review cadence as named users.
Logging is app-based. The security audit log and read access logging are configured and reviewed through Fiori apps rather than SM19 and SM20, and the retention available to the customer is defined by the service description rather than by local configuration.
No debugger, no direct table browsing. This removes several traditional attack paths and simultaneously removes several traditional investigation techniques, which changes how forensic work is scoped.

Organizations migrating from on-premise SAP Access Control also discover that segregation-of-duties analysis, access requests, role design, access certification, and privileged access for the public edition are delivered through SAP Cloud Identity Access Governance (IAG) rather than the on-premise GRC stack. Planning that transition late is expensive.

Identity Federation Across SAP and Non-SAP Systems

Identity federation unifies authentication across on-premise and cloud environments so that a user authenticates once and carries a trusted session into every connected system. For SAP customers it takes one of three shapes.

Hybrid federation - an on-premise Active Directory synchronised with SAP Cloud Identity Services so employees use one corporate identity across on-premise and SAP cloud applications.
Multi-cloud federation - a single centralised identity provider designated as source of truth for users authenticating across SAP and non-SAP cloud providers alike.
Cloud and external-provider federation - on-premise and cloud identities centralised behind one provider, with that provider's controls extended to external resources and partners.

External-facing scenarios generally follow three patterns: guest access, where users from another organization are invited into a controlled collaboration space such as an SAP Ariba sourcing event; business-to-business federation, where trust is configured directly between organizations, for example a managed-services provider supporting an SAP landscape; and business-to-consumer federation, where a customer-facing application such as an SAP Commerce Cloud storefront accepts credentials from an external provider.

Each pattern carries a different offboarding risk. B2B federation in particular tends to outlive the contract that justified it.

Single Sign-On and Self-Service Password Reset

Single sign-on removes the friction of separate logins across every SAP and non-SAP application a user touches. After one successful authentication, the identity provider issues a token representing the session, commonly valid for around twenty-four hours before re-authentication is required. In an SAP landscape, SAP Cloud Identity Services acts as that provider, issuing SAML or OpenID Connect assertions that SAP S/4HANA Cloud, BTP/BAIP sub-accounts, SuccessFactors, and connected third-party applications trust.

Self-service password reset complements SSO by allowing users to verify themselves through a one-time passcode or authenticator app and reset a forgotten password without contacting the service desk. The security value is larger than the convenience value: it removes the most reliable social-engineering route into an SAP landscape, which is a persuasive phone call to a help desk under ticket pressure.

Multifactor Authentication

Multifactor authentication adds an independent verification step on top of a username and password, drawing from three categories of factor: something known, such as a password or PIN; something held, such as a mobile device, hardware token, or smart card; and something inherent, such as a fingerprint or facial scan. Access is granted only when both factors verify.

SAP Cloud Identity Services supports MFA natively for logins to SAP S/4HANA Cloud, BTP/BAIP, and other connected applications, and can be paired with SAP Secure Login Service to strengthen SAP GUI connections that remain in scope.

Sequencing matters. Privileged administrator accounts, emergency access identities, and service principals with broad authorization are the highest-value targets in any SAP estate, and they are usually the smallest population to enrol. Organizations that start with the general user population spend six months of change management before protecting the accounts that would cause the most damage.

Least Privilege, Just-In-Time Access, and Conditional Access

Least privilege holds that every identity receives only the access its task requires. Two practices operationalise it.

Just enough access grants the minimum permission level a role's responsibilities demand. This is the direct counter to the familiar SAP anti-pattern of a broad composite or catch-all business role carrying far more authorization than any single job description justifies.

Just-in-time access grants elevated permissions only for the duration of a task and revokes them automatically afterwards. It is particularly valuable for BTP and BAIP administrator access and for emergency access to production SAP S/4HANA systems, where the alternative is a standing privileged account reviewed quarterly at best.

Conditional and behaviour-based access turns least privilege from a static decision into a dynamic one. Access controls define what an identity may do once admitted; conditions are the criteria evaluated before admission, including device compliance, network location, and sign-in risk score; and the applicable cloud apps and actions define the scope. Applied together, an organization can permit routine SAP Fiori access from a managed corporate device while challenging or blocking the same request from an unrecognised location and an unmanaged endpoint.

IAM Auditing and Monitoring

Granting the right access is half of an IAM programme. Verifying that the access is still appropriate, and detecting misuse when it happens, is the other half.

A mature capability combines four elements: activity and event logging that records what identities actually did; sign-in and user risk scoring that flags anomalous behaviour; posture management and an identity secure score that benchmark configuration against a baseline; and user behaviour analytics capable of surfacing deviations a log review would never catch.

For SAP landscapes this means feeding SAP Cloud Identity Services and BTP audit logs into a SIEM or SOAR platform for correlation and automated response, while relying on SAP's own governance tooling · SAP Cloud Identity Access Governance for public-cloud scope, SAP Access Control where on-premise systems remain · to monitor segregation-of-duties conflicts and critical authorization assignments continuously rather than at quarter end. SAP has also been extending native vulnerability visibility into the platform cockpit, which places open-source and configuration risk alongside identity risk in a single view.

The practical test of maturity is simple: how long it takes to answer the question of who assigned a privileged role, when, on whose approval, and whether it was ever removed.

AI Agents Are the Next Category of Principal

The platform rename from SAP Business Technology Platform to SAP Business AI Platform reflects a consolidation of platform, data, and AI services under one governance model, and it carries a direct identity consequence. Autonomous agents that read business data, make decisions, and post transactions are principals. They authenticate, they hold authorizations, they act on behalf of humans, and they need lifecycle management, least privilege, restriction design, and audit trails exactly as human users do.

Every weakness in the current identity model will be inherited and amplified by the agents built on top of it. An estate that cannot currently evidence who owns a communication user will not be able to evidence which agent posted a journal entry.

Source: SAP Community · SAP Business Technology Platform competency renamed to SAP Business AI Platform competency, effective 30 June 2026.

Closing Perspective

Securing SAP in the cloud is an identity problem before it is anything else. The five fundamentals of identity, access, authentication, authorization, and accounting establish the foundation. Correct classification of every principal, human and technical, combined with role-based access control applied deliberately at both the application and platform layers, keeps permissions precise. Federation, single sign-on, and self-service password reset deliver the experience users expect without weakening control, while multifactor authentication and least privilege ensure that a single compromised credential buys an attacker very little. Continuous auditing and monitoring close the loop and convert IAM from a one-time configuration project into a standing discipline.

SAP Cloud Identity Services and SAP Cloud Identity Access Governance were built to operationalise exactly these principles across SAP S/4HANA Cloud, SAP BAIP, SAP SuccessFactors, and the wider portfolio. Organizations that treat identity as the genuine perimeter of the SAP estate, and fund federation, adaptive access, and monitoring accordingly, are the ones positioned to absorb the next wave of change · including a generation of AI agents that will hold identities of their own.

Sources

SAP Help Portal - SAP Cloud Identity Services documentation.
SAP Help Portal - SAP S/4HANA Cloud Public Edition, identity and access management.
SAP Help Portal - SAP Cloud Identity Access Governance.
SAP Community - SAP Business Technology Platform competency renamed to SAP Business AI Platform competency, effective 30 June 2026.