Perry Chaffee

∙

7 Tips for Choosing Encryption Solutions

7 Tips for Choosing Encryption Solutions

Perry Chaffee

∙

7 Tips for Choosing Encryption Solutions

7 Tips for Choosing Encryption Solutions

Perry Chaffee

∙

7 Tips for Choosing Encryption Solutions

7 Tips for Choosing Encryption Solutions

Evaluating an encryption vendor comes down to seven questions: whether their marketing relies on vague buzzwords, whether the algorithm is a proven standard, how well it's actually implemented, whether it fits your specific use case, when and where the data gets encrypted, where the encryption keys live, and whether the whole effort is aimed at compliance or at genuine security. Asking them in order filters out most of the noise vendors put in front of real answers.

As tech has facilitated the rapid migration of value from the physical to the digital world, crime has followed the money online. In the resulting high-threat world we live in, cybercriminals and cybersecurity experts are in a high-stakes arms race. Attackers seek new ways to gain unauthorized access to data and information systems, and defenders try to find new ways to prevent this. These strategies quickly become highly technical and highly nuanced. The devil is in the details, and for those lacking deep technical knowledge, explanations can quickly become confusing.

Making things worse, cybersecurity vendors often employ marketing and sales teams with only a basic understanding of the solutions they're selling, and who are quick to throw around the latest buzzwords to impress prospects. Cybersecurity vendors are businesses, and businesses earn money from closing deals, not necessarily from delivering the best fit or the best quality solution. Do they need to know everything about encryption? No. Do they want you to know everything about encryption? Of course not. They simply want to know what keywords get their site to the top of your search results, and what buzzwords get you to hand over your money on a sales call. "It's military grade encryption," they'll say, "it's unhackable, unbreakable, all the other big companies use it, and your competitors use it too."

For business leaders simply trying to protect themselves, these conversations aren't far off from pharmaceutical commercials on TV about miracle drugs: "Try this new medication, it will change your life! You don't need to understand how it works, just trust us. By the way, our attorneys require us to list possible side effects, which include nausea, diarrhea, cancer, blindness, tinnitus, migraine headaches, and death."

Comparing different solutions for encryption and encryption key management can feel like trying to decide between fourteen-syllable medications that all look the same and sound equally unfamiliar. You can Google each one, and the manufacturer will tell you all the reasons they're great and why you'll suffer without them. If you want a second opinion before trying one, here are the questions worth asking first.

1. Is the Vendor Selling Snake-Oil Cryptography?

Terms like "military grade encryption" don't actually mean anything. They're used to sound impressive, and should be viewed as a red flag. If a vendor can't explain their solution without resorting to tactics like these, you won't know what inadequacies and vulnerabilities the marketing is hiding until it's too late.

2. Is the Encryption Algorithm a Proven Industry Standard, or "Advanced, New, Cutting Edge"?

When it comes to encryption, always go with industry standards. These solutions are well tested and proven by the world's leading cryptographers. Homegrown solutions often lack this level of testing, can have unknown vulnerabilities, and can be unreliable, which can leave your data lost or compromised. The bad guys aren't the only ones who can execute a denial-of-service attack against your own data; you can do it to yourself too.

For what a transparent, independently reviewable approach to this looks like in practice, see Is Open Source Security Really Safe?

3. What Is the Encryption Architecture? How Is the Standard Implemented?

Just because an industry standard is used doesn't mean it's used correctly. If the encryption isn't properly implemented, it can completely invalidate the value it provides. Think of it like locking the door and leaving the key in the lock. It's not very useful, but it's alarmingly common in the encryption world.

You may not have the deep technical knowledge to assess the architecture yourself, so look for reviews by independent third parties. Also consider open source solutions, where you or your team can read through feedback and reviews from the open source community to avoid software with obvious, severe problems.

4. Will This Encryption Architecture Actually Work for My Use Case?

There's no silver bullet. Trying to apply a one-size-fits-all solution to your business could do more harm than good, creating user experience problems or leaving you exposed to vulnerabilities unique to your use case that an off-the-shelf solution doesn't address. Be wary of vendors who claim their standard, off-the-shelf encryption will easily integrate into your unique, customized architecture straight out of the box. There's a good chance your architecture itself needs modification to actually realize the value of the security solution, and a good vendor will help you assess and accomplish that.

