SAP Ariba Security: Supplier Access, SSO and Controls

SAP Ariba holds the purchase orders, contracts, supplier records and remittance details that move an organisation's money, so the way its users, groups, supplier accounts and API applications are set up decides who can approve spend and who can change where payments go. This guide covers the customer-side controls in SAP Ariba procurement and sourcing solutions and in SAP Business Network (formerly Ariba Network): identity and sign-in, the administrative groups, supplier account protection, bank detail changes, Developer Portal applications and OAuth secrets, and the audit service. It is written for procurement system administrators, IAM teams and security engineers who own an Ariba realm or support suppliers on the network. For SAP identity more broadly, see the SAP Identity and Access 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

Federate sign-in through SAP Cloud Identity Services. SAP describes SSO with Identity Authentication (IAS) as mandatory for Ariba next generation solutions, and IAS can proxy to your corporate identity provider so that your own MFA and Conditional Access rules apply.
Keep Customer Administrator small. It is the broadest group in a realm, the only group that can use Act As, and SAP notes it can consume up to three user licences, so it should be assigned sparingly and reviewed often.
Turn on MFA for supplier accounts and for critical fields. SAP Business Network offers "Require multi-factor authentication for login" and "Require multifactor authentication for critical fields", which adds a second check when users change email, phone or remittance information.
Treat Developer Portal applications as non-human identities. Each application has an application key and an OAuth client ID and secret; only Organization Admins can request production access and generate secrets, and the secret is shown once.
Use the audit service and send it to your SIEM. SAP Ariba records security-related activity in logs that cannot be modified, readable by the Customer Administrator and Audit User groups.

How identity and access work in SAP Ariba

