Bring Your Own Key Without Losing Control

Core defect. Meridian has not separated the key trust boundary from the data trust boundary. The same three administrators can read database credentials and data-encryption keys, and keys have not been rotated in five years. That is a separation-of-duties and key-custody failure regardless of whether the label says BYOK.

Proposed BYOK. Keeping client keys in an HSM account owned by Meridian, in the same cloud tenancy as the data, with Meridian administrators retaining key-administrator roles, is not meaningful customer control. The client cannot prevent Meridian from using or exposing the key, and a Meridian insider or compromised administrator account can reach both key and data. It may satisfy a checkbox, but it does not satisfy a serious separation-of-duties review.

Hybrid model. An external key broker with client-held keys gives a real trust boundary: Meridian cannot use the key without the client’s release policy. The 40–80 ms latency and disaster-recovery complexity are real engineering constraints, not reasons to reject the model. They should drive architecture: envelope encryption with short-lived data keys, caching within approved limits, asynchronous payroll processing, and a documented break-glass procedure with dual control. The bank/client should decide whether the latency is acceptable for payroll batch, not the vendor alone.

Recommendation. Offer a tiered model: standard encryption with strict separation of duties for lower-risk clients; external key broker/HYOK for clients that require customer-controlled keys. Fix the core first: separate key-administrator and data-administrator roles, implement dual control for key use and deletion, rotate keys, log all key operations, and build a cryptographic inventory. Then validate FIPS 140-3 (or 140-2 where still valid) at the module level and state exactly what is validated.

Priority 1: the hard-coded AES key. This is an immediate compromise vector. A secret in a repository can be copied by anyone with read access, may persist in history, and is likely shared across environments. Remediation is relatively cheap: remove the key from code, rotate it, move to a secrets manager or KMS, enable secret scanning, and purge history where feasible. The likelihood of exploitation is high; the effort is low.

Priority 2: the 3DES integrations. 3DES is deprecated and weak against modern cryptanalysis; it also creates compliance friction. But the immediate risk depends on exposure: are these internal, low-volume, or Internet-facing? Treat Internet-facing or credential-bearing 3DES first, then migrate the rest to AES-GCM or ChaCha20-Poly1305 with authenticated encryption. The ranking is below the hard-coded key because exploitation is less immediate, but above cosmetic rotation because the algorithm itself is no longer acceptable.

Priority 3: cryptographic inventory and key rotation. You cannot rotate or migrate what you cannot find. Build a inventory of algorithms, keys, owners, locations, and data classifications. Then rotate the five-year-old keys in a controlled sequence, testing decryption and rollback.

Priority 4: BYOK/HYOK architecture. This is a strategic differentiator, but it should not be built on the current broken key-custody model. Fix separation of duties and inventory first; then implement external key brokering for clients who require it. Otherwise Meridian risks building a sophisticated customer-facing control around an insecure foundation.

The statements must be precise and must not overclaim. A defensible response could read:

• Key custody: “Customer data is encrypted at rest with AES-256 using envelope encryption. Data-encryption keys are stored in a FIPS 140-2 validated hardware security module. Meridian administrators cannot export key material in plaintext. For customers on the external key-broker tier, key release is controlled by the customer’s policy and Meridian cannot use the key without that release.”
• Separation of duties: “Key-administrator roles are separate from data-administrator and application-administrator roles. Key use and deletion require dual control. All key operations are logged to an independent audit trail.” If Meridian administrators currently retain key-administrator roles in the proposed BYOK design, the statement must say so: “In the standard BYOK tier, Meridian key administrators can administer keys within Meridian’s HSM account; this tier does not provide customer-exclusive key control.”
• Rotation: “Data-encryption keys are rotated at least annually and on demand after a suspected compromise. Customer-controlled keys can be rotated by the customer through the key broker.” If the legacy keys have not yet been rotated, give the remediation date, not a false present-tense claim.
• Validation: “The HSM module is FIPS 140-2 validated; validation applies to the cryptographic module, not to the entire service. Meridian’s key-management procedures are independently audited.” Do not say “FIPS certified service” if only the module is validated.

Attach a shared-responsibility matrix and a roadmap for the gaps. Clients would rather see an honest gap with a dated remediation than a claim that collapses under audit.