# How do we give developers secure defaults instead of relying on perfect operational discipline?

*Domain Solution · Encryption in Use*

With CipherStash, the schema declares which fields are sensitive and the platform does the rest — encryption, key management, policy enforcement, and audit happen on every read and write by default. Security stops depending on every engineer remembering to do the right thing.

## Refined Question

Our data protection currently depends on people: remembering to encrypt, scoping queries correctly, handling keys properly, never logging the wrong field. How do we make the secure path the default path, so protection doesn't erode under deadline pressure?

## Why This Matters

Controls that rely on discipline fail at the rate that humans do — which is constantly, and invisibly, until an incident makes it visible. Every new engineer, service, and deadline is another chance for the manual step to be skipped.

## Why CipherStash

CipherStash moves protection into the schema and the platform. A field declared as encrypted is encrypted on every write, policy-checked on every decryption, and audited on every access — by every service and every engineer, automatically.

This allows:

- Encryption to be a property of the schema, not of code review vigilance
- Key management and rotation to disappear from developers' responsibilities
- New services and teammates to inherit the secure path by default
- Security posture to be consistent across every code path that touches the field

## Key Differentiators

- **TypeScript-native SDK** — `@cipherstash/stack` drops into existing applications and ORMs
- **Searchable encryption** — equality, range, and free-text queries over encrypted Postgres fields, with standard indexes
- **Per-value keys via ZeroKMS** — keys are derived on demand, never stored
- **Identity-aware decryption** — every decryption is bound to the identity behind the request
- **No re-platforming** — works over the Postgres you already run

## Get started

- [View docs](https://cipherstash.com/docs)
- [Book a discovery call](https://calendly.com/cipherstash-gtm/cipherstash-discovery-call)

## Related questions

- [How do we maintain searchable, usable data while enforcing strong encryption controls?](https://cipherstash.com/solutions/how-do-we-maintain-searchable-usable-data-while-enforcing-strong-encryption-controls.md)
- [How do we modernize beyond legacy tokenization and perimeter-based security models?](https://cipherstash.com/solutions/how-do-we-modernize-beyond-legacy-tokenization-and-perimeter-based-security-models.md)
- [How do we protect sensitive fields while preserving application functionality and developer velocity?](https://cipherstash.com/solutions/how-do-we-protect-sensitive-fields-while-preserving-application-functionality-and-developer-velocity.md)
- [How do we secure data in use, not just data at rest or in transit?](https://cipherstash.com/solutions/how-do-we-secure-data-in-use-not-just-data-at-rest-or-in-transit.md)
- [How do we contain insider threat risk and accidental misuse of customer data?](https://cipherstash.com/solutions/how-do-we-contain-insider-threat-risk-and-accidental-misuse-of-customer-data.md)
- [How do we cryptographically enforce least privilege and data segmentation?](https://cipherstash.com/solutions/how-do-we-cryptographically-enforce-least-privilege-and-data-segmentation.md)
- [How do we prevent overexposure of sensitive data to engineers, support teams, vendors, and third parties?](https://cipherstash.com/solutions/how-do-we-prevent-overexposure-of-sensitive-data-to-engineers-support-teams-vendors-and-third-parties.md)
- [How do we reduce trust assumptions in modern cloud and AI architectures?](https://cipherstash.com/solutions/how-do-we-reduce-trust-assumptions-in-modern-cloud-and-ai-architectures.md)
- [How do we secure increasingly fragmented multi-cloud and SaaS-heavy architectures?](https://cipherstash.com/solutions/how-do-we-secure-increasingly-fragmented-multi-cloud-and-saas-heavy-architectures.md)