SAP Concur Security: SSO, Permissions and Audit Rules

SAP Concur decides who can submit, approve and pay expenses and invoices, so a shared administrator login, a forgotten partner connection or a switched-off audit rule turns straight into money leaving the business. Concur is a SaaS service: SAP runs the infrastructure, and the customer makes the user and authorisation decisions, which is the split SAP's own administrator training describes. This guide covers the customer-side controls: how sign-in and single sign-on work, which administrative permissions to separate, how API clients, company request tokens and App Center partner connections behave, how to provision users through the Identity v4 API, and how audit rules support expense fraud detection. It is written for Concur administrators, finance systems owners and the identity and security teams who review them. Concur has Standard and Professional editions with different menus, so confirm names in your own site.

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

Key takeaways

Make SSO required once testing is done. The SSO Setting on the Manage Single Sign-On page can be optional or required; SAP recommends optional only while testing, and with required SSO users can reach the site only through your identity provider.
Split the Authentication Admin permissions. SSO Manager, Password Manager and Web Services Administrator each open one section of Authentication Admin, while Company Administration opens all three; SAP itself points to least privilege here.
Company request tokens are keys to the whole company. A Web Services Administrator can generate one with the Company Request Token tool; it is valid for 24 hours and is exchanged for an access token and a long-lived refresh token.
Refresh tokens last six months by default. Access tokens expire after one hour, but the refresh token behind every API client and partner connection is a durable non-human credential that needs an owner and a review.
Audit rules are your fraud tripwires. Default and custom audit rules flag missing receipts, amounts over limits, non-compliant categories and duplicates for approvers and processors; review that they are active and tuned.

How identity and access work in SAP Concur

Concur separates authentication (how a user proves who they are) from permissions (what the user can do once signed in). Both are administered from Company Administration.

Sign-in and single sign-on

Concur's self-activated SSO service is SAML 2.0 compliant, with Concur as the service provider. Setup has two halves: you load Concur's service provider metadata into your identity provider, and you upload your identity provider's metadata XML to Concur on the Manage Single Sign-On page. SAP's training lists supported identity providers including SAP Cloud Identity Services Identity Authentication, Microsoft Entra ID (listed as Azure AD), Okta, Ping Identity, OneLogin, JumpCloud, Google, ADFS, Shibboleth and others.

Each SSO configuration has a custom identity provider name, shown on the sign-in page as "Sign in with" followed by that name, an optional logout URL and the uploaded metadata file. The SSO Setting chooses the policy:

SSO Setting	Effect	When to use
Optional	Users can sign in through SSO or with a Concur login ID and password	During testing, and for a small, reviewed set of accounts that genuinely need a password, such as travel management company agents or test users
Required	Users can reach the site only through SSO	Normal operation for employees, so that MFA, conditional access and leaver disablement in your identity provider apply to Concur

With SSO required, password reset and MFA move to your identity provider, which is where they belong. See the SAML Security Guide for assertion signing and certificate rollover, and the SAP Identity and Access Security Guide for the wider SAP identity picture.

Permissions

Concur permissions control access to features and administrative functions. In Concur Travel, permissions can be assigned to individual users, to groups of users, to users in a rule class or to everyone in the company, and are reached through User Permissions under User Administration or the Permissions Administrator. In the Standard edition, the SSO administration menu appears for users with the "Can Administer" checkbox on their profile; in the Professional edition it appears for users with the SSO Manager permission. Treat company-wide grants with care: a permission given to "everyone" is rarely the intent for anything administrative.

User provisioning

The Identity v4 API manages a user's core identity profile using SCIM 2.0 schemas (urn:ietf:params:scim:schemas:core:2.0:User) and SCIM PATCH messages. It accepts only company-level access tokens. Scopes are narrow and split by read and write, for example identity.user.core.read, identity.user.coreenterprise.writeonly and identity.user.externalID.writeonly; identity.user.sap.read is needed for integrations that use SAP Identity Provisioning (IPS). The identity.user.delete scope performs a hard delete, which SAP marks as not recommended and only for users with no transaction history. Use the active attribute to disable leavers rather than deleting them, so expense history stays intact. Note that a PUT replaces the whole record and clears any field left out, so provisioning connectors should use PATCH. See the SCIM Provisioning Guide.

