Most integration platforms at Saudi banks store their secrets in Kubernetes Secrets, environment variables, or properties files committed to a configuration repository. The secret is visible to anyone who can read the namespace, the environment, or the repository. Rotation requires a deployment. Audit of who accessed a specific secret at a specific time is impossible. When SAMA’s examination team asks to see evidence of key rotation for database credentials used by the payment processing service, the answer — “we rotate them manually when we remember, and we restart the pods after” — is not a satisfactory control demonstration.
HashiCorp Vault on OpenShift is the production answer to secret lifecycle governance. Dynamic secrets — where Vault generates a unique, short-lived database credential for each application pod at startup, and revokes it when the pod terminates — make the concept of credential rotation obsolete: the credential never persists long enough to require rotation because it expires automatically. The audit log Vault maintains records every secret read, every credential issuance, and every revocation with timestamps and requester identity — exactly the evidence SAMA requires to demonstrate that secrets access is controlled, auditable, and time-bound.
What the regulatory examination tests
SAMA’s Technology Risk Management framework treats cryptographic key and credential management as a Tier 1 control. The examination team will ask three questions. First: can you show the last rotation date for every secret that touches a production payment system, and confirm it was rotated within your policy period? A Vault dynamic secrets engine provides a clean answer: every secret was issued at time X and expired at time Y, so the maximum credential age is the TTL, not the last manual rotation date. Second: can you show who had access to production database credentials in the past 90 days? Vault’s audit log provides a complete access record with Kubernetes service account identity, timestamp, and the specific secret path accessed. Third: can you demonstrate that a credential cannot be used after an employee leaves? With Vault’s Kubernetes auth backend, credentials are issued to pod service accounts — revoking the service account binding revokes all subsequent credential issuances immediately.
There is also an operational resilience dimension. When Vault is unavailable, every pod that depends on dynamic secrets will fail to start. This means Vault has the same availability requirement as the payment processing system itself — five nines, with a tested failover between Vault clusters. Integration teams that deploy Vault without understanding this dependency discover it during a Vault HA failover exercise that takes down their payment processing pods for 12 minutes. The correct architecture is Vault HA across three Raft nodes in three availability zones, with agent-cached credentials that survive short Vault outages, and a tested recovery procedure.
Static secrets with manual rotation schedules are a compliance theatre answer to a real threat model. Dynamic secrets with automated issuance and short TTLs are the only architecture that survives both an incident and an examination.
What leadership must decide before the platform team builds it
Three policy decisions require executive input before the engineering team can design a Vault deployment that will satisfy SAMA and survive production. First: which secrets are in scope, and in what order? A full Vault adoption covers database credentials, TLS certificates, IBM MQ credentials, core banking API keys, and encryption keys used by the integration layer. Doing all of this simultaneously across a production integration estate is a 12-to-18-month programme, not a sprint. The prioritisation — which secrets have the highest risk if compromised, which are easiest to migrate to dynamic issuance — is a risk decision that the CISO and CTO must make jointly, not an engineering decision about what is technically feasible first.
Second: who owns Vault operationally? Vault is not a fire-and-forget deployment. It requires a dedicated platform engineering function that understands Raft consensus, unsealing procedures, policy path management, and audit log monitoring. At a minimum, two engineers with deep Vault expertise before the system goes live with any payment-adjacent secret. “We will learn it as we go” is not acceptable for a system that is a single point of failure for credential issuance to payment processing.
Third: how does Vault integrate with the bank’s PKI? The intermediate certificate authority that Vault uses to sign dynamic certificates must be signed by the bank’s root CA, which is managed by a separate PKI team on a different governance cadence. Getting the intermediate CA signed, establishing the annual renewal procedure, and integrating it into the bank’s certificate management process is a cross-team dependency that cannot be resolved by the integration platform team alone. It requires a named project with a committed timeline from the PKI team — and that commitment requires executive sponsorship.
For the engineering depth behind this decision — Vault Agent Injector vs. CSI driver, dynamic database secrets for DB2 and Oracle, Kubernetes auth backend, Raft HA configuration, cert-manager integration, and the production checklist — see the companion Lab article: DevOps & Platform: Vault Secrets Management.