5. When and Where Is the Data Encrypted?

Approach

How it works

Main risk

Server-side encryption

Data is encrypted at rest while stored by the provider

A single breach can expose all of it in bulk at once

Encryption in transit

Protects data moving between client and server

Doesn't protect data at rest, before or after transmission

Client-side encryption

Data is encrypted on the client before it's ever transmitted or stored

Each client's data uses a separate key, so bulk compromise isn't practical

Typical solutions use server-side encryption, where data is encrypted at rest while being stored by the provider. If the provider is hacked, it's possible that all of the data could be compromised in bulk at once. As another attack vector, hackers can try to intercept data in transit between the server and the client, which is why end-to-end encryption has become more common. Many companies consider data well protected with a combination of these two approaches, but the most secure approach by far is to encrypt the data on the client side first, before it's ever transmitted or stored. With client-side encryption, the data is never useful during transmission or while stored at rest. Even if the provider's server is compromised, the data is encrypted with a separate key for every client, which means bulk compromise isn't possible, and breaking the encryption for each individual record isn't practical. For how to evaluate specific vendor claims around this, see Client-Side vs Zero-Access Encryption: What Buyers Should Ask.

6. Where Are the Encryption Keys Stored?

Many companies, focused more on compliance than security, are tasked with encrypting data at rest. One of the simplest, and unfortunately most common, ways to do this is to store the encryption key right on the same server as the data it protects, which is also one of the least secure methods. It's like being required to protect something with a lock, then leaving the key right there in the lock. If the server is compromised, the encryption key for the data on it is usually compromised too. Hackers love this, because it creates a central point of failure that gives them access to everything they want.

There are alternative approaches, but the most secure of all is for the client to physically possess the encryption key for their own data. With this approach, there's a different key for every client, all physically distributed, a pattern worth understanding in more detail. Hackers hate this, because it makes bulk data compromise extremely impractical.

There are multiple ways to equip users with client-side encryption keys, but they can become cumbersome when combined with traditional 2FA or MFA solutions. WWPass is one approach that lets a user consolidate their authentication and encryption tokens into one device, app, or service, improving both security and convenience for the whole system at once.

7. Is the Focus of the Solution on Compliance or Security?

Just because something is compliant doesn't mean it's secure, and most companies that suffer data breaches were compliant at the time. When something is truly secure, though, it often exceeds compliance requirements. If you focus on compliance, you'll have a checklist to point to after you get hacked. If you focus on security, you'll be compliant too, and you'll also build a reputation for quality, credibility, and trust, while avoiding the damage a breach causes.

Think of compliance like having a driver's license. You shouldn't be driving at all without one, but having one doesn't make you a safe driver. A valid license may keep a driver who causes a serious accident out of jail, but it doesn't keep anyone involved out of the emergency room. If you value your business and its customers, focus on security rather than compliance alone. For a related angle on this trade-off in document systems specifically, see 5 Ways to Secure Document Management.

FAQ

What does "military grade encryption" actually mean?
Nothing specific. It's a marketing phrase, not a technical standard, and vendors who lean on it instead of explaining their actual architecture are worth a closer look before you trust them.

Why does it matter where encryption keys are stored?
If a key sits on the same server as the data it protects, compromising that server compromises the key too, creating a single point of failure. Keys held physically by the client, one per client, make bulk compromise far harder to pull off.

Is a compliant encryption solution automatically a secure one?
No. Many companies that suffer data breaches were compliant at the time of the breach. Compliance is a baseline checklist; genuine security usually exceeds it.

What's the difference between server-side, in-transit, and client-side encryption?
Server-side encrypts data at rest on the provider's servers. In-transit encryption protects data moving between client and server but not data at rest. Client-side encryption encrypts the data before it ever leaves the client, so even a compromised server only yields ciphertext tied to a key the provider never had.

The Bottom Line

