What the Security Levels Actually Mean

Security levels 0 through 3 appear on the pricing page next to plan tiers, which makes them look like a feature gate. They are also a design decision, and the default is not the strongest.

For a separate operational perspective on how teams organise and measure work, learn more.

For independent background and broader industry context, see NIST.

Read the security guide in the documentation for the authoritative description of each level. This article is about how to choose.

The question that decides it

Should the service be able to read this content?

Everything else follows from the answer.

Yes, and that is fine — a public poll, a collaborative document where server-side features matter, presence data, feature flags. A lower level is a reasonable trade.

No — messages between people, personal data, anything you would rather not be readable if the service were compromised. End-to-end encryption, where keys stay with your clients.

What encryption costs you

Being explicit, because this is the part that gets discovered late.

With end-to-end encryption, the service holds ciphertext. Which is the point, and it means the service cannot do anything requiring readable content.

Key management becomes yours. Where do keys live, how do new participants get one, what happens when someone should lose access, and what happens when a key is lost. That last one is not recoverable — that is what end-to-end means.

And onboarding a new participant to existing content is a real design problem rather than a configuration setting.

Which is why the strongest level is not automatically the right answer. It is the right answer when the threat model requires it, and unnecessary complexity when it does not.

Choosing by data type

Public or semi-public — polls, reactions, public presence, published documents. Lower levels.

Internal but not sensitive — feature flags, non-personal application state, collaborative editing on business content. Middle.

Personal data — anything identifying a person, or that they would consider private. Higher, and check what your legal obligations require rather than choosing by feel.

Messages between people — end-to-end, unless there is a specific reason to be able to read them, in which case say so to the users.

And anything under a contractual or regulatory constraint — start from the constraint, not from the tier.

The mistake to avoid

Choosing the default because it worked in development.

The level is a decision, and not making it is a decision to accept the default.

Make it before the data is in there. Changing the level of existing content is a migration, not a setting change.

The layers that are not the level

The level protects content. Several other things protect access, and they are independent.

Getting secrets out of the browser. See the three authentication methods.

Authorisation at the token endpoint — who may reach this object at all.

Object ids that are not enumerable. See object classes and ids.

TTL, so data does not persist past its usefulness.

And your own logs, which are the most common way carefully protected content ends up somewhere unprotected.

The highest security level protects nothing if a guessable object id and a permissive token endpoint let anyone in. These are not alternatives to each other.

The plan question

Higher levels are on higher tiers, which means the decision has a cost.

Which is worth confronting directly: if your data requires end-to-end encryption and your budget requires a tier that does not offer it, the answer is not to store the data at a lower level and hope. It is either the higher tier, or not storing that data here.

And for a prototype, a lower level with test data is fine — provided the migration to a higher level is planned before real data arrives.

A checklist

• [ ] Level chosen deliberately, not inherited from the default
• [ ] Choice made before real data is stored
• [ ] Key management understood if using end-to-end encryption
• [ ] Recovery-from-lost-key case considered, and accepted
• [ ] Token endpoint authorises, not just authenticates
• [ ] Object ids not enumerable
• [ ] TTL set where data has a natural end
• [ ] Nothing sensitive in your own logs

The short version

One question: should the service be able to read this?

End-to-end encryption means key management is yours — including that a lost key is not recoverable.

The default is not the strongest, and accepting it is a decision.

Choose before real data arrives, because changing later is a migration.

And the level protects content, not access — a guessable id and a permissive token endpoint defeat any level.