A Developer’s Guide to Multi-Factor Identity Proofing for eSignatures

Hook: Why banks’ confidence is a dangerous baseline for identity

In January 2026 a PYMNTS analysis estimated that banks overestimate their identity defenses to the tune of $34 billion a year. For developers and IT teams building eSignature systems, that number is a reminder: legacy, checkbox identity checks are a liability, not a safeguard. If your signing workflows still treat a single document scan or an SMS OTP as sufficient proof, you're building on brittle assumptions attackers have already learned to exploit.

The 2026 landscape: what’s changed and why layered identity proofing matters now

Three trends that sharpen the need for layered identity proofing in 2026:

• Regulatory tightening — eIDAS updates, regional privacy rules and sector-specific mandates (finance, healthcare) push for stronger, auditable identity bindings for legal documents.
• More capable attackers — deepfake video, synthetic identities and organized bot fleets now routinely bypass single-factor checks.
• Better primitives for secure binding — widespread support for WebAuthn/FIDO attestation, verifiable credentials (DIDs), and richer risk scoring APIs let you combine signals into a tamper-evident identity assertion.

Core concept: layered identity proofing for eSignatures

Layered identity proofing means combining multiple, independent evidence sources so the overall assurance strength exceeds any single control. In an eSignature workflow you want to bind three things together in a verifiable, auditable way:

1. Who is signing (identity)
2. That identity is tied to the signing device and session
3. The document and the action (consent, timestamp, signature)

Key signal types to combine

• Document scans — ID images, MRZ, OCR, and data element extraction; useful for KYC and data matching.
• Biometrics — face match, liveness detection and passive behavioral biometrics for session-level assurance.
• Device attestations — FIDO2/WebAuthn attestation, platform integrity (Android Play Integrity / SafetyNet, Apple DeviceCheck / App Attest), TPM-backed keys.
• Risk signals — IP reputation, velocity, geolocation anomalies, fraud lists, email and phone intelligence, and third-party risk scoring.

Design pattern: a defensible identity proofing pipeline

The following architecture is production-ready for teams integrating with signing APIs. It is written to be vendor-agnostic and optimized for minimal engineering friction.

High-level components

• Frontend SDK — captures ID images, selfie, and invokes device attestation; does client-side telemetry collection (fingerprinting, user agent).
• Identity Microservices
  • ID OCR & parsing
  • Biometric matching & PAD (Presentation Attack Detection)
  • Device attestation verifier
• Risk Engine — aggregates signals, applies ML models or rules, and produces a risk score with reasons.
• Policy Engine — evaluates score and signals against your business policies and returns decisions (allow, step-up, deny).
• Identity Assertion Service — issues a signed assertion (JWT or verifiable credential) that contains the identity binding and evidence references.
• eSignature Provider — consumes the assertion and evidence to create an auditable signature (AdES/QES or provider-specific).
• Audit & Evidence Store — WORM storage with tamper-evident timestamps for evidence packages.

Practical, step-by-step integration with a signing API

Below is an actionable flow your engineering team can implement. Assume you already use an eSignature provider that supports adding custom metadata and attachments to signatures.

1) Session initialization and device attestation

1. Frontend requests a one-time session nonce from your backend.
2. Frontend performs WebAuthn registration or App Attest call; sends attestation object + nonce to backend.
3. Backend verifies attestation (certificate chain, signature, attestation format) and stores attestation result.

2) Capture identity documents and biometric evidence

1. User uploads ID front/back and a selfie video or live selfie via your SDK.
2. ID OCR microservice extracts fields (name, DOB, ID number, MRZ) and computes a document hash.
3. Biometric service performs a 1:N or 1:1 face match between selfie and ID portrait and runs PAD checks (liveness). Store match confidence and PAD result.

3) Risk scoring and contextual signals

Send the following to your Risk Engine:

• Attestation result and device properties
• IP address, ASN, VPN/Tor detection
• Velocity metrics (account creation time, previous auths)
• Email/phone intelligence and any negative indicators

The Risk Engine returns a numeric score and an explanation vector (features and weights).

4) Policy decision and identity assertion

1. Policy Engine applies rules (e.g., score < 30 = deny, 30–60 = step-up, > 60 = allow) and picks a remediation.
2. On allow/step-up success, your Identity Assertion Service issues a signed JWT or verifiable credential that contains:
• Subject identity claims (hashes, not necessarily PII)
• Evidence references (document hash, selfie hash, attestation ID)
• Risk score and policy decision
• Timestamp and signer (service key) signature

5) Attach identity assertion to eSignature request

1. When creating the signing envelope, include the signed assertion as a metadata attachment or as a verifiable claim linked to the signature object.
2. Ensure the eSignature provider records the timestamp and stores the assertion along with the signed document.
3. Persist the full evidence package (raw images, video, attestation objects) into a WORM store and reference its hash in the assertion.

Decisioning: thresholds, remediation, and UX

A good identity proofing implementation balances security and user friction. Use a risk-tiered policy:

• Low risk (score >= 75): proceed, minimal friction, attach assertion.
• Medium risk (50–74): step-up with strong MFA (WebAuthn/FIDO), request additional document, or session video.
• High risk (< 50): block and require live agent review or in-person verification.

Design seamless fallback flows: if WebAuthn is unavailable, fall back to a certified device attestation SDK or an identity wallet flow (verifiable credentials). Ensure every rejected or step-up flow is logged and the reason code is clear for compliance reviews.

