Deel Security: Admin Roles, SSO, API Tokens and Payment Controls

Deel holds contracts, pay data, tax details and payment instructions for employees and contractors in many countries, so an over-permissioned admin, an unprotected sign-in or a loosely scoped API token can expose a global workforce or redirect money. Most of the protection is in settings the customer controls: who holds which admin role, how people sign in, which integrations hold tokens and how payment changes are checked. This guide covers how identity and access work in Deel, the organisation admin roles and custom group roles, SSO and two-factor authentication, API tokens, SCIM and webhooks, logging, and a hardening baseline aimed at payment fraud. It is written for HR operations and payroll owners, identity engineers and security teams responsible for a Deel organisation.

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

Key takeaways

• Keep Organization Admin rare. Deel's Organization Admin role has the widest visibility and permissions, including managing admins, payment methods and API tokens; use the narrower IT Developer Admin, Integrations Admin and custom group roles for everyone else.
• Turn on SSO and require 2FA by role. Deel connects to identity providers over SAML 2.0 and OpenID Connect, and administrators can make two-factor authentication mandatory for specific roles under Access Management.
• Scope every API token. Deel offers organisation, personal and worker tokens with resource:read and resource:write scopes; give each integration its own token with the minimum scopes and rotate it on a schedule.
• Verify webhooks and watch request logs. Deel signs webhooks with HMAC-SHA256 in the x-deel-signature header, and Developer Center request logs keep 15 days of API calls, including rejected ones.
• Check payment changes out of band. Payroll diversion relies on convincing messages, so confirm any change to a worker's pay details or your organisation's payment methods with a known contact before the next pay run.

How identity and access work in Deel

A Deel organisation has three broad populations: admins on the client side who manage contracts, payroll and settings; managers and group members with scoped permissions; and workers (employees and contractors) who manage their own profile, documents and pay details. Groups divide the organisation, for example by entity, country or team, and roles can be scoped to groups.

Deel documents four organisation admin roles:

Workers sign in to their own accounts. Deel notes that without 2FA a user can still log in with an emailed one-time password but cannot perform sensitive actions until 2FA is enabled, which makes 2FA the gate for changes that matter.

Admin roles and privileged access

Custom group roles

Where the predefined roles are too broad, Deel lets admins create custom roles under Organization Settings, Access Management, Roles & Permissions. A custom role is scoped by group, can start from an existing role as a template, and sets permissions per category: People & Contracts, Tracker, Time off requests, Payroll & Payments, Documents, Custom Fields, Analytics & Reports, Taxes, Services, Group Settings and Other Settings. Members are then assigned to the role from the Admins tab in Access Management. Org admins can preview a role with the Simulate option in Admin Roles before assigning it.

• Separate preparing from approving: give the people who key adjustments and payroll items a role with Payroll & Payments edit rights for their group only, and give approval to a different person. See the Segregation of Duties Guide.
• Scope by group: a country payroll lead needs their entity's group, not the whole organisation.
• Use Simulate: check what a new role can see before you assign it, especially for Payroll & Payments and People & Contracts.
• Review quarterly: export the admin list, confirm each assignment with the person's manager and remove leavers the same day. See the Joiner-Mover-Leaver Guide.

Approval policies

Deel's approval policies, under Organization Settings, Approval Policies, support multiple approval levels with several approvers per level, plus substitutes and conditions. Deel's article describes them for time off, timesheets and other data change requests; pre-created policies can be modified but not deleted. Use multi-level approval wherever your instance offers it for changes that affect pay, and confirm which request types it covers in Deel's current documentation.

SSO and two-factor authentication

Single sign-on

Deel's help centre has set-up guides for SAML 2.0 (Okta, Microsoft Entra ID, JumpCloud, OneLogin) and OpenID Connect (Okta, OneLogin, Ping Identity). For SAML with Okta, Deel describes this flow: from the Hub icon, open the Apps tab, search for SAML 2.0 and click Connect; paste the identity provider's metadata URL and entity ID; copy Deel's redirect URL into the identity provider's single sign-on URL; assign users or groups in the identity provider; then click Enable in Deel's SAML 2.0 settings. Deel states that once SSO is enabled, the organisation requires SSO for any employee to log in. To remove it, open the integration, click More, then Disconnect.

• Put strong MFA at the identity provider: with SSO, the identity provider's sign-in policy protects Deel. Use phishing-resistant MFA for admins. See the Phishing-Resistant MFA Guide.
• Assign by group: grant the Deel application to identity provider groups that match your Deel populations, so removal from the group removes access.
• Protect the Integrations Admin, People role: it can change SSO, so treat it as privileged.

See the SAML Security Guide for assertion and certificate handling.

Two-factor authentication

Deel supports an authenticator app, which it describes as the most secure option, and an emailed six-digit one-time password. Users set up the authenticator under Profile Settings, Security tab, Set Up Authenticator. Administrators can make 2FA mandatory for specific roles under Access Management in Organization Settings. Deel notes that 2FA cannot be turned off once enabled, that only one authenticator device is connected at a time (a new one replaces the old), and that a user who loses both the authenticator and email access schedules a live video call with Deel Support.

