SAP SuccessFactors Security: RBP, IAS, API and Audit

SAP SuccessFactors holds compensation, bank details, national identifiers and the hire and leaver events that drive accounts elsewhere, so one over-broad permission role, a long-lived proxy or an unwatched API user can expose the whole workforce or redirect pay. Unlike the ABAP systems in the SAP basis guides, SuccessFactors is a SaaS suite with its own authorisation model (Role-Based Permissions, or RBP), its own login through SAP Cloud Identity Services Identity Authentication (IAS) and its own API Center and Integration Center. This guide explains how identity and access work in a SuccessFactors instance, how to control administrators, proxies and API users, what the Change Audit and General Audit tools record, and how to harden an instance. It is written for SuccessFactors platform administrators, HRIS and integration teams, and the identity and security engineers who have to review them. Menu and permission names can shift between releases, so confirm them in your instance.

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

Access is granted population times target population. An RBP permission role does nothing until it is granted to a permission group and pointed at a target population, and when roles overlap the stronger permission wins, so reviews must look at both sides of every grant.
IAS is the front door. Instances upgraded through Upgrade Center authenticate through an IAS tenant that can proxy your corporate identity provider, which is where multi-factor authentication and conditional rules belong, and the upgrade cannot be undone.
API users are the main non-human identities. OData access through OAuth 2.0 client applications signed with X.509 certificates is preferable to Basic Authentication, which needs its own permission and an IP allowlist and should be the exception.
Proxy is impersonation by design. A proxy acts with the account holder's permissions, so proxy rights, Proxy Now and open-ended assignments need the same control as administrator roles.
Audit evidence expires fast. Change Audit reports are purged 48 hours after they are generated and cover only changes made after the feature was enabled, so turn it on early and export reports to your own retention.

How identity and access work in SAP SuccessFactors

A SuccessFactors user is normally created from Employee Central or an HR import. Authentication and authorisation are separate layers.

Authentication through IAS

SAP's Upgrade Center process connects an instance to SAP Cloud Identity Services: Identity Authentication (IAS) handles sign-in and Identity Provisioning (IPS) synchronises SuccessFactors users into IAS. According to SAP KBA 2791410, each customer receives two IAS tenants by default, one for production and one for preview, and the tenant must match the instance type. The upgrade disables Partial SSO, enables SSO with IAS on instances that did not have it, and replaces existing asserting parties with a new IAS asserting party. It cannot be undone. Emails must be unique because IAS uses email for login, and IAS includes only active users. A corporate identity provider can sit behind IAS so that employees keep their normal sign-in, with IAS acting as a proxy that issues the assertion SuccessFactors trusts. Configure multi-factor authentication and risk-based rules in IAS or in the corporate identity provider, not as an afterthought. See the SAP Cloud Identity Services guide for IAS and IPS hardening in depth.

Authorisation through Role-Based Permissions

RBP has three building blocks. Permission roles define what can be seen or done. Permission groups define who receives a role (the granted population) and, separately, who the role acts on (the target population). Groups are either dynamic, built from rules over up to four People Pools with exclusions, so membership follows HR data, or static, a fixed list loaded through Manage Permission Groups and Import Static Groups. Predefined relationship groups (Everyone, Managers, Matrix Managers, Custom Manager and Second Manager) let you grant by relationship rather than by list. SAP's training material states that when roles overlap, the stronger permission always wins, so a narrow HR role does not restrict a user who also holds a broad one.

Element	What it controls	Typical mistake
Permission role	Fields, actions, admin tools and integration permissions	Copying a broad role and adding to it, so every derivative inherits admin rights
Granted population (permission group)	Who holds the role	Static groups that never shrink when people move
Target population	Whose data the role acts on	Target set to Everyone where a department or country scope was intended
Relationship grant (Managers, HR manager)	Access based on reporting lines	Stale or wrong manager data quietly granting access
Proxy assignment	Acting as another user with their permissions	No end date, all modules, granted by end users
API user and OAuth client	Programmatic read and write through OData	One shared API user with an administrator role and Basic Authentication

Admin roles and privileged access

SuccessFactors administrator power sits in permission roles that include Administrator Permissions, such as Manage Permission Roles, Manage Permission Groups, Manage Integration Tools and the audit configuration permissions. Anyone who can edit roles can grant themselves anything, so treat RBP administration as a privileged function and apply separation of duties, which SAP's own RBP guidance recommends.

Separate the security administrator from the HR administrator: the person who edits roles and groups should not be the person who processes pay or bank detail changes, and neither should hold integration permissions by default.
Keep the role model small and layered: SAP recommends a broad "All Employees" style role with publicly viewable profile fields, then roles that add only their unique exceptions, few groups and naming prefixes such as "Granted:" and "Target:". SAP training gives about 1,000 dynamic groups as recommended guidance, not a hard limit.
Document every role: write the purpose, the owner and the approver into the role description, and log who changed it and why.
Alert on group changes: the "Role Based Permission Notification" group change email template under E-mail Notification Templates can notify you of large permission group changes.
Use the RBP Check Tool and table reports: SAP's RBP Check Tool flags risky configuration, and the RBP User to Role, RBP Permission to User and RBP User to Group reports are the raw material for access reviews. SAP announced that the User Role and Permission Search part of the RBP Troubleshooting tool reached End of Maintenance on 14 November 2025 and is deleted on 15 May 2026, so build reviews on the reports instead.
Control shared and support access: changes made through shared accounts such as sfadmin are attributed to the named person when secondary login in Provisioning is used, and the Manage Support Access Change Report records support access changes.

