Ramp and Brex Corporate Card Security: Lock down admin roles, cards, vendors and API tokens

A spend management platform can issue cards, change vendor bank details and release payments, so an administrator session or an over-scoped API token on it is a direct route to money. Brex and Ramp both combine corporate cards, bill pay, reimbursements and accounting sync in one web console, and both give customers detailed controls over who can sign in, what each role can do and how integrations reach the data. This guide explains how to configure those customer-side controls on each platform: single sign-on and sign-in methods, admin roles and segregation of duties, card and spend limits, vendor bank detail changes, API tokens and OAuth apps, and the audit records to watch. It is written for finance systems owners, IT and identity teams, and the auditors who test spend controls. Platforms are listed alphabetically throughout the body of this guide, and order is never a ranking.

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

Key takeaways

• Route every finance user through your identity provider. Both platforms support SAML single sign-on with per-user or per-role routing, so joiners, movers and leavers follow your directory and MFA policy.
• Keep the money-moving roles small. The roles that can manage bank accounts, release payments and edit roles are the privileged accounts of a spend platform; review them like domain administrators.
• Treat vendor bank detail changes as a payment event. Use the vendor portal and ownership checks each platform offers, and require a second person to approve the change before money follows it.
• Scope API access to the job. Brex user tokens and Ramp OAuth apps both take explicit scopes; read-only scopes cover most reporting and accounting integrations.
• Export the audit trail. Login, role, vendor and payment events belong in your SIEM, where you can alert on self-approval, new admins and bank detail changes.

How identity and access work in Brex and Ramp

Both platforms authenticate people in the browser and mobile app, and both let you choose between local credentials, social sign-in with Google or Microsoft accounts, and enterprise single sign-on. The design choice for the customer is how far to push users onto SSO and where MFA is enforced. For general federation hardening, see the Identity Provider and SSO Security Guide and the SAML Security Guide.

Brex

• Local sign-in: email and password with multi-factor authentication (2FA and/or device verification). Eligible users can create a passkey under Personal settings > Security and privacy > Create passkey, which replaces both password and MFA at sign-in.
• Social sign-in: an account admin or card admin turns on "Allow Google or Microsoft Social Sign-in" under Company settings > Company. The Google or Microsoft email must match the Brex email.
• Single sign-on: SAML or OIDC, configured under Security > Authentication > Setup Single Sign-On. SAML assertions must carry an email attribute and be signed with SHA-256; OIDC clients use the authorization_code grant. Brex documents Microsoft Entra ID with SAML. Users signing in through SSO complete MFA at your identity provider rather than at Brex, so enforce strong MFA there.
• Routing: "Individual users" sends selected users through SSO, which suits a pilot; "All users" sends everyone through SSO with named exceptions who keep password and MFA. Changing routing mode means disabling the integration first, so plan the change in a quiet period. SSO and Enterprise IdP (social) login are configured one at a time.
• Availability: Brex lists SSO on its Premium and Enterprise plans; confirm current plan terms with Brex.

Ramp

• Local sign-in: password, with passkeys available to users who have registered one and whose role has Password enabled.
• Google SSO: on by default for users with Google Workspace email addresses.
• SAML single sign-on: configured under Company security > Identity providers, with guided setup for Microsoft Entra ID, Okta, OneLogin and JumpCloud and an "Other identity provider" option for any other SAML IdP. Each email domain maps to one provider. Ramp uses SP-initiated sign-in, so point IdP tiles and bookmarks at Ramp's sign-in URL.
• Login methods per role: under Company security > Account access > Configure > Login methods, enable or disable Password, Google SSO and SAML for each role. Ramp recommends requiring SSO for all roles except Guest, which always keeps Password. The Exceptions tab grants named users password access regardless of role, so keep that list short and reviewed.
• Availability: confirm SSO plan terms in Ramp's current documentation.

Admin roles and privileged access

On a spend platform the privileged permissions are the ones that move money or change who can: managing bank accounts, releasing payments, editing vendor payment details, issuing cards and editing roles. Map these against your Segregation of Duties Guide before assigning roles.

