E-Signature Platform Compromise Playbook

A compromised e-signature account lets an attacker send genuine signing requests in your organisation's name, read every contract and identity document in it, and alter the templates that carry prices, bank details and terms. E-signature platforms sit between sales, HR, procurement and finance systems, so they hold API keys, OAuth grants, webhooks and sender roles that act without a human in the loop. The incident can begin with a phished administrator or sender, a leaked integration key, an over-scoped connected app, or a breach at the provider. This playbook covers how the compromise shows up, triage, containment by priority, rotating integration credentials, checking whether signed documents and templates can still be trusted, warning counterparties and notification. It is vendor-neutral and written for incident responders, SaaS owners, legal and finance teams. Normal hardening is covered in the Electronic Signature Workflow Security Guide; this page assumes the controls there have failed or were never applied.

Key takeaways

Fraud first, forensics second. Stop outbound signing requests and freeze payments tied to recent envelopes before investigating, because genuine-looking requests from your account are what make this incident profitable.
Integrations are the quiet path. API keys, impersonation grants and connected apps can send and download documents without anyone signing in, so revoke them alongside user sessions.
The archive is a data breach. Completed envelopes often hold personal data, identity documents and bank details, so scope downloads from the start.
Templates and in-flight envelopes need an integrity check. A changed bank field or recipient on a template affects every document sent from it after the change.
Warn counterparties through a channel you trust. Tell customers and suppliers what genuine requests look like, using contact details already on file, not the platform.

What the platform can reach

This is NHI Mgmt Group's view of common e-signature components and what each gives an attacker. Names differ by product; map your own before an incident.

Component	What an attacker gains	First containment action
Administrator accounts	User, role, SSO, retention and integration control; persistence	Disable compromised admins; restrict administration to a break-glass account
Sender accounts and shared mailboxes	Genuine signing requests in your name to customers, suppliers and staff (T1534 Internal Spearphishing for internal recipients)	Suspend the accounts; revoke sessions at the identity provider
Templates and branding	Silent edits to payment details, prices, terms and routing	Lock templates; export current versions for comparison
Envelope archive	Contracts, HR files, identity documents and bank details (T1530 Data from Cloud Storage)	Review download and export history; restrict archive access
API keys and integration users	Unattended sending and bulk download through the API	Revoke keys; disable integration users
Impersonation or "act as user" grants	Ability for an integration to send as any user	Remove the grants until each integration is reviewed
Connected apps (OAuth) to CRM, HR, storage	Tokens that read documents or push data out (T1528 Steal Application Access Token)	Revoke grants on both sides
Webhooks and callbacks	Redirection of completion events, or forged "completed" events that trigger downstream payments or onboarding	Check endpoint URLs; rotate webhook secrets

How the compromise shows up

Counterparties ask about requests you did not send: often the first signal, from customers or suppliers who received an unexpected envelope from your genuine account.
Payment and bank detail changes arriving as signed documents: a supplier "update" form or invoice signed through your platform, requested from an account that does not usually handle finance.
Bulk sends or unusual recipients: volumes above baseline, or envelopes to personal and lookalike domains.
Template edits: changes to locked templates, especially fields holding bank details, amounts or recipient routing.
Envelope corrections: recipients or documents swapped on in-flight envelopes.
Bulk downloads or exports: archive exports, certificate downloads or API document retrievals at unusual volume.
New API keys, integrations, connected apps or webhook URLs: persistence that survives a password reset.
Mailbox signs alongside: new forwarding rules on the sender's mailbox (T1114.003 Email Forwarding Rule), which often accompany account takeover and hide replies.

Triage: the first hour

Where did it start? A user account (phishing, password reuse, token theft), an integration key or connected app, or the provider.
What has been sent? List envelopes sent in the window by the affected identities, recipients and template used.
Is money moving? Identify envelopes that change bank details, approve invoices or authorise payments, and alert finance immediately.
What was taken? Check archive exports, downloads and API retrievals; note envelopes with identity documents or payment data.
Which integrations exist? List every API key, integration user, impersonation grant, connected app and webhook, with owner and scope.
Is access ongoing? Active sessions, recent API calls or new envelopes in the last hours mean containment starts now.

Containment by priority

