An Acrobat Sign account holds contracts, HR forms and customer data, and the people and applications allowed to send, read and sign those agreements are set by a handful of customer-side settings. Acrobat Sign security splits into three layers that administrators control: how internal users sign in (Adobe Admin Console identity and SSO), how external recipients prove who they are before they sign (identity verification methods), and how integrations reach agreements through the REST API (OAuth applications, scopes and webhooks). This guide walks through each layer with the setting names from Adobe's documentation, a hardening baseline and the logs to watch. It is written for Acrobat Sign account administrators, identity teams and the developers who build Sign integrations. For the cryptography behind signatures themselves, see the Digital Signatures Guide.
This is an independent guide from NHI Mgmt Group, based on Adobe's public documentation as of November 2026. It is not sponsored or reviewed by Adobe. Product features change, so confirm settings against Adobe's current documentation.
Key takeaways
- Federate internal users through the Admin Console. Adobe documents Federated ID as the only identity type that supports SSO with Adobe products, so it is the route to your own MFA and joiner, mover and leaver process.
- Signer identity is set per account, per group and per agreement. Account Settings > Send Settings sets the enabled methods and default; groups inherit and can override, and each agreement uses the settings of the group it is sent from.
- Scope modifiers decide the blast radius of an API token. A scope with the :account modifier lets an application act for any user in the account, and only an account admin can approve it.
- Refresh tokens stay valid while they are used. Adobe's developer guide gives access tokens a one-hour life and refresh tokens a 60-day inactivity expiry that resets on each use, so revocation is a deliberate step.
- The audit report is evidence and a disclosure surface. Decide whether the transaction verification page may show audit reports without sign-in, and which events the report includes.
How identity and access work in Acrobat Sign
Adobe's Acrobat Sign security overview (October 2023) lists three ways for internal users to sign in: an Acrobat Sign ID (verified email address and password), an Adobe ID, and single sign-on through SAML so administrators can manage users from the company identity system. Enterprise accounts are usually entitled and managed through the Adobe Admin Console, where identity is configured once for all Adobe products.
| Identity route | Who authenticates the user | When to use it |
|---|---|---|
| Federated ID (Admin Console) | Your identity provider over SAML 2.0, or the Microsoft Entra and Google Workspace connectors that Adobe documents | Default choice for staff accounts: your MFA, Conditional Access and deprovisioning apply |
| Enterprise ID (Admin Console) | Adobe, with the account owned by your organisation | Where federation is not yet in place |
| Adobe ID | The user, with an Adobe-managed account | Individual or small team use; plan how access is removed when someone leaves |
| Acrobat Sign ID | Acrobat Sign, with email and password | Accounts not entitled through the Admin Console; apply the account password policy |
Setting up federation: in the Admin Console, create a directory under Settings > Identity > Directories, connect it to one identity provider, then claim and verify your email domains and link them to the directory so users on those domains are routed to your IdP. Several directories can segment authentication policy by business unit. The detailed Admin Console hardening (admin roles, directory trusts, user sync) is in the Adobe Admin Console Security guide.
Password policy where Acrobat Sign IDs remain: the security overview describes admin-configurable password complexity and strength, change frequency, reuse comparison and lockout rules. Set these for any account that still has non-federated users.
Recipient identity verification
External signers rarely have an account, so Acrobat Sign verifies them per agreement. Adobe's Signer Authentication Methods page defines internal recipients as active users with the same email address in the same Acrobat Sign account, and everyone else as external. The methods are configured at Account Settings > Send Settings > Signer Identification Options.
| Method | Factor type (per Adobe) | Key behaviour | Fits |
|---|---|---|---|
| Acrobat Sign Authentication | Single factor | Recipient logs in to Acrobat Sign; Adobe states it is not a second factor | Internal countersigning |
| One-Time Password via Email | Single factor | Code to the same address as the signing link | Low-value external agreements |
| Signer password | Second factor | Sender sets it and shares it out of band; not recoverable | Known counterparties |
| Phone | Second factor | Six-digit code by text or voice, valid ten minutes | Most external agreements with a known number |
| Knowledge-Based Authentication | Second factor | Questions from personal history; USA recipients only | US consumer agreements |
| Government ID | Second factor | ID document plus selfie; Adobe says it is not intended for regulated or high-value workflows on its own | Remote onboarding with human review |
| Cloud-based digital signatures and Digital Identity | Second factor | Third-party or federated identity provider chosen by the admin | Regulated signatures, eIDAS workflows |
Phone, KBA, Government ID and cloud-based digital signatures are metered premium methods. Second-factor methods can cancel an agreement automatically after a set number of failed attempts. A separate control, "different identity authentication methods for internal recipients", lets you apply a lighter method set to internal users while keeping a stronger default for external signers. For the legal side of qualified signatures in the EU, see the eIDAS Qualified Trust Services Guide.
Admin roles and privileged access
Adobe describes Acrobat Sign authority levels that run from Senders up to Privacy Administrators, with each level adding access to the account's agreements and the tools to manage them. In practice there are four tiers to govern:
- Account admin: controls account-level settings (security, send, global and audit report settings) and is the only role that can approve OAuth requests with the :account scope modifier.
- Group admin: manages settings and users for a group, overrides inherited account settings, and can approve OAuth requests with the :group modifier.
- Privacy admin: a separate promotion ("Promote users to privacy admin status" in Adobe's user management pages) that sits at the top of the authority levels and is used for privacy requests. Confirm its exact capabilities in Adobe's current documentation and treat it as privileged, because privacy tooling can remove records.
- Admin Console roles: system and product admins in the Admin Console can entitle users to Acrobat Sign and edit their roles, so they sit above Sign admins in practice.
What to do: keep account admins to a named few with federated, MFA-protected identities; use group admins for departmental delegation; grant privacy admin only to the people who handle data subject requests; and review all three lists quarterly alongside Admin Console roles (our recommended cadence).
Integrations, API tokens and service accounts
Every Acrobat Sign API integration is an application created under Account (or API) > API Applications. Adobe's developer guide describes two application domains: CUSTOMER for apps that access only your own account, and PARTNER for apps that need access to other Acrobat Sign accounts, which must be certified for full access.
| Element | What Adobe documents | Customer-side control |
|---|---|---|
| Application ID and secret | Issued on the application's View/Edit page; the client secret authenticates the application | Store the secret in a secrets manager; rotate when staff or vendors change |
| Redirect URI | Must be a secure, absolute HTTPS URI from the set registered on the OAuth configuration page | Register exact URIs only; remove test hosts before go-live |
| Scopes | For example agreement_read, agreement_send, user_login, webhook_read, webhook_write; requested scopes must be a subset of those enabled | Enable only what the integration calls. Adobe notes it is easier to enable everything in development, so re-scope before production |
| Modifiers | self (default), group (group admin must approve), account (account admin must approve) | Prefer self; justify every :account scope in writing |
| state parameter | Adobe highly recommends it to protect against CSRF | Require it in code review |
| Access and refresh tokens | Access token 3,600 seconds; refresh token expires after 60 days of inactivity, reset on each use | Revoke through /oauth/v2/revoke when an integration is retired; revoking a refresh token revokes its access tokens |
| Webhooks | HTTPS URLs only; verification by echoing the X-AdobeSign-ClientId header; two-way SSL supported; webhook OAuth 2.0 needs the account setting WEBHOOK_OAUTH20_ROLLOUT enabled by Adobe support | Validate the client ID on every notification, not only at registration |
- Service users: integrations that send on behalf of a department are often authorised by one admin. If that person leaves, the token may keep working or break without warning. Authorise integrations from a dedicated, documented integration user with an owner, and record which scopes and modifiers it approved.
- Integration keys: Adobe's samples still mention integration keys as an alternative to OAuth tokens. Inventory any that exist and move integrations to OAuth applications, where scopes and revocation are explicit (our recommendation).
- Refresh token hygiene: because a used refresh token never ages out, treat every stored refresh token as a long-lived credential. See the OAuth Refresh Token Rotation and Expiry Guide and How to detect use of a stolen OAuth refresh token.
Logging and detection
- Audit report per agreement: the security overview describes a certified PDF audit trail recording each participant at every workflow step, a separate CSV export of form field values, and the certified signed agreement with a digital certification seal. Options under Account Settings > Global Settings > Audit Report, such as "Include view events", change what the report records; turn view events on if you need evidence of who opened an agreement.
- Verification page access: the setting "Allow unauthenticated access to audit report on transaction verification page" lets anyone with a valid transaction ID open the audit report without signing in. Clear it at account or group level if audit reports contain information you do not want disclosed that way.
- Settings Activity Audit report: an admin report in Acrobat Sign's reporting section that records changes to settings. Export it on a schedule so a settings change (for example, a weaker default identity method) is visible to the security team.
- Admin Console logs: user entitlement and role changes are made in the Admin Console, so its audit log belongs in the same review.
- Webhook events as telemetry: events such as AGREEMENT_EMAIL_OTP_AUTHENTICATED and AGREEMENT_RECALLED_MAX_SIGNING_EMAIL_OTP_ATTEMPTS can be forwarded to a SIEM to spot repeated verification failures.
Metrics: percentage of Sign users on Federated ID; number of account admins and privacy admins; number of API applications with any :account scope; percentage of external agreements sent with a second-factor method; days since the last review of API applications and their owners.
Hardening baseline
- Identity first: move staff to Federated ID in the Admin Console, enforce MFA at the IdP, and remove or convert stray Adobe IDs on your domains.
- Set signer defaults at account level: in Signer Identification Options require senders to pick a method other than None, enable the methods you use, set a second-factor default for external recipients and decide whether senders may change it. Use group overrides for stricter teams such as HR and legal.
- Review Security Settings: Adobe's Security Settings section includes allowed IP ranges for users and APIs, administrator managed sharing, agreement sharing controls, document password strength, document link expiration, blocking signers in specific geographies, blocking iframe embedding and customer-managed encryption. Decide on each and record the decision.
- Re-scope API applications: for each application, confirm domain, owner, redirect URIs, enabled scopes and modifiers; disable unused scopes and delete unused applications.
- Configure the audit report: choose view event inclusion and verification page access deliberately; retain exported reports in your records system.
- Test and roll back safely: trial new identity defaults in a pilot group first (group settings override the account), then promote them to account level. Rolling back is a settings change at the same level, and agreements already in flight keep the method they were sent with unless the sender edits them.
Common misconfigurations
- Treating Acrobat Sign Authentication as MFA: Adobe states it is not a second-factor method. Pair it with a second factor where the agreement warrants one.
- Development scopes left in production: an application built with every scope enabled, then approved with :account modifiers, can read and send for every user.
- Integrations tied to a personal admin: tokens authorised by an individual stay in use after that person changes role. Use a documented integration user.
- Group overrides nobody remembers: a group can override a strong account default with a weaker one. Review group-level identity settings as part of each settings audit.
- Webhook endpoints that skip client ID checks after registration: Adobe expects the same client ID behaviour on POST notifications, so validate it on every request.
Framework mapping
| Control area | Acrobat Sign setting | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| Federated authentication | Admin Console Federated ID, SAML | IA-2, IA-8 | PR.AA-01 |
| Signer identity proofing | Signer Identification Options | IA-8 | PR.AA-02 |
| Least privilege for apps | OAuth scopes and modifiers | AC-6 | PR.AA-05 |
| Audit evidence | Audit report, Settings Activity Audit | AU-2, AU-10 | DE.CM-03 |
Practitioner checklist
- Move all staff Acrobat Sign users to Federated ID with MFA enforced at the identity provider.
- List account admins, group admins, privacy admins and Admin Console admins; remove anyone without a current need.
- Set a second-factor default identity method for external recipients and require senders to choose a method.
- Review group-level overrides of identity and security settings.
- Inventory API applications: owner, domain, redirect URIs, scopes and modifiers; remove unused ones.
- Revoke refresh tokens for retired integrations and move any integration keys to OAuth applications.
- Validate X-AdobeSign-ClientId on every webhook request and use HTTPS endpoints you control.
- Decide on audit report view events and unauthenticated verification page access, and document the choice.
- Export the Settings Activity Audit report on a schedule for security review.
Standards and references
- Adobe: Acrobat Sign security overview
- Adobe: Acrobat Sign signer authentication methods
- Adobe: Unauthenticated access to the audit report on the verification page
- Adobe: Set up identity with SSO (Admin Console)
- Adobe: Acrobat Sign Developer Guide, create an application and configure OAuth
- Adobe: Acrobat Sign Developer Guide, managing OAuth tokens
- Adobe: Acrobat Sign Webhook Guide
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Adobe Admin Console Security · Digital Signatures Guide · OAuth Scope Design Guide · API Keys vs OAuth Tokens Guide