Security
Security & Trust
Trust is the product. Here is how Verifycate handles identity, data, and access — what we support today, what we store, and what we do not yet hold.
Identity and access
Workspace members sign in with passwordless email one-time codes or Google. We do not store passwords. Each member holds a role — admin, manager, issuer, or support — and access is scoped to the workspace they belong to.
Enterprise single sign-on is available on the Pro plan over OpenID Connect (OIDC) and SAML 2.0. A workspace can require SSO for its verified domains so email and Google sign-in are refused. Pro also includes SCIM 2.0 provisioning — with directory group-to-role mapping and deprovisioning that revokes sessions immediately.
Programmatic access uses workspace API keys. Keys are stored hashed, are scoped to permissions you choose, and can be revoked at any time.
Recipient access
Recipients do not need accounts. A certificate is reached through a public identifier or a private unlock link, and verification is public by design — that is the point of a verifiable credential.
Recipients never receive workspace access, and no recipient can see another recipient's data.
What we store
We store what we need to issue and verify credentials: your account details (email, name, avatar), workspace settings, certificate definitions, and issued credentials including the recipient fields you provide.
We also keep an audit trail of security-relevant workspace actions, described below.
We do not sell your data, and we do not run third-party advertising trackers in the app.
Data protection
Data is encrypted in transit using TLS. Sensitive material, such as credential signing keys and provider secrets, is encrypted at rest and is never exposed through the API.
We minimize what we collect: we ask for personal data only where a feature needs it to work.
Email delivery
Certificate and account email can be sent through the shared Verifycate sender or a sender the workspace controls. Every workspace can set its display name, reply-to address, and optional CC/BCC.
On Pro, a workspace can send from a verified domain it controls, connect its own provider (Cloudflare, Resend, Amazon SES, Postmark, SendGrid, or Mailgun), or use raw SMTP. Provider credentials and SMTP passwords are encrypted at rest and are never returned by the API.
When a workspace connects its own provider or SMTP server, that provider is selected and controlled by the customer. It is not a Verifycate subprocessor, and its own terms and data processing apply.
Audit logging
We keep an append-only audit trail of security-relevant workspace events — sign-ins, membership and role changes, and API-key and integration changes. Workspace admins can review this trail and export it.
The trail is append-only by design: entries are recorded and read, never edited or deleted.
Access control
Internal access follows least privilege. Platform-staff actions are gated by a separate, audited admin surface, and this access is logged.
Workspace data is isolated per tenant; one workspace cannot see another's credentials or recipients.
Compliance
Verifycate is not SOC 2 certified today, and we would rather say so than imply otherwise. We support data processing agreements and security questionnaires for customers who need them.
If your procurement process needs a specific document, email [email protected] and we will tell you exactly what we can provide.
Report a vulnerability
Send security reports to [email protected], or read the responsible disclosure policy.