Skip to main content

Encryption

eCourtDate encrypts all data in transit and at rest using FIPS-validated cryptographic modules. This page consolidates encryption details across all platform services.

Encryption in Transit​

All communication with eCourtDate is encrypted during transmission:

  • Protocol: HTTPS with TLS 1.2 or higher
  • FIPS validation: TLS termination uses FIPS 140-2/140-3 validated cryptographic modules
  • HTTP enforcement: Plain HTTP requests are rejected; all API endpoints require HTTPS
  • HSTS: HTTP Strict Transport Security headers are recommended for agency web applications that integrate with eCourtDate
info

For specific TLS cipher suite details, contact the eCourtDate security team through the Help Center.

Encryption at Rest​

All data stored on eCourtDate servers is encrypted:

  • Algorithm: AES 256-bit encryption
  • Key management: AWS Key Management Service (KMS) within GovCloud
  • FIPS validation: Storage encryption uses FIPS 140-2/140-3 validated hardware security modules
  • Scope: Covers databases, backups, file storage, and logs

Certificate Management​

eCourtDate automatically manages SSL/TLS certificates for custom domains:

  • Provisioning: Certificates are automatically provisioned via the ACME protocol
  • Renewal: Certificates are renewed automatically before expiration
  • No manual management: Agencies do not need to purchase, install, or renew certificates

For custom domain SSL setup, see SSL Certificates.

SFTP Encryption​

SFTP connections use SSH encryption for secure file transfers:

  • Protocol: SSH-based file transfer with encrypted channels
  • Authentication: SSH key authentication recommended over password authentication
  • Key storage: Private keys should be stored securely with restricted file permissions (chmod 400)

For SFTP setup and authentication details, see SFTP Authentication.

Webhook Payload Security​

Webhook payloads are delivered securely and can be verified for authenticity:

  • Delivery: All webhook payloads are sent over HTTPS
  • Verification: HMAC-SHA256 signatures in the X-ECD-Signature header allow receivers to verify payload authenticity and integrity
  • Shared secret: A shared secret (up to 24 characters) is configured per webhook in the Console

For webhook verification implementation, see Webhook Verification. For webhook security best practices, see Webhook Security.