Dropbox Sign Security: Signers, API Keys and Audit Trails

An e-signature account holds contracts, offer letters and identity documents, and its API keys can send signature requests and pull completed documents on behalf of the whole account, so both the people and the integrations that use Dropbox Sign need deliberate controls. This guide covers the customer-side settings Dropbox documents for Dropbox Sign (formerly HelloSign): team roles, SAML SSO, signer authentication with access codes and SMS, API keys and OAuth apps, callback verification, and the audit trail attached to each signed document. It is written for Dropbox Sign admins, developers who build on the API, and the security and legal operations teams who rely on signed records. For Dropbox file storage controls, see the Box and Dropbox Security Guide; for choosing an e-signature platform, see the E-Signature Platform Security buyer's guide.

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

Key takeaways

Keep API rights with Admins and Developers only. In Dropbox Sign only the Admin and Developer roles can create API apps, use an API key in production and make API signature requests.
Move admins to SSO after testing. SAML SSO is configured under Admin console > Security; turn off "Allow standard logins for admins" once SSO is proven.
Turn on signer authentication for sensitive documents. Admins enable SMS, access codes or both; senders then add a check per signer, with access codes shared outside the request email.
Treat API keys as long-lived secrets. Keys stay valid until deleted, each account can hold up to four, and the Primary Key also signs callback event hashes, so plan rotation with callback verification in mind.
Use the audit trail as evidence. Each signed document carries a hashed transaction trail with timestamps, IP addresses and a PDF hash you can use to check for later changes.

How identity and access work in Dropbox Sign

A Dropbox Sign team has members in one of four roles, set by admins, and on Premium plans can be split into multiple teams, each with its own admins and team managers. Team members cannot automatically see other teams' documents. Signers are separate: they usually have no account at all and reach a document through a link in an email, which is why signer authentication matters.

Single sign-on

SAML SSO is available on the Premium plan. An admin opens Admin console > Security > SSO and enters the Single Sign-On URL, Issuer and X.509 certificate from the identity provider, which sends attributes including first and last name.

Admin fallback: Dropbox advises keeping Allow standard logins for admins on during setup and testing so an SSO fault does not lock admins out.
Enforce for admins: once SSO is verified, turn that option off so admins also sign in through SSO. Keep one documented recovery route with Dropbox support for an identity provider outage (our recommendation).
Lifecycle: as of November 2026 the Dropbox Sign SSO article describes user management in the admin console rather than SCIM, so add Dropbox Sign to your joiner, mover and leaver runbook and reconcile members against your identity provider each month (our cadence).

See the Identity Provider and SSO Security Guide for identity provider settings such as phishing-resistant MFA and session length.

Leavers

Dropbox documents two leaver actions. Locking a user stops access while keeping the user, documents and templates, and it can be reversed. Removing a user is final: before removal, review whether documents, templates and API apps need a new owner, and export any reports you need, because reports for a removed user are no longer available. Our recommendation: lock on the leaver date, transfer ownership, export reports, then remove. See the SaaS deprovisioning guide.

Admin roles and privileged access

Capability (Dropbox docs)	Admin	Team Manager	Member	Developer (API plans)
Send and receive signature requests	Yes	Yes	Yes	Yes
Change team settings and role permissions	Yes	Yes
Add and remove team members, lock users out, reset passwords	Yes	Yes
Run reports, manage billing and subscriptions	Yes	Yes
Create API apps, use API key in production, make API signature requests	Yes			Yes
Access team documents; access and share team templates	Yes

Two points follow from this matrix. First, the Admin role combines settings, user management, API rights and access to every team document, so it is the most sensitive identity in the account: keep it to two or three named people. Second, Team Manager can reset passwords and change settings, so treat it as privileged too, and give day-to-day user administration to Team Managers rather than more Admins. Give API work to the Developer role (on API plans) instead of making developers Admins. Review role assignments each quarter (our cadence). See the SaaS Admin Account Protection guide.

Signer verification

Signers prove who they are mainly by having access to an email inbox. Signer authentication adds a second check before the document opens.

