SAP Cloud Identity Services Security: IAS and IPS

SAP Cloud Identity Services sits in front of almost every SAP cloud application, so its tenant settings decide who can sign in to SuccessFactors, S/4HANA Cloud, Ariba and custom BTP apps, and how strongly. The tenant combines Identity Authentication (IAS), which handles sign-in and single sign-on, with Identity Provisioning (IPS), which creates and removes users and groups in connected systems, plus the Identity Directory and Authorization Management. This guide explains how authentication routing works, which administrator roles carry the most power, how to manage API secrets, certificates and provisioning credentials, what the audit and change logs give you, and a hardening baseline you can apply tenant by tenant. It is written for SAP identity architects, basis and BTP teams, and the IAM engineers who own the corporate identity provider behind IAS. Menu names change between releases, so confirm them in your administration console. For the wider BTP picture, where IAS is one dependency among many, see the SAP BTP Security Guide.

This is an independent guide from NHI Mgmt Group, based on SAP's public documentation as of November 2026. It is not sponsored or reviewed by SAP. Product features change, so confirm settings against SAP's current documentation.

Key takeaways

IAS is usually a proxy, not the source of truth. Most enterprises delegate sign-in to a corporate identity provider, and IAS then decides per application which provider authenticates each user, so its routing rules are a security control in their own right.
Manage Tenant Configuration is the master key. An administrator with that role can grant any role to themselves or others, so hold it for a very small, named group and protect their sign-in with strong two-factor rules.
Risk-based authentication starts at Allow. Each application's Default Action begins as Allow for any user from any IP, so set the default to Two-Factor Authentication or Deny and add explicit Allow rules where you have compensating controls.
Client secrets can be set to never expire. Choose 1 year or 2 years, limit the scope to what the integration needs, and prefer certificates or JWT client authentication for long-running integrations.
Audit logs are short-lived and API-only. IAS keeps audit log entries for 90 days on Cloud Foundry tenants and change logs for 24 months, so pull both into your own log platform on a schedule.

How identity and access work in SAP Cloud Identity Services

SAP describes Cloud Identity Services as the central solution for authentication, single sign-on and the identity lifecycle across its cloud portfolio. Many SAP solutions are preconfigured against one central tenant. Applications delegate authentication to IAS and read users from the Identity Directory or receive them through SCIM-based provisioning.

Applications and user access types

Every connected service is an application in the administration console, with its own trust (SAML 2.0 or OpenID Connect), authentication and access settings. SAP's security information recommends matching user access to the scenario: Public for business-to-consumer, Private for business-to-business and Internal for business-to-employee. Getting this wrong on a workforce application can open self-registration to anyone, so check it on every application, not only new ones.

Corporate identity provider proxying and identity federation

Under Identity Providers > Corporate Identity Providers you configure trust with a SAML 2.0 or OpenID Connect corporate provider. IAS then acts as a proxy: the corporate provider authenticates, IAS issues the assertion or token the SAP application trusts. The Identity Federation settings on each corporate provider control what happens next:

Use Identity Authentication user store: off by default. When off, IAS forwards the attributes it received from the corporate provider. When on, IAS checks that the user exists in the Identity Directory and sends attributes from its own store.
Allow Identity Authentication users only: off by default, which means every user who authenticates at the corporate provider is let through. Turn it on when only provisioned users should reach SAP applications. Group and email domain restrictions on the corporate provider take effect only when this option is on.
Apply Application Configurations: off by default. Turn it on so that application-level risk-based authentication, terms of use and privacy policy still apply to federated users.
Forward All SSO Requests to Corporate IdP: lets the corporate provider process every single sign-on request when IAS is a proxy, so its session and conditional access policies stay authoritative.

Conditional authentication

Conditional authentication routes users to an identity provider by email domain, user type, user group and IP range (CIDR). Rules are evaluated by priority and the first match wins. Three behaviours matter for security design:

