eSignature signing URLs need authentication, not trust by default

At a glance

What this is: This is an eSignature security analysis showing that public signing URLs need authentication because link possession alone does not prove signer identity.

Why it matters: It matters because IAM, PAM, and lifecycle teams often secure access to systems while leaving transaction-level trust gaps open in customer and partner signing flows.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read OneSpan's guidance on securing eSignature signing URLs with authentication

Context

A signing URL is a transaction link that grants access to documents waiting for signature. When that link is public and not bound to authentication, the security model relies on secrecy rather than identity, which is a weak foundation for legal, compliance, and fraud-sensitive workflows.

The gap matters most in business-to-customer and partner journeys, where links can traverse email, SMS, gateways, and monitoring systems before reaching the intended recipient. Once a signing workflow depends on a bearer link, the organisation must treat the transaction as an identity problem, not just a document delivery problem.

Key questions

Q: How should security teams protect public eSignature signing URLs?

A: Security teams should require signer authentication before any document can be opened, because a public signing URL is a bearer link, not proof of identity. They should also segment workflows by exposure type, use stronger authentication for higher-risk transactions, and treat any message path that can read the link as part of the trust boundary.

Q: Why do public signing links create identity risk?

A: Public signing links create identity risk because possession of the URL often becomes the only gate to the transaction. If email, SMS, or downstream systems can expose that link, an attacker or unintended recipient may reach sensitive documents without proving they are the signer.

Q: What do organisations get wrong about eSignature authentication?

A: The common mistake is assuming that the communication channel proves identity. It does not. Authentication must be tied to the signing step itself, and the method should reflect the sensitivity of the document and the acceptable fraud risk.

Q: When should teams use stronger authentication for signing workflows?

A: Teams should use stronger authentication when the signing transaction carries legal, financial, or high-PII risk, or when the link may travel through multiple systems before reaching the recipient. Higher assurance is warranted whenever impersonation would create material harm.

Technical breakdown

Public signing URLs are bearer links, not proof of identity

A public signing URL behaves like any other bearer token. Whoever holds the link can reach the signing ceremony unless the workflow adds a second control that binds the transaction to the intended signer. That distinction matters because the transaction may contain contracts, mortgage files, account opening records, or other documents carrying PII. In practice, the trust boundary is not the email or SMS channel, but the authentication step before document access. Without that step, the system proves link possession, not signer identity.

Practical implication: require authentication before document access whenever the signing URL is exposed outside a protected application session.

Signer authentication turns transaction access into identity verification

Signer authentication can use knowledge factors, possession factors, certificates, passkeys, or government identity systems, depending on risk and user experience. The point is not to overload every signature with the strongest possible method, but to match assurance to the transaction. Higher-risk agreements need stronger proof than low-risk acknowledgements. Layered authentication can also reduce the chance that a forwarded link, intercepted message, or harvested URL becomes a valid signing path.

Practical implication: set authentication strength by document risk, not by convenience alone.

Embedded flows change the exposure model

Embedded or integrated eSignature flows are different from public links because access is mediated through the application session rather than a directly exposed signing URL. That does not eliminate identity risk, but it shifts control to the app authentication boundary. Organisations need to distinguish between link-based ceremonies and embedded transactions, because the control design, monitoring, and abuse path are not the same. Treating both as equivalent leads to false confidence in the protection model.

Practical implication: classify each signature workflow by exposure type before deciding which controls are actually required.

Threat narrative

Attacker objective: The attacker wants to access sensitive signed-document workflows and extract identity data that can be reused for fraud or impersonation.

1. Entry occurs when attackers or automated scanners discover exposed signing URLs that were distributed by email or SMS and are reachable without authentication.
2. Escalation happens when the bearer link is used to open the transaction, exposing documents, personal information, and potentially account-opening or contract data.
3. Impact follows when harvested PII or contract details are reused for impersonation, social engineering, or unauthorized agreement access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Signing URL exposure is a transaction identity problem, not a document delivery problem. The security failure begins when organisations assume the link itself can stand in for signer verification. That assumption is weaker than the controls used for login, privileged access, or API access, even though the business consequences can be just as severe. The practitioner conclusion is simple: the workflow must prove who is signing, not merely who clicked.