Proxy management

A proxy can open, view, edit and send anything the account holder's permissions allow. That suits absence cover and testing, and is also an impersonation path into a payroll administrator's account. Advanced Proxy Management ("Enable Advanced Proxy Management (Proxy Now and Proxy Import)") adds Proxy Now to the name menu for users with proxy rights. Keep proxy assignment with administrators by selecting "Disable Proxy access for users without Proxy rights", restrict assignments to the modules needed, always set start and end dates, and review the Proxy Assignment Change report. General Audit records proxy sessions by default.

Integrations, API tokens and service accounts

Every payroll connector, identity governance tool, learning platform and data warehouse that talks to SuccessFactors does so as an API user with an RBP role. These are non-human identities with access to the most sensitive data in the company, and they deserve the controls described in the SaaS API Token Security Guide.

OAuth 2.0 client applications

SAP KBA 2850646 describes the OAuth 2.0 setup for the OData API. A role needs "Manage OAuth2 Client Applications" under Manage Integration Tools (SAP suggests a dedicated API Administrator role), and the client is registered through Manage OAuth2 Client Applications and Register New Client Application. The client authenticates with an X.509 certificate: SuccessFactors stores the public certificate and the client holds the private key. The KBA recommends generating the key pair on the client side or in your key management system and uploading only the certificate. SAP notes that any user of a registered client can connect with it, so the client and its API user are both credentials to protect.

Basic Authentication and IP allowlists

Basic Authentication to the OData API needs the "Manage Odata API Basic Authentication" permission, and the caller's IP must be allowed both in OData API Basic Authentication Configuration (OData API Allowlisting in API Center, IPv4 and IPv6) and in Password and Login Policy Settings under Set API Login Exceptions, according to SAP KBA 3108814. A request that fails these checks returns error LGN0010 with HTTP 401. Treat Basic Authentication as a legacy exception: grant the permission to named integration roles only, keep allowlists to specific egress addresses rather than wildcard ranges, and plan each remaining Basic Authentication integration's move to OAuth. The legacy SFAPI is deprecated and should not be used for new development.

Integration Center and file transfers

Integration Center builds scheduled outbound and inbound integrations, many of which push files over SFTP. Change Audit can also deliver recurring reports over SFTP with optional PGP File Encryption, using keys imported on the PGP File Encryption Keys page. Store SFTP credentials and PGP keys as managed secrets, encrypt files that leave the instance, and include every Integration Center job in your integration inventory with a named owner.

Method	Credential	Main risk	Control
OData with OAuth 2.0 (X.509)	Client private key plus API user	Private key copied to scripts or downloaded from API Center	Client-side key generation, vaulting, certificate validity limits, rotation
OData with Basic Authentication	Username and password	Password reuse and spraying from any allowed range	Named permission, tight IP allowlist, migration to OAuth
SFAPI (legacy)	Username and password	Deprecated surface kept alive for old jobs	Inventory and retire
Integration Center SFTP jobs	SFTP credential or key, PGP keys	Bulk HR files on third-party servers	PGP encryption, secrets management, owner per job

Give each integration its own API user and role, scoped by target population (a country payroll connector does not need Everyone), with no user interface use. For governance of these accounts see the NHI Ownership Guide.

Logging and detection

SuccessFactors offers three audit sources that matter for security, plus the API logs.

Source	What it records	Where to switch it on	Watch for
Change Audit: personal data	Inserts, updates and deletes to personal data from UI, API and import	Manage Audit Configuration (Personal Data Audit, on by default)	Bank detail and address changes, especially outside working hours
Change Audit: configuration and business data	RBP roles and groups, proxy assignments, feature settings, MDF configuration, user account changes	Manage Audit Configuration (Configuration and Business Data Audit)	RBP Role Change, RBP Group Change and RBP Static Group Membership Change entries without a ticket
General Audit	Page access, data exports and proxy sessions	Manage General Audit Configuration (data export and proxy on by default, page access off)	Large exports, proxy sessions into HR or payroll administrators
OData API Audit Log	API transactions with status and entity; optional request and response payloads	API Center, Audit Log Settings	New callers, failed authentication bursts, bulk reads of compensation or bank entities

Two constraints shape the design. Change Audit captures only changes made after it is enabled, and activation takes about a day. Generated reports remain downloadable for 48 hours before they are purged, personal data reports cover up to 31 days per request, and report storage is capped. A practical pattern is a scheduled report delivered over SFTP with PGP to a collection point that forwards it to your SIEM, plus a weekly configuration report reviewed by someone outside the RBP administration team. See the SaaS Audit Log Retention and Licensing Guide.

