Key takeaways
- Each organization's data at rest is encrypted with its own AES-256 key.
- Separate keys create a boundary between customers on the same platform.
- Per-organization keys work alongside TLS in transit and access rules inside the team.
- They are part of C Chat's auditable encryption model, not end-to-end encryption.
- Keys are managed by the service; ask support if your policy needs more detail.
Many cloud services encrypt stored data, but “encrypted at rest” can mean very different things. In some systems one key protects everything for every customer. In others, each customer has its own. The difference rarely appears on a pricing page, yet it shapes how isolated your data really is. This page explains which approach C Chat uses and what it buys you.
Short answer: one key per organization
C Chat encrypts each organization’s stored content, including messages, photos, videos, files and voice notes, with AES-256 using a key specific to that organization. Two companies using C Chat never share an encryption key for their stored data.
The glossary entry on per-organization encryption keys defines the term in general. For where this fits among the other layers, start with how C Chat encrypts your messages.
How per-organization keys work in C Chat
Think of a building with one master key versus a building where every office has its own lock.
| Design | What happens if one key is exposed | Boundary between customers |
|---|---|---|
| One shared key | Every customer’s stored data depends on it | Only logical (software rules) |
| Per-organization keys (C Chat) | Only that organization’s data is involved | Logical and cryptographic |
In C Chat, the organization’s key encrypts its stored data. When an authorized person opens a conversation, the service uses that key to decrypt the content and sends it to their device over TLS. No team member ever handles the key directly.
This is a form of symmetric encryption, where the same key encrypts and decrypts. It differs from public-key cryptography, which uses a pair of keys and is typical of apps that use end-to-end encryption.
Who can see what
Per-organization keys protect against exposure outside your organization. Inside your organization, access is governed by roles:
- Group members read their groups.
- Owners and admins can audit and export all of the team’s group conversations.
- Direct messages are private between participants.
- The platform accesses content only for moderation of reported messages or legal requirements, and logs it.
That is why C Chat is described as auditable: the key belongs to the organization’s data, and the organization keeps oversight of its groups. Compare with end-to-end encryption, where no one but the participants can decrypt.
What it means for owners, admins and members
Owners and admins benefit from a clean separation without any setup. You do not generate, store or rotate keys; your organization’s data is simply encrypted under its own key from the first message.
Security and IT reviewers can describe the design accurately in assessments: “AES-256 at rest with per-organization keys; TLS in transit; customer can audit and export group conversations.” The guide on security questions to ask a messaging vendor helps you dig further, and the glossary on key management explains concepts such as rotation and custody so you know what to ask.
Members do not need to do anything. The protection applies to every group and attachment automatically, as described in attachment security.
Honest limits and caveats
- Service-managed keys. The keys are held by the service. That is what allows audit and export, and it also means the provider could technically decrypt; platform access is limited to moderation and legal requirements and logged.
- Not a substitute for access hygiene. A key cannot stop a former employee who is still in a group from reading it. Remove people when they leave.
- No customer-held keys described. This page does not describe bring-your-own-key or customer-controlled rotation. If you need either, contact support@cguardpro.com.
- Devices are outside the key’s reach. Content on an unlocked phone or in a downloaded file is not protected by the organization key.
Getting started
Per-organization keys apply automatically to every team. Create yours at getcchat.com/c and your data is encrypted under its own key from day one. For a deeper look at the at-rest layer, read AES-256 encryption at rest.
Frequently asked questions
What is a per-organization encryption key?
It is an encryption key dedicated to one customer organization. All of that organization's stored content is encrypted under it, so it is cryptographically separated from other customers' data.
Why not use one key for all customers?
A single shared key means every customer's data depends on the same secret. Separate keys reduce the impact of a problem with any one key and make the boundary between organizations explicit.
Do I need to manage the key myself?
No. In C Chat, encryption keys are handled by the service, so teams do not have to generate, store or rotate anything to be protected. If your policy requires customer-held keys, ask support@cguardpro.com before assuming that is available.
Does a per-organization key stop my admins from reading group chats?
No. Encryption keys protect stored data from outside exposure. Inside your organization, owners and admins can still audit and export group conversations, because that is part of the auditable model. Direct messages stay private through access rules.
Is per-organization encryption the same as end-to-end encryption?
No. With end-to-end encryption, only the participants' devices hold the keys. With per-organization keys, the service holds the keys and decrypts content for authorized access under its rules.