How Rhea works: data, access, and identity

1. Rhea's category and purpose

Rhea is the company behind one layer above all data: authority, authentication and identity. It separates the infrastructure that holds or moves information from the authority that determines when, how and by whom it may be read or executed — and backs that authority with proof anyone can verify offline.

Rhea Data is the governance, execution and evidence layer for organisational data — not an encrypted storage service. Institutions keep their chosen storage and databases, while Rhea Data governs how that data is protected, organised, authorised, accessed, shared, moved and audited.

Infrastructure holds protected objects. Rhea Data governs how they become readable and usable, and proves what happened.

2. What Rhea Data is, and is not

Rhea Data is the governance, execution and evidence layer for organisational data. It connects to the object storage and databases an institution already runs, governs seven operations across them, and records every one of those operations in a hash-chained ledger.

Client-side encryption is one enforcement mechanism inside Rhea Data. The category is data authority: governance, execution and evidence over estates the customer continues to own.

3. Storage access versus readability

Storage access is not the same as data authority.

Cloud credentials and storage permissions determine who can reach stored objects. Rhea Data adds a separate authority model around the content itself. Possession of a protected object — obtained through administration, copied credentials, or a provider incident — is not sufficient to make that content readable.

If protected objects are copied from connected storage without the required decryption authority, the copied encrypted file content is not independently readable. This does not protect plaintext after authorized decryption or eliminate risks on a compromised authorized endpoint.

4. Current Rhea Data operating model

The Rhea Data operating model. Content is protected on the device before it reaches the customer's own storage; Rhea Data maintains the authority, policy and evidence functions around every operation performed on it.

One command centre for the whole estate: live operations, policy state, quorum approvals awaiting signature, and a verifiable audit ledger — across every connected provider and database at once.

Protected content is encrypted on the device before it reaches any provider. In Standard custody, Rhea holds provider credentials.

5. Rhea Data, Rhea Key and Rhea ID responsibilities

The three lanes describe product responsibilities. The operating model describes how an institution runs Rhea Data together with Rhea Key and its own infrastructure.

• Rhea Data — Rhea Data is the governance, execution and evidence layer for organisational data. It connects to the object storage and databases an institution already runs, governs seven operations across them, and records every one of those operations in a hash-chained ledger.
• Rhea Key — Rhea Key is the authority product. It authenticates by challenge and response against a key the holder controls, with no passwords and no magic links, and it signs approvals against an exact, human-readable description of what is being approved. In organisation mode it enforces M-of-N quorum over exports, policy changes and key rotations.
• Rhea ID — Rhea ID is the identity product: a boolean-first answer engine. A relying party asks a question — is this person over eighteen, is this the named director of this company, is this individual on a sanctions list — and receives a cryptographically signed Yes, No or Unknown. It never transfers the underlying documents.

Separating governance, authority and identity limits how much sensitive information any single Rhea product ever handles. Rhea Key and Rhea ID never receive protected file contents. A storage provider receives ciphertext rather than readable content. Rhea ID holds cryptographic facts, not the documents they were derived from.

6. Content, key, identity and metadata boundaries

Only encrypted protected-file content reaches connected object storage. Rhea Data and Rhea may still process the operational metadata required to provide authorization, organization administration, metering, security and audit functions.

Each protected document is encrypted with its own data-encryption key, which is wrapped for authorized recipients.

Private authentication material remains protected by the user's device and is not transmitted to Rhea. Rhea does not operate a key-recovery service.

• Protected content: the objects a user encrypts with Rhea Data. Rhea's services have no independent ability to decrypt protected customer content.
• Encryption keys and private keys: held under the user's control. Private authentication material remains protected by the user's device and is not transmitted to Rhea. Rhea does not operate a key-recovery service.
• Operational metadata: Only encrypted protected-file content reaches connected object storage. Rhea Data and Rhea may still process the operational metadata required to provide authorization, organization administration, metering, security and audit functions.
• Audit records: Rhea Data records relevant operational metadata for verified categories — actor, action, resource, time and outcome where applicable. Audit records contain operational metadata, not readable protected content.
• Storage provider: sees ciphertext and object metadata such as sizes and access times. It does not see plaintext or encryption keys.

7. Current availability matrix

The tables below are the same product and deployment status used across Rhea's public site, so this article never drifts from other pages.

8. Future controlled-use model (Planned)

One authority model for every actor that touches your data.

People, executive quorums, enterprise applications and autonomous agents all receive authority in the same shape: scoped to one operation, bounded in time, revocable at any moment, and recorded. An agent estate does not need a new security model — it needs this one, applied.

One authority model spans the three products and every connected estate: object storage, relational databases, applications and agents. An institution begins wherever its exposure is greatest and extends the same model outward, because the model does not change with the surface it governs.

As institutions add applications and autonomous agents, every one of them becomes another actor asking for data. Rhea's purpose is to make authority reusable across all of them — people, executive quorums, software and agents — without Rhea ever becoming its owner. Rhea Data governs the estate, Rhea Key holds the authority, Rhea ID answers who the counterparty is.

9. What remains planned

The following are not currently generally available. Only the native mobile applications are still to come. The web cryptographic interfaces and the relying-party APIs behind them work today, on every platform.

• Planned. Rhea Key native Android application (coming soon).
• Planned. Rhea Key native iOS application (coming soon).
• Planned. Rhea ID native mobile applications (coming soon).

10. Compliance boundary

Organizations operating under GDPR, NIS2, DORA, EHDS or sector-specific requirements may evaluate Rhea Data as one technical and organizational control within a broader compliance programme.

Rhea Data does not by itself make an organization compliant, and legal obligations depend on the organization's deployment, policies, processes, contracts and applicable law.

Available vs planned, at a glance

Where to go next

This article introduces the whole system at a high level. For product-specific detail, see Rhea Data, Rhea Key, and Rhea ID. For a vocabulary reference, see the Learn glossary.