DocuSign Security: Hardening SSO, Admin Roles, API Integrations and Signers

A DocuSign account holds contracts, HR files and payment instructions, and it can send legally binding requests in your organisation's name, so the login, integration permissions and defences against fake envelopes all need care. Most organisations secure the people who sign but not the account that sends: shared sender logins, admin rights spread widely, JWT integrations that impersonate a user indefinitely and webhook listeners that accept any request. This guide covers how identity works in Docusign eSignature and Docusign Admin, privileged roles, API integrations and their credentials, logging, a hardening baseline and the phishing that abuses the brand. It is written for identity, SaaS and security teams who own the platform, and for evaluators checking how it can be locked down. Product names and settings are from Docusign and Microsoft documentation checked on 8 November 2026; labels in the console change, so match them to what you see.

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

Key takeaways

• Claim your domain and put SSO in front of it. Docusign Admin lets you claim an email domain by DNS TXT record and connect a SAML identity provider, so sender logins follow your joiner, mover and leaver process.
• Treat JWT impersonation as a privileged credential. A JWT Grant integration with the impersonation scope can act as a user long term without that user present; Docusign itself says to use Authorization Code Grant when you do not need that level of trust.
• Keep admins few and separate. Organisation administrators control domains, identity providers and users across accounts; account admins (the DS Admin permission profile) control eSignature settings. Both belong in your privileged access process.
• Authenticate signers by document risk. Access codes, phone or SMS codes, knowledge-based authentication and ID verification exist; match them to what the envelope is worth.
• Teach the safe path to open documents. Genuine requests come from @docusign.net, never arrive as file attachments, and can be opened with the security code on the Access Documents page rather than the email link.

How identity and access work in Docusign

Docusign separates the organisation, managed in Docusign Admin, from one or more eSignature accounts. Users are members of accounts and receive a permission profile in each. The organisation layer holds the controls that matter most for identity: claimed (reserved) domains, identity providers and organisation-wide user management. Docusign's developer documentation states that production use of the Admin API requires Docusign Admin enabled on an enterprise account.

Domain claim and single sign-on

1. Claim the domain: in Docusign Admin, Domains, Claim Domain, then add the validation token as a DNS TXT record and wait for the domain to show as active. Claiming the domain is what lets you govern every user with that email suffix.
2. Add the identity provider: under Access Management, Identity Providers, add a SAML 2.0 provider with the issuer, login URL, logout URL and signing certificate from your IdP, and copy Docusign's service provider endpoints back to the IdP. Microsoft's Entra ID tutorial for Docusign walks through these exact fields.
3. Decide on provisioning: the Entra tutorial notes just-in-time provisioning is on by default, creating a user at first SSO sign-in. Automatic provisioning can create, update and disable users, and set permission profiles from IdP app roles; it provisions users only, not groups, and needs a Docusign user with Team Admin permissions to connect. See the SCIM Provisioning Guide.
4. Require SSO for claimed-domain users once testing is complete, and keep a small number of break-glass administrators who can sign in if the IdP fails.

Without a claimed domain and SSO, every sender has a separate Docusign password and leavers keep access until someone closes their account by hand. Docusign also describes customer-configurable multi-factor authentication for eSignature; enforce it for any user who cannot use SSO. See the SAML Security Guide.

Signers are a different identity problem

Recipients usually have no Docusign account; they prove control of an email address by clicking a link. For higher-risk envelopes, Docusign's eSignature documentation lists four recipient authentication methods that can be combined:

For embedded signing inside your own application, the documentation notes that the authenticationMethod value only records how your app authenticated the signer on the certificate; Docusign does not enforce it, so your application's own login must be strong.

Admin roles and privileged access

• Organisation administrators: control domains, identity providers, organisation users and, through the Admin API, bulk user import, permission profile assignment and account access revocation. Compromise of one equals control of every claimed-domain identity. Limit to two or three named people, require SSO with phishing-resistant MFA, and review quarterly.
• Account administrators: users with the DS Admin permission profile change eSignature security settings, signing settings, Connect configurations, integration consent and users within that account. Grant through IdP roles, not by hand.
• Senders and viewers: use the least capable profile that works, and create custom permission profiles for teams that must not send on behalf of others, edit templates or see all envelopes.
• Shared mailboxes and team senders: a shared login for "contracts@" removes accountability. Use individual users with shared templates or folders, or a dedicated integration identity for automated sends.
• Admin consent: organisation admins can grant consent for an integration to impersonate users across the organisation. Treat consent grants like any OAuth app approval: record owner, purpose and scopes, and review them. See the SaaS and OAuth App Governance Guide.

Integrations, API tokens and service accounts

Docusign APIs use OAuth 2.0. Every integration has an integration key (its client ID) created in the developer console, plus a secret key or an RSA keypair depending on the grant. These are non-human identities and need owners, rotation and monitoring. See the Non-Human Identity (NHI) Guide.

