Fully Homomorphic Encryption (FHE) is a privacy-preserving technology that allows you to perform computations on encrypted data. In theory, FHE allows organizations to make use of sensitive data that must otherwise be held in a secure silo: medical information, financial transactions, biological markers. Emphasis on “in theory”: until recently, FHE has been regarded as proven possible, but practically infeasible.

Now, the barriers to adoption are falling. Specialized acceleration hardware is delivering orders-of-magnitude performance improvements for certain FHE workloads. Developers have access to open-source FHE tooling. With AI assistance, even those with no FHE background can begin to vibe-code an FHE application.

The removal of these barriers does not mean FHE development is without limits, however. FHE can perform computations on encrypted data. However, in order to use FHE as a privacy-enhancing technology, an application must be shaped to fit certain constraints. In this article, I’ll share a series of questions to help you decide whether that’s possible and desirable for whatever you want to build.

Do You Require Data Privacy?

The first gate is assessing whether an application should use FHE. Designing an FHE application is a lot of work. Before molding a program to fit the constraints of FHE, be certain that encrypted computation is worth the overhead. The right applications are those where data exposure could result in significant harms like legal or regulatory exposure, security breaches or intellectual property theft. When the risk of exposing sensitive data during computation is too high, that’s when FHE becomes worth considering.

FHE is exciting because it allows us to build applications that would otherwise be too risky because of their data privacy requirements. If a data breach would be an inconvenience rather than a disaster, you might be better served by more traditional application design.

Can You Write the Circuit of Operations Before Looking at the Input Data?

An FHE application cannot directly inspect the plaintext inputs or intermediate values of an encrypted calculation. That means it generally has to run on rails: computations must be structured as circuits, without conventional branching based on encrypted values. Conditional operations are possible, but they must be expressed within the circuit rather than through ordinary if/then logic.

If the complete sequence of operations is the same no matter what the input data is, your application is a good candidate for FHE. If what the program needs to do changes depending on the input or intermediate values, you will be fighting the constraints of FHE at every step.

For example, weighted sums, linear regression inference, dot products and matrix-vector multiplication all lend themselves well to FHE. Algorithms that require data-dependent branches, like sorting or graph traversal where program behavior is chosen at runtime, can be extremely difficult to adapt.

Do You Have a Large Number of Samples to Process Simultaneously?

Parallelism is where FHE really shines. Some FHE schemes pack thousands of independent values into a single ciphertext. If your workload applies the same operation to a large set of independent values, you can make efficient use of FHE. This is why FHE can be particularly well suited to applications like fraud or anomaly detection: the program can evaluate large numbers of data points against a model in parallel. If you are working with single-item computations that cannot be batched, FHE may incur far more overhead.

Is Your Workload Arithmetic, Logical, or Both?

There are mature FHE schemes for both arithmetic and logical workloads. Combining the two, however, can significantly increase FHE processing costs and application complexity. FHE generally works best when the application stays in one lane: e.g., arithmetic workloads like polynomial evaluation or statistical aggregation, or logical workloads like Boolean circuit evaluation or encrypted data lookups.

How Deep Is the Multiplication Chain?

Because data remains encrypted during computation, multiplication in many FHE schemes increases ciphertext noise or consumes part of a limited computation budget. Too many sequential multiplications, and the accumulated noise can prevent correct decryption. An FHE operation called bootstrapping can refresh a ciphertext to support further computation, but it can introduce substantial processing overhead.

Determining how to reduce the multiplication chain is one of the central challenges of adapting an existing algorithm for FHE. If you can figure out how to refine your circuit to a handful of sequential multiplications, that can provide significant benefits in lowering the processing overhead of your program.

When Is FHE Feasible and Practical?

If your application data must be kept private during computation, and your use case can benefit from large-scale parallel processing, FHE may be exactly the privacy technology you need. Once you’ve determined that you should use FHE, figuring out whether you can adapt to its constraints will likely require you to think about application design in totally new ways.

The open-source tooling mentioned above can assist you in adapting a plaintext application for FHE: designing a single-stream logical or arithmetic workflow; reformulating operations into a circuit of addition and multiplication gates; and paring down multiplicative depth. These tools can help you operate within FHE’s natural boundaries and give you the freedom to build something totally new.