Rippling Security: Securing permissions, payroll data, API tokens and devices

A Rippling tenant joins HR records, payroll, app access and managed devices in one employee graph, so a single over-scoped permission profile, an unattended API token or a quietly changed bank account can reach salaries, identity documents and the apps every employee signs in to. That integration is also what makes Rippling straightforward to secure well: access follows employee attributes, offboarding can remove app and device access in one step, and sign-in policies apply across the tenant and its connected apps. This guide explains how identity and access work in Rippling, how to scope admin permission profiles, how to govern API tokens, App Shop installs and the Rippling MCP, what to log, and a hardening baseline built around payroll diversion risk. It is written for Rippling administrators, HR and payroll systems owners, and the IT and security engineers who review them. All settings described here sit on the customer side of the shared responsibility model.

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

Key takeaways

• Permission profiles are scope, access and actions. Each profile decides whose records it covers, which apps and fields it reaches, and whether it can view, edit or approve, so review all three dimensions, not just the profile name.
• Enforce strong sign-in through authentication policies. Require MFA for everyone, and give Super Admins a separate policy with a hardware security key and a short session timeout, as Rippling's own security guidance advises.
• API tokens act as their owner. A token inherits its creator's permission profile, is limited further by its scopes, and is revoked automatically when the owner is terminated or after more than 30 days unused.
• Bank detail changes need a second signal. Use Rippling's workflow automation and approval rules so that a change to an employee's payment details alerts payroll and is confirmed out of band before the next pay run. See the Payroll Diversion Fraud Guide.
• Offboarding is a security control. Termination in Rippling revokes the owner's API tokens and MCP access and can trigger app deprovisioning and device lock or wipe, so the HR termination date is part of your access control.

How identity and access work in Rippling

Every person in Rippling is an employee record with attributes such as department, level, location, manager and employment type. Those attributes drive almost everything else: which permission profiles apply, which apps are provisioned, which devices are configured and which approval chains a request follows. Supergroups are Rippling's dynamic membership lists built from attributes, and access attached to a Supergroup updates automatically when an attribute changes. The result is attribute-based access control with the HR record as the source of truth.

Rippling as the identity provider

Rippling can act as the identity provider for other applications. According to Rippling's product documentation it supports SAML single sign-on (including custom SAML apps), OIDC, LDAP, Active Directory and RADIUS, and SCIM provisioning for custom integrations. Dynamic provisioning policies create, modify or suspend accounts in connected apps when source data changes, and access can be removed immediately or scheduled in advance. For apps that offer no SSO, Rippling IT includes a browser-based password manager that ties stored credentials to the employee record so they are included in revocation at termination. See the Identity Provider and SSO Security Guide and the SCIM Provisioning Guide.

Authentication policies

Sign-in to Rippling itself is governed by authentication policies in Rippling IT settings. A policy sets password requirements, session timeout (in hours or days) and whether MFA is required, and can apply to all employees or to specific groups. Rippling lists YubiKey, Duo, biometrics, one-time passcodes and WebAuthn passkeys among supported factors. Build at least three policies:

Phishing-resistant factors matter most where payroll data is reachable. See the Phishing-Resistant MFA Guide.

Conditional access and behavioural detection rules

Conditional access policies can block or restrict sign-ins by location, impossible travel, managed device status and network (IP address, VPN or region). Behavioural detection rules (BDRs) evaluate sign-in signals such as location, device, IP address and failed attempts, and can allow or block access, set session lifetime or require MFA, either for Rippling or for a single SSO-connected app. Rippling's example "impossible travel" rule flags sign-ins implying travel faster than 650 miles per hour and blocks the account until an admin restores access.

Admin roles and privileged access

A permission profile has three parts, as Rippling describes them: scope (the people whose data it can reach, such as a reporting line, a department or a Supergroup, with exceptions), access (the data types and apps, such as Payroll or Time and Attendance, down to individual fields) and actions (view, edit or approve within those apps). Profiles attach to attributes rather than named people, and before a change takes effect an administrator can see the access that will be gained and lost. Use that preview at every profile change.

