Frequently asked questions.

No. RED is enterprise data protection and management infrastructure, not an encrypted storage service. Organizations keep their own storage environment; RED governs how sensitive data inside it is protected, organized, authorized, accessed, shared, moved and audited.

Available today: RED; Rhea Key Web; Rhea Key Android; BYOS with AWS S3; client-side AES-256-GCM encryption for protected file content; per-document data-encryption keys with wrapped keys; Owner/Admin/Member organization roles; Rhea Key cryptographic authentication, signing and approval; supported Trezor authentication and approval inside RED; and operational audit records. Coming soon: Rhea Key iOS and Rhea ID. Planned: additional storage providers, BYOD, database policy interfaces, public application-integration interfaces, controlled agent interfaces, and public API/SDK/MCP surfaces. See the Architecture page for the full matrix.

Protected file content lives in the storage environment the organization chooses under Bring Your Own Storage (BYOS) — AWS S3 is supported today. RED encrypts each object client-side before it is uploaded; Rhea does not host a copy of the protected content.

Only encrypted protected-file content and the object metadata needed to store it, such as object keys, sizes and access times. The storage provider does not receive plaintext or encryption keys.

RED and Rhea may process the operational metadata required to provide authorization, organization administration, metering, security and audit functions — for example organization structure, roles, sessions, document identifiers, storage references, usage records, and audit events. This operational metadata is distinct from protected file content and does not include the plaintext of anything stored.

Bring Your Own Storage (BYOS) means encrypted objects are written to a storage bucket the organization owns and controls rather than to a Rhea-hosted store. RED encrypts each object client-side with AES-256-GCM, then uploads the ciphertext. AWS S3 is supported today; Azure Blob, Google Cloud Storage, Cloudflare R2, Oracle Object Storage and S3-compatible storage are planned.

Planned. Bring Your Own Database (BYOD) and every database integration are planned, not currently available. BYOD is intended to let the database that indexes protected records live in infrastructure the organization owns.

Rhea Key provides user-controlled cryptographic authentication, signing and human approval for sensitive RED actions. Private authentication material remains protected by the user's device and is not transmitted to Rhea. Supported Trezor hardware can be used as an alternative authentication and approval option inside RED.

Because private authentication material stays on the user's device and Rhea does not operate a key-recovery service, losing the device without a working recovery path can make data whose access depended only on that device's key unrecoverable through it. A lost or compromised device should be reset from another trusted device or reported so its authority can be invalidated for future authorizations.

Coming soon. Rhea ID is planned to establish verified identity or specific identity attributes for services that choose to require them, while reducing repeated exposure of unnecessary personal information. Rhea ID is not required to use RED today.

No. Organizations operating under GDPR, NIS2, DORA, EHDS or sector-specific requirements may evaluate RED as one technical and organizational control within a broader compliance programme. RED does not by itself make an organization compliant, and legal obligations depend on the organization's deployment, policies, processes, contracts and applicable law.

No. RED uses a Bring Your Own Storage (BYOS) model. Your organization connects RED to storage under its own control. Rhea does not provide, host, or operate customer storage.