Security

• Tenant isolation by construction. Every query carries a tenant identifier enforced at the data layer. Cross-tenant access is structurally impossible, not just policy-restricted.
• Privacy-centric defaults. Recipient data is never shared across customers, never used for cross-tenant analytics, and never used to train models.
• Minimal data surface. We collect only what is required to issue and verify a credential. Where a feature can work without persisting data, it does.
• Explicit consent. Any feature that transmits data outside our infrastructure is opt-in and clearly labelled.

The verification URL is the most important security surface we run. It must be tamper-proof, easy to reach, and answer only what the issuing institution chose to publish.

• Each certificate is assigned a cryptographically random identifier at issue time. Identifiers cannot be guessed and are not derived from recipient data.
• The verification record is signed and stored append-only. Once issued, a credential's record is not editable; it can only be revoked, which produces a separate, auditable state change.
• The verification page is read-only and requires no login. Verifiers see exactly the fields the institution chose to publish, nothing more.
• Revoked credentials return a clear "revoked" status with the date of revocation.

• In transit: TLS 1.2+ for all network communication. HSTS enforced on every Certfill endpoint, including verification URLs.
• At rest: AES-256 for stored recipient data, certificate records, and templates.
• Secrets: API keys and signing keys are managed by a dedicated secrets store with hardware-backed key material. Keys are rotated on a fixed schedule and on demand.

• Password authentication uses Argon2id with per-user salts.
• Multi-factor authentication is available on all paid plans and recommended for every administrator account.
• Single sign-on (SAML, OIDC) is available on enterprise plans.
• Internally, access to production systems is gated behind hardware security keys, role-based controls, and time-bounded approvals. Standing access to customer data is not granted.

Certfill runs on a single, well-known cloud provider with a documented compliance posture (SOC 2, ISO 27001). Each customer's data is logically isolated. We do not run shared compute across customer datasets. A current list of subprocessors is available on request.

• Production access is logged with immutable retention.
• Customers on enterprise plans receive an audit log of every administrative action and every issuance, revocation, or verification event in their tenant.
• Application telemetry is non-identifying and never contains recipient details, certificate content, or the body of issuance emails.

• Production data is replicated across availability zones.
• Backups are taken daily, encrypted, and retained for 30 days.
• Annual disaster-recovery exercises are run with documented RTO and RPO targets.
• Verification URLs are served from an isolated path with its own scaling and caching profile, so verification remains available even if other parts of the platform are degraded.

We welcome responsible disclosure. Reports submitted through your account dashboard or your subscription's designated support channel are acknowledged within one business day, and we do not pursue legal action against good-faith research.

We align with the principles of SOC 2, ISO 27001, and the NIST Cybersecurity Framework. Where customer requirements demand it, attestations and security questionnaires are available under NDA.

See our Privacy Policy for how we handle recipient data and our Terms of Service for the agreement governing use of the platform.