Homomorphic Encryption – Enabling Secure Computations on Encrypted Data

Published: June 2025. Updated: August 2026. Reviewed by Encryption Consulting’s Encryption Advisory team.

What Is Homomorphic Encryption, and Why Does It Matter?

Homomorphic encryption (HE) is a class of encryption that allows a party to perform computations directly on ciphertext, without ever decrypting it, such that decrypting the result gives the same answer as running the computation on the original plaintext. It matters because it lets an organization hand sensitive data to a cloud service, an AI model, or a third-party analytics vendor and get a useful answer back, without that party ever seeing the underlying data.

In a typical HE workflow, a client generates a key pair and, for the more advanced schemes, a separate evaluation key. The client encrypts data with the public key and sends only ciphertext to the server. The server uses the evaluation key to run additions and multiplications on that ciphertext, never touching the private key and never recovering plaintext. The client alone decrypts the final result with the private key. As ISACA’s 2024 white paper on privacy enhancing technologies puts it, HE “can be used to obtain insights from computation without revealing the contents of a dataset,” keeping data encrypted “at rest, in transit, and during computation.”

This post defines every acronym you need, walks through how to pick a scheme, states plainly how slow FHE actually is today, and tells you where HE genuinely fits against alternatives like secure multi-party computation (MPC) and trusted execution environments (TEEs). For a shorter, plain-language primer on the concept, see our related explainer, Homomorphic Encryption – Basics.

What Are the Types of Homomorphic Encryption, and Which Scheme Should You Use?

HE comes in three tiers, distinguished by which operations are allowed on ciphertext and how many times.

• Partially Homomorphic Encryption (PHE): Supports one kind of operation, either addition or multiplication, an unlimited number of times. Classic examples are RSA (multiplication) and Paillier (addition).
• Somewhat Homomorphic Encryption (SHE): Supports both addition and multiplication, but only for a limited number of total operations before ciphertext noise grows too large to decrypt correctly.
• Fully Homomorphic Encryption (FHE): Supports arbitrary circuits, any combination of additions and multiplications, using a bootstrapping step that refreshes ciphertext noise. NIST’s Privacy-Enhancing Cryptography project describes FHE as enabling “non-interactive evaluation of functions and operations over encrypted data” without ever exposing the secret key.

Within FHE, the scheme you choose determines what kind of math your application can actually run. The table below summarizes the four schemes that matter in practice, all of which are implemented in the open-source OpenFHE library and, for BFV and CKKS, in Microsoft SEAL.

Scheme	Operations Supported	Data Type	Best Fit
BFV (Brakerski/Fan-Vercauteren)	Exact integer addition and multiplication	Integers, modular arithmetic	Exact analytics on integer or categorical data where precision cannot slip
BGV (Brakerski-Gentry-Vaikuntanathan)	Exact integer addition and multiplication, batched via SIMD-style packing	Integers, packed vectors	Similar to BFV; common in academic implementations and batched integer workloads
CKKS (Cheon-Kim-Kim-Song)	Approximate arithmetic on real and complex numbers	Real-valued vectors	Privacy-preserving machine learning, statistics, and approximate analytics
TFHE (Fast Fully Homomorphic Encryption over the Torus)	Boolean gates and small lookup tables, with very fast per-gate bootstrapping	Bits and small integers	Branching logic, comparisons, and encrypted control flow

Rule of thumb for selection: use BFV or BGV when your result has to be exact, use CKKS when you can tolerate a small approximation error in exchange for speed on machine learning and statistical workloads, and use TFHE when your computation is dominated by comparisons or branching rather than large-integer arithmetic. An ENISA report on data protection engineering summarizes the underlying trade-off well: FHE “has good protection and utility but poor performance,” which is exactly why scheme choice and scope matter more than in ordinary encryption decisions.

What Threat Model Does Homomorphic Encryption Protect Against?

HE is designed for an honest-but-curious (semi-honest) compute provider: a party that will run the computation you asked for correctly, but that you do not want to trust with your plaintext. HE removes that trust requirement entirely; the server operates on ciphertext it cannot read, and this holds even if the server’s storage or memory is later breached, because there is never plaintext there to steal.