Method	How it works (Dropbox docs)	Best for	Handling
Access code (password)	The sender sets a code per signer; it is not included in the request email	Signers you can reach by phone or another channel	Share the code by phone, text or a separate message, never in the same email thread
SMS	Dropbox Sign sends a one-time code to the signer's mobile number	Sensitive or regulated documents where you hold a verified phone number	Take the number from your own records, not from the requester
Request attachments	Signers upload supporting files such as photo ID or proof of address; up to five per signer, which can be required	Onboarding and identity-dependent agreements	Store attachments under the same retention and access rules as the signed document

Turning it on

An admin opens Admin console > Settings > Signature Requests > Signature Request Options, switches on Signer authentication, selects SMS, password or both, and saves. Admins can also manage each member's ability to require authentication.
Senders add authentication on the Who needs to sign? page, through the three-dot menu next to each signer, choosing an access code or text message. Each signer needs their own code.
If the option is missing for a sender, the admin has not enabled it, which is the first thing to check.

Signer reassignment lets a signer pass a request to someone else, with assigned fields transferred and the sender notified. For high-value agreements, our recommendation is to watch for reassignment notifications and confirm the new signer before countersigning. Decide which document types must use signer authentication (for example HR, finance and customer onboarding) and record that in policy. See the Digital Signatures Guide for the difference between electronic and cryptographic signatures.

Integrations, API tokens and service accounts

API keys

API keys authenticate with HTTP Basic authentication, the key as username and a blank password. They are managed on the API tab of the API Settings page, where you can create, rename, delete and set a primary key.

Property (Dropbox docs)	What it means for you
Up to four keys per account, all active	Use one key per integration so you can rotate or delete one without touching others
One Primary Key, which signs the callback `event_hash`	Changing the primary key changes callback verification; update receivers first
Keys remain valid until deleted and carry the account's API access	Rotate on a schedule (our view: at least every 90 days) and on any staff or supplier change
Keys belong to one account and cannot be transferred	Create keys under a dedicated integration account owned by the platform team, not a person

Store keys in a secrets manager, never in code or tickets. A rotation runbook that works: create a new key, deploy it to the integration, confirm traffic, then delete the old key. If the key is the Primary Key, move callback verification to the new key in the same change. See the API Key Management Guide and the SaaS API Token Security Guide.

OAuth apps

Apps that act for other Dropbox Sign users use OAuth. Access tokens are sent as bearer tokens, act for the user who authorised them, expire after one hour and are renewed with a refresh token through the oauthTokenRefresh endpoint. The access scopes are set on your API app and shown to users during authorisation, so request only the scopes the app needs and store refresh tokens as secrets. Keep a register of your API apps with owner and purpose. See the SaaS and OAuth App Governance Guide.

Callbacks

Account and app callbacks: account callbacks cover the whole account; app callbacks fire for API requests that include the app's client_id.
Verify every event: compute HMAC-SHA256 over event_time concatenated with event_type, keyed with your API key, and compare with event_hash before acting.
HTTPS only: callback URLs must use HTTPS; Dropbox stopped sending to non-HTTPS URLs from 1 December 2024.
Source addresses: Dropbox publishes a JSON list of IP addresses events may come from; use it as an extra filter and check it periodically.
Reliability: your endpoint must return HTTP 200 with "Hello API Event Received". Failed deliveries are retried up to six times over about 20 hours, and after ten consecutive failures the callback URL is cleared, so monitor delivery.
Download timing: wait for signature_request_downloadable before downloading final files.

See the Webhook Secrets Security Guide.

Logging and detection

The audit trail

Dropbox Sign records and timestamps activity from the moment a document is submitted for signature until it is fully signed, including details such as IP addresses. The transaction log is hashed so tampering can be detected, each audit trail carries an identifier that links to the stored log, and the records include a hash of the PDF that you can compare with a disputed copy. You can choose to receive the audit trail as a separate file rather than appended to the signed document. Self-signed documents using the "Just Me" option have no audit trail because there is only one signer.