Rules apply only when IAS itself is the application's default identity provider. Existing rules are ignored if you switch the default to a corporate provider.
If no rule matches, IAS authenticates the user locally. To send everyone to corporate providers, SAP recommends a lowest-priority catch-all rule with IP range 0.0.0.0/0, so that nobody falls through to a local password.
Non-prompt methods (SPNEGO, an existing session, remember me and tokens) are processed by IAS before the rules are checked, so session and token settings need the same care as the rules.

Identity Provisioning

IPS reads users and groups from source systems, transforms them and writes them to target systems, with proxy systems for hybrid scenarios such as an on-premise identity management tool. Provisioning jobs run on schedule or on demand, and real-time provisioning is available through an API. Each system holds connection properties, and the credentials in them are non-human identities that need ownership and rotation. See the SCIM Provisioning Guide for the protocol side.

Setting	Starting value	Recommended for workforce tenants
Risk-Based Authentication, Default Action	Allow	Two-Factor Authentication, or Deny with explicit Allow rules
Allow Identity Authentication users only	Off	On, with group restriction for sensitive applications
Apply Application Configurations	Off	On, so application rules apply to federated users
Client secret, Expire in	Chosen per secret (1 year, 2 years, Never)	1 year, never Never
Client secret, Scope	All scopes selected	Only the scope the integration uses
Session timeout	12 hours	A working day, aligned with corporate IdP session policy
Password policy	Standard	Custom or Enterprise for any local users

Admin roles and privileged access

Tenant administrators are users or systems with one or more administrator roles, assigned under the Administrators tile. SAP documents these roles:

Role	What it allows	Risk if over-assigned
Manage Tenant Configuration	Tenant settings and role assignment, including adding roles to yourself or other administrators	Full control of the tenant; equivalent to owning every connected application's sign-in
Manage Applications	Configure applications and their authorisation policies	Can change trust, routing rules and risk-based authentication
Manage Corporate Identity Providers	Configure corporate identity provider trust and federation	Can add a new trusted provider that asserts any identity
Manage Users / Read Users	Manage, import and export users; Read Users also covers the SCIM REST API	Bulk export of personal data; account changes
Manage Groups	Create and edit groups and assign authorisation policies	Group membership drives conditional and risk rules and application authorisations
Manage Identity Provisioning	Configure IPS (grants the IPS_ADMIN role)	Can repoint provisioning jobs and read connection properties
Access Proxy System API, Access Real-Time Provisioning API, Access Identity Provisioning Tenant Admin API	API access for provisioning integrations	Technical users that can create or change identities at scale

Separate duties: keep Manage Tenant Configuration and Manage Corporate Identity Providers away from day-to-day user administrators. A help desk team usually needs Manage Users only.
Know the built-in entries: the administrator list includes the SAP BTP system, which by default holds authorisations to set up trust with IAS. Review it alongside human administrators rather than removing it blindly.
Treat system administrators as NHIs: a system can receive the same roles as a person. Give each integration its own system administrator with a descriptive name (it cannot be renamed later) and the minimum roles.
Protect the console itself: the Administration Console appears as an application, so you can apply risk-based authentication to it. SAP cautions that administrators must meet the rules before saving, or they can lock themselves out. Keep at least two administrators who meet them, and document a break-glass route. See the Break-Glass Account Guide.
Use policy-based admin authorisations where available: SAP documents admin authorisations based on policies for more granular control than the fixed roles. Check availability for your tenant.

For SAP-wide privileged access design across ABAP and cloud, see the SAP Identity and Access Security Guide and the Privileged Access Management Guide.

Integrations, API tokens and service accounts

IAS exposes REST APIs (user management, invitation, password service and SCIM) and acts as an OpenID Connect provider. Each application's Trust > Application APIs > Client Authentication page holds the client ID and its credentials.

