Data Encryption Policy

This Data Encryption Policy describes the encryption standards and key management practices implemented by Frontal Labs, Inc. ("Frontal," "we," "us," or "our") to protect data processed through the Services. This policy supplements our Data Protection Policy. Capitalized terms not defined here have the meanings given in the Terms of Service.

1. ENCRYPTION IN TRANSIT

1.1 TLS Requirements

All data transmitted between Customers and the Frontal platform is encrypted in transit using Transport Layer Security (TLS). We require TLS 1.2 as a minimum and support TLS 1.3. Connections using TLS versions below 1.2 are rejected. Insecure cipher suites are disabled. Our TLS configuration is regularly reviewed and updated to align with current best practices and vulnerability disclosures.

1.2 External Connections

Connection Type	Encryption Standard
Customer to Frontal (browser, API, CLI, SDK)	TLS 1.2 minimum; TLS 1.3 supported
Frontal to Third-Party Model Providers	TLS 1.2 minimum; mutual TLS or API-key authentication
Frontal to Subprocessors	TLS 1.2 minimum
Frontal to Customer webhooks	TLS 1.2 minimum; customers must present a valid certificate on their webhook endpoint

1.3 Internal Traffic

All internal traffic between Frontal's services, including traffic within virtual private clouds and between availability zones, is encrypted in transit using TLS 1.2 or higher. East-west network traffic within our infrastructure is encrypted. Inter-service authentication uses short-lived credentials.

1.4 Certificate Management

TLS certificates are managed through automated certificate management services. Certificates are issued by trusted public certificate authorities. We monitor certificate expiration and perform automated rotation.

1.5 HTTP Strict Transport Security (HSTS)

Our public endpoints enforce HTTP Strict Transport Security (HSTS) with a minimum max-age directive and includeSubDomains flag. Our domains are on browser HSTS preload lists where applicable.

2. ENCRYPTION AT REST

2.1 Default Encryption

All Customer Data is encrypted at rest by default. Encryption is implemented at the storage layer for all managed databases, object stores, file systems, block storage volumes, and backup systems. No action is required by Customers to enable encryption at rest; it is always on.

2.2 Encryption Standards

Data Category	Encryption Standard	Key Management
Database storage	AES-256 (or equivalent)	AWS KMS, GCP Cloud KMS, or Azure Key Vault depending on infrastructure provider
Object and blob storage	AES-256 (or equivalent)	Service-managed keys with envelope encryption
Block and file storage	AES-256 (or equivalent)	Service-managed keys
Backups and snapshots	AES-256 (or equivalent)	Separate keys from source data
Logs and telemetry	AES-256 (or equivalent)	Service-managed keys
Search indices	AES-256 (or equivalent)	Service-managed keys

2.3 Key Management Hierarchy

We implement an envelope encryption architecture:

Data Encryption Keys (DEKs): Generated per resource or per storage volume. DEKs encrypt the data directly.
Key Encryption Keys (KEKs): Stored in a hardware security module (HSM)-backed key management service (AWS KMS, GCP Cloud KMS, or equivalent). KEKs encrypt DEKs.
Master Keys: HSM-protected. Master keys are never exposed in plaintext outside the HSM.

2.4 Customer-Managed Keys

Where offered as a feature, Customers may supply and manage their own encryption keys through integration with the cloud provider's key management service (AWS KMS, GCP Cloud KMS, Azure Key Vault). When Customer-managed keys are configured, Frontal cannot access data without Customer authorization through the key management service. Customers are responsible for managing key availability; if Customer-managed keys are disabled or deleted, encrypted data will become inaccessible.

3. ENCRYPTION IN USE

Where available and configured, we support confidential computing environments that encrypt data while in use (in-memory encryption) for specific workload types. Availability of confidential computing varies by infrastructure, region, and Service. Details are published in the Documentation.

4. KEY MANAGEMENT

4.1 Key Generation

Encryption keys are generated using cryptographically secure random number generators approved under applicable standards (NIST SP 800-90A or equivalent).

4.2 Key Rotation

Key Type	Rotation Policy
TLS certificates	Automated rotation before expiration; 90-day maximum certificate lifetime
Data Encryption Keys	Rotated at least annually or upon key compromise
Key Encryption Keys	Rotated at least annually
Customer API Keys	Customer-managed; we recommend rotation every 90 days
Internal service credentials	Automated rotation every 30 days or less
Master Keys	Per HSM provider policy

4.3 Key Access

Access to key management systems is restricted to authorized personnel and automated systems with a documented business need. All access is logged and monitored. Multi-factor authentication is required for administrative access to key management systems.

4.4 Key Destruction

When data is deleted in accordance with our Data Disposal Policy, the associated encryption keys are destroyed (cryptographic erasure). Key destruction follows the key management service's secure deletion procedures. Key material is irrecoverable after destruction.

5. CRYPTOGRAPHIC CONTROLS FOR CUSTOMER DATA

5.1 Password Storage

Account passwords are hashed using bcrypt, scrypt, or Argon2 with unique per-password salts. Passwords are never stored in plaintext.

5.2 API Key Storage

API Keys are stored in hashed form. Upon generation, the key is displayed once to the Customer. After that, the plaintext key is not retrievable, and a new key must be generated if the key is lost.

5.3 Secrets Management

Operational secrets (database credentials, API Keys, encryption keys, tokens) are stored in a dedicated secrets management system (HashiCorp Vault or cloud-native equivalent). Secrets are never stored in source code, configuration files, environment variables, or documentation. Injection of secrets into running services occurs through authenticated API calls to the secrets manager at runtime.

6. ALGORITHM STANDARDS

6.1 We use cryptographic algorithms and implementations that are publicly vetted and standardized (NIST, IETF). Proprietary or unverified algorithms are not used.

6.2 We maintain an inventory of cryptographic assets and monitor for published vulnerabilities affecting cryptographic libraries, algorithms, and protocols. When a vulnerability is disclosed, we assess impact and apply patches in accordance with our vulnerability management program.

6.3 We monitor developments in post-quantum cryptography but do not currently implement post-quantum algorithms in production.

7. CUSTOMER RESPONSIBILITIES

7.1 Customers are responsible for:

Securing their API Keys and credentials.
Encrypting data before submission to the Services when required by the Customer's security policy.
Configuring TLS on webhook endpoints.
Managing Customer-managed keys if that feature is used.
Implementing appropriate encryption on Customer-managed systems and applications that interact with the Services.
Encrypting files and data at rest on Customer devices before uploading to the Services, if required by the Customer's security policy.

7.2 Frontal cannot recover data encrypted with Customer-managed keys if the Customer revokes access to those keys.

8. CONTACT

Frontal Labs, Inc. Attn: Security 131 Continental Drive, STE 305 Newark, DE 19713 United States of America Email: security@frontal.dev