Choose signer authentication by risk, not habit

Delivery proves routing, not identity

An email link shows that a person obtained a message sent to an address. It does not automatically prove the legal identity, authority, or current control of the intended signer. The same distinction applies to SMS.

Start by rating the consequence of the wrong person signing: financial exposure, access to sensitive data, regulated obligations, reversibility, and the availability of human review.

Step up controls only where the risk requires it

Low-risk acknowledgements may be adequately served by a unique expiring link and a clear consent step. Higher-risk agreements can add an authenticated account, one-time code, signing reason, identity document check, or an approval step by another role.

Avoid collecting stronger identity data without a purpose. Every added factor creates accessibility, recovery, support, retention, and privacy obligations.

Know what MFA does and does not protect

NIST distinguishes multi-factor authentication from phishing-resistant authentication. Manually entered one-time passwords can add protection, but they are not phishing-resistant because an impostor verifier can relay them.

For workflows with high account-takeover risk, evaluate cryptographic authenticators such as WebAuthn in the account authentication layer. Keep the signing event linked to the authenticated session and document the assurance policy applied.

Record the policy decision with the signature event

Store which authentication policy was required, which checks succeeded, the authenticated user or recipient identifier, and the interaction identifier that connects authentication to signing. Do not put authenticator secrets or raw tokens in the audit trail.

• Policy name and version.
• Required and completed factors.
• Authentication and signing timestamps.
• Result, failure reason, and recovery path.
• Reviewer or exception approval where applicable.