OCI Vault and Key Management: Vault Types, Key Policies and Secret Rotation

In Oracle Cloud Infrastructure, whoever can use, disable or schedule deletion of a master encryption key controls every bucket, volume and secret that key protects, so Vault security is mostly an IAM policy problem. OCI Vault (the Key Management service) holds master encryption keys in HSMs or software, and the separate Secret Management service stores passwords, certificates, SSH keys and tokens encrypted by those keys. Choices made at creation (vault type, protection mode) cannot be changed later, and a key placed in pending deletion makes its data unreadable at once. This guide covers vault types and HSM options, the IAM resource types and verbs that govern keys and secrets, how services and workloads are granted key use, rotation for keys and secrets, logging and a hardening baseline. It is for OCI cloud security engineers, platform teams and auditors. Details were checked against Oracle documentation on 8 November 2026; tenancy-wide OCI controls are in the Oracle Cloud Infrastructure Security Guide.

This is an independent guide from NHI Mgmt Group, based on Oracle's public documentation as of November 2026. It is not sponsored or reviewed by Oracle. Product features change, so confirm settings against Oracle's current documentation.

Key takeaways

• Pick the vault type and protection mode deliberately. Neither can be changed after creation; automatic key rotation and vault backup are available only in virtual private vaults.
• Separate key administration from key use. manage keys includes rotate, delete, import and backup; use keys includes encrypt, decrypt, sign and export. Give application teams use key-delegate, not either of those.
• Scope every statement to a key or vault OCID. Oracle's own sample policies use where target.key.id = '<key_OCID>'; without it a grant covers every key in the compartment.
• Treat deletion as an outage. The waiting period is 7 to 30 days (default 30), but data encrypted by the key is inaccessible as soon as deletion is scheduled. Disable or cancel rather than delete when unsure.
• Read secrets with workload identities, not stored API keys. Grant read secret-bundles to a dynamic group, scoped by target.secret.name or vault, and apply expiry and reuse rules to every secret.

How identity and access work in OCI Vault

Vault has three building blocks. A vault is the container and its HSM partition. A master encryption key (MEK) lives in a vault, has one or more versions and a stable OCID across rotations. A secret is stored by the Secret Management service, base64 encoded and encrypted by a vault key, but not stored in the HSM. Every action on these is authorised by OCI IAM policy statements written against Vault resource types.

Vault types

Oracle states that its Vault HSMs are certified to FIPS 140-2 Security Level 3. For the trade-offs of keeping keys outside the provider, see the BYOK, HYOK and External Key Management Guide.

Protection modes and algorithms

• Algorithms: AES keys encrypt and decrypt; RSA keys encrypt, decrypt, sign and verify; ECDSA keys sign and verify only.
• Envelope encryption: Object Storage, Block Volume and File Storage generate data encryption keys and store only the DEK encrypted by your MEK; reading plaintext needs a call to Vault, which IAM controls. A generated DEK must be equal or greater in strength than the MEK. See the Envelope Encryption and KMS Integration Patterns Guide.
• BYOK import: each vault includes a 4,096-bit RSA wrapping key whose public half wraps key material for import; it cannot be created, rotated or deleted by you.
• Region: an integrated service can use a key only when the vault is in the same region. Plan one vault per region per data classification.
• Endpoints: vault provisioning uses a regional endpoint, while key management, cryptographic operations, secret management and secret retrieval each have separate endpoints. Reach them privately through a service gateway rather than an internet gateway.

Admin roles and privileged access

Vault permissions are cumulative across the verbs inspect, read, use and manage. The table shows what each verb adds on the resource types that matter most.

• Do not hand out secret-family broadly: secret-family is an aggregate of secrets, secret-versions and secret-bundles, so use secret-family lets a group read contents. Oracle's sample Allow group SecretsUsers to use secret-family in tenancy is a starting point, not a least privilege policy.
• Split duties: Oracle's sample policies give a SecurityAdmins group manage vaults, manage keys and manage secret-family in the tenancy. In larger organisations split this: one group manages vaults and keys, another manages secrets, and neither reads secret bundles in production.
• Watch KEY_EXPORT and request.includePlainTextKey: use keys includes export for software keys and data key generation can return plaintext; the policy variable request.includePlainTextKey lets you write conditions on that request.
• Protect the policies themselves: anyone who can edit IAM policies in the compartment can grant themselves key access. Keep vaults in a dedicated security compartment whose policies only tenancy administrators can change.

Integrations, API tokens and service accounts

Two non-human patterns cover most Vault traffic: OCI services encrypting customer data with your key, and workloads reading secrets.

Letting services use a customer-managed key

Customer-managed encryption needs two statements. The service gets key use, scoped to one key, and the team attaching the key gets use key-delegate. Oracle's documented form is:

• Service grant: Allow service blockstorage, objectstorage-<region_name>, oke, streaming to use keys in compartment ABC where target.key.id = '<key_OCID>', with one objectstorage- entry per region (for example objectstorage-us-ashburn-1).
• Delegation grant: Allow group VolumeWriters to use key-delegate in compartment ABC where target.key.id = '<key_OCID>', or the same for a dynamic group when automation attaches keys.

Workloads reading secrets