Credential type	Documented limits and behaviour	Use it for
Client secret	Up to 20 per application; expiry 1 year, 2 years or Never; scopes Application, Application Users and OpenID, all selected by default; shown once at creation	Short-lived or low-risk integrations, with a rotation date set
X.509 certificate	Up to 80 per application; uploaded or generated in the console; SAP-listed or customer CAs	Long-running server-to-server integrations and API calls
JWT client authentication	Issuer and subject or a JWKS URI configured for token requests	Workloads that can sign assertions with a key held in a vault or HSM
IPS credential properties	Passwords, private keys and OAuth secrets stored as Credential properties, shown masked as 40 characters	Every connection to a source, target or proxy system

Scope every secret: untick the scopes the integration does not use. A secret that only needs OpenID should not be able to call the user management APIs.
Set expiry and track it: record each secret's owner, purpose and expiry in your inventory. See the Service Account Security Guide and Secrets Management Guide.
Keep client ID locking on: by default a client ID locks for 60 minutes after five failed logon attempts. Disabling it removes a useful brute-force brake, so leave it enabled unless an integration genuinely needs otherwise.
Protect provisioning connections: SAP recommends secure protocols for every connection, avoiding the TrustAll property in production (it skips server certificate verification), and re-entering credential properties whenever you change a system's URL so credentials are not sent to a new host.
Limit detailed tracing: IPS can log complete entity data, including personal data, when you enable detailed entity tracing for a failing job. Switch it on only for the investigation and off afterwards.

For protocol-level guidance on OIDC clients and token handling, see the OAuth 2.0 and OpenID Connect Guide.

Logging and detection

IAS produces two kinds of evidence, and both need to leave the tenant.

Audit logs: changes to personal data and successful and failed authentications. You generate a client ID and secret for audit logs in the console, obtain a token and call the audit log retrieval API. Entries are retained for 90 days for tenants in the SAP BTP Cloud Foundry environment (AWS and Azure infrastructure) and 201 days for Neo environment tenants.
Change logs: CREATE, UPDATE and DELETE operations by administrators, exportable as CSV with date, administrator ID and name, resource type, resource ID and name, action and attribute. They are stored for 24 months.
Troubleshooting logs: useful for diagnosing failed sign-ins, not a replacement for audit logs.
SAP Cloud ALM: SAP's security information points to monitoring with SAP Cloud ALM as an option alongside your own SIEM.

Audit entries are key-value records with state, action, objectType, objectId, caller, cause and category (audit.authentication, audit.configuration or audit.data-change), which makes them straightforward to parse.

What to alert on	Where it shows	Why
New or changed corporate identity provider	Change log; `audit.configuration` with objectType identityProvider	A new trusted provider can assert any user
Administrator role added, especially Manage Tenant Configuration	Change log; objectType tenantAdmin	Privilege escalation inside the tenant
Risk-based or conditional rules edited on a production application	Change log; objectType serviceProvider	Removing two-factor rules or widening IP ranges
New client secret or certificate on an application	Change log	Fresh credentials for API access
Bursts of failed authentications or `otpCheckFailure`	`audit.authentication`	Password spraying or second-factor fatigue attempts
Bulk user export or SCIM reads by an unexpected caller	`audit.data-change` and API activity	Personal data leaving the tenant
Provisioning system properties changed	Change log; objectType provisioningSystem	Jobs repointed to a new target

Metrics that show the controls are working: percentage of production applications with a Default Action other than Allow; number of holders of Manage Tenant Configuration (target: a small named group); client secrets with expiry Never (target: zero); days since the last audit log pull (target: under one); percentage of provisioning systems using certificate or OAuth credentials; and time from administrator change to review. For detection techniques on identity logs generally, see the Identity Threat Hunting Guide.

Hardening baseline

Roll changes out in this order, testing each step on the test tenant first.

