Security at Zafeguard

Every wallet provisioned through Zafeguard uses multi-party computation. Key shards are distributed across separate, geographically distributed nodes. Signing requires a threshold of nodes to participate in a cryptographic protocol — the full key is never reconstructed on any single node.

The on-chain signature produced by an MPC ceremony is indistinguishable from a single-signer transaction: same gas cost, same chain compatibility, same privacy — with none of the seed-phrase or hot-wallet risk.

For institutions with strict data-sovereignty requirements, the same MPC stack is available as a self-hosted deployment. Key shards never leave your environment.

• Encryption in transit. All API and dashboard traffic is served over TLS 1.3 with HSTS preloading.
• Encryption at rest. Stored credentials, integration secrets, and workspace data are encrypted using authenticated encryption with envelope keys.
• Role-based access control. Workspace roles govern who can edit workflows, view run logs, manage API keys, and approve signing policies.
• Audit logging. Every authentication event, configuration change, and signing ceremony is logged with cryptographic chain-of-custody. Requests authenticated by an OAuth-issued access token are tagged with the issuing third-party application id and granted scopes so platform admins can answer “which app took which action on which workspace” with a single indexed query.
• Federated identity (OAuth 2.0 / OpenID Connect). When you sign in to a third-party application using your Zafeguard account, the access and ID tokens we issue are RS256-signed JWTs verifiable offline against our published JWKS. Signing keys are rotated on a defined cadence; retired keys remain in the JWKS until every token they signed has expired so live integrations never see a sudden verification failure.
• Threshold approvals. High-impact actions (large transfers, policy changes, recovery operations) can require multi-party approval before execution.
• Rate limits and anomaly detection. Unusual signing patterns trigger automated holds and human review.
• Dependency review. Third-party libraries are vetted and continuously scanned for vulnerabilities.

We design our controls to align with industry standards including SOC 2, ISO 27001, and the NIST Cybersecurity Framework. Formal audit attestations are in progress; we will publish them here as they are completed.

For payment-workflow customers, our payment processors handle PCI-scoped card data directly — Zafeguard does not store full card numbers.

If you believe you have found a security vulnerability in any Zafeguard product, please email hello@zafeguard.com with the subject line “Security disclosure”. We commit to:

• Acknowledging your report within 2 business days;
• Providing an initial triage within 7 days;
• Keeping you informed as we investigate and remediate;
• Crediting reporters who would like recognition once a fix is shipped (you can also remain anonymous).

Please do not publicly disclose a vulnerability before we have had a reasonable opportunity to address it. Do not access data that is not your own, and do not run automated scanning that may impact other users.

No security stack is complete without you. Treat your credentials, API keys, recovery factors, and any other authentication material as you would your most sensitive secrets. Use a hardware key or strong MFA for your account. Rotate credentials after any team member departure. Review workspace audit logs periodically.

For a full description of risk allocation and your obligations, see our Terms of Service and Privacy Policy.