Admin roles and privileged access

Authentication Admin has three sections: Manage Single Sign-On, Sign-In Settings and Company Request Token. SAP's training maps them to permissions as follows and recommends least privilege.

Permission	Authentication Admin access	Risk if misused	Control
Company Administration	All three sections, plus wider company configuration	Can change SSO policy, sign-in settings and issue company tokens	Two to three named holders, reviewed quarterly
SSO Manager	Manage Single Sign-On only	Can switch SSO from required to optional or add an identity provider configuration	Identity team only; alert on changes
Password Manager	Sign-In Settings only, including bulk password actions	Can reset passwords for accounts that still use them	Service desk lead, with ticket reference
Web Services Administrator	Company Request Token only	Can create a token that leads to company-level API access	Integration owner only; record every token generated

Beyond authentication, separate configuration rights from transaction rights. The people who configure expense policies, audit rules and payment settings should not be the people who approve or process expense reports and invoices, and nobody should be able to change their own approval routing. Map Concur permissions into your segregation of duties matrix: see the Segregation of Duties Guide. Keep a break-glass administrator that signs in through a reviewed optional-SSO path for the case where your identity provider is unavailable, store its credentials in a vault and alert on its use; see the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Concur integrations are non-human identities. They connect HR feeds, ERP posting, card feeds, travel partners and analytics tools, and each one holds tokens that can read or change financial data.

How Concur API authentication works

App registration: an app is registered with SAP Concur through partner enablement, which issues a clientId, clientSecret and a geolocation base URI (for example us.api.concursolutions.com).
Grant types: tokens can be obtained through the Password, Authorization, Client Credentials and One-time Password grants.
Company-level tokens: for the Password grant the username is the company UUID and the password is a temporary request token valid for 24 hours. Customers can generate it themselves with the Company Request Token tool.
Token lifetimes: access tokens last one hour; refresh tokens last six months by default and are used to get new access tokens.
App Center partner connections: when a user connects a partner app from App Center, Concur calls the auth token endpoint for the company and redirects the user to the partner's Connect URL with a request token, which the partner exchanges for an access token and refresh token.

Controls for API clients

Credential	Where it lives	Practice
Client ID and client secret	Your integration platform or middleware	Store in a secrets manager, never in scripts; rotate through partner enablement when staff with access leave
Company request token	Generated in Authentication Admin	Generate only at connection time, use within 24 hours, log who generated it and for which integration
Refresh token	Stored by your integration or the partner	Inventory each one with an owner; treat as a long-lived secret
App Center partner connections	Partner's systems	Approve partners through procurement and third-party risk; review connected apps each quarter and disconnect unused ones
Identity v4 provisioning client	IdP or IPS connector	Grant only the write scopes needed; avoid the delete scope

See the Secrets Management Guide and the Service Account Security Guide for lifecycle patterns that apply to these credentials.

Logging and detection

Two kinds of signal matter in Concur: changes to security configuration, and financial behaviour that looks like fraud.

Audit rules as fraud signals

Concur audit rules review expense reports for compliance with company policy and regulation. SAP's training lists the typical issues they flag: missing receipts, expenses over set limits, non-compliant categories such as personal purchases, and duplicate submissions. A flagged report goes to an approver or expense processor, or back to the submitter to correct. Default rules can be activated and edited. Custom audit rules sit on the Compliance Controls, Custom Audit Rules tab, which shows each rule's Name, Event, Exception Code, Applies To and Active status; they can test expense fields (vendor, amount, date, project code), report fields (total, approval status, report date) and attendees. SAP enables the custom audit rules capability for a site, so ask your account team if the tab is missing.

Fraud or misuse pattern	Signal to build	Owner
Duplicate claims	Duplicate expense or ticket number rule active and set to flag	Expense processing
Split transactions under a limit	Several entries from one vendor on one date just under the approval threshold	Finance controls
Personal spend on corporate card	Non-compliant category and weekend or holiday date rules	Card programme
Inflated attendee lists	Attendee count or per-attendee amount rules	Expense processing
Targeting by one employee	Custom rule that routes all reports from a named employee for review during an investigation	Internal audit
Payment detail changes	Out-of-band verification of any change to employee or supplier bank details before the next payment run	Accounts payable