Keep audit trails with the signed documents in your records system under the same retention rules. When a signature is questioned, compare the PDF hash first, then review timestamps, IP addresses and authentication events in the trail.

Account monitoring

Signal	Source	Why it matters
New Admin, Team Manager or Developer assignments	Admin console reviews and reports	Privilege growth
API key created, deleted or primary key changed	API Settings and change records	New or changed non-human credentials
Callback delivery failures and cleared callback URLs	Your receiver logs and Dropbox email notices	Missed events or misdirected callbacks
Unexpected API signature request volume	Your integration logs and Dropbox Sign reports	Possible misuse of a key
Signer reassignment notices on sensitive requests	Sender notifications	Signer substitution

Metrics that show it is working:

Number of Admins and Team Managers (trend down, named people only).
API keys with an owner and a rotation date within policy (target 100%).
Share of sensitive document types sent with signer authentication.
Callback events that fail event_hash verification (target zero, investigate any).
Days between a leaver's last day and account lock.

Hardening baseline

A phased rollout. Role changes and signer authentication settings revert in the admin console; test SSO with admin standard login still on.

Inventory: list members by role, API apps, API keys and their owners, callback URLs and teams.
Right-size roles: keep Admin to named people, use Team Manager for user administration and Developer for API work.
Configure SAML SSO (Premium), test with a pilot group, then turn off Allow standard logins for admins.
Enable signer authentication with SMS and access codes, and publish which document types require it.
Rework API keys: one key per integration under a dedicated account, stored in a vault, with a rotation runbook.
Harden callbacks: HTTPS, event_hash verification, IP filtering and delivery monitoring.
Review OAuth apps: minimal scopes, refresh tokens in a vault, owner recorded.
Set records handling: decide on separate audit trail files and store them with signed documents.
Build the leaver process: lock, transfer ownership, export reports, remove.
Schedule reviews: quarterly role and API reviews, monthly member reconciliation (our cadences).

Organisation profile	Priority choices
Small team, web use only	Few Admins, signer authentication for sensitive documents, documented leaver steps
Premium with multiple teams	SAML SSO, admins per team, Team Managers for user work, monthly reconciliation
API plan with integrations	Developer role, key per integration, callback verification, OAuth scope review, key rotation runbook

Common misconfigurations

Developers made Admins: this also grants access to every team document. Use the Developer role.
Access code in the same email thread: anyone with the inbox then has both. Share codes by another channel.
One API key shared by every integration: rotation becomes a big-bang change. Use a key per integration.
Callbacks accepted without verification: always check event_hash before acting on an event.
Primary key changed without updating receivers: callback verification then fails. Change both together.
Users removed before export: reports for removed users are gone. Lock, transfer and export first.

Follow Dropbox's product and security notices and apply recommended changes to integrations promptly.

Framework mapping

Dropbox Sign control	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK technique it helps address
SAML SSO, admin standard login off	IA-2	PR.AA-03	T1078.004 Cloud Accounts
Role design, lock and remove process	AC-2, AC-6	PR.AA-05	T1098 Account Manipulation
API keys per integration, OAuth scopes, rotation	IA-5	PR.AA-01	T1528 Steal Application Access Token
Signer authentication	IA-8	PR.AA-03	T1213 Data from Information Repositories
Audit trail retention, callback verification	AU-10, AU-6	PR.PS-04	T1213 Data from Information Repositories

Practitioner checklist

Admin role limited to named people; Team Manager and Developer used for narrower jobs.
SAML SSO configured and Allow standard logins for admins turned off after testing.
Members reconciled with the identity provider each month; leaver process locks, transfers, exports, removes.
Signer authentication enabled and required by policy for sensitive document types.
Access codes shared outside the request email.
One API key per integration, in a vault, with an owner and a rotation date.
Callback receivers on HTTPS, verifying event_hash, with delivery monitoring.
OAuth apps registered with minimal scopes and vaulted refresh tokens.
Audit trails stored with signed documents under the records retention policy.

Dropbox Sign Security: How to Protect Signers, API Keys and Audit Trails