Brex

Availability: Brex lists User management admin and custom roles on Premium and Enterprise plans.

Ramp

Ramp lets you separate managing cards from seeing full card numbers: grant the card management permission and leave the card detail permission off. Entity-specific access restricts Finance Admin, Accounting and Accounts Payable to chosen entities. Availability: Ramp lists role customisation and custom roles on Ramp Plus.

Running privileged access on both platforms

1. List every user in the money-moving roles and confirm each against an HR record and a manager.
2. Move those users onto SSO first, and keep local-credential exceptions to a named break-glass account stored in your vault.
3. Give auditors and executives read-only or custom roles rather than admin.
4. Review role membership monthly for admin roles and quarterly for the rest (our recommendation), and record the evidence for SOX testing. See the SOX IT General Controls (ITGC) Guide.

Card, spend and vendor controls

Card controls limit what a stolen card number or compromised employee account can spend; vendor controls protect bill pay from bank detail redirection. Both are configured by customers, and both are worth treating as security settings rather than finance preferences. For the fraud patterns behind these controls, see the Invoice Redirection and Supplier Bank Detail Fraud Guide.

Brex

• Spend limits: create a single spend limit shared by one or more users, or a spend limit group with a different amount per user, and choose additional rules that Brex enforces automatically on transactions.
• Limit requests and alerts: employees request limits and a designated team member approves them. Under "Manage alerts", turn on the approaching limit, expiring soon, period resetting soon and expired alerts.
• Budgets: nest limits under top-level budgets (Premium and Enterprise) so a single over-spent limit cannot exceed the parent.
• Vendor payment details: use "Request information" so the vendor enters payment and tax details through a secure temporary portal,.
• Payment approvals: use the Policy Rule Builder to add vendor owners and finance approvers to bills, and keep bill drafting (AP clerk, Bookkeeper) separate from releasing payments (Account admin, Card admin).

Ramp

• Funds controls: set amount and frequency, allowed or blocked categories and merchants, "Lock on a certain date" and "Spend on" (choose "Virtual card-only" for online vendor spend).
• Fund lifecycle: funds set to "Does not repeat" lock automatically when the limit is reached, and "Terminate" stops all future spend.
• Vendor ownership checks: when requesting ACH details, select "Ask vendor to confirm they own this account", then review results under "Ownership verification needs review". Request links expire after 30 days.
• Vendor edit approval: vendor changes stay pending until the vendor approval workflow completes, and this is separate from the ownership check, so turn on both.

On both platforms, a call-back to a known contact before the first payment to new bank details remains the strongest single control (our recommendation). See the Dual control and four-eyes approval for privileged and agent actions.

Integrations, API tokens and service accounts

Accounting sync, HRIS provisioning, expense tools and in-house scripts all reach spend data through each platform's API. Each credential is a non-human identity with finance reach. Inventory them alongside your other SaaS integrations. See the SaaS and OAuth App Governance Guide.

Brex

• User tokens: account admins or card admins create them under Developer > Settings > Create Token, after the company accepts the developer API agreement. The token acts with the scopes chosen at creation and is shown once.
• Scopes: pairs such as cards.readonly and cards, vendors.readonly and vendors, transfers.readonly and transfers, plus cards.pan for card numbers. Brex advises requesting the minimum set of scopes and using readonly variants for apps that only read.
• Lifecycle: a token expires if unused for 90 days, and tokens tied to non-active users stop working. Revoke tokens from the developer page; revocation takes effect immediately.
• Ownership: because a token is tied to a user, create integration tokens from a dedicated, named admin account with an owner, so a leaver does not break accounting sync.

Ramp

• Client credentials: for server-to-server access to your own business, configured in the Ramp Developer Console. Tokens are business-wide, limited by scopes, last 10 days and come with no refresh token.
• Authorization code: for third-party apps; a user approves access and codes expire after 5 minutes. For business-wide apps an Admin or Business Owner approves the connection.
• Scopes: format resource:permission, for example transactions:read and cards:write; cards:read_vault is limited to approved integrators. Ramp advises requesting only what you need.
• Handling: Ramp advises storing tokens encrypted, never logging them, keeping client secrets server-side, and using separate apps for sandbox and production.

