OneSpan Sign turns eSignature into a broader identity control surface

At a glance

What this is: OneSpan’s eSignature offering combines signing workflows with identity controls such as SSO, passkeys, SMS authentication, audit trails, and delegated access.

Why it matters: That matters because signing platforms often sit inside broader identity, access, and workflow governance, so their authentication and delegation choices affect human IAM, NHI-adjacent integrations, and accountability.

By the numbers:

• 20 languages.

👉 Read OneSpan’s eSignature pricing and feature details

Context

OneSpan Sign is not just a document workflow tool. It is a signing surface where authentication, delegation, auditability, and embedded access controls determine whether a signature process is trustworthy enough for regulated business use. In identity terms, the product sits at the edge of human access governance, with integrations that can extend into enterprise systems and customer-facing portals.

The governance gap is that many organisations treat eSignature as a back-office utility rather than an identity boundary. Once signing is embedded into apps, connected to SSO, or delegated across teams, it becomes part of the control plane for who can approve, route, and complete transactions. That makes the authentication model and the audit trail more important than the user interface.

For teams standardising identity controls across human, workload, and workflow systems, this is a reminder that access patterns do not stop at login. The signing workflow itself can create privilege, delegation, and evidentiary risk if it is not aligned with IAM policy and retention rules.

Key questions

Q: How should organisations govern eSignature platforms in IAM programmes?

A: Treat eSignature as a governed identity workflow, not a convenience layer. Define who may send, sign, delegate, and administer transactions, then align those roles with IAM policy, review cadence, and legal retention requirements. The platform should produce an evidentiary trail that connects the transaction to a verified identity and an accountable owner.

Q: When is SMS authentication not enough for document signing?

A: SMS is weak when a signed agreement carries legal, financial, or regulatory consequence. Codes can be forwarded, intercepted, or reused, so SMS should not be the default for high-assurance signing flows. Use phishing-resistant methods such as passkeys or smart cards when the business needs stronger proof of the signer’s identity.

Q: What do security teams get wrong about delegated signing?

A: They often treat delegation as a convenience feature instead of a privileged access decision. If another user can sign on someone’s behalf, the organisation needs an approval path, an expiry date, and a clear record of why the delegation existed. Otherwise, accountability becomes ambiguous and audit evidence weakens.

Q: How can teams prove who actually signed a document?

A: By combining authentication evidence, transaction logs, and a retained audit trail that records the signer, the delegate if one was used, the sequence of actions, and the final transaction state. If those records are fragmented or overwritten, the organisation may have a completed workflow but not a defensible identity record.

How it works in practice

Signing workflows as an identity control surface

An eSignature platform is effectively a controlled transaction environment. It binds a signer, a document, a sequence of actions, and an evidentiary record into one workflow. Features such as signing order, delegated access, reusable templates, and embedded signing change who can act, when they can act, and how the action is recorded. From an identity perspective, the platform is enforcing workflow authorisation, not just capturing a graphic signature. That means the trust question is less about the visual mark and more about whether the platform can prove the identity path, the approval path, and the transaction state at each step.

Practical implication: Map signing roles and delegation rules to IAM policy so approval rights are explicit and reviewable.

Authentication methods and assurance levels

The product supports multiple identity proofing and authentication methods, including SSO, SMS authentication, passkeys, knowledge-based checks, government ID verification, biometrics, and smart cards. These methods do not provide the same assurance. SSO ties the signing event to an upstream identity provider, while SMS and knowledge-based methods often provide weaker resistance to interception, social engineering, or shared-secret reuse. Passkeys and smart cards improve phishing resistance because they bind authentication to cryptographic possession and device trust. The architectural question is not how many methods exist, but whether the chosen method matches the transaction’s risk and regulatory profile.

Practical implication: Require stronger authentication for high-value signing flows and avoid using low-assurance methods as a default.

Audit trails, delegation, and evidentiary integrity

A detailed audit trail only helps if the event log is complete, durable, and tied to the true actor behind each action. Delegated signing and bulk send introduce operational efficiency, but they also complicate accountability if reviewers cannot distinguish original signer intent from delegated completion. Expiry dates, reminders, and in-app reporting help operational control, yet they do not solve the governance problem by themselves. The control question is whether the organisation can reconstruct who initiated the transaction, who completed it, and which identity source authenticated the signer. Without that chain, the audit record becomes descriptive rather than evidentiary.

Practical implication: Preserve signer provenance, delegation records, and transaction logs in a system of record with retention aligned to legal and compliance needs.

NHI Mgmt Group analysis

