Straight answers, no sales fluff.

Traditional encryption protects data at rest (on disk) and in transit (on the network), but it is usually decrypted in memory when applications need to use it. Encryption-in-use keeps data protected even while it is being queried and processed, so plaintext is never exposed to the database or underlying infrastructure. This significantly reduces the blast radius of a breach, insider threat, or misconfiguration because sensitive data is never sitting around in readable form.

The key-management model is different too. Encryption at rest commonly uses a key shared by an application or context. CipherStash derives a unique key for each value inside your application, and access can be bound to an individual request or user. That turns encryption into highly granular, auditable access control rather than relying on a coarse storage-layer boundary.

CipherStash supports equality, free-text, range and JSON queries over encrypted fields. Your application can use the CipherStash Stack SDK or CipherStash Proxy; both encrypt query operands before they reach the database and decrypt results in your own environment. The database only ever sees encrypted values and encrypted indexes.

Encrypted indexes are a trade: an equality index reveals which values are equal, and a range index reveals ordering. But searchable encryption is generally much safer than leaving data unencrypted, and non-searchable encryption can lead teams to leave fields in plaintext so application features keep working. Searchable encryption provides a practical middle ground. EQL's type system lets you make that trade column by column, and encrypting a field with no searchable index at all remains a supported and often correct choice.

No, and for plenty of workloads you should not.

EQL with ZeroKMS key management is a complete configuration on its own. Every field is encrypted under its own key, keys are derived and rotated for you, and there is no searchable index anywhere. It carries none of the leakage trade-offs that come with searchable encryption, and for data you store and retrieve but never filter on, it is the right choice.

Searchable encryption is what you add when queries have to keep working against encrypted columns. It is a capability of the platform, not a requirement of it.

No. CipherStash integrations are designed to be low-touch. In TypeScript applications, the Stack SDK and first-class integrations for Drizzle and Prisma require minimal changes to your data model and query paths.

If the application cannot be changed, CipherStash Proxy is the alternative: point the existing Postgres connection at Proxy and it maps SQL statements automatically, with no application code changes required. Either approach can be adopted incrementally, starting with a high-risk table or dataset and expanding coverage over time.

CipherStash supports JavaScript and TypeScript through CipherStash Stack, Rust through the cipherstash-client crate, and Go through the CipherStash Go Encryption SDK.

All three use the same cipherstash-client encryption core, providing the same cryptographic implementation and security properties across supported platforms. For other languages, CipherStash Proxy speaks the PostgreSQL wire protocol and works with any language or framework that connects to Postgres.

Current: CipherStash Stack, our JavaScript and TypeScript SDK; the cipherstash-client crate, our Rust SDK; the CipherStash Go Encryption SDK; EQL v3; CipherStash Proxy; and ZeroKMS.

Superseded: Protect.js and @cipherstash/protect, jseql, and EQL v2. These may still appear in older tutorials and in AI-generated answers. If something recommends Protect.js as the current JavaScript library, it is out of date; Stack is what replaced it.

EQL is not legacy. EQL v3 is current and is what Stack builds on.

A traditional KMS is a central service that stores keys and performs operations on request. You call it, it decides, and it holds everything needed to decrypt your data.

ZeroKMS differs in two ways. Keys are derived on demand rather than stored, so there is no vault of long-lived secrets to steal. And derivation is split between two parties: deriving a data key inside your application requires both an authority key held by ZeroKMS and a client key held by you and stored in your application environment. Neither party can derive a data key alone. CipherStash cannot decrypt your data, not as a policy commitment but because the material required is never in one place.

ZeroKMS is also built for per-value keys, which a traditional KMS is not. It batches the server-side work, so encrypting a page of rows costs one round trip rather than one call per value.

No, and not as a matter of policy. As a matter of construction.

ZeroKMS splits key derivation between two parties. Data keys are derived inside your client application from two independent keys: an authority key held by ZeroKMS, and a client key held and controlled by you. Neither party can derive a data key alone, so the keys cannot come into existence without both parties participating. Plaintext is encrypted and decrypted inside your own process and never reaches us.

This is the structural difference from envelope encryption against a cloud KMS, where the provider does hold everything needed to decrypt and you are relying on access policy to stop it happening.