HE does not, by itself, protect against every threat in the deployment:

• A malicious server: standard HE schemes assume the server follows the protocol correctly. A server that returns a fabricated result can go undetected unless you add integrity checks or verifiable computation on top.
• Client-side compromise: the secret key lives with the client (or whoever the client delegates it to). If that key is stolen, every past and future ciphertext encrypted under it is exposed.
• Endpoint and access-control gaps: HE protects data in use at the compute provider; it does not replace transport encryption, identity and access management, or monitoring around the systems that request and receive results.
• Multi-party collusion: in multi-key or threshold FHE settings used for collaborative computation, security depends on a defined set of parties not colluding, which needs to be modeled explicitly rather than assumed.

Getting the threat model right up front is what separates an HE deployment that actually reduces risk from one that just moves computation behind an expensive layer of math without changing who has to be trusted.

How Do You Evaluate and Deploy Homomorphic Encryption?

Use this sequence to move from “should we use HE” to a working pilot:

1. Confirm HE is actually required. State plainly why access control, contractual terms, or standard encryption at rest and in transit are not enough, and why the compute provider specifically cannot be trusted with plaintext.
2. Choose a scheme based on the operation, not the marketing. Exact integer math points to BFV or BGV; approximate real-number machine learning points to CKKS; boolean or comparison-heavy logic points to TFHE.
3. Pick a vetted, actively maintained library. Microsoft SEAL and OpenFHE are the two most widely used open-source options; do not build your own cryptographic primitives.
4. Select parameters using the standard, not guesswork. The HomomorphicEncryption.org Security Standard publishes parameter tables for security level, polynomial modulus degree, and ciphertext modulus chain length; most libraries also ship a parameter generator.
5. Prototype on a representative slice of the real workload. Benchmark actual latency and throughput on your target hardware (CPU, GPU, or accelerator) before committing budget to a full build.
6. Design key management up front. Decide where the secret key lives, whether an HSM protects it, how the evaluation key is distributed to the compute provider, and how keys rotate.
7. Account for noise budget and bootstrapping in the circuit design, and add integrity checks if you cannot assume the compute provider is honest but curious only.
8. Pilot with a fallback path, then scale once you have measured real cost, accuracy (particularly for CKKS’s approximate arithmetic), and interoperability with existing data pipelines.

How Much Performance Overhead Does Homomorphic Encryption Really Add?

Plainly: FHE is still orders of magnitude slower than plaintext computation, and any vendor claiming otherwise for general-purpose workloads should be pressed for a specific benchmark. Duality Technologies’ 2026 benchmark write-up puts raw, unoptimized FHE overhead at roughly 10,000 times slower than plaintext on CPU-only hardware, narrowing to roughly 10 to 100 times slower for throughput-oriented workloads once batching and optimized parameters are applied. The same source reports that FHE performance overall has improved by a factor of 1,000 to 10,000 over the past five years, and that with optimized CKKS and batching, encrypted logistic regression inference over 10,000 records can complete in 2 to 10 seconds, while encrypted batch analytics over 1 million records can finish in minutes on GPU-accelerated hardware.

For heavier workloads, the gap is still large. Raluca Ada Popa of UC Berkeley’s MC2 project notes that training a moderate-size neural network such as VGG16 on a dataset like CIFAR-10 under HE or MPC “could range into the years,” which is why full model training under FHE remains impractical for most organizations today; encrypted inference on a small model, or aggregate analytics, is the realistic near-term target. This lines up with the IEEE’s own summary, which calls HE “one of the most powerful” privacy technologies available while acknowledging it is “still in an early phase” for general business use.

What is actually closing the gap: algorithmic improvements (CKKS for approximate arithmetic, TFHE’s fast bootstrapping), compiler tooling (OpenFHE, Zama’s Concrete), and hardware acceleration on GPUs and emerging FHE-specific accelerators. Treat any performance claim you are given the same way: ask for the scheme, the operation, the hardware, and the batch size, because “homomorphic encryption is fast now” without those four details is not a verifiable claim.

How Does Homomorphic Encryption Compare to MPC and Trusted Execution Environments?