Our recommendation: require 2FA for every admin role and every manager with Payroll & Payments permissions, and tell workers to use an authenticator app and keep their account email secure, because the email one-time password is the recovery path.

Integrations, API tokens and service accounts

Deel integrations are non-human identities with access to some of the most sensitive data you hold. Deel's developer documentation describes three token types:

Tokens are created under More, Developer, Access Tokens, Generate new token, where you choose the type, the scopes and sensitive data access. Scopes follow a resource:read and resource:write pattern, such as contracts:read, and the API reference lists the scopes each endpoint needs. The token is shown only once. Deel's own guidance is to grant the minimum scopes, store tokens in environment variables or a secrets manager rather than code, create separate tokens for separate integrations, delete unused tokens, rotate quarterly and immediately if compromise is suspected or when people with access leave. For third-party apps that need user consent, Deel recommends OAuth2.

• SCIM: the Deel SCIM API (SCIM 2.0, at https://api.letsdeel.com/scim) supports list, create, update, search and de-provision of users. Deel recommends only the Users:read and Users:write scopes for it. See the SCIM Provisioning Guide and the Identity Lifecycle Event Design Guide.
• Webhooks: Deel signs each webhook with HMAC-SHA256 over "POST" plus the raw body, using the signing key returned when you create the subscription, and sends the hex result in x-deel-signature. Verify it with a constant-time comparison on the raw body and reject mismatches. Deel retries failed deliveries up to 10 times and then disables the webhook until it is re-enabled, so alert on disabled webhooks.
• Sensitive data access: choose it only for tokens whose job requires personal or pay data.

See the API Key Management Guide and the Secrets Management Guide.

Logging and detection

Developer Center request logs keep 15 days of API requests, including rejected ones with their rejection reason, and a failed call can be found by its X-Request-ID header. Export what you need before the 15 days pass. For admin and payroll activity, use the Analytics & Reports area and the approval trail on each request, and confirm the audit reporting available on your plan with Deel.

Metrics that show it is working

• Number of Organization Admins (target two or three named people).
• Percentage of admin and payroll roles with mandatory 2FA or SSO (target 100%).
• Percentage of API tokens with a named owner, minimum scopes and rotation in the last 90 days.
• Percentage of pay detail changes verified out of band before the pay run (target 100%).
• Days from leaver to Deel access removal (target same day).

Hardening baseline

Rollout steps (NHI Mgmt Group recommendation)

1. Export the admin list and every API token and webhook, and record an owner for each.
2. Connect SSO with a pilot group of admins, test sign-in and recovery, then enable it for the organisation.
3. Make 2FA mandatory for admin roles first, then for managers with payroll permissions.
4. Build custom group roles, test each with Simulate, and move people off Organization Admin in small batches. Roll back by restoring the previous role for anyone who loses needed access.
5. Replace shared or broad tokens with one minimum-scope token per integration, then delete the old ones.
6. Write and train the payment change verification procedure, and add the detections above to your SIEM.

Small and large organisations

A small company with a handful of contractors can run with two Organization Admins, an authenticator app for everyone and a simple rule that any change to payment details is confirmed by phone. A multinational using Deel for EOR and global payroll should use groups per entity, custom roles per country, SSO with SCIM, multi-level approvals and SIEM ingestion of token and webhook events.

Common misconfigurations

• Everyone is an Organization Admin: it is the easiest role to grant and the broadest. Move people to scoped roles.
• 2FA optional for admins: make it mandatory by role, and pair it with SSO.
• One organisation token for every integration: a single broad token is hard to rotate and impossible to attribute. Use one per integration with minimum scopes.
• Personal tokens outliving their owner: personal tokens represent a user. Replace them when that person changes role or leaves.
• Unverified webhooks: a receiver that skips the x-deel-signature check will accept forged events.
• Pay detail changes accepted by email: attackers impersonate workers and ask payroll to update bank details. Require out-of-band confirmation. See the Payroll Diversion Fraud Guide.

Framework mapping

Practitioner checklist

• Limit Organization Admin to two or three named people and review all admin roles quarterly.
• Build custom group roles scoped by group and test them with Simulate.
• Enable SAML 2.0 or OpenID Connect SSO and assign the Deel app by identity provider group.
• Make 2FA mandatory for every admin and payroll role under Access Management.
• Issue one minimum-scope API token per integration, vault it and rotate it quarterly.
• Verify x-deel-signature on every webhook and alert when a webhook is disabled.
• Use SCIM with Users:read and Users:write only, and deprovision leavers the same day.
• Export Developer Center request logs before the 15 day window closes.
• Verify every pay detail and payment method change out of band before the pay run.

Standards and references

• Deel: What Are the Different Roles for Organization Admins in Deel?
• Deel: How to Create Custom Group Roles on Deel
• Deel: How to set up SAML 2.0 Integration with Okta for Single Sign On
• Deel: Two Factor Authentication (2FA) For Your Deel Account
• Deel Developer: API Tokens
• Deel Developer: SCIM API
• Deel Developer: Webhooks quickstart
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: SaaS Security Guide · Payroll Diversion Fraud Guide · Contractor Identity Lifecycle Guide · API Key Management Guide