Payroll diversion is the fraud pattern to build detections for. The FBI's 2018 public service announcement I-091818-PSA describes criminals phishing employees' payroll credentials, changing the bank account and adding rules that suppress the change notification email. It recommends extra scrutiny of direct deposit changes and monitoring logins outside business hours. In SuccessFactors terms that means correlating IAS sign-in anomalies with bank detail changes in Change Audit, and holding or confirming changes made within hours of a new device or location. See the Business Email Compromise Awareness for Finance Teams Guide.

Metrics

Privileged role holders: number of users holding Manage Permission Roles or Manage Integration Tools, trending down or flat.
Open-ended proxies: proxy assignments with no end date or all modules, target zero.
Basic Authentication integrations: count of API users still holding the Basic Authentication permission, falling each quarter.
Unticketed permission changes: RBP role and group changes with no matching change record, target zero.
Bank detail change review time: hours from a bank detail change to confirmation or reversal.

Hardening baseline

Inventory first: export the RBP table reports, the OAuth client list, Basic Authentication allowlists, proxy assignments and Integration Center jobs, and assign an owner to each role and integration.
Turn on audit: enable Change Audit for personal and configuration data, confirm General Audit defaults for data export and proxy sessions, decide on page access auditing, and set OData audit logging at a level that does not store payloads you cannot protect.
Fix authentication: complete the IAS upgrade in preview first, connect the corporate identity provider, require phishing-resistant multi-factor authentication for administrators and anyone who can change pay, and keep a small, monitored set of IAS-only administrator accounts for break-glass.
Restructure RBP: split security administration from HR administration, narrow target populations, retire static groups that duplicate dynamic ones, and remove roles nobody uses after checking assignments.
Move integrations to OAuth: register one OAuth client per integration with a client-generated certificate, give each its own API user and role, then remove the Basic Authentication permission and allowlist entry. Test in the preview instance and keep the old credential disabled, not deleted, until the job has run a full cycle so you can roll back.
Lock down proxy: restrict proxy assignment to administrators, require end dates and module restrictions, and review active proxies monthly.
Protect pay changes: route bank detail changes through workflow approval or an out-of-band confirmation, and alert on changes made by proxies or API users.

Small and large organisations

A small company with one HRIS administrator cannot separate every duty; send RBP change alerts and the weekly configuration report to someone else. A large multi-country instance should define target populations by country or legal entity, run quarterly access certifications from the RBP reports through an identity governance tool, and treat each payroll vendor connection as a third party with its own risk review.

Common misconfigurations

Everyone as the target population: roles intended for one country or business unit set to Everyone, giving HR partners worldwide access to compensation and identifiers.
Integration users with administrator roles: an API user given a copy of the super administrator role so a connector "just works", leaving a password or key that can rewrite permissions.
Private keys downloaded from API Center: certificates generated in the instance and private keys emailed or committed to integration scripts, contrary to SAP's KBA advice.
Wildcard API login exceptions: broad ranges in Set API Login Exceptions or the OData allowlist, which turn Basic Authentication into an internet-facing password login.
Permanent proxies: proxy rights granted for a project or absence with no end date, letting someone act as a payroll administrator months later.
Audit switched on after the incident: Change Audit enabled only when evidence is needed, when it cannot show anything that happened before.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	MITRE ATT&CK
RBP roles, target populations, reviews	AC-2, AC-3, AC-6	PR.AA-05	5.15, 5.18, 8.2	T1098 Account Manipulation
IAS sign-in and MFA	IA-2	PR.AA-01	8.5	T1078.004 Cloud Accounts, T1566 Phishing
OAuth clients, certificates, Basic Authentication	IA-5, SC-12	PR.AA-01	5.17, 8.24	T1528 Steal Application Access Token, T1110.003 Password Spraying
Change Audit, General Audit, OData logs	AU-2, AU-6	PR.PS-04, DE.CM-03	8.15, 8.16	T1213 Data from Information Repositories
Payroll diversion controls	AC-6, AU-6	DE.CM-03	5.15, 8.16	T1657 Financial Theft

Practitioner checklist

Export RBP User to Role and RBP Permission to User reports and certify every holder of Manage Permission Roles, Manage Permission Groups and Manage Integration Tools.
Check every role whose target population is Everyone and narrow it where the business scope is smaller.
Confirm the IAS upgrade is complete, the corporate identity provider is connected and administrators use phishing-resistant multi-factor authentication.
List all OAuth2 client applications, confirm each has an owner, a client-generated certificate and a dedicated API user.
List every API user with "Manage Odata API Basic Authentication", remove wildcard allowlist entries and set a migration date for each.
Restrict proxy assignment to administrators, set end dates on all proxies and review the Proxy Assignment Change report monthly.
Enable Change Audit for personal and configuration data and schedule SFTP delivery with PGP to your log platform before the 48 hour purge.
Alert on bank detail changes made shortly after an unusual sign-in, by a proxy or by an API user, and confirm them out of band.

SAP SuccessFactors Security: Permissions, SSO, API access and audit hardening