• Use workload identity: compute instances, functions and container workloads should authenticate as members of a dynamic group (instance or resource principals) rather than carrying a user's API signing key. A user API key in a container image is a long-lived credential that outlives the workload. See the Workload Identity Federation Guide if your team federates from outside OCI.
• Scope reads to named secrets: read secret-bundles with where target.secret.name = '...' or target.vault.id so a compromised workload reads only its own secrets.
• Retrieve at start-up, cache briefly: fetch the current version through GetSecretBundle or GetSecretBundleByName and re-read on authentication failure so rotation does not cause outages.
• Metadata as a target: workload credentials obtained from the instance metadata service are the prize an attacker in a compromised instance looks for (ATT&CK T1552.005 Cloud Instance Metadata API); dynamic group scope decides how far they reach.

Where identity fits: every service grant, dynamic group and secret reader is a non-human identity with access to protected data. Record an owner for each. See the Secrets Management Guide.

Rotation for keys and secrets

Oracle notes that an expiry rule does not update the secret for you: the version must still be rotated, so pair expiry with an owner and a rotation job against the target system. See the Cryptographic Key Management Guide for cryptoperiod choices.

Logging and detection

The OCI Audit service automatically records calls to supported public API endpoints, including Vault and Secret Management, with request and response parameters. Key rotation success and failure also emit OCI Events.

Forward Audit events to your SIEM; Cloud Guard detectors can add posture findings. See the OCI Cloud Guard and Security Zones Guide.

Metrics

• Scoped grants: percentage of Vault policy statements with a target.key.id, target.vault.id or target.secret.name condition.
• Rotation coverage: percentage of master keys with automatic rotation or a documented manual schedule, and keys past their cryptoperiod.
• Secret rules: percentage of secrets with an expiry rule and a reuse rule.
• Stored user credentials: count of workloads using user API keys instead of dynamic groups (target zero).
• Unplanned destructive actions: key disables or deletion schedules without a change record.

Hardening baseline

1. Design: create a dedicated security compartment for vaults; one vault per region per data classification; virtual private vaults where you need rotation schedules or backup; HSM protection mode for master keys.
2. Policies: write separate groups for vault administration, key administration and secret ownership; grant services and delegates per key OCID; give workloads read secret-bundles on named secrets only. Test each statement in a non-production compartment before applying it to production.
3. Network: reach Vault endpoints through a service gateway from private subnets.
4. Rotation: enable automatic key rotation (60 to 365 days) in private vaults; add expiry and reuse rules to secrets and automate rotation against the target systems.
5. Deletion safety: prefer disable to delete; when deleting, keep the 30-day default, re-key dependent resources first, and use logs to confirm the key is unused. Remember data is inaccessible as soon as deletion is scheduled; the rollback is cancelling deletion within the window.
6. Resilience: back up private vaults, and configure cross-region secret replication where disaster recovery needs secrets in another region. See the Cryptographic Key Management Policy Template.
7. Monitoring: alert on the activities in the logging table and review Vault policies quarterly.

Decision guidance

• Oracle-managed or customer-managed keys: Oracle-managed encryption is on by default for storage services; move to customer-managed keys when you need to control revocation, rotation cadence or separation of duties for audit.
• Default or private vault: default vaults suit most teams; choose private vaults when automatic rotation, vault backup or partition isolation is required.
• External KMS: choose it only when keys must stay outside OCI, and accept that the external system becomes a dependency for every encrypt and decrypt.
• Small tenancy: one security compartment, one vault per region, two groups (key admins and secret owners) and per-key service grants is a sound baseline.

Common misconfigurations

• Unscoped service grants: Allow service objectstorage-... to use keys in tenancy lets the service use every key, so a team can encrypt its bucket with another team's key.
• Developers with use secret-family in tenancy: copying Oracle's sample unchanged gives read access to every secret's contents.
• Software keys with broad use keys: software-protected keys are exportable, so KEY_EXPORT in the wrong hands means the key has left your control.
• Deletion as cleanup: scheduling deletion of a low-activity key that still protects backups makes them unreadable immediately.
• User API keys in workloads: long-lived signing keys copied into images or CI variables instead of dynamic groups; this is the same class of exposure seen when stolen cloud credentials unlock secret stores (T1078.004 Cloud Accounts).
• Expiry without rotation: an expiry rule set to block retrieval, with no rotation job, takes the application down on the expiry date.

Framework mapping

Practitioner checklist

• Keep vaults in a dedicated compartment whose IAM policies only tenancy administrators can edit.
• Choose vault type and protection mode per data classification before creating keys; use HSM mode for master keys.
• Scope every service, delegate and secret grant with a key, vault or secret condition.
• Separate key administration, secret ownership and secret reading into different groups.
• Use dynamic groups for workloads; remove user API keys from images and pipelines.
• Enable automatic key rotation in private vaults and expiry plus reuse rules on secrets, with rotation jobs.
• Alert on key disable, deletion scheduling, export and Vault-related policy changes.
• Back up private vaults and replicate secrets needed for disaster recovery.

Standards and references

• Oracle: Key Management overview
• Oracle: Details for the Vault service (policy reference)
• Oracle: Common policies
• Oracle: Deleting a master encryption key
• Oracle: Secret rules
• Oracle: Secret Management overview
• Oracle: Audit overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Oracle Cloud Infrastructure Security Guide · OCI Cloud Guard and Security Zones Guide · Cryptographic Key Management Guide · Secrets Management Guide