Lite + Pro Lite limits

Security & Compliance

The Security & Compliance screen centralizes WPsigner’s signing gates and evidence settings. Use it to decide when signers must verify an email, complete KYC, enter an access code, and which cryptographic evidence is added to completed documents. A separate per-signer option can also require a matching WordPress login before the signing page opens.

Open WPsigner → More → Security & Compliance.

Signing gate policies

OTP, KYC, and access codes each support three policies:

Policy	Behavior
Always	Require the gate for every applicable signing request
Per document	Require it only when enabled in that document’s Review step
Off	Do not apply the gate

With Per document, review each document before sending and enable only the controls required for that transaction.

Email verification (OTP)

OTP verifies that the signer can receive a one-time code through a configured channel.

Method	Requirement
Email	Working WordPress email delivery
SMS	Configured Twilio integration
Both	Email delivery and Twilio

Test email and SMS delivery before requiring OTP in production. A failed delivery can prevent the signer from continuing.

WPsigner rate-limits OTP requests and verifies them through protected AJAX actions. If a firewall plugin blocks OTP, check System Status and allowlist the WPsigner actions it reports.

Identity verification (KYC)

KYC uses the Didit.me integration to verify a government-issued ID, selfie match, and liveness result before signing.

Configure and test Didit under WPsigner → More → Integrations → Didit.
Return to Security & Compliance.
Choose Always, Per document, or Off.

The KYC policy is unavailable or ineffective until Didit credentials are configured. WPsigner stores verification status and decision metadata; identity images remain with Didit.

Access codes

An access code is a 4–8 digit secret for the whole document (not per signer). There is no lock icon next to each signer. The stored value is hashed; WPsigner does not keep a readable copy of a sender-chosen secret.

Set the policy under WPsigner → More → Security & Compliance → Access codes (Off, Per document, or Always). If the policy is Off, Review will not show the access-code controls.

How to send a document with an access code

On Review, check Require access code (skip this if the policy is Always).
Choose how the code is set:

Option	What happens
Generate a random 6-digit code	WPsigner creates the PIN. After send, the admin can copy it.
I’ll set the access code	You type 4–8 digits the signer already knows (last 4 of SSN, last 4 of a mobile or account, 8-digit date of birth `MMDDYYYY`).

If you set the code yourself, you can add a Signer prompt (for example “Enter the last 4 digits of your SSN”). That text appears on the signing page. It is a label only — it is not the code. Presets are available for SSN, mobile, date of birth, and account number.
Include access code in signing email:
- On — the PIN is in the same email as the signing link (weaker if someone has the inbox).
- Off (default when you set your own code) — the email has only the link. Use this when the signer already knows the secret.
Send. The signer must enter the code before the document opens.

What the signer sees

The access-code page asks for the PIN. If you wrote a Signer prompt, that sentence replaces the generic “enter the code the sender shared” message.

Failed guesses are limited (a few tries per document, then a 30-minute lock). Documents already sent before this feature keep working with the same hashed code.

Request access code

Don’t have the code? Request access code appears only when all of these are true:

The code was auto-generated (not a secret you typed).
WPsigner still has that generated code stored for resend.
The signer has an email on file, or a phone on file with Twilio / WhatsApp enabled.

The code is sent only to the email or phone already stored on that signer. The signer cannot type a new number.

A sender-chosen code (SSN, date of birth, and similar) cannot be requested or resent from the signing page. The recipient uses the secret they already know.

What does not change on update

Updating WPsigner does not reset your Access codes policy, wipe existing PINs, or force you to resend pending documents. Signers who already have a code keep using it. Request access code applies to new random codes sent after the update.

This gate is opt-in per signer and off by default. It is not a global Security & Compliance policy and it does not replace OTP, KYC, or access codes.

When Require WordPress login with this email is checked on a signer:

The visitor must be logged in to WordPress.
The logged-in account email must match that signer’s email (case-insensitive).
The unique signing link is not enough on its own.