Bank detail changes are the highest-value target in finance SaaS. Verify any change by calling a number already on file, not one supplied in the request. See the Invoice Redirection and Supplier Bank Detail Fraud Guide and the Payment Verification Policy Template.

Configuration and identity signals

Identity provider logs: with SSO required, your identity provider holds the sign-in record, MFA result and risk score for every Concur session. Forward them to your SIEM.
Configuration changes: treat changes to the SSO Setting, new SSO configurations, Sign-In Settings and company request token generation as high-severity changes that need a ticket.
Permission changes: export user permission assignments regularly and diff them, focusing on Company Administration, SSO Manager, Password Manager and Web Services Administrator.

Metrics

SSO coverage: percentage of active users who can sign in only through SSO.
Privileged footprint: number of holders of each Authentication Admin permission.
Integration hygiene: percentage of API clients and partner connections with a named owner and a review in the last 90 days.
Audit rule effectiveness: exceptions raised per thousand reports and the share confirmed as genuine issues.
Leaver speed: hours from HR termination to the Concur account becoming inactive.

Hardening baseline

Configure SSO in optional mode: upload identity provider metadata, add test users and test sign-in end to end.
Switch to required: once testing passes, set the SSO Setting to required for employees, keeping optional sign-in only for a short, reviewed list of accounts such as travel agents and one break-glass administrator.
Split permissions: assign SSO Manager, Password Manager and Web Services Administrator to different named people, and limit Company Administration.
Automate the lifecycle: provision and disable users from your HR system or identity provider through Identity v4 or SAP IPS, disabling rather than deleting.
Inventory integrations: list every API client, refresh token and App Center connection with an owner and purpose, and remove the unused.
Turn on and tune audit rules: activate default rules, add custom rules for the patterns above and review exception rates each quarter.
Protect payment changes: require out-of-band verification for bank detail changes and separate who can edit payment data from who approves payments.
Roll back safely: if SSO breaks after a certificate change, the break-glass administrator can set the SSO Setting back to optional while the identity provider is fixed.

For small organisations, the priority order is required SSO, then a two-person split of Company Administration, then the integration inventory. Large organisations with several entities should also review rule class scoping, so that permissions granted in one entity do not reach another.

Common misconfigurations

SSO left optional after go-live: passwords remain usable for everyone, outside identity provider MFA and leaver controls. Move to required.
Company Administration as the default admin grant: every administrator holds all three Authentication Admin sections. Use the narrower permissions.
Untracked refresh tokens: integrations built years ago still hold six-month refresh tokens that renew silently, owned by nobody. Inventory and reassign them.
Hard deletes for leavers: using the delete scope removes history needed for audit. Disable instead.
PUT from a provisioning connector: full replacement clears attributes such as manager or cost centre, which can break approval routing. Use PATCH.
Audit rules activated but never reviewed: thresholds drift from policy and exceptions are cleared without reading. Review rules alongside policy changes.

Framework mapping

Concur control	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Required SSO through the identity provider	IA-2	PR.AA-05	A.8.5
Split Authentication Admin permissions, segregation of duties	AC-5, AC-6	PR.AA-05	A.5.3, A.8.2
Provisioning and leaver disablement	AC-2	PR.AA-05	A.5.18
API client and token inventory	IA-5	PR.AA-05	A.5.17
Audit rules and change monitoring	AU-6	DE.CM-09	A.8.16

Practitioner checklist

Set the SSO Setting to required for employees after testing, with a documented list of optional-sign-in exceptions.
Assign SSO Manager, Password Manager and Web Services Administrator separately and keep Company Administration to a few named people.
Vault a break-glass administrator and alert on its sign-in.
Provision and disable users automatically through Identity v4 or SAP IPS, using PATCH and the active attribute.
Record every company request token generated, by whom and for which integration.
Inventory API clients, refresh tokens and App Center partner connections with owners, and review them quarterly.
Activate default audit rules and add custom rules for duplicates, split transactions and attendee abuse.
Require out-of-band verification for any bank detail change before the next payment run.
Forward identity provider sign-in logs for Concur to your SIEM and diff permission exports monthly.

SAP Concur Security: Lock down SSO, admin permissions, API tokens and audit rules