Store every token and client secret in a secrets manager, record an owner and purpose for each, and rotate client secrets at least every 90 days (our recommendation). See the API Key Management Guide.

Logging and detection

Brex

Account admins and card admins can view the audit trail under Security > Audit trail, which also shows SSO errors, and vendor activity is recorded in the vendor audit trail. Review new admin and custom role assignments, SSO configuration changes, new API tokens, and vendor payment detail edits.

Ramp

Admins and Owners open Company settings > Audit log > View audit log (Ramp Plus). Login events can include method, MFA, IP address and location, and sign-out events record reasons such as admin session revocation. The "Acted on own item" filter finds people approving their own items, and saved views track recurring checks such as bank account and vendor changes. Pair the log with periodic role reviews (our recommendation).

Detections to build (ours)

Metrics: share of users signing in through SSO (target 100% except break-glass); number of users in money-moving roles; percentage of vendor bank changes with a second approval and call-back; API credentials with an owner and least-privilege scopes; days to remove leavers. See the SaaS Audit Log Retention and Licensing Guide.

Hardening baseline

1. Federate: configure SAML SSO, pilot with a small group (Brex "Individual users"; Ramp SAML on one role), then require it for all users. Roll back by restoring password sign-in for the affected role or routing mode.
2. Enforce MFA at the IdP: phishing-resistant MFA for admin roles. See the Phishing-Resistant MFA Guide.
3. Trim roles: two or three top admins, separate drafting from releasing payments, read-only roles for audit.
4. Lock down vendor changes: vendor portal or ownership check, plus edit approval and call-back.
5. Set card limits by purpose: virtual or vendor-specific cards with merchant restrictions and end dates for subscriptions and one-off purchases.
6. Scope integrations: read-only by default, named owner, secrets in a vault.
7. Stream logs: review the audit trail weekly or forward it to your SIEM.
8. Automate leavers: deprovision through SCIM or HRIS sync so access ends with employment.

Common misconfigurations

• Long-lived SSO exceptions: users added as exceptions during rollout keep password access for years. Review the exception list monthly.
• Integration tokens on a person's account: a token created by an individual admin ties a critical integration to one human identity. Use a dedicated, owned admin account and record it.
• Write scopes for read jobs: reporting tools granted write or card number scopes. Reissue with read-only scopes.
• One person drafts and releases payments: combined roles let a single compromised account redirect funds. Split the roles and require approval.
• Vendor detail changes accepted by email: bank details typed in from an email rather than collected through the vendor portal or ownership check. See the Business Email Compromise Awareness for Finance Teams Guide.
• Open-ended cards: cards with no end date, merchant restriction or limit reset left active after a project ends.

Framework mapping

Practitioner checklist

• SAML SSO configured and required for all users except a vaulted break-glass account.
• Phishing-resistant MFA enforced at the IdP for admin and payment roles.
• Admin role holders named, justified and reviewed monthly.
• Payment drafting and payment release held by different people.
• Vendor bank details collected through the vendor portal or ownership check, with edit approval and a call-back.
• Cards issued per purpose with limits, merchant restrictions and end dates.
• Every API token and OAuth app inventoried with owner, scopes and rotation date.
• Audit trail reviewed or forwarded to the SIEM, with alerts on new admins, bank changes and self-approval.
• Leavers removed through SCIM or HRIS sync within one working day.

Standards and references

• Brex: Signing into Brex
• Brex: Account role types and permissions
• Brex Developer: Roles, permissions and scopes
• Ramp: Setting up single sign-on (SSO) and login controls in Ramp
• Ramp: Customizing roles and permissions
• Ramp Developer: Authorization
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: Segregation of Duties Guide · Invoice Redirection and Supplier Bank Detail Fraud Guide · SaaS and OAuth App Governance Guide · Payment Fraud Guide