Encryption at Rest vs End-to-End

Scroll through the feature pages of any ten form builders and you will find the word "encryption" on nine of them. Look closer and you'll notice something revealing: most never say which kind. "Your data is encrypted" is not a specification — it's a vibe. And in the world of data protection, that ambiguity is where the real cost lives.

There are two fundamentally different encryption models in common use: encryption at rest and end-to-end encryption. They sound similar, they both use strong algorithms, and they both produce ciphertext on disk. But they solve completely different problems — and if you pick the wrong one for a breach you face tomorrow, the price tag can reach eight figures.

The Two Models, in Plain Language

Encryption at rest

Data arrives at the server in plain text (over HTTPS), the server processes it, and before writing it to disk the server encrypts it with a key the server controls. When the data is needed, the server uses the same key to decrypt it. The encryption is real, but the server is in possession of both the data and the key at the moments that matter.

End-to-end encryption

Data is encrypted on the sender's device before it is ever transmitted. The ciphertext travels over HTTPS and is stored on the server as ciphertext. The server never holds the decryption key. Only the intended recipient — using a key on their own device — can read the plaintext. The server is reduced from a custodian of data to a courier of ciphertext.

Where the Two Models Actually Diverge

The question you should ask about any encryption scheme is this: who can decrypt the data, and under what circumstances? Encryption at rest answers: "the server — whenever it wants." End-to-end answers: "only the recipient — and only on their own device." The gap between those two answers is where most real-world breaches happen.

Encryption at rest is essentially a physical-security control dressed up as a digital one. It meaningfully protects one narrow attack vector — loss or theft of the physical medium — and little else. Almost every data breach you have read about in the news happened through the application layer, where encryption at rest offers no protection.

Why the Difference Can Literally Cost Millions

According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach reached USD 4.88 million — the highest ever recorded. Healthcare breaches averaged USD 9.77 million, and breaches involving customer PII were the most expensive category across every industry.

But headline figures hide the structure of the cost. A single breach drives expense across four distinct categories:

• Detection and investigation — forensics, containment, third-party consultants
• Notification and response — informing affected individuals, regulator reporting, credit monitoring
• Regulatory penalties — GDPR fines up to 4% of global turnover, nFADP criminal sanctions up to CHF 250,000 on responsible individuals
• Lost business and reputation — churn, delayed deals, rebuilding trust

Here is the crucial part: under both GDPR and the Swiss nFADP, if the compromised data was rendered unintelligible to any unauthorised party — that is, if it was end-to-end encrypted and the keys remain protected — individual notification may not be required, and enforcement authorities typically view the incident as materially less severe. That single distinction can take a breach from a nine-figure catastrophe to a contained internal incident.

What Recent Breaches Actually Looked Like

Without naming specific incidents — most are ongoing stories with legal sensitivities — here is the pattern that recurs across almost every large breach in the last decade:

The quiet lesson is that "encrypted at rest" did not protect a single victim in this pattern. The encryption was real, the certification was valid, and the data was still exposed. End-to-end encryption is the model that changes the outcome in step 3: the attacker reads the database and gets ciphertext they cannot use.

When Encryption at Rest Is Still the Right Choice

This article is not an argument that encryption at rest is useless. It has a legitimate, important role — just not the one most marketing pages assign to it.

• Operational data that the service itself must read continuously — search indices, aggregate analytics, operational metrics
• Systems where the server is the intended reader — CRMs where staff legitimately query the data, e-commerce inventory, logging infrastructure
• Compliance with baseline requirements like PCI DSS at-rest clauses, or HIPAA's "addressable" encryption specification, where server-held keys are acceptable
• Defence against physical hardware theft — a legitimate, if rarer, threat vector

The key question is: does the server need to read this data to do its job? If yes, encryption at rest is appropriate, and end-to-end is impossible. If no — which is the case for most form submissions, secure messages, private files, and sensitive records — end-to-end is the model you should be asking for.

Seven Questions to Put to Any Vendor That Claims "Encryption"

The fastest way to cut through marketing copy is to ask specific technical questions. An honest vendor will answer them directly; an evasive answer is itself information.

1. Where, physically and logically, does my plaintext data exist at any point in time?
2. Which of your processes or employees can decrypt my data if they choose to?
3. If you received a lawful subpoena for my data tomorrow, what would you be able to hand over?
4. In the event of a server breach, would the stolen data be readable by the attacker?
5. Do you have the technical ability to reset or recover my data if I lose my credentials?
6. Who controls the encryption keys, and where are they stored?
7. Can I verify your encryption claims through independent audits, open-source code, or observable network behaviour?

Where Schweizerform Stands

Schweizerform was built to be end-to-end encrypted by default. Here is how we would answer the seven questions above, honestly:

• Your plaintext exists in two places: the respondent's browser at the moment of submission, and your browser when you view the submission. It never exists on our servers.
• None of our processes or employees can decrypt your data — we do not hold the keys.
• A lawful subpoena would produce encrypted ciphertext, encrypted key-wrapping material, and metadata. No plaintext answers.
• A server breach would expose ciphertext. No attacker in that scenario can read the submissions.
• We cannot recover your data if you lose your Access Code — which is a deliberate property, not a limitation we have failed to fix. Recovery requires the recovery-key flow that you set up in advance.
• Keys are controlled by you. The form's private RSA key is encrypted with a key derived from your Access Code, and that code never reaches our servers.
• You can verify the encrypted payload yourself in the browser's developer tools — the network tab on any submission will show only ciphertext.

The Bottom Line

Encryption at rest and end-to-end encryption are not two points on the same spectrum. They are two different answers to two different questions. The first is a commodity that almost every SaaS provides; the second is a deliberate architectural choice that meaningfully changes the outcome of a breach.

For most operational systems, encryption at rest is enough. For forms that collect sensitive data — medical, legal, financial, HR, whistleblower — it is not. In those domains, the difference between the two models really can be counted in millions: in fines avoided, notifications not required, and trust not lost.