• Protect the RSA private key: whoever holds it can mint tokens as any user who consented. Keep it in a secrets manager or HSM, never in code or CI variables visible to many people, and rotate by adding a new keypair before removing the old one. See the Secrets Management Guide.
• Impersonate a dedicated user: point JWT integrations at a purpose-built integration user with a narrow permission profile, not at a real administrator. A stolen key then sends envelopes but cannot change settings.
• Request only needed scopes: signature covers most eSignature calls; add impersonation only for JWT, cors only for browser apps, and Admin API scopes such as organization_read only for directory tools.
• Verify every Connect message: validate the HMAC signature over the raw body before acting, reject unsigned messages, and rotate keys by adding a second key, updating the listener, then removing the first. Mutual TLS and OAuth for Connect are further options in the documentation. See the Webhook Secrets Security Guide.
• Inventory integrations: list every integration key in each account, its owner, grant type, consented users and last use; remove keys with no owner.

Relevant ATT&CK techniques are T1528 Steal Application Access Token and T1550.001 Application Access Token for stolen keys and tokens, and T1078.004 Cloud Accounts for taken-over sender logins.

Logging and detection

Every completed envelope carries a Certificate of Completion, which Docusign describes as providing non-repudiation, and an envelope history of who viewed, signed or declined and from where. That is evidence for disputes, not a security monitoring feed. For monitoring, Docusign offers Docusign Monitor, described as round-the-clock activity tracking for agreements, with a Monitor API to pull events into a SIEM; check your licence before planning on it. Your IdP sign-in logs cover SSO users, and the Admin API can export users and permission profiles for regular reconciliation.

Signals worth alerting on:

• New organisation or account administrator, or a permission profile gaining admin rights.
• Changes to identity providers, claimed domains, SSO requirement or account security settings.
• New integration key, new admin consent or new Connect configuration pointing to an unfamiliar URL.
• Bulk envelope downloads or exports, or one user viewing an unusual number of envelopes.
• Envelopes sent to many external recipients from a user who rarely sends, or templates changed shortly before high-value sends (payment details are a common target).
• Sign-ins outside SSO for claimed-domain users.

Metrics: share of active users signing in through SSO; number of organisation and account admins; integration keys with a named owner and rotation in the last 12 months; Connect listeners validating HMAC; share of high-value envelope types using ID verification or phone authentication; reported Docusign-themed phishing per month and time to block.

Hardening baseline

Rolling it out: (1) inventory admins, integrations and Connect listeners; (2) claim domains and connect the IdP in allow mode with a pilot group; (3) move admins and then all senders to required SSO, keeping two break-glass accounts; (4) migrate JWT integrations to dedicated users and vaulted keys; (5) turn on HMAC and alerting. Roll back an SSO problem by switching the requirement back to optional for affected users while break-glass admins fix the IdP configuration. Small teams can stop after SSO, MFA and admin reduction; large or regulated organisations should add Monitor or equivalent logging, recipient ID verification for high-value workflows and formal integration reviews.

Common misconfigurations

• No claimed domain: staff create personal Docusign accounts with corporate email addresses that the company cannot see or close.
• JWT integration impersonating an admin: the private key becomes a skeleton key for the account. Impersonate a narrow integration user instead.
• Private key in source control: integration keys and RSA keys committed to repositories or pasted in tickets. Scan for them and rotate on exposure.
• Webhook listener without HMAC: anyone who finds the URL can post fake "envelope completed" events that trigger payments or provisioning.
• Phone authentication to attacker-supplied numbers: taking the SMS number from the requester's email defeats the check. Use numbers from your own records.
• Trusting the sender domain alone: a fake that spoofs Docusign fails the @docusign.net check, but an envelope sent from an attacker's own Docusign account passes it. Verify the requesting company and any payment change out of band. See the Business Email Compromise Awareness for Finance Teams Guide.

Phishing that uses the Docusign brand

Docusign's Safety Center lists spear phishing, whaling, smishing, vishing and QR code phishing using its name (T1566.002 Spearphishing Link). Its guidance: check that the sender ends in @docusign.net; remember that Docusign never sends signature requests as a file attachment; hover over links; and open documents by entering the security code at the Access Documents page (apps.docusign.com/sign/access) rather than clicking. Report suspicious emails by forwarding them as an attachment to [email protected] or using the Report Email link, and tell your own security team. Build these into awareness training and into mail filtering rules that flag "Docusign" display names from other domains. See the Phishing Guide.

Practitioner checklist

• Claim every corporate email domain in Docusign Admin and connect your SAML identity provider.
• Require SSO for claimed-domain users, with two documented break-glass administrators.
• Enable automatic provisioning so leavers lose access the day they leave.
• Reduce organisation and account admins to named individuals and review quarterly.
• Move each JWT integration to a dedicated low-privilege user with its RSA key in a vault.
• Validate HMAC signatures on every Connect listener and reject unsigned messages.
• Set a recipient authentication policy by envelope type, using ID verification for high-value documents.
• Send admin, identity provider, consent and integration changes to your SIEM.
• Teach staff the security code and Access Documents route and the [email protected] reporting address.

Standards and references

• Docusign Developer Center: Authentication overview
• Docusign Developer Center: JWT Grant
• Docusign Developer Center: Connect HMAC security
• Docusign Developer Center: Recipient authentication
• Docusign Trust Center: eSignature security
• Docusign: Safety Center
• Microsoft Learn: Microsoft Entra SSO integration with Docusign
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · Webhook Secrets Security Guide · Email Identity and BEC Guide