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, open a support ticket in the Console using the Help button in the bottom-right corner.

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.