Doctrine Encrypt Bundle Laravel Package

Product Decisions This Supports

• Compliance-driven roadmap items. Satisfies the "data at rest" control for GDPR Art. 32, CCPA, HIPAA-adjacent, and internal security baselines when the database, backups, read replicas, or DBA access cannot be trusted as the only boundary. This is the fastest path to closing a compliance finding that says "PII must be encrypted at rest at the application layer."
• Build vs. buy: buy the crypto layer, build the policy layer. Column/field encryption primitives are a solved problem; home-grown openssl_encrypt() wrappers are where IV reuse, CBC mode, and key-in-repo bugs come from. Adopt a bundle for the cipher and key handling, and spend product engineering on which fields are classified as sensitive, retention, and access auditing.
• Key rotation as a shippable feature, not a fire drill. Multi-key support plus rotation means credential compromise or an annual rotation policy becomes an operational runbook instead of a re-architecture project. This is a roadmap unlock for enterprise/security-questionnaire-gated deals.
• Enables new feature bets that require sensitive data. Patient notes, KYC documents, salary bands, support transcripts, free-text fields where users paste anything — encryption at rest lowers the risk of shipping these features and shortens security review.
• Data residency and tenant isolation. Per-entity/per-tenant key material lets you argue that one tenant's ciphertext is not decryptable with another tenant's key, supporting enterprise segmentation requirements.
• Scoping constraint for analytics. Adopting field-level encryption is an explicit decision that these columns are not queryable — it forces a product decision (encrypted ciphertext + hash for exact-match lookup, or a separate analytics pipeline) rather than discovering it after a reporting feature is committed.

When to Consider This Package

Consider it when:

• The stack is Symfony 6/7/8 with Doctrine ORM and the sensitive data lives in entity fields. Non-Symfony or raw PDO/microservice-polyglot setups get nothing from it.
• You need application-layer encryption, i.e. the threat model includes DBAs, stolen backups, snapshot leakage, or a managed-DB provider — not just disk encryption (which most clouds already give you).
• You have a finite, enumerable set of sensitive fields (email, phone, address, national ID, health notes, tokens) that you do not need to sort, range-query, aggregate, or LIKE on.
• You want key rotation without downtime and are willing to own the rotation runbook and key storage (env, secrets manager, KMS-wrapped).
• You are a small team without a cryptography owner and prefer a pluggable, tested cipher abstraction over a bespoke implementation.

Look elsewhere when:

• You need searchable or order-preserving encryption, deterministic joins across encrypted columns, or WHERE clauses over encrypted data at scale. Field encryption fundamentally fights this; a tokenization service or a separate encrypted search index is the right answer.
• You require FIPS 140-2/3 validated modules, HSM-backed envelope encryption, or a vendor with a compliance attestation (SOC 2 report, ISO 27001 certificate). This package provides none of that paper trail; a cloud KMS or a commercial data-security platform does.
• The real requirement is masking, tokenization, or format-preserving encryption for card data (PCI DSS scope reduction) — that is a different product category.
• You need performance at high write volume; encryption in the PHP process adds latency and CPU per field per row. Benchmark before committing to encrypting high-churn columns.
• Supply-chain risk tolerance is low. This is a 6-star, 1-maintainer-class package with zero known dependents and no third-party security audit. If your org requires provenance and independent review, plan to vendor/fork it, pin an exact version, add integration tests, and have a fallback to a thin in-house wrapper over libsodium.
• The bundle is unmaintained or the release/compatibility story does not hold up under your own verification — validate documentation depth, test coverage, and cipher defaults before adoption, not after.

How to Pitch It (Stakeholders)

To executives (1 minute): "We have to prove sensitive customer data is protected even if someone gets the database. Today, the database is the single point of failure. This bundle lets us encrypt those specific fields inside the application, before they ever reach the database, with key rotation so a leak or a staff departure doesn't become a breach. It's MIT-licensed, no vendor contract, and it's days of work instead of a quarter. The trade-off: those fields become opaque — we can't sort or search on them — so we encrypt only the columns we've classified as sensitive and keep the rest queryable. Main risk is maturity: it's a small open-source project, so we vendor it, pin it, and wrap it in tests. That's a contained risk versus an unmitigated compliance finding."

To engineering (1 minute): "It's a Doctrine bundle — you register the encryptor, tag entities/fields as encrypted, and a listener handles encrypt-on-write / decrypt-on-read. Pluggable backends: Halite, Defuse, or MySQL-native AES_ENCRYPT if you'd rather let the DB do it. Config-driven keys with multiple active keys support rotation. Work to size: inventory and classify fields, choose an encryptor and key source (secrets manager / KMS-wrapped), migrate existing rows, add a rotation runbook, and add tests for null/partial-write/migration paths. Constraints to design around: no range queries or sorting on encrypted columns, SELECT * hydration cost, and no audited compliance artifacts — so key storage and access logging stay our responsibility. Two unknowns to spike first: exact cipher defaults and how it behaves under schema migration and bulk update statements."

Ask: approve a one-sprint spike covering field inventory, two non-production encrypted columns end-to-end, a benchmark on the largest table, and a written rotation runbook. Decision to adopt follows the spike, not before.