Inventory: export administrators, applications, corporate identity providers, provisioning systems and every client secret and certificate. Note owners and expiry.
Reduce administrators: remove unused administrators and split roles so that Manage Tenant Configuration sits with two or three named people.
Federate workforce sign-in: route employees to the corporate identity provider with conditional authentication, add the 0.0.0.0/0 catch-all where nobody should use a local password, and turn on Forward All SSO Requests where the corporate provider should own session policy.
Restrict who gets through: enable Allow Identity Authentication users only and, for sensitive applications, a group restriction, so that a valid corporate login alone does not reach every SAP application.
Apply two-factor rules: set each application's Default Action to Two-Factor Authentication with Web (FIDO2 and WebAuthn devices) or TOTP methods. SAP itself advises against Email OTP Code as a second factor. Enable back-up channels so users can recover a lost TOTP device. Remember that risk-based rules apply to user sign-in, not to technical OIDC communication between systems, which you secure through client credentials. See the Phishing-Resistant MFA Guide.
Protect the console: apply a two-factor rule to the Administration Console application once at least two administrators meet it.
Tighten local accounts: for any users who still authenticate locally, use a Custom password policy and the password exclude list.
Clean up API credentials: replace Never-expiring secrets, narrow scopes, and move long-running integrations to certificates.
Stream logs: schedule audit log retrieval and change log export into your SIEM before the 90-day window closes.
Roll back safely: keep a record of the previous rule set for each application. Rules are reprioritised or removed in the console, and a test user who matches each rule confirms behaviour before production.

Small and large organisations

A small organisation with one SAP product can often use the central tenant with a single corporate provider, one catch-all rule and a two-factor default. A large group with several SAP products, partners and customers should separate test and production tenants, define user access types per application, use group-based routing for partners, and give each provisioning integration its own system administrator and credentials.

Common misconfigurations

Leaving the Default Action at Allow: an application federated to a strong corporate provider can still be reached with a local IAS password if routing falls through. Set a two-factor or deny default.
No catch-all routing rule: when no conditional rule matches, IAS authenticates the user itself. Without a lowest-priority catch-all, some users keep using local passwords nobody intended them to have.
Accepting every corporate login: with Allow Identity Authentication users only off, anyone who can sign in at the corporate provider, including guests, can reach the application. Turn it on and use groups.
Too many tenant configuration holders: project consultants granted Manage Tenant Configuration during rollout and never removed. Review the Administrators tile quarterly.
Never-expiring, all-scope secrets: one secret created with all scopes and Never expiry, shared across integrations. Create one credential per integration, scoped and dated.
TrustAll in production provisioning: left in from testing, it disables server certificate checks. Remove it and use proper trust.
Audit logs never collected: the 90-day retention passes and evidence is gone. Automate the pull from day one.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
Federated sign-in and two-factor rules	IA-2, IA-5	PR.AA-03	8.5	6
Administrator roles and least privilege	AC-2, AC-6	PR.AA-05	5.15, 8.2	5, 6
API secrets, certificates and provisioning credentials	IA-5	PR.AA-01	5.17	5
Tenant settings baseline	CM-6	PR.PS-01	8.9	4
Audit and change log collection and review	AU-2, AU-6, AU-11	PR.PS-04, DE.CM-03	8.15	8

Practitioner checklist

List every tenant administrator and system administrator, with roles, and cut Manage Tenant Configuration to a small named group.
Set the Risk-Based Authentication Default Action on every production application to Two-Factor Authentication or Deny.
Add a lowest-priority 0.0.0.0/0 conditional authentication rule wherever all users should go to a corporate provider.
Turn on Allow Identity Authentication users only and Apply Application Configurations on each corporate identity provider.
Prefer Web (FIDO2) or TOTP second factors over Email OTP Code, and enable back-up channels.
Replace client secrets with expiry Never, narrow their scopes, and move long-running integrations to certificates.
Remove TrustAll from production provisioning systems and store all secrets as Credential properties.
Schedule audit log retrieval and change log export into your SIEM, with alerts on the events in the detection table.
Apply a two-factor rule to the Administration Console application once two administrators are confirmed to meet it.

SAP Cloud Identity Services: Secure IAS, IPS and corporate IdP federation