HE is one of three practical approaches to computing on data you do not want to expose to the compute provider. The others are secure multi-party computation (MPC), where the data is split into secret shares across parties that must not collude, and trusted execution environments (TEEs), also called confidential computing, where the data is decrypted inside a hardware-isolated enclave. Each trades trust for performance differently.

Approach	Trust Assumption	Typical Performance Overhead	Deployment Model
Homomorphic Encryption (HE/FHE)	No trust required in the compute provider; data stays encrypted throughout	Roughly 10x to 10,000x slower than plaintext, narrowing with GPUs and optimized libraries	Software only; runs on any cloud or on-premises server
Secure Multi-Party Computation (MPC)	No single party sees the full data; requires a defined set of non-colluding parties	Similar order of magnitude to HE for complex workloads; better for specific protocols like private set intersection	Requires coordinating multiple parties across separate trust domains, often on-premises or private cloud
Trusted Execution Environment (TEE / Confidential Computing)	Trusts the chip manufacturer and the cloud provider’s hardware attestation, not the cloud operator’s software stack	Roughly 20 percent to 2x overhead for most workloads	Available today on major cloud providers’ confidential computing offerings

Choose HE when you cannot trust the underlying hardware or cloud provider at all and the workload is narrow enough to tolerate the overhead. Choose MPC when several distinct organizations each hold a piece of the data and none can be a single point of trust. Choose a TEE when you need near-native performance and can accept a hardware-rooted trust assumption, keeping in mind that enclaves carry their own side-channel history and depend on the cloud provider patching firmware promptly.

What Key Management Dependencies Does Homomorphic Encryption Introduce?

HE shifts key management risk rather than removing it. The client’s secret key must never reach the server; only the public key (for encryption) and the evaluation key (for computation) are shared. In practice, that creates a few dependencies most teams underestimate:

• Secret key custody: the secret key should be protected the same way any other high-value cryptographic key is, ideally in an HSM or a managed key management system, not a configuration file or environment variable.
• Parameter and security-level selection affects the key itself. Polynomial modulus degree and modulus chain depth determine both the security level and how many operations the ciphertext can survive before bootstrapping, so a later change in security requirements can force key and parameter regeneration, not just a config change.
• Post-quantum posture is already good, but not maintenance-free. Modern FHE schemes rely on ring learning with errors (ring-LWE) lattice problems, the same family of hard problems behind NIST’s ML-KEM (FIPS 203) standard, so they are considered post-quantum secure by construction. That does not remove the need for ongoing crypto-agility as parameter recommendations evolve.
• Multi-key and threshold settings add a key ceremony. Collaborative computation across several data owners requires distributing and, in some designs, jointly generating key material, which needs the same governance rigor as any other multi-party key ceremony.

Because the tooling ecosystem for HE key lifecycle management is far less mature than standard PKI, treat HE key custody, rotation, and inventory as a first-class design decision, not an afterthought bolted onto the cryptography.

Where Is Homomorphic Encryption Used Today?

• Privacy-preserving machine learning and analytics: IBM researchers demonstrated encrypted machine learning on banking data with accuracy matching the unencrypted baseline, and Zama’s Concrete ML compiler has been used to run encrypted neural network inference with published performance benchmarks, showing this is a working, if still specialized, deployment pattern.
• Healthcare and genomics: Duality Technologies and the Dana-Farber Cancer Institute applied HE to enable secure, large-scale genome-wide association studies across multiple institutions without ever decrypting the underlying genomic data.
• Verifiable elections: Microsoft’s ElectionGuard uses homomorphic tallying to count encrypted ballots without decrypting any individual vote, supporting end-to-end verifiable elections.
• Cloud and SaaS analytics: Any cloud-hosted analytics, database query, or AI inference can in principle run on encrypted inputs, letting a SaaS provider return results without the provider ever accessing plaintext.

Most of these deployments are still narrow and pilot-scale rather than default architecture, which is consistent with the performance picture above: HE earns its cost fastest on specific, high-sensitivity computations, not as a wholesale replacement for standard data processing.