Bearer-link trust creates a standing-access pattern inside the signing flow. A public signing URL behaves like persistent access until it is protected by authentication and transaction binding. That makes the problem structurally similar to unmanaged secrets in NHI governance, where possession is mistaken for authority. The practitioner conclusion is that link-based signing should be treated as exposed access, not as a neutral convenience layer.

Transaction assurance and legal enforceability now intersect with identity governance. If a signer cannot be authenticated, organisations lose both security confidence and evidentiary strength. This is where IAM and compliance requirements converge: proof of identity is part of control integrity, not just user experience. The practitioner conclusion is that eSignature governance belongs in the same review cycle as other high-risk identity-controlled workflows.

Authentication strength should follow transaction risk, not channel habit. SMS, email, certificates, passkeys, and government credential systems each shift assurance differently, and the right choice depends on the document type and the signer's context. That means organisations should stop treating authentication as a single default setting. The practitioner conclusion is to segment signing journeys by risk, then map authentication to the segment.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which is why bearer-link style access deserves the same scrutiny as other exposed credentials.
• For a broader threat pattern, see 52 NHI Breaches Analysis for root-cause patterns that show how exposed access turns into downstream compromise.

What this signals

Bearer-link governance is becoming part of identity security, not just workflow design. As organisations automate more customer and partner journeys, the control question shifts from whether a link is convenient to whether it is bound to a trusted identity. Teams that already manage machine identity and privileged access should treat exposed signing URLs as another form of access surface, then align them to the NIST Cybersecurity Framework 2.0 functions for protect and detect.

Link possession is not evidence of entitlement. That distinction matters because the same operational weakness appears across unmanaged credentials, delegated access, and low-friction transaction flows. In practice, the quickest win is to identify every signing path that can be reached without an authenticated session and remove the assumption that channel controls equal identity controls.

The next step is to connect transaction assurance to lifecycle governance, especially where signature rights are issued to customers, partners, or contractors. If the organisation cannot say when a signing entitlement begins and ends, then the workflow has an access lifecycle problem as much as a security problem. For deeper context, practitioners should compare these flows with the lifecycle patterns discussed in the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

For practitioners

• Classify signing URLs by exposure model Separate embedded application sessions from public link workflows, then require different controls for each. Public links should never be assumed safe because they travel through email or SMS.
• Bind signature access to signer authentication Require a verified identity step before any document is shown, especially for contracts, mortgage files, and account-opening flows that carry PII.
• Match assurance to document risk Use stronger methods for higher-risk transactions, such as passkeys, certificates, or government credential systems, and reserve lighter methods for lower-risk use cases.
• Review message-path exposure for signing links Check whether gateways, filtering systems, or monitoring tools can see signing URLs before the intended recipient does, then remove any assumption that message privacy equals transaction privacy.

Key takeaways

• Public signing URLs are vulnerable because link possession can replace identity proof unless authentication is enforced at the transaction boundary.
• The scale of the risk is not just data exposure, but also weakened legal assurance when sensitive agreements can be opened without verifying the signer.
• Practitioners should classify each eSignature flow by exposure, bind access to authentication, and raise assurance for higher-risk documents.

Key terms

• Signing URL: A signing URL is a web link that opens an eSignature transaction for a document waiting to be signed. In risk terms, it is a bearer mechanism unless the workflow adds authentication, because link possession can be enough to reach the transaction and its data.
• Signer authentication: Signer authentication is the control that verifies the person opening a signing transaction is the intended recipient. It can use knowledge, possession, certificate, or identity-verification factors, and it should be selected according to the sensitivity of the document and the fraud impact of misuse.
• Transaction binding: Transaction binding is the practice of tying access to a specific signing action, account, or authenticated session rather than a generic link. It reduces the chance that a forwarded or intercepted URL can be used outside the intended identity context.
• Bearer link: A bearer link is a URL that grants access to a resource based on possession alone. In eSignature workflows, bearer links are risky because they can be copied, forwarded, or captured by intermediary systems before the intended signer authenticates.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by OneSpan: eSignature security tip, How to protect your signing URLs against cyberattacks. Read the original.