• Keep Super Admin small: hold it for at least two named people for continuity and use narrower custom profiles for day-to-day administration.
• Separate setup from money: the profile that edits permission profiles, authentication policies or API tokens should not also edit payment details or approve payroll. See the Segregation of Duties Guide.
• Use approval rules for sensitive changes: Rippling approval workflows route by attributes, support multi-approver chains with re-routing when an approver is away, and can apply thresholds (Rippling's example requires approval when compensation or equity changes by more than 20 per cent). Apply the same approach to payment detail and compensation changes.
• Check field-level edits: a profile that can view a field may also be able to edit it; set edit rights on payment and tax fields deliberately.
• Review quarterly: export profile membership through Rippling's reporting and certify it with HR and finance owners. See the Access Reviews Guide.

Integrations, API tokens and service accounts

Rippling has three integration paths a security team needs to govern: customer-created REST API tokens, OAuth apps installed from the App Shop, and the Rippling MCP for AI assistants. Each carries employee data out of the tenant, so each needs an owner and a review.

REST API tokens

Tokens are created under Developer > API credentials > New API token. Requests made with a token appear as its owner, and Rippling's documentation says to treat a token as a password. Scope names follow a resource.access pattern, for example users.read or teams.read-write; choose only the scopes the integration needs, and where Custom Objects scopes are chosen, restrict the object and record types too. Only the token owner can change its scopes, while admins can rename tokens and change their API version. Token creation and revocation send email notifications to the owner, API Token Admins and Super or Full Admins, which gives you a built-in detection signal.

• Use a dedicated integration owner: because a token inherits its creator's profile and is revoked when the creator is terminated, create production tokens under a dedicated, narrowly scoped integration identity with a named human owner, rather than under a Super Admin's personal account.
• Watch Last accessed: the API credentials page shows when each token was last used; revoke tokens that are idle before the 30-day automatic revocation, and investigate tokens used from unexpected systems.
• Store the value in a vault: the token is shown once at creation; put it straight into a secrets manager and never into code or tickets. See the SaaS API Token Security Guide.

App Shop installs

App Shop scopes are set per listing, and an admin consents to the full set at install. Treat the install screen as an access request: record the scopes, the data they expose (for example compensation or identity data) and the business owner, and add the app to your third-party register. Remove apps that no longer have an owner. See the SaaS and OAuth App Governance Guide.

Rippling MCP and AI assistants

The Rippling MCP acts under the connected employee's own identity, not a shared service account, and enforces two layers: the MCP Gateway policy must allow the tool and the user must hold the underlying Rippling permission. Rippling states that sensitive fields such as national identifiers, home addresses and tax IDs are never exposed through it, and high-impact actions such as new hires are saved as drafts for human review. Employees have no MCP access until an admin creates a policy, so scope policies to Supergroups and start with read-only tools for a pilot group.

Logging and detection

Collect the Activity Log through a dedicated read-only token holding only activity-log.read, owned by the security team, so the collector cannot change anything if its token leaks. Retain events in line with your policy rather than the 90-day API window. See the SaaS Audit Log Retention and Licensing Guide.

Detections worth building first

• Payment detail change then pay run: an employee's bank details change within a few days of a payroll run, especially after a password reset or a sign-in from a new device.
• Privilege change: a permission profile gains payroll or Super Admin access, or an authentication policy is relaxed.
• New API token: a token created outside a change ticket, or one with read-write scopes on worker or compensation data.
• Bulk export: large report downloads of compensation or identity data by a profile that does not usually run them.

Metrics

• MFA coverage: share of active users under a policy that requires MFA, target 100 per cent, and share of admins on a hardware key or passkey.
• Super Admin count: holders of the Super Admin profile, held at the agreed small number.
• Token hygiene: API tokens with a named owner and a last-accessed date inside 30 days, target 100 per cent.
• Bank change confirmation: payment detail changes confirmed out of band before the next pay run, target 100 per cent.
• Leaver closure: terminated employees with any remaining app access in the Application Access Count Report, target zero.

Hardening baseline

1. Inventory: export permission profiles and their members, authentication policies, BDRs, API tokens with owners and last-accessed dates, App Shop installs and their scopes, MCP Gateway policies and SSO-connected apps.
2. Authentication: create the three authentication policies in the table above. Pilot the admin policy with two Super Admins first, keep a second Super Admin with a registered backup key so a lost key does not lock the tenant out, then extend MFA to all employees with a communication plan and a help desk recovery process that verifies identity before resetting factors. See the MFA Guide.
3. Permission profiles: reduce Super Admin holders, split IT, HR and payroll profiles, switch off payroll access for IT profiles, and use the gained-and-lost preview before saving changes.
4. Payroll protections: add an approval rule and an automation alert for payment detail changes, require payroll to confirm changes through a known contact method before the pay run, and train employees to update bank details only by signing in to Rippling directly, never through a link in a message. See the Business Email Compromise Awareness for Finance Teams Guide.
5. Integrations: move production tokens to dedicated integration owners, trim scopes, revoke idle tokens, review App Shop installs, and create MCP Gateway policies only for named Supergroups.
6. Conditional access and devices: require managed devices for admin profiles, enforce FileVault on macOS and BitLocker on Windows through Rippling device management, enforce OS updates, and schedule device lock or wipe as part of offboarding.
7. Logging: connect the Activity Log to the SIEM, route token notifications to a monitored queue, and switch on BDRs for impossible travel on admin and payroll profiles.

Roll back a policy change by moving the affected group back to its previous authentication policy, which is why each population should have its own policy rather than one shared policy edited in place.

Small and large organisations

A company of 50 people can reach a strong baseline in a day: two Super Admins on hardware keys, MFA for everyone, one payroll profile, an alert on bank detail changes to the finance lead and no long-lived API tokens. A large, multi-entity tenant should define permission profiles per entity and function, manage profile changes through change control, feed the Activity Log into the SIEM with detection rules, and run quarterly access certification for every profile with payroll or compensation access.

Common misconfigurations

• Super Admin as the default: giving Super Admin to everyone in HR or IT because a narrower profile was not built yet.
• Company-wide scope by accident: an HR or manager profile scoped to the whole company when it should cover one department or reporting line.
• Personal tokens in production: integrations running on a token owned by an individual admin, which inherits their full profile and stops working when they leave.
• Payment changes without a second check: employees can update bank details and the change flows into the next pay run with no alert or confirmation, the core pattern behind payroll diversion.
• One authentication policy for everyone: admins on the same factor and session length as the wider workforce, instead of hardware keys and short sessions.
• Activity Log left in the console: events reviewed only in Rippling and lost after the API retention window, leaving no evidence for an investigation.

Framework mapping

Practitioner checklist

• List every Super Admin and move anyone who does not need full control to a narrower permission profile.
• Create separate authentication policies for admins, payroll and the workforce, with hardware keys or passkeys and short sessions for admins.
• Review each permission profile's scope, app access, field edit rights and approval actions with its business owner.
• Inventory API tokens, assign owners, trim scopes, move production tokens to dedicated integration owners and revoke idle ones.
• Record every App Shop install with its scopes and owner, and create MCP Gateway policies only for named Supergroups.
• Add an approval rule and an automation alert for bank detail changes, with out-of-band confirmation before payroll runs.
• Forward the Activity Log to the SIEM with a read-only activity-log.read token and alert on profile, policy and token changes.
• Require managed, encrypted devices for admins and schedule device lock or wipe and app deprovisioning at termination.

Standards and references

• Rippling Developer: API Tokens and Permissions
• Rippling Developer: API Scope Reference
• Rippling Developer: App Shop Scopes
• Rippling Developer: Overview of the Rippling MCP
• Rippling: Steps to secure your Rippling tenant
• Rippling: Custom permission profiles
• Rippling: SSO, provisioning and authentication policies

Related NHI Mgmt Group resources: Payroll Diversion Fraud Guide · SaaS API Token Security Guide · SaaS Security Guide · Joiner-Mover-Leaver Guide · Phishing-Resistant MFA Guide