Encryption is a term every business recognizes but that few actually interrogate in conversations with potential vendors. If a provider says that it encrypts data or that it offers “bank-grade security”, these phrases sound reassuring. But they don’t actually tell you anything about the encryption itself: encrypted where, encrypted when, and encrypted how?
We’ll explain the difference between encryption at rest and encryption in transit, what your business needs to know about them, and what to ask vendors when you’re approaching them.
What do encryption at rest and encryption in transit mean?
What encryption in transit means
Encryption at rest vs encryption in transit
Why zero-access architecture mitigates risk
Why both types of encryption matter for businesses
What security agencies say about cloud services
What to ask vendors about encryption
What do encryption at rest and encryption in transit mean?
Credentials, customer records, financial data, employee files, and internal documents pass through three distinct conditions during an ordinary workday:
- They sit in storage.
- They travel across networks.
- They’re decrypted so someone can actually use them.
Each of those conditions is vulnerable to a different kind of attack, and a service can be well-protected in one condition while vulnerable in another.
The two terms every business leader should understand are encryption at rest and encryption in transit. They are often mentioned together, but they do different jobs. One protects data while it is stored. The other protects data while it is moving.
Both are necessary, but when you’re using encryption you have to consider who holds the keys to decrypt your data. If your service provider does, then they can access everything in your business network. We’ve written extensively about how encryption works if you need to refresh your memory.
Understanding end-to-end encryption and zero-access architecture is essential for every business trying to protect its data. Especially when it comes to choosing a business password manager and other systems that store sensitive business information.
What encryption at rest means
Encryption at rest means that data is encrypted while it is stored. That storage could be a server, database, hard drive, laptop, backup, cloud storage system, or mobile device.
For a business, stored data is a target for hackers and cyber criminals. A stolen laptop, lost hard drive, compromised server, exposed backup, or breached database all put information at risk. But if the data is encrypted at rest, the person who obtains the storage medium or database still needs the right key to read it.
Think of a locked filing cabinet. The cabinet may be stolen, but the files inside are still protected if the lock holds and the key is not available. Encryption at rest plays a similar role for stored data.
Encryption at rest is especially important for credential management. A business password manager, for example, stores usernames, passwords, secure notes, recovery codes, and other sensitive items. If that stored data were not encrypted, a server breach could expose the contents directly. With strong encryption at rest, the attacker may obtain encrypted material but not the readable secrets inside it.
However, encryption at rest has a limit that businesses often miss. It protects stored data against certain types of unauthorized access, but it can’t automatically protect data from every authorized user, malicious insider, compromised admin account, or provider with access to the encryption keys.
A vendor can encrypt data at rest and still be technically able to decrypt it if they control the keys. That may be acceptable for some services, depending on the data and use case. It is not the same as saying the provider can’t read the data.
What encryption in transit means
Encryption in transit protects data while it travels between systems. For example, this could be between an employee’s browser and a cloud application, between an app and a server, between two servers, or between a password manager on someone’s laptop and the servers it syncs with.
The most obvious example is HTTPS. When a website uses HTTPS, the connection between the browser and the website is encrypted. This helps prevent someone on the same network, an internet service provider, or another intermediary from reading or altering the data as it travels.
For businesses, encryption in transit is important because work (and data) now moves constantly between people, devices, and cloud services. A login request, file upload, API connection, dashboard view, or message may pass through networks the business doesn’t control. Encryption in transit helps protect that movement, so sensitive information is not exposed while traveling between the employee and the service they’re using.
Login pages, payment forms, dashboards, cloud tools, and password managers should never rely on unencrypted connections. If credentials travel across the internet without encryption, they are exposed before they even reach the system that stores them.
Encryption in transit is essential, but it only protects the data while it’s moving. Once the data arrives, the receiving system still needs to store and process it safely. A service can use HTTPS and still store data in a way that creates risk later. Encryption at rest and encryption in transit need to work together.
Encryption at rest vs encryption in transit
The difference between these two types of encryption is easier to understand by looking at what happens to a piece of business data throughout the day:
A password stored in a business password manager needs protection while it sits in a vault. This is encryption at rest.
When the app syncs with a server, or when an employee connects from a browser or mobile device, that same data also needs protection while it travels. This is encryption in transit.
Both stages are important, but they protect against different risks. Stored data can be exposed through a server breach, stolen device, compromised database, or unprotected cloud backup. Data in transit can be exposed through interception, insecure networks, or misconfigured connections. Once data is decrypted for use, the risk changes: phishing, malware(新しいウィンドウ), compromised accounts, malicious access, or provider-side access can all come into play depending on how the service is built.
A claim of encryption alone from a vendor isn’t enough. A vendor that encrypts the connection but not the stored data may still leave information vulnerable after it reaches the server. A vendor that encrypts both storage and transport has a stronger baseline, but businesses still need to understand who holds the keys and who can decrypt the data.
This is especially important for a business’s credentials. Passwords, recovery codes, and secure notes aren’t ordinary business records. They’re access paths into multiple sensitive systems. For lower-risk information, standard encryption at rest and in transit may be enough. For business credentials, legal data, sensitive files, and customer records, businesses should ask whether data is only encrypted while it is stored and moving, or whether the service is designed so the provider can’t read the content either.
Why zero-access architecture mitigates risk
End-to-end encryption means data is encrypted before it leaves the user’s device and can only be decrypted by the intended user or recipient. In a zero-access model, the provider stores encrypted data but does not have the keys needed to read it.
This distinction often gets lost in business discussions about encryption. A provider may encrypt data at rest on its servers and encrypt data in transit over the network, but still hold the keys. In that case, the provider’s systems can decrypt the data during normal operations.
With zero-access encryption, the service is designed differently. The provider can store and sync encrypted data, but can’t read the underlying content. This eliminates the risk created by provider access, server compromise, or internal misuse, because the most sensitive data isn’t available in readable form on the provider side.
Proton’s encryption hub offers a full explanation of how encryption works across the Proton ecosystem, including end-to-end encryption and zero-access encryption.
A secure business password manager like Proton Pass for Business applies end-to-end encryption to every field, not only the password: Usernames, web addresses, and everything stored in encrypted notes are encrypted before the data reaches Proton’s servers, and can only be decrypted with the user’s account password, which Proton doesn’t hold. That metadata coverage is a genuine differentiator.
Some password managers encrypt the password field and leave metadata such as usernames and URLs exposed, which means the provider — and anyone who breaches it — can still see which services a company holds accounts with, even without reading a single password.
This list is an effective map for an attacker: which finance platform, which payroll provider, or which admin console to target in order to work effectively. It’s exactly the kind of reconnaissance an attacker would otherwise have to work for. With Proton Pass for Business, nothing is left unencrypted.
Why both types of encryption matter for businesses
Businesses depend on cloud services for email, file storage, HR, payroll, finance, CRM, analytics, and much more. Each service they rely on then becomes part of their data protection posture.
Encryption in transit helps protect employees as they connect to those services. Encryption at rest helps protect the data stored inside them. Zero-access or end-to-end encryption adds another layer when the business needs stronger assurance that the provider itself cannot read the content.
It’s also key to take metadata into account, because it is the layer most often left unprotected. Metadata can tell an attacker who holds an account with which service, when an item was created or last changed, or which URLs a vault points to. Even if a business has every password encrypted, unencrypted metadata can leak a full inventory of its tooling, its vendors, and its internal structure through metadata alone.
When it comes to a password manager, the difference is clear. If it encrypts data in transit but not at rest, stored credentials may be exposed if the service is breached. If it encrypts at rest and in transit but keeps the decryption keys, the provider may still be able to access the data. If it uses end-to-end encryption with a zero-access model and extends that encryption to metadata, neither the credentials nor the picture of where they are used is readable to anyone but the business itself.
What security agencies say about cloud services
Many businesses rely on cloud services without fully understanding how those services protect data. The NCSC’s cloud security guidance(新しいウィンドウ) in the UK encourages organizations to assess cloud services against a set of security principles, including data protection, identity and authentication, secure administration, and operational security. CISA in the United States and ENISA across the EU publish comparable frameworks, and they converge on the same core expectations.
For encryption, that means businesses should not only ask whether a vendor encrypts data. They should understand how data is protected across the service lifecycle: when it is uploaded, stored, processed, accessed, backed up, shared, and deleted.
This is especially relevant for SaaS tools where the vendor manages much of the infrastructure. The business may not control the servers, but it can still choose vendors with better security architecture, clearer documentation, stronger authentication, and encryption models that match the sensitivity of the data.
A business password manager belongs in the high-sensitivity category because it concentrates access to other business systems. If its encryption model is weak, the risk does not stop at the password vault. It can extend to email, cloud storage, finance tools, customer platforms, admin panels, and any other service connected to the credentials stored inside.
As a password manager for IT teams, Proton Pass for Business adds business controls such as admin policies, reporting, logs, group management, SCIM provisioning, and SSO integration. These features help businesses manage who can access credentials, how access is granted, and how credential security is governed across the team.
What to ask vendors about encryption
When a vendor says your data is encrypted, ask for specifics. The word “encrypted” is useful only when the business understands what is protected, when it is protected, and who can decrypt it.
For any service that stores sensitive business data, ask:
- Is data encrypted in transit?
- Is data encrypted at rest?
- Which data types are covered, passwords only, or every field?
- Is metadata encrypted too, including usernames, URLs, and item titles?
- Are backups encrypted too?
- Who creates and stores the encryption keys?
- Can the provider decrypt customer data?
- Can support teams access the content?
- Does the service use end-to-end encryption or zero-access encryption?
- What happens if the provider’s servers are breached?
- Does the service support MFA, admin policies, access logs, and secure sharing?
These questions are even more important to ask of a business password manager because credentials connect to other systems. The service should protect passwords throughout their lifecycle: creation, storage, sharing, use, monitoring, and removal.
Strong password generation is useful, but it is a feature inside the password manager rather than a standalone solution. The real value comes from combining unique credentials with encrypted storage, controlled sharing, MFA, passkeys, admin visibility, and offboarding controls.
A business password manager fits into that broader data protection strategy by helping teams store credentials with end-to-end encryption, share access securely, reduce password reuse, manage passkeys, use built-in two-factor authentication, and give admins more control over business credential access.
Store your business credentials with zero-access encryption, try Proton Pass for Business.