Although cybercrime continues to escalate, and incidents continue to grow larger and more frequent, a little common sense goes a long way in protecting your business and its customers. Asking these seven questions can help you avoid implementing a solution that causes more harm than good.

Evaluating an encryption vendor comes down to seven questions: whether their marketing relies on vague buzzwords, whether the algorithm is a proven standard, how well it's actually implemented, whether it fits your specific use case, when and where the data gets encrypted, where the encryption keys live, and whether the whole effort is aimed at compliance or at genuine security. Asking them in order filters out most of the noise vendors put in front of real answers.

As tech has facilitated the rapid migration of value from the physical to the digital world, crime has followed the money online. In the resulting high-threat world we live in, cybercriminals and cybersecurity experts are in a high-stakes arms race. Attackers seek new ways to gain unauthorized access to data and information systems, and defenders try to find new ways to prevent this. These strategies quickly become highly technical and highly nuanced. The devil is in the details, and for those lacking deep technical knowledge, explanations can quickly become confusing.

Making things worse, cybersecurity vendors often employ marketing and sales teams with only a basic understanding of the solutions they're selling, and who are quick to throw around the latest buzzwords to impress prospects. Cybersecurity vendors are businesses, and businesses earn money from closing deals, not necessarily from delivering the best fit or the best quality solution. Do they need to know everything about encryption? No. Do they want you to know everything about encryption? Of course not. They simply want to know what keywords get their site to the top of your search results, and what buzzwords get you to hand over your money on a sales call. "It's military grade encryption," they'll say, "it's unhackable, unbreakable, all the other big companies use it, and your competitors use it too."

For business leaders simply trying to protect themselves, these conversations aren't far off from pharmaceutical commercials on TV about miracle drugs: "Try this new medication, it will change your life! You don't need to understand how it works, just trust us. By the way, our attorneys require us to list possible side effects, which include nausea, diarrhea, cancer, blindness, tinnitus, migraine headaches, and death."

Comparing different solutions for encryption and encryption key management can feel like trying to decide between fourteen-syllable medications that all look the same and sound equally unfamiliar. You can Google each one, and the manufacturer will tell you all the reasons they're great and why you'll suffer without them. If you want a second opinion before trying one, here are the questions worth asking first.

1. Is the Vendor Selling Snake-Oil Cryptography?

Terms like "military grade encryption" don't actually mean anything. They're used to sound impressive, and should be viewed as a red flag. If a vendor can't explain their solution without resorting to tactics like these, you won't know what inadequacies and vulnerabilities the marketing is hiding until it's too late.

2. Is the Encryption Algorithm a Proven Industry Standard, or "Advanced, New, Cutting Edge"?

When it comes to encryption, always go with industry standards. These solutions are well tested and proven by the world's leading cryptographers. Homegrown solutions often lack this level of testing, can have unknown vulnerabilities, and can be unreliable, which can leave your data lost or compromised. The bad guys aren't the only ones who can execute a denial-of-service attack against your own data; you can do it to yourself too.

For what a transparent, independently reviewable approach to this looks like in practice, see Is Open Source Security Really Safe?

3. What Is the Encryption Architecture? How Is the Standard Implemented?

Just because an industry standard is used doesn't mean it's used correctly. If the encryption isn't properly implemented, it can completely invalidate the value it provides. Think of it like locking the door and leaving the key in the lock. It's not very useful, but it's alarmingly common in the encryption world.

You may not have the deep technical knowledge to assess the architecture yourself, so look for reviews by independent third parties. Also consider open source solutions, where you or your team can read through feedback and reviews from the open source community to avoid software with obvious, severe problems.

4. Will This Encryption Architecture Actually Work for My Use Case?

There's no silver bullet. Trying to apply a one-size-fits-all solution to your business could do more harm than good, creating user experience problems or leaving you exposed to vulnerabilities unique to your use case that an off-the-shelf solution doesn't address. Be wary of vendors who claim their standard, off-the-shelf encryption will easily integrate into your unique, customized architecture straight out of the box. There's a good chance your architecture itself needs modification to actually realize the value of the security solution, and a good vendor will help you assess and accomplish that.

5. When and Where Is the Data Encrypted?

