Chaindoc logoChaindoc

Security best practices

Chaindoc encrypts documents at rest (AES-256) and in transit (TLS 1.3), verifies integrity on the blockchain, and logs every action. This page covers what's built in and what you should configure before going live.

Most of the security works out of the box. But there are settings you should turn on (MFA, IP restrictions) and habits your team should follow (key rotation, access reviews). This guide covers both.

Authentication

Multi-factor authentication

Turn on MFA for everyone, not just admins. It's the single most effective thing you can do. Chaindoc supports:

  • Authenticator apps (TOTP) — Google Authenticator, Authy, 1Password
  • SMS codes — works but less secure. Use authenticator apps when possible.
  • Hardware security keys (FIDO2/WebAuthn) — the strongest option
  • Biometric authentication on mobile devices

Password policies

If you're not using SSO, enforce strong passwords. Chaindoc lets you configure minimum length (12+ characters recommended), complexity requirements, expiration intervals, and lockout after failed attempts. You can also block reuse of the last 10 passwords.

Role-based access

Give people only the access they need. Chaindoc has built-in roles (Owner, Admin, Manager, Member, Guest, Auditor) and supports custom roles with per-action permissions. Review assignments quarterly and remove anything that's no longer needed. See the team management docs for how to set this up.

Encryption

At rest

All documents are encrypted with AES-256 in storage. Backups are encrypted with separate keys. Encryption keys are managed through a dedicated KMS (key management service) and rotated quarterly.

In transit

Every connection uses TLS 1.3. Weak cipher suites are disabled. HSTS headers are set so browsers never downgrade to HTTP. This applies to the web app, the API, and blockchain transactions.

API key security

API keys are the most common source of security issues. A leaked secret key gives full access to your Chaindoc account.

Public keys (`pk_`) are designed for frontend use and have read-only access, so they're safe to include in client bundles. For more on key types, see the API integration guide.

Blockchain verification

Every published document gets a hash written to the blockchain. This is the tamper-proof part. Even if someone accessed the database directly, they couldn't modify a document without the blockchain hash becoming invalid.

  • Document hashes are recorded at publish time and at each state change (signatures, void, etc.)
  • Transaction receipts are stored with the document for easy verification
  • Anyone can independently verify a document against the blockchain record
  • The record is permanent — it survives even if Chaindoc goes away

For high-value documents, it's worth verifying the blockchain record after signing to confirm everything matches.

Webhook security

If you're using webhooks, verify the HMAC signature on every incoming request. Without this, someone could send fake events to your endpoint. The webhooks guide has the verification code.

Compliance

Chaindoc's infrastructure is SOC 2 Type II certified. Depending on your industry, you may need to configure additional settings:

  • GDPR — data residency options (EU, US, Asia), right to erasure, data portability. Document retention policies handle automatic deletion.
  • HIPAA — audit logging and access controls for healthcare documents. Contact support for a BAA.
  • SOC 2 — security controls are documented. Annual third-party audits are conducted.
  • eIDAS / ESIGN Act / UETA — signature compliance is built in for all three signature types.
  • ISO 27001 — information security management practices are aligned with ISO 27001.

Audit logging

Chaindoc logs every action: logins, document access, edits, signature events, permission changes, and API calls. Logs are stored in a tamper-proof system and retained for at least one year (longer if your retention policy requires it).

You can export audit logs for external compliance reviews. Failed login attempts and suspicious activity trigger alerts if you've configured monitoring.

Monitoring and incident response

Set up alerts for failed login attempts, unusual API activity, and permission escalation. Chaindoc integrates with SIEM systems if your security team uses one.

Have an incident response plan ready. Know who to contact, what to shut down, and how to communicate a breach. Test the plan at least once a year. For security incidents involving Chaindoc, contact security@chaindoc.com.

Pre-production checklist

Run through this before going live:

  1. MFA enabled for all accounts
  2. Password policies configured (12+ chars, lockout after 5 failures)
  3. Roles assigned with least-privilege access
  4. AES-256 encryption confirmed (enabled by default)
  5. TLS 1.3 enforced on all endpoints
  6. API keys stored in environment variables or secrets manager
  7. Test keys swapped for live keys
  8. Rate limiting configured for API endpoints
  9. Webhook HMAC verification implemented
  10. Audit logging enabled and retention period set
  11. Security monitoring and alerting configured
  12. Incident response plan documented
  13. Backups tested (try a restore)
  14. Compliance requirements documented and met

What to do next