Cross-Device Signing

Signers often open a portal link on their desktop but prefer to sign on their phone, or need to hand off to a colleague on a different device mid-session. VaultESign's cross-device transfer lets a signer move seamlessly to any other device without restarting the session, re-sending invitations, or bypassing security controls.

The mechanism is a one-time QR transfer token: a 256-bit cryptographically random URL minted on demand, redeemed once, and expired immediately. The new device must pass the same OTP identity challenge before it can access the signing session. The entire token lifecycle is tracked in your Azure Table Storage.

User Experience

On the OTP / Identity Page

When a signer opens their portal link on desktop, a "Continue on your phone" panel appears automatically alongside the identity verification form. No action required. The QR code is ready to scan immediately.

The signer scans the QR code with their phone's camera. Their phone opens the same signing session URL. They verify their identity via OTP on the phone. Once verified, the phone becomes the active signing device and the desktop session becomes read-only.

Inside the Signing Session

After OTP verification, a "Continue on another device" button appears in the left sidebar, visible before signing begins. This lets a signer who has already verified on desktop transfer to their phone (or any other device) before completing the signature fields.

Tapping the button expands a QR panel with the same one-time token flow. The new device must complete OTP verification. Once verified, signing continues on the new device from exactly where it left off.

How the Transfer Works

Desktop (original device)              Phone (new device)
────────────────────────               ──────────────────
Portal generates QR code
  ↓ POST /api/sessions/{id}/transfer-token
  ← 256-bit one-time token
  ← QR encodes {portalUrl}?xt={token}

                                       Scan QR → GET /api/x/{token}
                                         ↓ token validated & consumed
                                         ↓ vp_device cookie set
                                         ↓ redirect → /sign/{sessionId}

                                       OTP challenge (email/SMS)
                                         ↓ POST /api/sessions/{id}/verify-otp
                                         ↓ device binding updated
                                         ↓ redirect → /sign/{sessionId}/signature

                                       Signing continues on phone

The QR code refreshes automatically every 8 minutes (token TTL is 10 minutes). A countdown timer is displayed so signers are never caught with an expired code mid-scan.

Security Architecture

One-Time Token

Each token is:

• 256-bit cryptographically random, generated via crypto.getRandomValues, not a hash or predictable sequence
• Single-use: consumed and deleted on first redemption; replay is impossible
• 10-minute TTL: expired tokens are rejected even if not yet redeemed
• Stored in your Azure Table Storage (vaultpdfxtokens); Vault Shared Services holds no copy

Device Binding

When a token is redeemed, the portal sets a vp_device HttpOnly, Secure, SameSite=Strict cookie on the new device. This cookie:

• Is not readable by JavaScript, making it immune to XSS exfiltration
• Is scoped to the signing session
• Updates the session's deviceToken in Azure Table Storage to match the new device

If the original desktop device attempts to submit a signature after the phone has taken over, the device token mismatch causes the submission to be rejected.

OTP Re-Verification on the New Device

Scanning the QR code does not bypass OTP verification. The new device must complete the full OTP identity challenge: the same email or SMS code the signer used on the original device. This ensures:

• The person holding the phone is the same person who opened the original portal link
• Transfer cannot be exploited to hand off a signing session to an unauthorized third party
• The audit trail records OTP verification on each device that participated in the session

Double-Sign Prevention

The signing completion route uses an ETag conditional write on the session slot in Azure Table Storage. If two devices somehow reach the completion route simultaneously (e.g., a race condition after a transfer), only one write succeeds. The second attempt receives a conflict error and is rejected. A session slot can only be signed once.

Audit Trail

Every cross-device transfer is recorded in the session audit trail under your Azure Blob Storage. The evidence certificate includes:

This provides complete traceability: who signed, on which device, after how many device transfers, with OTP verification on each device.

Token Expiry and Refresh

The countdown timer displayed in the QR panel refreshes every second. If the timer reaches zero before scanning, the portal generates a fresh token automatically. The signer does not need to take any action.

Constraints and Considerations

• One active device at a time. Once a token is redeemed and the new device completes OTP verification, the original device's session becomes secondary. Signing on the original device after a successful transfer will be rejected.

• Transfers are not chained. If a signer transfers from Desktop to Phone to Tablet, each transfer requires a new QR scan and OTP verification on the incoming device. Each hop is recorded independently in the audit trail.

• Session expiry is unaffected. Cross-device transfer does not extend the session TTL. If the session expires between the QR scan and the OTP verification on the new device, the transfer fails and the session cannot be recovered.

• Mobile optimisation. On mobile screens (viewport width below 768 px), the QR panel is replaced with a Copy Link option. The transfer URL is copied to clipboard for the signer to share to another device manually. The security model is identical; the same OTP challenge applies.

Infrastructure