Approach

How it works

Main risk

Server-side encryption

Data is encrypted at rest while stored by the provider

A single breach can expose all of it in bulk at once

Encryption in transit

Protects data moving between client and server

Doesn't protect data at rest, before or after transmission

Client-side encryption

Data is encrypted on the client before it's ever transmitted or stored

Each client's data uses a separate key, so bulk compromise isn't practical

Typical solutions use server-side encryption, where data is encrypted at rest while being stored by the provider. If the provider is hacked, it's possible that all of the data could be compromised in bulk at once. As another attack vector, hackers can try to intercept data in transit between the server and the client, which is why end-to-end encryption has become more common. Many companies consider data well protected with a combination of these two approaches, but the most secure approach by far is to encrypt the data on the client side first, before it's ever transmitted or stored. With client-side encryption, the data is never useful during transmission or while stored at rest. Even if the provider's server is compromised, the data is encrypted with a separate key for every client, which means bulk compromise isn't possible, and breaking the encryption for each individual record isn't practical. For how to evaluate specific vendor claims around this, see Client-Side vs Zero-Access Encryption: What Buyers Should Ask.

6. Where Are the Encryption Keys Stored?

Many companies, focused more on compliance than security, are tasked with encrypting data at rest. One of the simplest, and unfortunately most common, ways to do this is to store the encryption key right on the same server as the data it protects, which is also one of the least secure methods. It's like being required to protect something with a lock, then leaving the key right there in the lock. If the server is compromised, the encryption key for the data on it is usually compromised too. Hackers love this, because it creates a central point of failure that gives them access to everything they want.

There are alternative approaches, but the most secure of all is for the client to physically possess the encryption key for their own data. With this approach, there's a different key for every client, all physically distributed, a pattern worth understanding in more detail. Hackers hate this, because it makes bulk data compromise extremely impractical.

There are multiple ways to equip users with client-side encryption keys, but they can become cumbersome when combined with traditional 2FA or MFA solutions. WWPass is one approach that lets a user consolidate their authentication and encryption tokens into one device, app, or service, improving both security and convenience for the whole system at once.

7. Is the Focus of the Solution on Compliance or Security?

Just because something is compliant doesn't mean it's secure, and most companies that suffer data breaches were compliant at the time. When something is truly secure, though, it often exceeds compliance requirements. If you focus on compliance, you'll have a checklist to point to after you get hacked. If you focus on security, you'll be compliant too, and you'll also build a reputation for quality, credibility, and trust, while avoiding the damage a breach causes.

Think of compliance like having a driver's license. You shouldn't be driving at all without one, but having one doesn't make you a safe driver. A valid license may keep a driver who causes a serious accident out of jail, but it doesn't keep anyone involved out of the emergency room. If you value your business and its customers, focus on security rather than compliance alone. For a related angle on this trade-off in document systems specifically, see 5 Ways to Secure Document Management.

FAQ

What does "military grade encryption" actually mean?
Nothing specific. It's a marketing phrase, not a technical standard, and vendors who lean on it instead of explaining their actual architecture are worth a closer look before you trust them.

Why does it matter where encryption keys are stored?
If a key sits on the same server as the data it protects, compromising that server compromises the key too, creating a single point of failure. Keys held physically by the client, one per client, make bulk compromise far harder to pull off.

Is a compliant encryption solution automatically a secure one?
No. Many companies that suffer data breaches were compliant at the time of the breach. Compliance is a baseline checklist; genuine security usually exceeds it.

What's the difference between server-side, in-transit, and client-side encryption?
Server-side encrypts data at rest on the provider's servers. In-transit encryption protects data moving between client and server but not data at rest. Client-side encryption encrypts the data before it ever leaves the client, so even a compromised server only yields ciphertext tied to a key the provider never had.

The Bottom Line

Although cybercrime continues to escalate, and incidents continue to grow larger and more frequent, a little common sense goes a long way in protecting your business and its customers. Asking these seven questions can help you avoid implementing a solution that causes more harm than good.

