Field Encrypt Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for field-level encryption. This package is a candidate answer to "do we hand-roll AES-GCM plus a key ring, or adopt something?" It gives you a concrete implementation to evaluate instead of starting from a blank file — useful even if the eventual decision is "fork it and own it." The v3.0.5 release doesn't change this calculus; it just keeps the reference implementation viable on a current stack.
• Where encryption lives in the stack. Choosing application-layer field encryption (this package) instead of database TDE or disk encryption is an architecture/product decision with real consequences: it changes who can read data (DBAs, backups, analytics exports), what breaks (queries on encrypted columns), and what you can claim to auditors.
• Compliance scoping and data classification. Adoption forces an explicit inventory of which fields are sensitive, which is itself the artifact security reviews and privacy counsel ask for. Supports GDPR Art. 32 arguments, breach-blast-radius reduction, and data-minimization narratives.
• Retention and erasure roadmap. Per-record or per-tenant key destruction (crypto-shredding) is a legitimate way to satisfy deletion requirements without chasing rows across backups and replicas — a capability that shapes how you design account deletion and tenant offboarding.
• Buy/partner risk posture. With 5 stars, zero dependents, and a release history that went quiet after December 2023, this is effectively a single-vendor artifact (likely extracted from an agency's internal work). v3.0.5 is a one-line Symfony 7 compatibility patch — it proves the maintainer is reachable, not that the project has a roadmap or support commitment. Adopting it remains a decision to accept supplier concentration risk and to fund an internal owner.
• Prioritization signal. Field-level encryption is usually a compliance checkbox, not a differentiator. It competes for sprint capacity against features; the low opportunity score plus near-zero community traction argues for treating it as a scoped security task, not a platform initiative. A framework-compatibility bump doesn't move it up the roadmap.

When to Consider This Package

Reasonable fit when:

• The stack is Symfony 6/7 + Doctrine — despite being framed as a "Laravel/PHP package," this is a Symfony bundle built around Doctrine entity attributes. v3.0.5 adds Symfony 7 support, which removes the most obvious blocker if you're on a current Symfony line; confirm the corresponding Doctrine ORM and PHP 8.2+ versions in composer.json before assuming full compatibility. A Laravel team should still first check Laravel's native encrypted cast and custom casts; adopting this would mean porting, not installing.
• You have a small, well-bounded set of sensitive columns (PII, API tokens, health or financial identifiers) rather than a need to encrypt the entire data model.
• You need key material separated from the database — the DBA or a leaked backup should not yield plaintext.
• You can name an owner for key management, rotation runbooks, and backfill migrations, and you're willing to vendor or fork if upstream goes quiet again (it already has once).

Look elsewhere when:

• You need searchable, sortable, or aggregatable encrypted fields at scale. Deterministic encryption buys equality lookups at the cost of leaking frequency patterns — that's a security decision, not a library one. Tokenization or a vault service is usually the better answer.
• Queries are read-heavy and latency-sensitive; per-field decryption has a measurable cost and will show up in p95s.
• You require vendor support, SLAs, or a certification path — AWS KMS, HashiCorp Vault Transit, or a commercial tokenization platform.
• You need proof of production use. Zero dependents and five stars mean no independent evidence of fitness; treat the README as a claim, not a reference. Still true after v3.0.5.
• You're on Symfony <6, or Doctrine's attribute mapping isn't in place. The patch also signals the maintainers are dropping older Symfony support rather than backporting — verify your target versions first.

How to Pitch It (Stakeholders)

For executives: Field-level encryption limits the damage from a database leak — stolen backups and over-broad internal access stop yielding readable customer data, and it gives us a defensible answer in security questionnaires without re-architecting storage. This specific package is a small, likely single-maintainer component with no visible adoption; its latest release only adds Symfony 7 compatibility after a long quiet period, which is a maintenance signal but not a support commitment. So I'm not recommending it as a long-term dependency. I'm recommending a two-week spike against our real schema to validate the approach, with a budgeted assumption that we fork and own roughly a few hundred lines of crypto glue. The strategic value is the decision and the data inventory it forces, not the library.

For engineering: Attribute-driven field encryption on Doctrine entities, with key handling and rotation handled for us — it removes the temptation for each team to invent its own crypto. v3.0.5 adds Symfony 7 support, so it's usable on a current framework line, but that's the entire change: no security fixes, no new features, no tests added. Plan accordingly: vendor it into the repo, add our own tests, and pin the crypto primitives. Also flag the sharp edges early — encrypted columns can't be indexed or sorted, and any equality-search requirement turns this into a deterministic-encryption design review, not a drop-in.