Stop outbound sending. Suspend compromised senders and pause bulk send jobs. Void in-flight envelopes the attacker created, after recording their details as evidence.
Freeze dependent payments. Hold any payment or bank detail change backed by an envelope from the window until confirmed by phone on a number already on file. If money has already gone, the FBI's IC3 advises contacting your financial institution straight away to request a recall and filing a complaint with IC3 promptly, whatever the amount.
Revoke integration access. Revoke API keys, disable integration users and remove impersonation grants. Revoke OAuth grants in the platform and in the connected application. RFC 7009 notes that revoking a refresh token should also invalidate access tokens from the same grant where the server supports it; otherwise access tokens may remain valid until expiry, so watch for use during that window.
Cut user sessions at the identity provider. Reset credentials and revoke sessions for affected users, and remove any local password login if SSO is available. Microsoft's guidance for compromised applications starts by disabling the service principal's sign-in for an app registration used by an integration.
Lock templates and archive access. Restrict template editing to a named owner and remove broad archive sharing.
Secure webhooks. Remove unknown callback URLs and rotate the shared secrets or keys used to sign them. Downstream systems should confirm envelope status through the API before acting on any callback.
Lock the tenant. Remove unknown administrators, SSO changes, domain claims and retention changes.

Rollback: record each role, key, grant, template and webhook changed with its previous state, so legitimate business processes can be restored one at a time.

Credential rotation and trust reset

Credential or trust	Rotation action	Check afterwards
Platform API keys and integration secrets	Revoke all, issue new keys only for reviewed integrations, store them in a secrets manager	No API calls signed with old keys
Impersonation and consent grants	Re-grant per integration to a dedicated service user with named templates and folders	Grant list matches the integration inventory
Connected app OAuth tokens	Re-consent with the narrowest scopes	Old refresh tokens rejected
App registrations used by integrations	Microsoft's playbook: add a new certificate, then remove every old password and key credential on the application and service principal	No unexpected credential additions afterwards
Webhook secrets or signing keys	New secret per endpoint; HMAC or HTTP Message Signatures (RFC 9421) verified by the receiver	Callbacks signed with the old secret are rejected
User credentials and recovery methods	Reset, re-register phishing-resistant MFA, remove attacker-added methods	No sign-ins from attacker infrastructure
Secrets inside documents	Rotate passwords, keys or account numbers found in downloaded envelopes	Owners confirm rotation

See the API Key Leak Response Playbook and the Webhook Secrets Security Guide for the detail on keys and callbacks.

Where identity fits

Most e-signature volume is sent by non-human identities: CRM, HR and procurement integrations holding keys or impersonation grants that can send any document to anyone in the organisation's name. In the Salesloft Drift breach, OAuth tokens stored for a third-party integration were used to export data from hundreds of connected tenants without anyone being phished. Rebuild with one integration identity per business process, scoped to the templates it needs, an owner and a rotation date. See the OAuth Token Theft Incident Playbook.

Can signed documents still be trusted?

Responders must tell legal which agreements are sound, which are suspect and which are fraudulent.

Document group	Risk	Action
Completed before the window, sealed and unchanged	Low	Validate the seal or signature and the recorded hash; keep as is
Sent from templates edited during the window	Terms or bank details may be altered	Compare with the trusted template version; contact counterparties for anything that differs
Sent by compromised identities during the window	Possibly fraudulent	Treat as suspect; void if in flight; confirm completed ones out of band
Corrected mid-flow (recipient or document changed)	Recipient substitution	Review the audit trail for each correction
Completed by signers whose inboxes were compromised	Signer impersonation	Check the signer authentication method recorded and confirm with the signer

The audit trail carries the case. Under eIDAS Article 26, an advanced electronic signature must be linked to the signed data so that any subsequent change in the data is detectable, which is why validating the platform's seal or signature on completed files is the first integrity test. Under the US ESIGN Act, 15 U.S.C. 7001(d), electronic retention satisfies a legal retention duty only where the record accurately reflects the information and remains accessible for the required period, so export completed documents and certificates of completion to your own records store and keep them under legal hold. See the eDiscovery and Legal Hold Guide.

Eradication and recovery

Restore templates from a trusted version, with named owners and change alerts on payment, price and routing fields.
Remove persistence: unknown users, keys, connected apps, webhook URLs, sending domains and mailbox forwarding rules.
Reconnect integrations one at a time with new scoped credentials, testing in a sandbox account where the platform provides one.
Re-enable senders after MFA re-registration, starting with low-risk teams; finance and HR senders last, with a second reviewer on high-value envelopes.
Raise signer authentication for payment and identity documents to access codes or identity verification for a period after the incident.