Evaluating an encryption vendor comes down to seven questions: whether their marketing relies on vague buzzwords, whether the algorithm is a proven standard, how well it's actually implemented, whether it fits your specific use case, when and where the data gets encrypted, where the encryption keys live, and whether the whole effort is aimed at compliance or at genuine security. Asking them in order filters out most of the noise vendors put in front of real answers.

As tech has facilitated the rapid migration of value from the physical to the digital world, crime has followed the money online. In the resulting high-threat world we live in, cybercriminals and cybersecurity experts are in a high-stakes arms race. Attackers seek new ways to gain unauthorized access to data and information systems, and defenders try to find new ways to prevent this. These strategies quickly become highly technical and highly nuanced. The devil is in the details, and for those lacking deep technical knowledge, explanations can quickly become confusing.

Making things worse, cybersecurity vendors often employ marketing and sales teams with only a basic understanding of the solutions they're selling, and who are quick to throw around the latest buzzwords to impress prospects. Cybersecurity vendors are businesses, and businesses earn money from closing deals, not necessarily from delivering the best fit or the best quality solution. Do they need to know everything about encryption? No. Do they want you to know everything about encryption? Of course not. They simply want to know what keywords get their site to the top of your search results, and what buzzwords get you to hand over your money on a sales call. "It's military grade encryption," they'll say, "it's unhackable, unbreakable, all the other big companies use it, and your competitors use it too."

For business leaders simply trying to protect themselves, these conversations aren't far off from pharmaceutical commercials on TV about miracle drugs: "Try this new medication, it will change your life! You don't need to understand how it works, just trust us. By the way, our attorneys require us to list possible side effects, which include nausea, diarrhea, cancer, blindness, tinnitus, migraine headaches, and death."

Comparing different solutions for encryption and encryption key management can feel like trying to decide between fourteen-syllable medications that all look the same and sound equally unfamiliar. You can Google each one, and the manufacturer will tell you all the reasons they're great and why you'll suffer without them. If you want a second opinion before trying one, here are the questions worth asking first.

1. Is the Vendor Selling Snake-Oil Cryptography?

Terms like "military grade encryption" don't actually mean anything. They're used to sound impressive, and should be viewed as a red flag. If a vendor can't explain their solution without resorting to tactics like these, you won't know what inadequacies and vulnerabilities the marketing is hiding until it's too late.

2. Is the Encryption Algorithm a Proven Industry Standard, or "Advanced, New, Cutting Edge"?

When it comes to encryption, always go with industry standards. These solutions are well tested and proven by the world's leading cryptographers. Homegrown solutions often lack this level of testing, can have unknown vulnerabilities, and can be unreliable, which can leave your data lost or compromised. The bad guys aren't the only ones who can execute a denial-of-service attack against your own data; you can do it to yourself too.

For what a transparent, independently reviewable approach to this looks like in practice, see Is Open Source Security Really Safe?

3. What Is the Encryption Architecture? How Is the Standard Implemented?

Just because an industry standard is used doesn't mean it's used correctly. If the encryption isn't properly implemented, it can completely invalidate the value it provides. Think of it like locking the door and leaving the key in the lock. It's not very useful, but it's alarmingly common in the encryption world.

You may not have the deep technical knowledge to assess the architecture yourself, so look for reviews by independent third parties. Also consider open source solutions, where you or your team can read through feedback and reviews from the open source community to avoid software with obvious, severe problems.

4. Will This Encryption Architecture Actually Work for My Use Case?

There's no silver bullet. Trying to apply a one-size-fits-all solution to your business could do more harm than good, creating user experience problems or leaving you exposed to vulnerabilities unique to your use case that an off-the-shelf solution doesn't address. Be wary of vendors who claim their standard, off-the-shelf encryption will easily integrate into your unique, customized architecture straight out of the box. There's a good chance your architecture itself needs modification to actually realize the value of the security solution, and a good vendor will help you assess and accomplish that.

5. When and Where Is the Data Encrypted?

Approach

How it works

Main risk

Server-side encryption

Data is encrypted at rest while stored by the provider

A single breach can expose all of it in bulk at once

Encryption in transit

Protects data moving between client and server

Doesn't protect data at rest, before or after transmission