OneSpan Sign shows how document signing has become an identity workflow, not a standalone business feature. Once a platform handles authentication, delegated access, embedded signing, and audit logging, it participates in the identity control plane. That means IAM teams should judge it by assurance, traceability, and delegation behaviour, not by convenience alone. The practitioner takeaway is to govern signing as a privileged workflow.

Passkeys and smart cards matter more than SMS when the signing event carries legal or financial weight. SMS authentication is common, but it is not equivalent to phishing-resistant authentication. When a signing platform supports cryptographic factors, the assurance ceiling rises because the signer identity is anchored to device-bound credentials rather than a code that can be forwarded or intercepted. Practitioners should treat factor choice as a policy decision, not a UI preference.

Delegated signing creates an accountability boundary that many approval processes do not model well. The platform can let another person act on behalf of an absent user, but the organisation still has to decide whether that is an approved delegation, an emergency exception, or an access-control weakness. This is where access governance and workflow governance intersect. The practitioner implication is to define delegation rights with the same discipline used for temporary privilege.

Embedding eSignature inside portals and applications expands the risk surface beyond the signing vendor itself. Once signing is integrated into CRM, HRIS, or customer-facing systems, identity assurance depends on upstream controls, session handling, and application-side entitlement design. The signing step becomes one part of a larger chain of trust. IAM and security teams should therefore evaluate the full path from application entry to signed completion, not just the point solution.

eSignature platforms create lifecycle obligations that look familiar from NHI governance even when the actor is human. Templates, delegated roles, bulk send, and account access all need joiner-mover-leaver discipline, recertification, and revocation logic. The named concept here is signing workflow governance: a policy layer that defines who may initiate, approve, delegate, and evidence a transaction. Practitioners should align that policy with the business process, not leave it embedded in application defaults.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why control confidence and control reality diverge.
• For a broader control baseline, see Ultimate Guide to NHIs for lifecycle, rotation, and governance patterns that translate across identity types.

What this signals

Signing platforms are increasingly part of the identity stack, which means governance teams need to review them the way they review other access-critical systems. The practical shift is from treating eSignature as a document utility to treating it as a controlled approval boundary. That matters most where embedded signing or delegated access can alter who is able to complete a regulated transaction.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, identity teams are already operating in a world where trust boundaries leak across systems. That concern is not limited to code. Any workflow that moves sensitive identity data, approvals, or authorisations through integrations needs similar scrutiny, including signing platforms connected to HR, CRM, or customer portals.

signing workflow governance: the policy layer that defines who may initiate, approve, delegate, and evidence a transaction. As enterprises embed more business processes into identity-aware applications, the control question becomes whether the workflow can still prove provenance after delegation, automation, and integration have done their work.

For practitioners

• Classify signing roles as governed access Map sender, signer, delegate, approver, and admin roles to explicit IAM and business-owner accountability so each authority is reviewable and revocable.
• Prefer phishing-resistant authentication for high-value signing Use passkeys or smart cards for legally sensitive or financially material agreements, and restrict SMS or knowledge-based methods to lower-risk use cases.
• Treat delegated signing as privileged access Require a documented delegation reason, expiry, and reviewer approval before another user can sign on someone’s behalf.
• Preserve evidentiary logs outside the application Export transaction logs, signer provenance, and audit trails into retention-controlled storage so legal and compliance teams can reconstruct the full chain of events.

Key takeaways

• eSignature is an identity governance problem when authentication, delegation, and auditability determine who can complete a transaction.
• Weak signer assurance and poorly defined delegation can undermine the evidentiary value of a completed document workflow.
• IAM teams should govern signing roles, factor strength, and audit retention with the same discipline they apply to privileged access.

Key terms

• Signing Workflow Governance: The policy and control layer that defines who may initiate, approve, delegate, and evidence an eSignature transaction. It turns signing from a convenience process into a governed identity workflow, with accountability, reviewability, and retention requirements that can stand up to audit or dispute.
• Phishing-Resistant Authentication: An authentication method that resists credential capture and replay because it binds the signing event to cryptographic proof or device-held trust. In signing workflows, passkeys and smart cards provide stronger assurance than reusable secrets or one-time codes sent over channels that can be intercepted.
• Delegated Signing: A model where one person is authorised to complete a signing action on behalf of another user. It is operationally useful but governance-heavy because the organisation must distinguish approved delegation from casual substitution, and retain evidence of who acted, under what authority, and for how long.

Deepen your knowledge

Identity assurance, delegated access, and auditability in signing workflows are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending IAM controls into embedded business workflows, it is worth exploring.

This post draws on content published by OneSpan: eSignature plan and pricing for OneSpan Sign. Read the original.