Does Homomorphic Encryption Help with GDPR, HIPAA, and PCI DSS Compliance?

HE strengthens the technical safeguards these frameworks already require, but it does not replace the legal and procedural obligations underneath them.

• GDPR: the European Data Protection Board’s breach notification guidance allows an exemption when data is rendered unintelligible by encryption; if HE ensures leaked ciphertext cannot be decrypted without the key, a breach of that ciphertext may not need to be notified. Legal analysts still caution that HE processing itself needs a lawful basis under Article 32.
• HIPAA: if protected health information is encrypted with HE and the decryption key stays solely with the covered entity, that data can often be treated as de-identified for purposes outside HIPAA’s scope, supporting secure outsourced analytics on patient data.
• PCI DSS: PCI DSS does not name HE explicitly, but running fraud detection on encrypted cardholder data without decrypting it reduces exposure in line with PCI’s end-to-end data protection goals.
• NIST and ISO/IEC: NIST‘s Privacy-Enhancing Cryptography project and the community-run HomomorphicEncryption.org Security Standard (first published in 2018 and still updated at each standards meeting) formalize HE’s security properties, while ISO/IEC 18033-6:2019 specifies mechanisms such as Exponential ElGamal and Paillier.

What Are the Limitations of Homomorphic Encryption?

• Performance overhead: even after a 1,000x to 10,000x improvement over five years, FHE remains far slower than plaintext computation for heavy workloads like full model training.
• Operation types are constrained by scheme: BFV and BGV give exact integer math, CKKS trades exactness for speed on real numbers, and TFHE handles boolean logic well but not large-integer arithmetic efficiently, so the scheme choice caps what the application can compute.
• Complex key and parameter management: choosing secure, efficient parameters requires cryptographic expertise, and the tooling ecosystem for managing HE keys is far less mature than PKI or standard key management.
• Limited protection against a malicious server: standard HE assumes an honest-but-curious compute provider; a malicious one can return incorrect results unless integrity or verifiable computation is added.
• Tooling and interoperability maturity: libraries differ in scheme support, language bindings, and hardware acceleration, and ciphertexts or parameter sets generally do not port between libraries.
• Not a replacement for other controls: HE protects data in use from a specific threat class; access control, transport encryption, endpoint security, and monitoring are still required around it.

What Would Encryption Consulting Recommend?

Most organizations evaluating HE today should not reach for FHE as a default. Confirm first that the computation genuinely requires cryptographic-level confidentiality from the compute provider, something access control, contracts, or standard encryption at rest and in transit cannot give you, before the performance cost becomes worth paying. When that bar is met, we recommend piloting on a narrow, well-bounded computation, such as an encrypted aggregate or a CKKS-based inference on a small model, and benchmarking it against a confidential computing (TEE) alternative side by side before committing production budget.

Because current FHE schemes are lattice-based and already post-quantum secure by construction, adopting HE is also a long-term cryptographic commitment. Our Encryption Advisory Services help assess whether HE, MPC, or confidential computing best fits your actual data-sharing problem, size parameters against the HomomorphicEncryption.org standard, and design the key management architecture around it. Because HE key material and cryptographic assets need governance as libraries and parameter guidance evolve, we typically pair that advisory work with CBOM Secure for cryptographic asset inventory and our crypto-agility practice, so an HE deployment stays upgradeable rather than becoming another hard-coded legacy cryptographic system.

Conclusion

Homomorphic encryption is the only mainstream technique that keeps data encrypted through an entire computation, not just at rest or in transit. Its three tiers, PHE, SHE, and FHE, and its four working schemes, BFV, BGV, CKKS, and TFHE, give you real options depending on whether your workload needs exact integer math, approximate real-number machine learning, or boolean logic. The honest limitation is performance: even after a 1,000x to 10,000x improvement over five years, FHE remains meaningfully slower than plaintext computation, and it should be scoped to workloads that specifically need what it offers rather than deployed by default. Compare it against MPC and confidential computing for your actual threat model, get parameter selection and key management right from the start, and pilot narrow before you scale.

Frequently Asked Questions