Client-side encryption

Data is encrypted on the client before it's ever transmitted or stored

Each client's data uses a separate key, so bulk compromise isn't practical

Typical solutions use server-side encryption, where data is encrypted at rest while being stored by the provider. If the provider is hacked, it's possible that all of the data could be compromised in bulk at once. As another attack vector, hackers can try to intercept data in transit between the server and the client, which is why end-to-end encryption has become more common. Many companies consider data well protected with a combination of these two approaches, but the most secure approach by far is to encrypt the data on the client side first, before it's ever transmitted or stored. With client-side encryption, the data is never useful during transmission or while stored at rest. Even if the provider's server is compromised, the data is encrypted with a separate key for every client, which means bulk compromise isn't possible, and breaking the encryption for each individual record isn't practical. For how to evaluate specific vendor claims around this, see Client-Side vs Zero-Access Encryption: What Buyers Should Ask.

6. Where Are the Encryption Keys Stored?

Many companies, focused more on compliance than security, are tasked with encrypting data at rest. One of the simplest, and unfortunately most common, ways to do this is to store the encryption key right on the same server as the data it protects, which is also one of the least secure methods. It's like being required to protect something with a lock, then leaving the key right there in the lock. If the server is compromised, the encryption key for the data on it is usually compromised too. Hackers love this, because it creates a central point of failure that gives them access to everything they want.

There are alternative approaches, but the most secure of all is for the client to physically possess the encryption key for their own data. With this approach, there's a different key for every client, all physically distributed, a pattern worth understanding in more detail. Hackers hate this, because it makes bulk data compromise extremely impractical.

There are multiple ways to equip users with client-side encryption keys, but they can become cumbersome when combined with traditional 2FA or MFA solutions. WWPass is one approach that lets a user consolidate their authentication and encryption tokens into one device, app, or service, improving both security and convenience for the whole system at once.

7. Is the Focus of the Solution on Compliance or Security?

Just because something is compliant doesn't mean it's secure, and most companies that suffer data breaches were compliant at the time. When something is truly secure, though, it often exceeds compliance requirements. If you focus on compliance, you'll have a checklist to point to after you get hacked. If you focus on security, you'll be compliant too, and you'll also build a reputation for quality, credibility, and trust, while avoiding the damage a breach causes.

Think of compliance like having a driver's license. You shouldn't be driving at all without one, but having one doesn't make you a safe driver. A valid license may keep a driver who causes a serious accident out of jail, but it doesn't keep anyone involved out of the emergency room. If you value your business and its customers, focus on security rather than compliance alone. For a related angle on this trade-off in document systems specifically, see 5 Ways to Secure Document Management.

FAQ

What does "military grade encryption" actually mean?
Nothing specific. It's a marketing phrase, not a technical standard, and vendors who lean on it instead of explaining their actual architecture are worth a closer look before you trust them.

Why does it matter where encryption keys are stored?
If a key sits on the same server as the data it protects, compromising that server compromises the key too, creating a single point of failure. Keys held physically by the client, one per client, make bulk compromise far harder to pull off.

Is a compliant encryption solution automatically a secure one?
No. Many companies that suffer data breaches were compliant at the time of the breach. Compliance is a baseline checklist; genuine security usually exceeds it.

What's the difference between server-side, in-transit, and client-side encryption?
Server-side encrypts data at rest on the provider's servers. In-transit encryption protects data moving between client and server but not data at rest. Client-side encryption encrypts the data before it ever leaves the client, so even a compromised server only yields ciphertext tied to a key the provider never had.

The Bottom Line

Although cybercrime continues to escalate, and incidents continue to grow larger and more frequent, a little common sense goes a long way in protecting your business and its customers. Asking these seven questions can help you avoid implementing a solution that causes more harm than good.

Get WWPass

Download the WWPass Key app and test authentication without a username or password.

© 2026 World Wide Pass — WWPass

Get WWPass

Download the WWPass Key app and test authentication without a username or password.

© 2026 World Wide Pass — WWPass

Get WWPass

Download the WWPass Key app and test authentication without a username or password.

© 2026 World Wide Pass — WWPass