Evidence, counterparties and notification

Platform records: audit log, envelope histories, certificates of completion, template version history, API and download logs, integration and webhook changes.
Identity records: identity provider sign-in logs and MFA changes for affected users.
Mail records: message traces for signing notifications and mailbox rule changes.
Finance records: payment instructions, recall requests and bank correspondence.

Warn counterparties who received envelopes from compromised identities, using contact details already on file, and tell them which platform and sender address you genuinely use. Under GDPR Article 33 the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach; a processor must tell the controller without undue delay. Article 34 requires informing individuals where the breach is likely to result in a high risk, unless an exception in Article 34(3) applies. Identity documents and bank details in the archive usually push the assessment towards high risk. See the Cyber Incident Reporting Requirements Map.

Decision guidance

Situation	Choose	Trade-off
One sender account, no integrations touched	Suspend the user, void their envelopes, warn recipients	Fast, but confirm no API keys were created
Integration key or connected app leaked	Revoke all integration credentials, reconnect one by one	Business processes pause until reconnected
Administrator compromised	Full tenant review and rotation of every credential	Days of reduced signing capacity
Provider-side breach	Rotate keys and grants, scope archive exposure with the provider	Relies on the provider's scope statement
Small organisation	Suspend, rotate, phone counterparties from a written list	Manual but quick
Large organisation	Scripted key and grant revocation, template diff against version control	Needs an integration inventory kept current

Detection and measurement

Time to stop sending: from first report to compromised senders and integrations suspended.
Integration inventory accuracy: percentage of keys, connected apps and webhooks with an owner and rotation date.
Template change alerts: edits to locked templates traced to an approved change (target all).
Payment verification rate: bank detail changes confirmed out of band before payment (target all).
Webhook verification coverage: receivers that verify signatures and confirm status through the API.
Counterparty notice time: from scoping to warnings sent to affected recipients.

Framework mapping

Framework	Reference	Where it applies
NIST CSF 2.0	RS.MA-01, RS.AN-03, RS.AN-06, RS.MI-01, RS.MI-02, RC.RP-05	Coordinated response, root cause, recorded actions, containment, eradication, verified restoration
NIST SP 800-53 Rev. 5	IR-4, IR-6, AC-2, AC-6, IA-5, SA-9, AU-9, AU-10, SI-7	Incident handling, accounts, least privilege, authenticators, external services, audit protection, non-repudiation, integrity
CIS Controls v8.1	Control 5, Control 6, Control 9, Control 15, Control 17	Accounts, access, email, service providers, incident response
ISO/IEC 27001:2022 Annex A	5.19, 5.23, 5.24 to 5.28, 5.33	Supplier and cloud service security, incident management and evidence, protection of records
MITRE ATT&CK	T1199, T1528, T1550.001, T1534, T1114.003, T1530, T1657	Trusted relationship, token theft and use, internal phishing, mailbox rules, document collection, financial theft

Common failure patterns

Resetting the password and stopping. API keys, impersonation grants and connected apps keep working after a user reset.
Telling finance late. Recall chances fall quickly once a fraudulent transfer has left; finance belongs in the first hour.
Warning counterparties by e-signature or reply email. Use known contact details, or the warning itself looks like the attack.
Trusting completion webhooks. Downstream systems that pay or onboard on a callback without checking status through the API can be triggered by forged events.
Ignoring the archive. Bulk downloads of identity documents and contracts turn a fraud incident into a notifiable data breach.
Reconnecting every integration at once. A missed key or grant comes back with them.

Practitioner checklist

Keep an inventory of senders, administrators, templates, keys, connected apps and webhooks with owners.
Know how to suspend senders and pause bulk sends in minutes.
Bring finance in within the first hour and hold dependent payments.
Revoke API keys, impersonation grants and OAuth grants on both sides.
Diff templates against trusted versions; classify documents by trust group.
Validate seals and hashes on completed documents; export evidence under legal hold.
Rotate webhook secrets and require receivers to verify and confirm status.
Warn counterparties using contact details already on file.
Reconnect integrations one at a time with scoped service users.
Run the notification analysis with legal and the data protection officer.

If your e-signature platform is compromised: containment, credential rotation and rebuild playbook