If nobody is logged in, the signing page asks them to log in and then returns to the same link. If they are logged in with a different account, they see that mismatch and can log out, then log in as the matching user.

Use this when the signer already has a WordPress account on your site (members, staff, LMS users). The checkbox is refused if that email is not a WordPress user — create the account first, or leave the option off. Leave it off for guests and external counterparties. Public campaign links and Bulk Send CSV rows do not use this gate — those flows have no preassigned WordPress user.

You cannot activate a public campaign on a document that already has a gated signer, and you cannot turn the checkbox on while that document has an active campaign. If someone still reaches a public link and types a gated signer’s email, WPsigner re-checks the login requirement and refuses the signature until the matching WordPress account is signed in. Individual signing links for a gated signer are never redirected to the campaign URL.

The invitation email adds a short note when the flag is on. Customized email templates need the require_wp_login variable if you want that sentence in your own copy.

Evidence capture

Control	Evidence added
Capture geolocation	Approximate signer location when permission and browser support allow
Capture device information	Browser/device metadata in the audit record
Digital ID (PKI)	Cryptographic PDF certificate signature
Timestamp provider (TSA)	Trusted time evidence for the document hash
Immutable timestamping	Additional configured timestamp evidence

Geolocation may be unavailable when the signer denies permission, the browser blocks it, or the network obscures the location.

Compliance score

The screen displays an orientation score based on selected controls:

Factor	Maximum contribution
OTP policy	25
Geolocation	10
Device information	5
Custom Digital ID certificate	10
Timestamp provider	Up to 50

KYC and access codes are important gates but do not currently add points to this score.

Displayed level	Score / conditions
SES	0–39
SES+	40–64
AdES	65–79
HA (QES-oriented)	80+ plus an active PKI certificate and qualified/custom TSA

The score is configuration guidance, not a legal classification or QES certification. A true Qualified Electronic Signature depends on regulated identity, certificate, provider, and jurisdictional requirements outside a score.

Recommended profiles

Routine internal acknowledgement

OTP: Per document
KYC: Off
Access code: Off or Per document
Device information: On
Geolocation: Based on privacy policy
Audit trail and secure backups: On

Higher-risk external agreement

OTP: Always
KYC: Per document or Always
Access code: Per document
Device and geolocation evidence: On where lawful
Commercial certificate and reliable TSA

Document the reason for each control and avoid collecting more personal data than necessary.

Before enabling a gate globally

Send a test document to accounts you control.
Test on desktop and mobile.
Confirm SMTP, Twilio, Didit, and TSA connectivity as applicable.
Verify the final PDF and audit trail.
Publish signer-facing privacy and support instructions.
Define retention and deletion policies for collected data.

Troubleshooting

KYC cannot be enabled

Configure and test Didit first. The KYC gate only operates when the integration is available.

SMS is unavailable

Install and configure the WPsigner Twilio integration, then reload the Security & Compliance screen.

OTP requests fail

Check SMTP, spam filtering, caching, and security-plugin logs. Use WPsigner → More → System Status to test email and identify blocked AJAX actions.

Signers are unexpectedly asked for a gate

Check both the global policy and the document’s Review settings. Always overrides per-document choice; Per document follows the document’s saved security settings.

The score is lower than expected

Confirm the Digital ID is active and the selected TSA provider is recognized. KYC and access codes do not increase the current score.

The signer email must already belong to a WordPress user. Create that account first, or leave the option off. WPsigner does not create users.

You also cannot turn the checkbox on while the document has an active public campaign, and you cannot activate a campaign if any named signer already has the gate on.

That row has Require WordPress login with this email on. They must sign in with the WordPress account that uses the same email, then they return to the signing link. A different logged-in account is rejected.

Creating Documents — user picker, Add me as signer #1, and the checkbox
Didit.me KYC
Digital ID
Timestamping
Audit Trails
System Status, Storage & Retention