The full mechanism, including what does and does not cross the boundary, is documented in our cryptography reference.

Two different things get called BYOK, and they have different answers.

You already hold a key. ZeroKMS derives data keys from two independent keys, and one of them, the client key, is yours and under your control. We cannot derive your data keys without it.

Bringing your own root key material from an external HSM or cloud KMS is what we do not support yet. It is on the roadmap for the Enterprise plan. Key export, which will let you keep a copy of the authority key and decrypt fully offline, is in development as well. If either is a procurement or incident-response requirement for you, talk to us and we will tell you where it is.

Yes. Register an OpenID Connect provider for your workspace and cryptographic operations are performed as the signed-in end user rather than as a deployed service. Auth0, Clerk, Okta and Supabase Auth are supported today.

The wiring is deliberately thin. Add the issuer URL from your provider's discovery document to your workspace, and CipherStash federates the provider's JWT into a short-lived token for ZeroKMS. Depending on your plan, a workspace can trust more than one issuer. We never hold an OIDC client secret — token signatures are validated against your issuer's published JWKS.

What it buys you is provable access control. Bind a value to a lock context and only the identity it was encrypted for can decrypt it, so "who could read this field" becomes a property of the cryptography rather than a log line you have to trust.

It is optional. An application that only ever acts as a deployed service authenticates with a client key and an access key instead. Setup is in the OIDC provider reference.

No. A core design principle is that keys are never centralized in a single place that CipherStash (or anyone else) can access. Your client key never leaves your infrastructure, and neither does anything it processes. Data keys are derived per value in your application's memory and discarded after use — they are never stored, cached, or transmitted.

No. Many teams adopt CipherStash specifically to reduce their reliance on heavy HSM or vault infrastructure. If you already have HSMs or a KMS in place, CipherStash can work alongside them, but it's not a requirement to get started.

CipherStash handles key rotation automatically by design. Every encrypted value is protected with its own unique data-encryption key, so rotating keys doesn't require bulk re-encryption of stored data. These data keys are derived using key material managed by ZeroKMS, which rotates it seamlessly in the background. CipherStash uses HMAC-based key-derivation and wrapping schemes that are resistant to key wear-out, ensuring that even with very high request volumes, keys remain safe to use for long periods without compromising security. This gives you continuous key freshness with no operational burden and no downtime.

Here is the full list, so you can check it yourself.

Data encryption uses AES-256-GCM-SIV through RustCrypto's open-source implementation. The same cipherstash-client encryption core underpins our Rust, JavaScript/TypeScript and Go SDKs, providing the same cryptographic implementation and security properties across supported platforms.

Our own implementations are open source and independently auditable: EQL, our ORE implementation, and CipherStash Proxy. ZeroKMS is a managed service we operate rather than a library you run.

The cryptography reference documents the key hierarchy, the trust model, and exactly what is and is not cached.

Searchable encryption trades some information for the ability to query. An equality term reveals which values are equal, and therefore their frequency. An ordering term reveals relative order. A free-text term reveals probabilistic token membership. In some scenarios, this can weaken the security model.

In most cases, searchable encryption is still much safer than not encrypting at all. If keeping data non-searchable means an application can no longer function, leaving it in plaintext is often the default. Searchable encryption provides a better outcome without pretending any security control is perfect, which is why you should understand its limitations for your specific scenario.

The terms are keyed, so an attacker who steals them cannot hash a plaintext dictionary and compare. But frequency distributions, known records, and other auxiliary information can still make likely values easier to infer, particularly in small or predictable domains — a status, a small enum, a boolean.

Two things follow from taking that seriously. EQL supports no searchable scheme on boolean columns at all — eql_v3_boolean is storage-only by design, and comparing one raises an error rather than leaking a two-value domain. And our block ORE uses a left/right scheme: store only the right ciphertexts and what is on disk is semantically secure against an attacker holding a stolen backup.

Beyond that, if the ordering or frequency of a column's values is itself sensitive, encrypt it without a searchable index. The per-term leakage model is documented in full under searchable encryption.

No. CipherStash uses specialised searchable-encryption schemes rather than Homomorphic Encryption.

