Key takeaways
- 'Encrypted' is not a model; ask in transit, at rest and end-to-end separately.
- Key control decides who can read content: participants, the business or the vendor.
- Strong standard algorithms (TLS, AES-256) are expected, not a differentiator.
- Superlatives like 'unhackable' or 'military-grade' are red flags, not features.
- Get written answers about vendor access and whether it is logged.
Every messaging app now says it is encrypted. That is good news, and it is also why the word has stopped being useful. Two apps can both be “encrypted” and give completely different answers to the question a buyer actually cares about: who can read our messages, and when? This guide gives you the vocabulary and the questions to cut through vendor marketing, including ours.
Why evaluating encryption claims matters
Evaluating encryption claims matters because the wrong assumption leads to the wrong tool. A company that needs to review group conversations may pick an end-to-end app and discover it can’t. A company that wanted no provider access may pick a server-encrypted app without realizing the provider holds keys.
The broader security picture, including access and offboarding risks, is in business messaging security. Here we focus only on encryption.
In transit, at rest and end-to-end
Three different protections, often blurred together:
| Layer | What it protects | Who can read the content |
|---|---|---|
| In transit (TLS) | Data moving between device and server | The server, once it arrives |
| At rest | Data stored on servers and disks | Whoever controls the keys, usually the service |
| End-to-end | Data from sender device to recipient devices | Only participants’ devices |
A typical business messenger without end-to-end encryption uses the first two. An end-to-end app uses all three, but its servers can still see some metadata, such as who talks to whom and when, depending on design. Algorithms like AES-256 are the standard for the “at rest” layer.
Who holds the keys
Key control is the real question behind “who can read our messages?”:
- Keys only on users’ devices: end-to-end. Neither the vendor nor your company can read content.
- Keys managed by the service, per customer organization: the service can decrypt when needed, and one customer’s key compromise doesn’t expose others.
- One shared key for everything: the weakest arrangement for a multi-customer service.
Then ask the follow-up: if the vendor can decrypt, when does it, who approves it and is that access logged? A vendor that answers clearly is more trustworthy than one that only repeats “military-grade”.
Red flags in marketing copy
Be cautious when you see:
- Superlatives. “Unhackable”, “100% secure”, “military-grade”. Real security teams don’t talk like this.
- “Encrypted” with no layer. Encrypted where? With whose keys?
- End-to-end claims with company oversight. If the vendor also promises your admins can read every chat, ask how both can be true.
- Proprietary algorithms. Custom cryptography is a risk, not a feature.
- Certification badges without documents. Ask for the scope and the report.
- No privacy policy or no named company. You need to know who operates the service.
Questions to send the vendor
Copy these into an email. For a fuller list covering access, logging and account deletion, use the messaging vendor security questionnaire.
- Is data encrypted in transit? With what protocol?
- Is data encrypted at rest? With what algorithm?
- Are messages end-to-end encrypted? If yes, which conversations, and what metadata is still visible to you?
- Who holds the keys? Are keys separate per customer?
- Under what circumstances can your staff access content? Is it logged?
- Can our admins review or export conversations? Which ones?
- How are attachments, such as photos, files and voice notes, protected?
Vendors that manage shared buildings, contractors or field work have a lot of attachments in chat, which is why question 7 matters for workflows like facility vendor coordination or property maintenance requests.
How C Chat answers these questions
Here are our answers, in the same format. C Chat encrypts data in transit with TLS and at rest with AES-256, using per-organization keys. It is not end-to-end encrypted. Instead it uses auditable encryption: team owners and admins can audit and export their team’s group conversations, and direct messages between people are private. The C Chat platform only accesses content to moderate reported messages or for legal requirements, and that access is logged. Photos, files and voice notes are protected the same way as text.
If your requirement is that nobody but participants can read messages, an end-to-end tool is the better fit; see C Chat vs Element, C Chat vs Wire and C Chat vs Threema Work, or the overview of secure business messaging apps. The guide on how to choose a secure messenger helps you decide which model you need.
Getting started
Send the seven questions to every vendor on your list and compare answers in one table. Our full answers are on the security page; to test C Chat yourself, create a team at getcchat.com/c.
Frequently asked questions
What does 'encrypted' mean in a messaging app?
It means data is scrambled so that only someone with the right key can read it. The important details are where it is encrypted (in transit, at rest, or end-to-end between devices) and who has the keys. Without those, the word tells you little.
What is the difference between encryption at rest and end-to-end encryption?
Encryption at rest protects data stored on servers, but the service can decrypt it with its keys when needed. End-to-end encryption means messages are encrypted on the sender's device and only decrypted on recipients' devices, so the service cannot read them.
Is AES-256 secure?
AES-256 is a widely used, well-studied encryption standard and is considered strong when implemented correctly. The algorithm is rarely the weak point; key management, access controls and implementation usually matter more.
Can a messaging company read my messages?
It depends on the model. With end-to-end encryption, the provider cannot read content. With server-side encryption, the provider technically can, so ask under what circumstances it does, who approves it and whether access is logged.