Encryption & key management - Hilt Documentation

Hilt encrypts data in transit and at rest using the native capabilities of your cloud provider. Because the platform runs in your account, the encryption keys live in your account too.

In transit

TLS 1.2+ on external connections. Collector-to-ingest traffic and dashboard access use TLS 1.2 or higher; load-balancer listeners enforce a TLS 1.2/1.3 policy. Internal service-to-service traffic runs within your private VPC/VNet — the streaming buffer (Kafka) and the dashboard database use TLS, while other internal hops rely on the isolation of that private network.
Private networking. On AWS, Azure, and Ali Cloud, collector telemetry rides a private link path (PrivateLink or equivalent). On GCP v1, collectors reach {name}-ingest.hilt.ai over HTTPS Gateways. See Architecture and data flow and GCP.
Collector to ingest. The collector connects over HTTPS on TCP/443 to the ingest endpoint. The endpoint presents a certificate issued against your private zone, and the collector validates it against your CA chain. See Networking and security.

Certificates

Certificates are managed with each cloud’s native certificate service: ACM on AWS, Certificate Manager on GCP, and the equivalent service on Azure and Ali Cloud. The ingest certificate is issued against the private DNS zone associated with your VPC, so name resolution and TLS validation both happen inside your account.

At rest

Persistent storage is encrypted at rest using your cloud provider’s native encryption:

Storage layer	Encryption
Analytics database (ClickHouse)	Provider volume encryption on the underlying cloud volumes
Streaming buffer (Kafka or Event Hubs)	Provider-managed encryption at rest
Dashboard database (PostgreSQL)	Provider-managed KMS encryption (RDS, Cloud SQL, or equivalent)
Object storage (S3, Cloud Storage, Blob, OSS)	Provider-managed server-side encryption (e.g. SSE-S3 / AES-256)

Encryption at rest uses your cloud provider’s default/managed keys across these storage layers; customer-managed keys (CMKs) are optional — see Key ownership below.

Key ownership

Because the deployment runs in your cloud account, encryption keys reside in your account’s key management service (AWS KMS, Cloud KMS, Azure Key Vault, or Ali Cloud KMS). Hilt does not hold or escrow your keys outside your account. Whether storage uses provider-managed keys or customer-managed keys (CMKs) can vary by cloud and by your configuration. To use CMKs with key rotation and access policies you define, raise it during provisioning and confirm per-resource support with your Hilt representative.

Revoking or restricting a key in your KMS affects the platform’s access to the data it protects, because the keys are yours. Coordinate key policy changes with your Hilt representative to avoid disrupting the deployment.

Secrets in the deployment

Platform secrets (database credentials and service identities) are provisioned by Terraform into your cloud’s native secret and identity services and are scoped to the deployment. Service-to-service authentication uses cloud-native workload identity (IAM roles on AWS, Workload Identity on GCP, Managed Identity on Azure, RAM roles on Ali Cloud) rather than long-lived shared credentials where the platform supports it. See the deployment guides for AWS, GCP, Azure, and Ali Cloud.