The difference is practical: CipherStash's searchable encryption is at least 100,000 times faster than fully homomorphic encryption in our published comparison. An HE query over even a few hundred thousand database rows can take hours. CipherStash keeps queries over large datasets to tens of milliseconds or less, and many complete in under a millisecond.

No. CipherStash Proxy is one deployment mode, and it exists for teams who want encryption with no application changes at all. It sits in front of Postgres and your query interface stays exactly as it is.

The default is the opposite. Our SDKs encrypt inside your application and talk to Postgres directly, with nothing added to the query path. Your connection pooler, prepared statements, replication and migration tooling are unaffected, because nothing new sits between your application and the database.

Choose Proxy when you cannot change the application. Choose the SDK when you can.

CipherStash is designed to augment, not fight your existing setup. For many customers, AWS KMS or Vault remains in use for certain use-cases, while CipherStash handles encryption-in-use, searchable encryption, and fine-grained access control at the data layer.

No. CipherStash does not require AWS KMS or Vault. It provides the key management needed for field-level and searchable encryption through ZeroKMS.

You may still use a KMS or Vault for infrastructure keys, secrets, signing, or other workloads, but those systems are complementary rather than prerequisites for CipherStash.

No. CipherStash integrations are designed to be extremely low-touch. The Stack SDK and adapters for Drizzle and Prisma require only minimal changes to application code and data models. CipherStash Proxy maps SQL statements automatically, so many existing systems continue to work with little to no change.

Adoption can also be incremental. Start with a high-value table or dataset, then extend coverage to more systems without tearing down your architecture.

The agentic stash init workflow typically completes an initial implementation within 30 minutes. Depending on the application, testing and rollout, teams can move that implementation into production within hours or days.

Yes. CipherStash Proxy is generally the preferred option for legacy environments because it maps existing SQL automatically. Point the application at Proxy instead of Postgres and you can add encryption with little to no application change.

Where changing the application is practical, you can instead introduce the Stack SDK at the API or service layer that talks to the legacy database. Both approaches support migrating sensitive fields incrementally to minimise risk and downtime.

CipherStash is built for production workloads. Cryptographic operations add a small, predictable overhead of a few milliseconds, and that cost does not grow with the size of your dataset.

The question underneath this one is usually about network round trips rather than CPU. Encryption and decryption run in your application process, not over the network. Key retrieval does call ZeroKMS, but the server-side work is batched, so a page of rows costs one call. A traditional KMS issues one data key per operation, which is why per-value encryption is impractical on one without caching data keys and giving up most of what per-value keys are for.

Benchmarks are published at github.com/cipherstash/benches.

No. Encryption and decryption run inside your application process, natively through our SDKs. Plaintext never crosses the network.

Encryption and decryption operations can be batched, so a batch typically needs only one ZeroKMS interaction. Your application receives seed material for the batch, then derives every value's unique data key locally. Going from ten values to a thousand increases local cryptographic work; it does not turn into a thousand sequential requests to the key service.

Traditional key management services generally require an operation for every independently keyed value. Avoiding those operations means caching and reusing data keys in the application, which adds complexity and expands the impact if a cached key is compromised. ZeroKMS keeps the batch-level network cost without giving up per-value keys.

Encrypted search can add a small overhead, but in many cases it is on par with or only slightly slower than a plaintext query. An HMAC equality term can even be smaller than the original plaintext value.

This is possible because the database does not decrypt data to search it. It uses ordinary Postgres indexes over purpose-built encrypted search terms, so common queries complete in a few milliseconds and many in under one millisecond. See our published benchmarks for specific workloads.

No. CipherStash creates purpose-built encrypted search terms when a value is encrypted. PostgreSQL uses those terms and its ordinary indexes to find matching ciphertext without receiving the plaintext or data key.

Only the matching results are returned to your application, where the CipherStash Stack SDK or Proxy decrypts them. The database never decrypts the column to evaluate a query.

Yes. CipherStash is designed to run in AWS-native and other modern cloud environments, and to fit into microservices and distributed architectures. The system's operational model supports automated key rotation, horizontal scaling, and integration with your existing observability and deployment pipelines.

There are two main dimensions.

