Doctrine Encryption Bundle Laravel Package

Product Decisions This Supports

• PII/PHI field-level encryption roadmap items: This bundle now provides a maintained path for encrypting sensitive Doctrine-mapped columns (data-loss and ciphertext-integrity defects fixed in 2.0.0), so "encrypt sensitive columns at rest" can move from backlog to spec.
• Build vs. buy on crypto plumbing: The 2.0.0 line covers value encryption, an encrypted_text DBAL type, and blind-index query helpers — the three things teams usually hand-roll badly. Adopting it avoids a bespoke encryption layer and the associated security review burden.
• Searchable-encryption feasibility: The new blind index query helper turns "can users look up a record by email/SSN without decrypting the whole table?" from a research spike into a design option, which directly affects data-model and indexing decisions.
• Data migration/backfill planning: The documented 1.x → 2.0 upgrade path and the "dry runs read every value" behavior give us a credible, low-risk migration story for encrypting existing plaintext columns — a prerequisite for any compliance-driven reprioritization.
• Platform scoping caveat: This is a Doctrine bundle (Symfony-style), not a native Laravel package. It influences decisions only where our stack uses Doctrine ORM (e.g., Laravel + Doctrine via doctrine/dbal/ORM bridges, or Symfony services). If we are Eloquent-only, this is a reference implementation at best, not an adoptable dependency.

When to Consider This Package

Consider it when:

• Our persistence layer is Doctrine ORM and we need transparent, type-level encryption rather than manual encrypt()/decrypt() calls scattered through services.
• We have a regulatory or contractual driver (GDPR, HIPAA, PCI, SOC 2) for encryption at rest at the column level, beyond disk/volume encryption.
• We need equality lookups on encrypted fields (find user by email) — the blind index helper is the differentiator.
• We have existing encrypted data under 1.x, in which case the 2.0.0 integrity fixes make upgrading a correctness/security obligation, not a nice-to-have.
• We can absorb a major-version migration with a documented dry-run verification step.

Look elsewhere when:

• The application is Eloquent-first — a Laravel-native solution (custom casts, laravel-doctrine/orm caveats, or a vault/KMS envelope-encryption service) will fit better and be easier to support.
• We need range queries, sorting, or LIKE on encrypted fields — blind indexes support equality only; that constraint should be surfaced before anyone promises "searchable encryption."
• Key management is unsolved. The bundle encrypts; it does not remove the need for a KMS/secret-rotation strategy, and that is usually the bigger engineering and operational commitment.
• We want a widely adopted, vendor-backed dependency. This is a single-maintainer project and 2.0.0 ships the first contribution from that maintainer. Bus-factor and long-term support risk are real; plan for the ability to fork or vendor it.

How to Pitch It (Stakeholders)

For executives: A v2.0.0 release of an encryption library we are evaluating fixed two serious defects — potential data loss and weakened ciphertext integrity — and added a database column type plus a way to look up records by their encrypted values. In plain terms: it now does the two things compliance reviewers ask about (encrypt the field, still find the record) without us building and auditing custom cryptography. The catch is scope and maturity: it fits our Doctrine-based services, not our Eloquent code, and it is maintained by essentially one person, so treating it as a strategic dependency requires a fork-and-own contingency. Recommendation: pilot on one Doctrine-backed service with a sensitive field, not a platform-wide standard.

For engineering: 2.0.0 is a required upgrade for anyone already on 1.x — the integrity fix means existing ciphertext handling had a correctness bug, and the release notes explicitly tell us dry runs now read every value, so migration verification behavior changes. New capability worth designing around: encrypted_text DBAL type (encryption at the type layer, no manual calls) and a blind index query helper (equality search over encrypted columns, with the usual determinism/leakage tradeoffs). Before we commit we need answers on key management and rotation, index key separation from the encryption key, behavior under doctrine/dbal version bumps, and whether the upgrade path is reversible. Assign one owner to read the 1.x→2.0 upgrade doc and produce a migration runbook before we schedule the pilot.