Encryption key management under the CBN directive
Encryption keys are explicitly in scope of the CBN directive. How to design in-country key custody: HSM, KMS, key hierarchy, rotation, ceremonies and the evidence inspectors will ask for.
The CBN circular of 15 June 2026 names encryption keys as part of the administrative functions that must be localised alongside primary processing, databases, backups, identity and audit logs. Of all the items in scope, keys are the one with the least floor space and the greatest consequence. A key held abroad makes every byte it protects dependent on foreign infrastructure. This article sets out how to design key management that is defensible under the directive by 1 January 2027.
Why keys are singled out
Encryption is only as local as the key. If a Nigerian database is encrypted at rest with a key stored in a foreign key management service, then:
- The foreign service can, in principle, deny access to the data by withholding the key
- Every decrypt operation requires a network call outside Nigeria
- Key material or key-usage metadata is logged outside Nigeria
- A regulator inspecting the system cannot verify custody without access to a foreign provider
The directive's prohibition on dependency on foreign cloud infrastructure is squarely engaged. Key management is therefore not an optimisation to do after migration; it is a prerequisite of the migration itself.
Inventory first: which keys exist
Before choosing a KMS, enumerate what needs to move. In a typical payment platform we find keys in at least these places:
| Key class | Typical location today | Protects |
|---|---|---|
| Database transparent data encryption master keys | Hyperscaler KMS | Every row in the payment database |
| Storage volume and object encryption keys | Hyperscaler KMS, default | Disks, snapshots, backups |
| Application-level field encryption keys | Application config or cloud secrets manager | PANs, account numbers, tokens |
| TLS private keys for payment APIs | Cloud load balancer or certificate manager | Data in transit |
| Signing keys for JWTs and API credentials | Identity provider | Access to the platform |
| Backup encryption keys | Backup product's vault | Every backup |
| HSM-resident keys for card and PIN processing | Payment HSM, sometimes on-premises already | Card cryptography |
| SSH and infrastructure credentials | Cloud secrets manager, CI/CD | Administrative access |
The last two rows are often the only ones already in Nigeria. The rest need a plan.
Target architecture: a Nigerian key hierarchy
A defensible design has three tiers, all resident in Nigeria:
Tier 1: root of trust
A hardware security module, or an HSM-backed service, in a Nigerian facility. This holds the root keys and never exports them in clear. Options include a dedicated HSM appliance in your own rack in a colocation facility, or an HSM cluster shared across the institution's platforms. The HSM should be FIPS 140-2 Level 3 or equivalent, with a documented key ceremony for initialisation.
Tier 2: key management service
A KMS layer that issues, wraps and rotates data-encryption keys, backed by the HSM. Self-hosted open-source tooling (HashiCorp Vault Community or OpenBao with an HSM seal, for example) runs well in a private cloud and gives you a control plane that is resident in-country. This layer exposes the APIs that databases, storage and applications call.
Tier 3: data-encryption keys
Per-datastore or per-tenant keys, generated by the KMS and wrapped by tier-2 keys. These are what the database, the object store and the applications actually use. They rotate frequently and are never stored unwrapped.
The property to preserve is simple: with every network path outside Nigeria cut, the platform must still boot, unseal and decrypt. If it cannot, the design still has a foreign dependency.
Migrating keys without downtime
Moving keys is different from moving data because you cannot simply copy a key out of a foreign HSM. The usual approach is re-encryption:
- Provision the Nigerian HSM and KMS. Run the key ceremony with witnesses and record it.
- Generate new master keys in-country.
- For each datastore, add the new master key as an additional key-encryption key, then rotate the data-encryption key so it is wrapped only by the in-country master.
- Re-encrypt data at rest where the product requires it (most modern databases and storage systems re-wrap rather than rewrite).
- Move application-level field encryption to the new KMS by dual-reading old and new keys during a transition window, then retiring the old key.
- Reissue TLS certificates with private keys generated in-country.
- Rotate every credential that was ever stored in the foreign secrets manager.
- Destroy the foreign keys and retain the destruction record as evidence.
Step 5 is where most of the calendar goes. Applications that embedded a foreign KMS client library need code changes, testing and a release cycle. Start there.
Backups and keys
Two rules avoid the most common failures:
- Backups must be recoverable with in-country keys only. Test a full restore from a Nigerian backup using only Nigerian key material. If the restore reaches out to a foreign KMS, the backup is not compliant.
- Backups of the KMS itself stay in Nigeria. The KMS state and HSM backup tokens are the most sensitive artefacts in the platform. Store them in a second Nigerian facility, under separate custody.
Operational controls inspectors will ask about
The directive requires evidence, not just architecture. For key management, prepare:
- A key inventory listing every key class, its location, its custodian and its rotation period
- Key ceremony records for HSM initialisation, with witness signatures
- Rotation logs showing keys rotate on schedule
- Access logs for the KMS, retained in Nigeria, showing who used which key and when
- Separation of duties: no single person can both administer the HSM and administer the database
- A destruction record for foreign keys retired during migration
- Restore test results demonstrating recovery with in-country keys only
These are ordinary controls in a mature key management practice. The difference under the directive is that the location column must read "Nigeria" on every row.
Common mistakes
- Using a hyperscaler's Nigerian region for KMS. Even where a global provider has local presence, the control plane and operations may not be Nigerian, and the dependency prohibition applies. Verify where the service is administered before relying on it.
- Leaving the identity provider abroad. JWT signing keys are keys. If the IdP is foreign, access to the platform is controlled by foreign keys.
- Forgetting certificates. TLS private keys for payment endpoints are often generated by a cloud certificate service and never seen by the team.
- Keeping the old KMS "just in case". A retained foreign key is a retained foreign dependency. Destroy it and keep the record.
How this fits the wider programme
Key management touches every other workstream: databases cannot be migrated until they have somewhere to get keys from; backups cannot be validated until restore-with-local-keys is possible; the observability stack needs the KMS access logs. In the migration plans we build, the KMS is stood up in the first phase, before any data moves. See How long does a payments data migration really take? for where it sits on the timeline, and the data repatriation solution for the full workstream structure.
This is not legal advice. This article describes technical design options for planning purposes. Consult your legal and compliance advisers on how the directive applies to your institution.
NuxFamily designs and operates in-country key management as part of the private cloud platforms we build for financial institutions, including HSM integration, self-hosted KMS and the key migration itself. If you want to review your key inventory against the directive, start with our CBN data localisation resource or contact us.
