For most of the last twenty years, the data a company collects about people — where they have been, what their heart did last night — has been close to pure asset. You collect it and you hold onto it, and somewhere down the line, you find a use that more than covers the cost. The more data you hold, the more you can eventually learn.
That arithmetic is breaking. Those same records are turning into a standing liability: a breach waiting to be reported, and in a growing number of states, the basis for a class-action suit. Even though the data didn't change, the law around it did.
The problem stated as plainly as possible: the data you are holding and are now on the hook for is, in most cases, the exact data your product runs on. The asset and the liability are the exact same bytes.
The law is moving in one direction
Massachusetts is about to make this concrete. The legislature has passed a comprehensive privacy bill in both chambers — unanimously in each — and as I write this it is headed for reconciliation between the House and Senate versions and then to the governor, who is expected to sign it. It is not law yet. But it is close, and if you hold data on anyone in the state, read it.
The law requires data minimization: you collect what the service the person asked for actually needs, and you delete it when you no longer need it. A long list of categories count as sensitive — health, biometrics, precise location, and more — and you cannot sell or share any of them without explicit opt-in. Location gets singled out: the bill bans the sale of precise geolocation outright, for visitors to the state as well as residents. Minors’ personal data also gets enhanced protection, including prohibitions on the sale of such data and its use for targeted advertising. Individuals get the right to sue the largest data holders. In contrast, most state privacy laws reserve all enforcement to the attorney general.
Massachusetts is not an outlier. Around twenty states now have comprehensive privacy laws on the books — the exact number depends on who is counting and whether they include the narrower ones — and there is no federal law sitting above them to smooth out the differences. Thresholds, definitions, and penalties all differ from state to state, so a product that is comfortably in scope in one might be exempt one state over.
For companies handling data, the state I would point to first is Maryland. Maryland already caps the collection and use of sensitive data at what is strictly necessary to provide the service. Consent does not buy you out of the cap. You cannot get someone to agree to let you collect more than necessary. It also bans the sale of sensitive data outright, regardless of consent. For most of the history of privacy law, the deal was "ask permission and you can proceed." Maryland is different: there are things you may not hold in usable form at all, no matter what anyone signs.
Why the usual fixes don't solve the problem
The first instinct is to get consent. Put up the banner and keep the records. That works right up until the law stops letting consent be the answer, which, as Maryland shows, is already happening for the most sensitive categories.
The second instinct is to encrypt, and most companies already encrypt data at rest and in transit as they should. But there is a gap built into that phrase. To actually use the data — to run anything on it — you have to decrypt it first. The data is in the clear inside the machine for at least as long as the computation runs, and for those long moments, that data and your company are exposed. Encryption at rest and in transit protects the data everywhere except the one place you need to do something with it.
The industry knows about that gap, and the answer we have been buying is hardware-based confidential computing: secure enclaves that decrypt and process data inside a protected region of the processor. Billions of dollars are going into it, which tells you the worry is real. But the enclave still has to decrypt the data to compute on it. For the length of the computation, the data and the key that unlocks it both exist in the clear inside the chip. An attacker who gets into the enclave walks away with one or the other, and a steady run of side-channel attacks over the past several years shows that getting in is not hypothetical. The protection is real, but it is not the mathematical guarantee it is often taken for.
The liability that comes from data being readable, the breach and the disclosure, attaches under every one of these approaches, because each still produces readable data at the moment you compute on it. You have made the data harder to steal in storage and on the wire, and narrowed — but not closed — the exposure in use.
Computing on data you never decrypt
There is a way to close that gap, and it sounds like magic. Fully homomorphic encryption (FHE) lets you run a computation directly on encrypted data and get an encrypted result, without ever decrypting the data in between. The machine doing the work never sees the inputs or the output, and it never holds a decryption key. There is no plaintext inside the chip to capture, because nothing is ever in the clear. You decrypt the result yourself, somewhere else, after the fact.
The data can be the asset — you still compute on it and still get the answer your product needs — without being the liability, because at no point does anyone hold the data in a form they could read or leak.
Encrypted data is still personal data under these laws, so the limits on how much you may collect, how long you may keep it, and what you need consent to process still apply. What FHE removes is the exposure, the part that attaches to data being readable: the breach, the sale, the disclosure to anyone who could read it.
FHE is not free. Computing on encrypted data takes longer and costs more than computing on plaintext and it is not the right tool for every workload. What has changed over the past few years is the range of real workloads where the cost has dropped enough to be worth paying, especially when the alternative is holding data you are no longer allowed to hold. And the cost keeps falling as hardware built specifically for encrypted computation comes online, which matters most exactly where these workloads get large. Two examples below are ones where the trade already makes sense.
A wearable that never hands over your sensitive data
Take a fitness and health wearable. The most recognizable one is Whoop, so I will use it as an example, with the caveat that I am describing the category and a way to build it, not anything about how Whoop runs its systems today. A device like this collects data continuously — heart rate sampled every second, plus heart-rate variability, sleep, blood oxygen, and increasingly clinical-grade signals like ECG. The whole value proposition is to collect densely and keep collecting, so the picture of you sharpens over months and years.
That proposition runs straight into the laws above. Health and biometric data are sensitive in every state model, and most consumer wearables fall outside HIPAA, which means they are governed by state privacy law — not a medical carve-out. "Collect everything continuously and keep it" is the exact pattern minimization and retention limits are written to constrain. And as these companies expand into virtual care and research, they start sharing the most intimate data they hold with outside parties. Opt-in walls are built to slow this down.
Here is how you build the same product without holding the liability. The raw sensor stream never leaves the device — the wearable reduces it on the spot to the compact set of features the analytics actually use, and encrypts those before they leave the device. The cloud stores only the encrypted, reduced form. Once a day it runs the analytics on the encrypted features, producing the baselines, trends, and recovery scores the member sees, all as an encrypted result. The cloud cannot read any of it, and cannot even tell which members' numbers moved. Only the member, holding the key on their own device, decrypts their own results. For virtual care, the member can extend that key to a clinician — the same delegation clinical systems already make, except now it is enforced by the math instead of a contract.
This does not need to happen in real time. The analytics run as a daily batch and batching is part of what makes the economics work — you pay the cost of encrypted computation once a day per person, on your schedule, not on every heartbeat.The questions this raises about who holds the keys, and what happens when someone loses their phone, are real, and they have reasonable answers borrowed from the world of self-custody wallets.
A driving score without the trip history
Location is the headline of the Massachusetts bill, so the second example is telematics — the usage-based auto insurance that prices your premium on how you actually drive. These products work by collecting precise location and motion data from your phone or a device in the car, continuously, and scoring the risk. Cambridge Mobile Telematics is the largest player in this space.
A complete record of everywhere you have driven and how hard you braked getting there is precise geolocation – more than anyone strictly needs to produce a risk number, and a breach of it would be ruinous. But notice what the product actually delivers: a score. The insurer wants to buy the risk number, not the trip history.
So, compute the score and never hold the trace. The phone extracts the driving features on the device — hard-braking events, cornering, time-of-day exposure, mileage — and encrypts them. The raw GPS path never leaves in a readable form. The scoring runs on the encrypted features, and the insurer decrypts only the risk number. The vendor in the middle never holds a trip history that anyone could read. This architecture removes the readable trip history, which is what the law actually legislates through its retention limits and its ban on selling location. While what the vendor holds in encrypted form still counts as personal data, the technology of FHE does all that the law requires: you can't sell the data because nobody can read it.
This part isn't about compliance
Everything so far is defense — keep the value, drop the liability. But the same capability does something more interesting.
There are computations that are valuable and that simply do not happen today, because the data needed to run them is too sensitive to pool. A research group called 0xPARC built a working example: an open-source air-quality sensor network where many devices contribute encrypted readings, and the system computes population-level statistics across all of them — the full covariance structure of the whole population — entirely on encrypted data, without ever decrypting any single device's readings. It runs on hardware costing a few dollars per user device. Only the aggregate insight comes out; no individual's data is ever exposed. The same pattern lets a wearable company study health outcomes across its whole population without reading any one member's record, and lets companies that would never share raw data with each other compute a shared result none of them could reach alone.
The laws we talk about above are written as constraints, and they are. But the technology that satisfies the constraint also unlocks work that was previously off the table — work that was blocked not by cost but by the simple fact that pooling the raw data was unthinkable or illegal. The law is what makes a capability that once seemed exotic suddenly worth building.
What’s next
The law and the technology are converging from opposite directions. Year by year, the law narrows what you are allowed to hold in readable form, and it moves fastest on the most valuable categories — location, health, the things a data business most wants to use. Coming the other way, computing on encrypted data is getting cheap enough to be the practical answer rather than a theoretical one. Where those two lines cross is a specific bet: that the companies built for the next decade are the ones that can compute on sensitive data without holding or sharing it.
I have left out most of the cryptographic details here such as the schemes, the way the encrypted storage and the encrypted computation fit together, and what the performance really looks like at scale. We have written that up separately for anyone who wants to check our work. If you are building in this space and want it, reach out.
A technical companion to this post is available on request.