Is homomorphic encryption ready for production use today? For narrow, well-defined computations, such as encrypted aggregation, lookups, or CKKS-based inference on a small model, yes, several organizations already run FHE in production using libraries like Microsoft SEAL and OpenFHE. For general-purpose workloads such as full model training or complex SQL analytics, FHE is still generally too slow for most production budgets, and confidential computing or MPC are usually a better fit.

Do I need a background in cryptography to implement homomorphic encryption? You do not need to design a new scheme, but you do need someone who understands parameter selection, including security level, modulus chain depth, and noise budget, since the wrong parameters can either leak information or make the computation impossible. Most teams pair an application developer with a cryptography advisor or use a library’s built-in parameter generator.

Is homomorphic encryption quantum resistant? Yes. Modern FHE schemes such as BFV, BGV, CKKS, and TFHE are built on ring learning with errors (ring-LWE) style lattice problems, the same hard problem family behind NIST’s ML-KEM (FIPS 203) standard, so they are considered post-quantum secure. That said, quantum resistance does not remove the need for careful parameter selection and key management.

How is homomorphic encryption different from confidential computing (TEEs)? Homomorphic encryption keeps data encrypted in software throughout the computation, so no party ever sees plaintext, at the cost of significant performance overhead. Confidential computing decrypts data inside a hardware-isolated enclave, trusting the chip manufacturer and the enclave’s attestation, and typically runs at roughly 20 percent to 2x overhead rather than orders of magnitude slower. Choose HE when you cannot trust the underlying hardware at all; choose a TEE when you need near-native performance and can accept hardware-rooted trust.

What is the difference between partially, somewhat, and fully homomorphic encryption? Partially homomorphic encryption (PHE), such as RSA or Paillier, supports unlimited use of exactly one operation. Somewhat homomorphic encryption (SHE) supports both addition and multiplication, but only for a limited number of operations before ciphertext noise overwhelms the result. Fully homomorphic encryption (FHE) supports unlimited chained additions and multiplications through a bootstrapping step that refreshes ciphertext noise, enabling arbitrary computation.

References

• NIST, “Fully Homomorphic Encryption (FHE), Privacy-Enhancing Cryptography,” CSRC: https://csrc.nist.gov/projects/pec/fhe
• HomomorphicEncryption.org, “Homomorphic Encryption Security Standard”: https://homomorphicencryption.org/standard/
• Microsoft SEAL, GitHub repository: https://github.com/microsoft/SEAL
• OpenFHE, official project site: https://openfhe.org/
• OpenFHE documentation, schemes and quickstart guide: https://openfhe-development.readthedocs.io/en/latest/sphinx_rsts/intro/quickstart.html
• Duality Technologies, “Is FHE Still Too Slow? Homomorphic Encryption Benchmarks 2026”: https://dualitytech.com/blog/homomorphic-encryption-performance-2026/
• Raluca Ada Popa, MC2 Project (UC Berkeley), “Secure computation: Homomorphic encryption or hardware enclaves?”: https://medium.com/mc2-project/secure-computation-homomorphic-encryption-or-hardware-enclaves-83da90102593
• Cloud Security Alliance, Fully Homomorphic Encryption working group: https://cloudsecurityalliance.org/research/working-groups/fully-homomorphic-encryption
• ISACA, “Exploring Practical Considerations and Applications for Privacy Enhancing Technologies” (2024): https://www.isaca.org/resources/white-papers/2024/exploring-practical-considerations-and-applications-for-privacy-enhancing-technologies
• ENISA, “Data Protection Engineering” report: https://www.aepd.es/documento/enisa-report-data-protection-engineering.pdf
• IEEE Digital Privacy, “Advantages of Homomorphic Encryption”: https://digitalprivacy.ieee.org/publications/topics/advantages-of-homomorphic-encryption
• “CryptOracle: A Modular Framework to Characterize FHE,” arXiv:2510.03565 (2025): https://arxiv.org/html/2510.03565v1
• “Performance Analysis of Leading Homomorphic Encryption Libraries: A Benchmark Study of SEAL, HElib, OpenFHE, and Lattigo,” ACM (2025): https://dl.acm.org/doi/10.1145/3729706.3729711