Doctrine Ciphersweet Encryption Bundle Laravel Package

Product Decisions This Supports

• Field-level encryption of PII at rest (build vs. buy): This bundle is a thin Symfony/Doctrine integration over Paragon Initiative's CipherSweet, letting you store encrypted column values (names, emails, national IDs, payment references) transparently through Doctrine types rather than hand-rolling openssl_encrypt calls in every service. The buy-vs-build decision here is largely settled in favor of buy: the cryptography layer is a maintained upstream library, and this bundle supplies the ORM plumbing only.
• Searchable encryption as a product constraint: CipherSweet's blind indexes mean you can keep exact-match lookups (find user by email, dedupe on tax ID) on encrypted columns. That directly shapes roadmap items — features requiring LIKE/range/ORDER BY on sensitive fields must be designed around blind indexes or explicitly descoped.
• Compliance-driven roadmap sequencing: If GDPR/CCPA/HIPAA/PCI obligations are on the roadmap, this bundle turns "encrypt sensitive fields" from an open-ended engineering epic into a bounded dependency evaluation plus a key-management workstream. Scope the KMS/secret-rotation work separately — the bundle does not supply it.
• Data-retention and right-to-erasure features: Encryption at field level gives a cryptographic-deletion lever (destroy the key material or per-row key) alongside row deletion, which is useful when designing account-deletion and retention-expiry flows.
• Upgrade-path planning: Release 0.13.0 swaps symfony/property-info for symfony/type-info and clears Doctrine ORM deprecations. Both are forward-compatibility moves toward newer Symfony and Doctrine ORM 3.x — treat this as evidence the maintainer is tracking the current platform baseline, and factor it into your framework-upgrade planning rather than as a user-facing feature.
• Vendor-risk register entry: Pre-1.0 (0.13.0), single-maintainer-dominant activity. Add to the third-party dependency register with a pinned minor version and a review trigger.

When to Consider This Package

Adopt when:

• Your stack is Symfony + Doctrine ORM — this is a bundle, not a Laravel/Eloquent package. Laravel teams should look at ciphersweet directly with a custom cast, or a maintained Eloquent equivalent.
• You need column-level encryption for a defined set of sensitive attributes, and you control the schema so column types and blind-index columns can be added.
• You need exact-match search on encrypted data (unique-email checks, lookup by national ID) — blind indexes are the differentiating capability here.
• You are on, or migrating to, recent Symfony/Doctrine versions. 0.13.0's move to symfony/type-info and deprecation cleanup suggests the bundle tracks modern ORM releases; verify your exact Symfony/Doctrine versions against the bundle's composer constraints before committing, and check whether anything in your app depended on symfony/property-info arriving transitively.
• You accept 0.x versioning: pin the minor version, read changelogs before bumping, and budget for occasional interface adjustments on upgrade.

Look elsewhere or build around it when:

• You are on Laravel/Eloquent, or any non-Doctrine persistence layer — the bundle has no value there.
• You need range queries, sorting, or fuzzy search on encrypted fields; blind indexes do not provide this and you should not design around that assumption.
• Your requirement is whole-database or storage-level encryption (TDE, encrypted volumes, managed-DB encryption) — that is an infrastructure control, not this package.
• You need opinionated key management: KMS/HSM integration, automated rotation, per-tenant key isolation, audit trails. The bundle gives you the primitives; multi-tenant key strategy and rotation are your design work.
• You have no operational plan for keys and rotation. Encryption without a rotation and recovery story is a compliance liability, not a control.
• Your regulatory posture demands a supported, SLA-backed vendor rather than a community 0.x bundle — in that case evaluate commercial field-encryption offerings or a funded in-house implementation.

Risk notes for the current release: 0.13.0 contains no explicit breaking-change callouts, but the property-info → type-info swap can shift the effective minimum Symfony version and remove a transitive dependency some projects relied on incidentally. Treat it as a routine upgrade with a compatibility check, not a drop-in patch, and validate against a staging schema with existing encrypted data before rollout.

How to Pitch It (Stakeholders)

To executives: We can meet our field-level encryption obligations for customer PII with a small, free, open-source dependency instead of a multi-sprint in-house crypto project. The cryptography is handled by an established upstream library; this component only wires it into our existing data layer, so the engineering cost is an integration and testing exercise, not a cryptography research program. The realistic budget line is the key-management work — rotation, recovery, per-tenant isolation — which is required regardless of which option we pick and is where the actual operational risk sits. The trade-off is dependency risk: the package is pre-1.0 and community-maintained, so we pin versions, review changelogs, and keep an in-house fallback path. This release shows the maintainer is actively keeping pace with current framework versions, which is a positive maintenance signal.

To engineering: This is a Doctrine bundle on top of paragonie/ciphersweet — Doctrine types plus blind-index columns, configured through bundle config. Not a Laravel package; Eloquent needs a different integration. 0.13.0 replaces symfony/property-info with symfony/type-info and removes ORM deprecation noise, which cleans the path toward Doctrine ORM 3.x. Before adopting: confirm composer constraints against our Symfony/Doctrine versions, check whether we depend on property-info elsewhere, verify blind-index columns against our real query patterns (exact-match only), and write the migration for existing plaintext columns — including backfill and a decision on whether to re-encrypt in place or via a dual-write window. Pin to the minor and gate upgrades behind a changelog review.