Evidence packaging: making proofs tamper-evident and admissible

For legal admissibility and compliance, collect a minimum, verifiable evidence package that can be presented in disputes:

• Document image hashes and OCR output
• Selfie/video hash + liveness report
• Device attestation proof and related metadata
• Risk score and the feature vector
• Signed identity assertion (JWT or verifiable credential)
• eSignature audit trail including timestamps and signer IPs

Store the package in a WORM or cryptographically anchored store. Optionally anchor a merkle root to a public timestamping service or blockchain for stronger non-repudiation.

Privacy, retention and compliance considerations (GDPR, eIDAS, regional rules)

When you collect PII and biometrics, you become a data controller in the GDPR model. Key practical requirements:

• Purpose limitation — store only what is necessary to support the signing event and dispute resolution.
• Data minimization — store hashes instead of raw PII where possible; redact images in exports but preserve originals in secure WORM storage.
• Retention policies — align with legal hold requirements and local regulation (finance often needs longer retention). Implement configurable retention with audit logs.
• Consent and transparency — collect explicit consent for biometric processing and provide clear notices about how evidence will be used and stored.

Technical hardening: defenses against adversarial attacks

2026 attackers use AI-augmented deepfakes and synthetic identity farms. Defend with these technical measures:

• Advanced PAD — multi-modal liveness detection (depth, motion patterns, reflection analysis) and adversarial resistance testing (ISO/IEC 30107 alignment).
• Device key provenance — prefer TPM-backed or Secure Enclave keys and validate attestation certificates.
• Continuous signal fusion — combine device, behavioral, and environmental signals across the session, not just at proof time.
• Red-team and synthetic tests — regularly run deepfake attacks and synthetic identity tests against your pipeline and tune ML models.

Integration tips: SDKs, webhooks, and observability

• Use vendor SDKs for device attestation and capture to reduce client-side complexity, but validate attestation objects server-side.
• Design webhooks for asynchronous tasks (e.g., manual review results) and make them idempotent and signed.
• Log every decision with a decision ID; include the decision ID in the eSignature metadata so audit logs correlate easily.
• Expose developer feature flags to tweak thresholds in real time for A/B testing and gradual rollouts.

Advanced strategies and 2026 trends to leverage

• Verifiable Credentials and Wallets — increasingly adopted in the EU and some national ID programs. Allow users to present a verifiable credential from an eID wallet as an alternative to document scans.
• Decentralized Identifiers (DIDs) — for long-term identity portability and cryptographic proofs of claims.
• Federated identity & risk sharing — consortiums and regulated sectors increasingly share fraud signals via privacy-preserving APIs; integrating with these networks raises detection rates.
• Explainable risk models — regulators now expect explainability. Adopt models that output feature importance so reviewers can understand why a score was low.

Operational checklist for engineers and infra teams

• Implement server-side verification for all client-side assertions (attestation, OCR results, biometrics).
• Issue a signed identity assertion and ensure the eSignature provider records it atomically with the signed document.
• Store raw evidence in a WORM store and save only hashes in the primary DB.
• Instrument decision IDs across services to enable fast audits.
• Define clear risk thresholds and document remediation UX flows for each tier.
• Run periodic adversarial testing and update PAD models at least quarterly.

Case example: reducing fraud while improving completion

Bank X in 2025 replaced SMS-only verification with a layered proofing pipeline: document OCR + selfie liveness + WebAuthn attestation + risk scoring. They reported:

• 60% reduction in dispute-related chargebacks within 6 months
• 25% drop in manual review volume due to higher automated decision accuracy
• Improved completion rates because step-ups were targeted only at high-risk flows

These outcomes mirror industry research that shows incremental layers reduce fraud while keeping wholesome UX for low-risk users.

"When 'good enough' isn’t enough: organizations must move to layered identity proofing to maintain growth and reduce fraud costs." — Industry analysis, January 2026

Final notes: measuring success and iterating

Measure the right KPIs: fraud rate, false positive rate (legitimate users blocked), completion rate, manual review volume, and time-to-decision. Use these to tune your risk model and policy thresholds. In 2026, continuous improvement combined with explainable models and cross-industry signal sharing will be the differentiator for teams that want both security and scale.

Actionable takeaways

• Stop treating single-factor checks as sufficient — combine document, biometric, device and risk signals.
• Issue a signed identity assertion and attach it to the eSignature envelope for legal traceability.
• Store evidence in tamper-evident storage and keep only necessary PII in active databases.
• Use WebAuthn/FIDO attestation and verifiable credentials where possible to strengthen device and identity binding.
• Implement tiered risk policies with targeted step-ups to reduce friction for low-risk users.

Call to action

If you’re evaluating eSignature integrations or ready to harden an existing pipeline, we can help map a layered identity proofing architecture to your product requirements and compliance needs. Contact our engineering team for a technical workshop and a 90-day integration plan that balances assurance, UX, and regulatory compliance.

Related Reading

• Is RGBIC Lighting Worth It for Phone Photographers and Content Creators?
• Turn Your Business Data into Tax Savings: Use Analytics to Find Deductions and Credits
• How to Score Media Partners: Lessons from Disney’s Big-Event Ad Sales
• Optimizing Research Essays for AI-Powered Answers: Formatting, Headings and Source Signals
• When Bystanders Become Protectors: Liability and Insurance Considerations for On-Site Interventions