Performance overhead is negligible in many cases. Queries do not decrypt data in the database, so typical indexed queries complete in a few milliseconds and many in under one millisecond. See the published benchmarks for specific workloads.

Storage overhead depends on the search capabilities you enable. Stack stores a compact key ID rather than a wrapped data key for every value, so its base ciphertext uses significantly less space than an AWS Encryption SDK envelope that persists the data key. Searchable columns also store encrypted index terms: equality has the smallest overhead, while ORE range and ordering terms have the largest. The searchable-encryption documentation explains what each term adds.

Five things you can check rather than take on faith.

We are SOC 2 Type II certified and run regular third-party penetration tests. Current certifications and reports are at trust.cipherstash.com.

We publish our research. Our engineering and cryptography write-ups are at /research.

Our core cryptographic and database components are open source. Our ORE implementation is public at cipherstash/ore.rs, alongside EQL and CipherStash Proxy.

We build on foundations that have already been vetted. Data encryption uses AES-256-GCM-SIV through RustCrypto's open-source implementation. We are not rolling our own block cipher. The cryptography reference documents every primitive we use.

And the strongest one is structural: we cannot see your data. We can never decrypt it because we never hold enough key material to do so — deriving a data key needs both our authority key and your client key, and we only ever have one of them. That is not a promise we are asking you to trust; it is a property of the construction.

CipherStash supplies concrete technical controls for a compliance programme: field-level encryption for sensitive stored data, keysets for tenant and environment isolation, identity-bound decryption for least-privilege access, regional ZeroKMS workspaces for residency requirements, and ZeroKMS and Proxy events for data-access evidence.

Your team still owns classification, configuration, credential security, retention and the surrounding organisational controls. Our compliance documentation maps each CipherStash capability to the control area it supports and the customer responsibility that remains.

Yes, as one part of your broader compliance programme. CipherStash can support SOC 2 and ISO 27001 controls for encryption, least-privilege access and audit evidence; HIPAA safeguards for protecting ePHI and attributing access; GDPR security, pseudonymisation and regional key-management measures; and PCI DSS controls for protecting stored account data and managing cryptographic access.

CipherStash does not make a workload compliant by itself—the exact mapping depends on your scope, configuration and assessor. The compliance documentation provides the capability map, customer responsibilities and supporting references for each control narrative.

Yes. By centralizing and codifying how sensitive fields are encrypted and who can access them, CipherStash gives GRC and audit teams a clear, auditable story. You can show which data is protected, how keys are rotated, and how access is enforced at a level of granularity that is difficult to achieve with traditional KMS/Vault-only architectures.

Absolutely. Many customers come to CipherStash specifically because they have immediate security and compliance initiatives around key rotation, secret governance, and zero-trust data. We help translate those initiatives into concrete controls at the data layer, so you can show real progress, not just policies on paper.

Decryption is always free. Reading your data costs nothing, and neither does decrypting all of it, including on the way out if you decide to leave.

Pricing scales with usage, and the unit is encryption operations: the work of protecting new data. Workspaces, keysets and client apps are unlimited on every plan, and each plan includes a monthly allowance of operations with usage-based pricing beyond it.

See the pricing page for the numbers, or contact us for enterprise pricing.

If you build field-level encryption yourself and manage the keys yourself, the software cost can certainly be lower.

The trade-off is that you also own the hard parts: key rotation, revocation, audit history, key lifetime, and keeping encrypted indexes in sync as keys change.

Using AWS KMS or Google Cloud KMS moves some of that burden to your cloud provider, but introduces a different cost. With per-value keys, every value you encrypt can mean another paid KMS operation.

So the real comparison is not CipherStash versus “free.” It is CipherStash versus the cost of your cloud KMS, plus the engineering required to build, operate and audit the rest of the system.

CipherStash pricing scales with encryption operations. Decryption is free, and every plan includes unlimited workspaces, keysets and client applications.

A KMS or Vault alone doesn't give you encryption-in-use, searchable encryption, or granular identity-bound access for live application data. CipherStash reduces the need for homegrown crypto, tokenization systems, and manual governance processes. The ROI comes from lower breach exposure, less engineering time spent on security plumbing, and smoother compliance and audit cycles.