An SAP Ariba realm (the customer's site) has its own users, groups and permissions. SAP's administration training describes three kinds of user: internal enterprise users, external users such as suppliers, and third-party users. Users are created by someone holding the Customer User Administrator permission, manually, by CSV import or, in ERP-integrated realms, by synchronisation from the ERP. A user cannot be deleted: it is deactivated, and its User ID cannot be edited or reused, which keeps audit history intact.

Permissions come from groups, not from individual grants:

System groups: built into the product, carry permissions, and usually map to job roles such as Sourcing Agent or Contract Manager. A permission granted through a system group applies across the whole site.
AribaManaged groups: custom groups with no permissions of their own. Nest one under a system group to inherit its rights, or use it to control access to reports, workspaces and events.
External groups: maintained in a source system such as the ERP or a CSV file. Changes made in Ariba can be overwritten by the next import, so manage them at the source.

Sign-in options

Option	How it works	When to use it
Application authentication	SAP Ariba holds the user name and password; users reset their own passwords	Small realms, supplier-side users, break-glass accounts
Corporate authentication	Credentials match the corporate user name and password and are validated remotely	Legacy integrations being moved to SSO
Corporate SSO through SAP IAS	Ariba is the service provider; IAS is the identity provider, or proxies to your corporate IdP over SAML or OpenID Connect	The default for buyer realms; SAP describes it as mandatory for next generation solutions

With SSO, the Ariba User ID must match the corporate identifier, and password resets move to IT. In the IAS proxy model, IAS is still configured as the identity provider for Ariba, and IAS is registered as a service provider in your corporate IdP, so authentication policy (MFA strength, device checks, session length) is enforced in one place. Test realms pair with an IAS test tenant and production realms with an IAS production tenant: keep those trust relationships separate. SAP Identity Provisioning can load users into the IAS user store where features such as group-based access restrictions need them. See the Identity Provider and SSO Security Guide and the SAML Security Guide.

Admin roles and privileged access

A small number of groups control the realm. The table lists the ones SAP's training material names, with our recommended handling.

Group	What it allows (per SAP documentation)	NHI Mgmt Group recommendation
Customer Administrator	Broad administration, data import and export in Ariba Administrator, creating users and adding groups; the only group that can use Act As	Two to three named people, no shared accounts, quarterly review
Customer User Administrator	Creates users and sends invitations, adds groups to users	Separate from approvers of spend; joiner and leaver tickets as evidence
Audit User	Reads the security audit logs	Give to security operations, not to procurement administrators
SM Ops Administrator, SM ERP Administrator	Supplier management data import and export, ERP integration configuration	Treat as privileged; change records for every import
Supplier Registration Manager	Starts and manages supplier registrations	Keep separate from people who approve payment runs in the ERP
Sensitive Data Access	Views masked answers and attachments in supplier management questionnaires	Small group; review membership alongside finance access

Act As: lets a Customer Administrator work as another user, which is useful for support and powerful for misuse. Record a ticket for each use and review it in the audit log.
Segregation of duties: the classic procurement conflicts are creating a supplier and approving its invoices, changing supplier bank details and releasing payments, and administering users while approving spend. Map Ariba groups and ERP roles together in one matrix. See the Segregation of Duties Guide.
Lock versus deactivate: Lock is temporary; the user stays visible and can still be added to projects and events. Deactivate hides the user and blocks assignment. Use Deactivate for leavers and drive it from the HR leaver event, not a manual list.
Break-glass: agree with SAP support how emergency administrator access works for your realm if the corporate IdP is unavailable, document it, and protect any emergency account with a long random password in your vault and an alert on every sign-in.

Supplier accounts and bank detail changes

Suppliers connect through their own SAP Business Network accounts. Those accounts are administered by the supplier, but the buyer depends on them: a supplier user who can edit remittance details can change where the buyer pays. This is a shared responsibility, and both sides have settings to use.

MFA for login: in SAP Business Network, the account Administrator or a user with User Administration permission goes to Account Settings, Settings, Users, then the Manage User Authentication tab, and selects "Require multi-factor authentication for login". It can also be enabled for selected users. Users sign in with a time-based one-time passcode from SAP Authenticator or another authenticator app.
MFA for critical fields: "Require multifactor authentication for critical fields" asks for a second verification when users change email addresses, phone numbers or remittance information. Encourage suppliers to turn on both settings, and say so in supplier onboarding material.
Who can edit remittances: SAP's support article states that the Remittances page needs the account administrator role or the Payment Profile permission. Suppliers should limit Payment Profile to finance staff.
Buyer-side verification: after a supplier updates bank details, SAP advises the supplier to contact the customer so the customer can update its records. Make that update a controlled process: call back on a number already held, never one from the change request, and have a second person approve the change in the vendor master. See the Invoice Redirection and Supplier Bank Detail Fraud Guide.
Developer Portal MFA: SAP also offers MFA for the Developer Portal in Ariba Network, using time-based verification codes once enabled for the organisation.

Integrations, API tokens and service accounts

Ariba APIs are reached through applications registered in the SAP Ariba Developer Portal, which is regional, so register in the portal for your data centre. SAP's Developer Portal guide describes the model:

Create the application: an Organization Admin or Developer creates it, which generates an application key. Every REST call sends this key in the apikey header.
Request production access: only an Organization Admin can request it, naming the APIs, the Ariba solution, the realm name, optionally the AN ID, and whether the realm is test or production. The application cannot be used in production until the request is approved. A test realm registration does not carry over to production.
Generate the OAuth secret: after approval the admin receives the OAuth client ID and generates the secret. The portal shows the secret and its Base64 client:secret string once.
Get tokens: the client posts to the regional /v2/oauth/token endpoint with Basic authentication and grant_type=openapi_2lo. The default access token lifetime is 1440 seconds; each refresh returns a new refresh token and invalidates the old one.
Rotate: generating a new secret invalidates the previous secret, so every client must then fetch new tokens. Plan rotation as a coordinated change.

Credential	Where it lives	Handling
Application key	Header on every call	Store in a secrets manager; one application per integration and environment
OAuth client ID and secret	Token request	SAP advises secure external storage, never a database, email, source code, local text file or browser session storage; regenerate if exposure is possible
Access and refresh tokens	Integration runtime memory	Do not log; refresh no earlier than two minutes before expiry
Technical users for ERP or middleware	Ariba realm and integration platform	Named owner, least-privilege group, excluded from interactive sign-in where possible

Our recommendation is to rotate Ariba OAuth secrets at least every 12 months and immediately when an administrator who could see them leaves, and to keep an inventory row for every application: owner, APIs approved, realms, environment and last rotation date. SAP recommends separate test and production applications even where one application could serve several realms. See the API Key Management Guide and the NHI Offboarding and Decommissioning Guide.

Logging and detection

SAP Ariba's audit service records security-related activity across Buying, Sourcing, Contracts, Invoice Management, Supplier Lifecycle and Performance, and Supply Chain Collaboration for Buyers. SAP states that the logs cannot be modified and do not capture passwords, shared secrets, private keys or tokens. Users need the Customer Administrator or Audit User group, and the service sits in the Intelligent Configuration Manager workspace in Ariba Administrator. SAP also offers an API Integration Event Monitoring Query API for Procurement, used by SAP Cloud ALM, for integration event monitoring.

Event to watch	Why it matters	Suggested response
User added to Customer Administrator or Customer User Administrator	Privilege change in the realm	Match to an approved ticket within one business day
Act As sessions	Acting as another user	Review weekly against support tickets
SSO configuration or IdP certificate changes	Sign-in trust change	Alert immediately; confirm with the IAM team
Developer Portal secret generated	New credential for an integration	Confirm a change record and the owning integration
Supplier remittance or vendor master bank change	Payment redirection risk	Hold until call-back verification is recorded
Bulk user or data export	Large data movement	Review the requester and purpose

Metrics: number of Customer Administrator members (target three or fewer); percentage of buyer users signing in through SSO (target 100% apart from break-glass); percentage of strategic suppliers with MFA for critical fields; OAuth secrets older than 12 months; median time to deactivate a leaver; bank detail changes verified by call-back (target 100%). See the SIEM Log Source Onboarding Checklist.

Hardening baseline

Set up SSO with IAS: confirm your IAS tenants in SAP for Me, configure the proxy to your corporate IdP, test in the test realm with a pilot group, then move production. Agree the rollback and emergency access path before switching.
Reduce administrators: list members of each administrative group, remove anyone without a current need, and move day-to-day user work to Customer User Administrator.
Turn on the audit service and export it: grant Audit User to security operations and set up regular export to your SIEM.
Build the SoD matrix: map Ariba groups to ERP roles, flag conflicts, and add a review step for exceptions.
Govern API applications: inventory every Developer Portal application, move secrets to a vault, separate test from production, and set a rotation date.
Raise supplier assurance: ask suppliers to enable MFA for login and critical fields, and require call-back verification on every bank change.
Stay current: apply SAP security updates promptly using SAP Security Notes; SAP Patch Day is the second Tuesday of each month. Read the quarterly Ariba release updates for new security features.

Common misconfigurations

Too many Customer Administrators: granted during implementation and never removed. Review after go-live and every quarter.
Editing external groups in Ariba: changes are overwritten by the next import, leaving access different from what reviewers approved. Change them at the source.
Locking instead of deactivating leavers: locked users remain assignable to projects and events. Use Deactivate.
One API application for everything: shared across test and production or across integrations, so one secret rotation breaks several flows and ownership is unclear. Use one application per integration and environment.
Secrets in integration configuration files or email: SAP's guidance rules these out. Use a secrets manager and regenerate if a secret was ever sent by email.
Bank changes accepted on the strength of a supplier email: verify through a known contact and a second approver before the vendor master changes.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0
Users, groups, leavers	AC-2	PR.AA-01
Administrative groups, SoD	AC-5, AC-6	PR.AA-05
SSO and MFA	IA-2	PR.AA-01
OAuth secrets and keys	IA-5	PR.AA-01
Audit logging and review	AU-2, AU-6	DE.CM-03
Supplier relationships	SR-3	GV.SC-07

Practitioner checklist

SSO through SAP IAS is live for all buyer users, with separate test and production tenants.
Customer Administrator has three or fewer named members, reviewed quarterly.
Act As use is ticketed and reviewed weekly in the audit log.
The audit service is enabled, Audit User is held by security operations, and logs reach the SIEM.
Leavers are deactivated, not locked, from the HR leaver event.
An SoD matrix covers Ariba groups and ERP roles together.
Every Developer Portal application has an owner, a vault-held secret and a rotation date.
Strategic suppliers have MFA for login and for critical fields turned on.
Bank detail changes need call-back verification and a second approver.
SAP Security Notes and Ariba release updates are reviewed every month.

SAP Ariba Security: Supplier Access, SSO and Procurement Controls