End-to-end encryption means the file is encrypted before it leaves the sender’s device and decrypted only by the recipient’s browser, so the vendor never holds a usable key. At-rest and in-transit encryption protect storage and transport, but the service can still process plaintext. The difference matters when the goal is preventing the platform itself from seeing file contents.
Why This Matters for Security Teams
File sharing controls are often described with the same language, but they protect against different threats. End-to-end encryption changes who can read the content at all, while at-rest and in-transit encryption mainly protect against interception, lost media, and some infrastructure compromise. For security teams, that distinction affects legal exposure, insider risk, vendor trust, and whether a cloud service can perform indexing, previewing, or content inspection. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful baseline for thinking about encryption as part of a broader control set rather than a standalone guarantee.
The practical question is not whether encryption exists, but where keys live, who can access them, and whether the service must ever decrypt content to function. Salesforce-style encryption is often implemented to reduce exposure of stored files and data in transit, but it does not necessarily stop the platform from processing plaintext during normal operation. That means security claims must be read against the actual key management model, not the marketing label.
In practice, many security teams discover the gap only after a sharing workflow, compliance review, or breach investigation forces them to ask whether the vendor could read the file all along.
How It Works in Practice
End-to-end encryption usually works by encrypting the file on the sender’s device, then keeping the decryption key only with the intended recipient or their client application. The service may store and relay ciphertext, but it cannot meaningfully inspect the contents without the key. That makes it well suited to highly sensitive documents, though it can limit server-side search, previews, malware scanning, and automated workflow features.
By contrast, at-rest and in-transit encryption protect data while it sits on servers or moves across networks, but the provider may still decrypt content in memory to index it, render previews, enforce policy, or support user collaboration. For that reason, these controls reduce exposure to some threats without eliminating platform visibility. In cloud services, that is usually an acceptable tradeoff when usability and governed collaboration are required.
- End-to-end encryption protects content from the service provider itself when keys are not available to the platform.
- At-rest encryption protects stored files, backups, and disks if infrastructure is exposed.
- In-transit encryption protects files against interception between client and service.
- Key custody determines whether the vendor can ever access usable plaintext.
Current guidance suggests treating these as different trust models rather than interchangeable safeguards. If the use case requires the platform to process file contents, then the service is not delivering true end-to-end secrecy for that workflow. The OWASP guidance on application data handling is a useful reminder that security controls must be assessed against actual processing paths, not only storage protections. These controls tend to break down in highly integrated collaboration environments because search, preview, eDiscovery, and automation often require temporary plaintext access.
Common Variations and Edge Cases
Tighter confidentiality often increases operational friction, requiring organisations to balance user convenience against the need to keep the platform blind to file contents. In practice, that tradeoff is where most confusion appears.
Some services advertise customer-managed keys, which improves control over cryptographic material but does not automatically equal end-to-end encryption. If the application can still request decryption for indexing or sharing, the vendor may remain able to process plaintext under defined conditions. There is no universal standard for this yet, so buyers should ask exactly what the service can and cannot do with the content.
Another common edge case is collaboration. If multiple users need live editing, search, comments, or server-side virus scanning, pure end-to-end designs may require reduced functionality or additional client-side processing. That can be acceptable, but it should be a conscious decision. Where personal data, regulated records, or sensitive commercial documents are involved, teams often map the model to NIST SP 800-53 Rev 5 Security and Privacy Controls and verify whether encryption, key management, and access controls align with their confidentiality requirements.
The right choice depends on whether the goal is transport and storage protection, or true content secrecy from the service operator. If the latter is required, organisations should validate key custody, client-side encryption behavior, and any exception paths such as previews, backups, or support access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Data protection guidance fits the distinction between stored, transmitted, and decrypted content. |
| NIST SP 800-63 | Identity assurance affects who can receive and decrypt sensitive shared files. | |
| OWASP Non-Human Identity Top 10 | Service keys and automation identities can expose plaintext if mismanaged. |
Treat file-sharing service identities as NHI and tightly govern their key and access rights.
Related resources from NHI Mgmt Group
- What is the difference between encryption at rest and encryption in transit?
- What is the difference between at-rest protection and runtime protection?
- What is the difference between encryption and access control in AWS data protection?
- What is the difference between access review and sharing revocation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