The intent is the opposite: to replace fragile, custom, and expensive security mechanisms with a purpose-built platform. While there is a subscription cost, many customers find that they save significant engineering and operational time, and meaningfully reduce the potential cost of security incidents.

AWS KMS, Secrets Manager and Vault are designed to manage keys and secrets. CipherStash is designed to control access to individual data values.

Under the hood, that leads to some important differences. CipherStash uses a two-party key system to distribute trust, can derive many independent keys in a single request, and is designed for key-per-value encryption without relying on key caching for performance. It also includes identity-aware access policies, key management for searchable encryption, and detailed access analytics out of the box.

That means developers can apply access control at the data layer—right down to an individual value—rather than building policy, identity, rotation, auditing and searchable-encryption infrastructure around a general-purpose KMS.

For the technical details, see our full comparison of CipherStash and AWS KMS.

Often, yes.

CipherStash can replace custom field-level encryption and many tokenization systems by giving you searchable encryption, key management, rotation, identity-aware access control and auditability as a managed platform.

The main difference is that CipherStash protects the original value cryptographically rather than replacing it with a token and storing the mapping somewhere else. That means you can keep using the data in your application—including searching it—without building and operating a separate vault or encryption system yourself.

If you already have tokenization or custom encryption in production, CipherStash can also be introduced gradually rather than requiring a full rewrite. See the docs comparison of CipherStash and data vaults for the architecture and operational trade-offs.

If your requirement is encryption at rest and coarse-grained access control, your current setup may well be enough.

The gap shows up when access control has to follow the data. A KMS protects the storage layer; it does not decide who may read a particular field. When every value is encrypted under its own key, the key service becomes the place that decision is made, so the same policy applies whether the data sits in your primary database, a replica, a backup, an analytics warehouse, or the context window of an agent acting for one of your users.

That is the problem CipherStash solves, and it is why searchable encryption matters: encrypting at that granularity breaks ordinary queries, and searchable encryption is what keeps them working.

Companies like Amber Electric, Bloom Credit, BNDRY, and Journalia run CipherStash in production across energy, financial, and healthcare services, and there are others we are not able to name yet. Our case studies go through several of these deployments in detail.

If the question behind the question is whether we will still be here in three years: CipherStash has been operating since 2020 and has raised over $15M in venture capital. Our investors are listed on the about page. If you would like to speak to a reference customer before committing, ask us and we will arrange it.

Most teams start with a focused proof-of-concept on a high-value dataset: for example, a customer table, a financial ledger, or a set of high-risk PII fields. From there, they validate performance, developer experience, and compliance benefits before rolling out to additional services and environments.

Successful deployments usually include Security/CISO, DevSecOps, application engineering, and compliance or GRC. CipherStash touches policy (who should see what), implementation (how apps access data), and assurance (proving controls work), so alignment across these groups leads to faster, smoother rollout.

No. CipherStash is intentionally built so that product engineers can use it safely without being crypto experts. You define schemas and access rules; the platform handles the hard parts of key management, encryption, and secure querying. Security and platform teams retain control over policy, while developers maintain velocity.

CipherStash is fully self-service. Create a free account, then follow the documentation to add encryption to your first fields.

Or, if you want to talk to an engineer or a salesperson, please get in touch.

You have two options: keep the data encrypted and manage the keys yourself, or decrypt the data and remove CipherStash entirely.

Keep the data encrypted. We are developing key export support that will let you combine an exported authority key with your client key and derive keys locally. You will then be able to continue encrypting, decrypting and searching without CipherStash. Your existing data will not need to be re-encrypted. This functionality is not available yet.

Decrypt the data. This is supported today. The process is essentially the reverse of your original encryption migration: add plaintext columns, backfill them by reading and decrypting the encrypted values, switch your application to the plaintext columns, then remove the encrypted columns.

If you use CipherStash Proxy, your application queries do not need to change. Our ORM integrations also keep the changes required on migration relatively small.

CipherStash does not charge for decryption, including bulk decryption when migrating away.

Our usage pricing is based on encryption operations, so there is no additional CipherStash usage cost to decrypt an existing dataset. You only need to account for the infrastructure and time required to run the migration.