Lock down the Oracle Cloud root or owner account

Why this matters

Every Oracle Cloud tenancy starts the same way: one user, created at sign-up, sitting in the Default identity domain and holding the tenancy administrator role. That user is what most people mean by the root or owner account. It is not federated, it does not depend on a policy you wrote, and it can delete the tenancy, open new identity domains, change the contact record and mint credentials that outlive any password reset.

The dangerous part is not the console login. It is the credentials the account can create for itself: API signing keys, auth tokens, customer secret keys for the S3-compatible API, and SMTP credentials. None of these expire on their own. If one leaks, changing the password changes nothing, and the account keeps working for whoever holds the key.

The goal is not to delete the owner account. Oracle will not let you remove the last administrator, and you would not want to. The goal is to turn it into a break-glass login used a few times a year, with a documented owner and a tested way back in, while daily work happens through federated users with scoped policies.

Before you start

Sign in as the tenancy administrator and open Identity and Security, then Domains, then your Default domain, then Users. Write down every user in the Administrators group. For each one, check the resources attached to the user: API keys, auth tokens, customer secret keys, SMTP credentials and enrolled MFA devices. That list is both your starting point and your finish line.

Confirm two things before you touch anything: that you can receive mail at the address on the tenancy contact record, and that you know who holds the owner password right now. If either answer is no, stop and fix that first. Every other step depends on being able to get back in.

Next, decide the break-glass model. Some teams keep one named local administrator whose credentials sit in a sealed envelope in a safe. Others keep two, with access approved by a manager. Either works. What does not work is a shared login in a password manager that nobody owns. Write down who may use it and when.

Finally, get your identity provider ready. You need SAML 2.0 metadata from the domain and a mapping from IdP groups to the OCI groups you plan to create. Do not remove an existing administrator until a federated account has signed in and finished a real task.

How to do it

The order matters. Build the new access path, test it, then shrink the old one. Teams that start by deleting the owner credentials usually spend an afternoon on the phone with support.

The break-glass account is an ordinary local user in the Default identity domain, added to the Administrators group, with MFA enrolled on a device the company owns rather than one in an employee's pocket. Give it a name that says what it is, so it stands out in the audit log.

Federation is the part that changes daily life. Add your identity provider to the domain, map its groups to OCI groups, and write a sign-on policy that forces MFA and, where you have fixed egress addresses, restricts sign-in to a network perimeter.

Then clean up authorization. Human access should come from group membership and narrow policies, not from one wide grant. Workloads should use instance principals and dynamic groups so no application stores a user key.

1. Inventory every credential on the owner account. Open Identity and Security, Domains, your Default domain, Users, and list the administrators. For each one, record API keys, auth tokens, customer secret keys and SMTP credentials. Keep the list; you will check against it later.
2. Create a named break-glass administrator. Make a new local user in the Default identity domain, add it to the Administrators group, and enroll MFA on a company-owned device. Store its password and recovery codes offline and record who may use it.
3. Federate human sign-in through your identity provider. Add your IdP to the identity domain using SAML 2.0 metadata. Map IdP groups to OCI groups so that adding someone to a group in your directory grants the right access and removing them takes it away.
4. Require MFA and restrict sign-in for administrators. Create a sign-on policy in the domain that applies to the Administrators group and forces MFA on every sign-in. If your team works from fixed addresses, add a network perimeter so sign-in fails from anywhere else.
5. Strip machine credentials from the owner account. Delete every API key, auth token, customer secret key and SMTP credential attached to the tenancy administrator. Before deleting, find what uses them: CLI profiles, cron jobs, backup tools. Move each caller to a service identity first.
6. Replace tenancy-wide grants with scoped policies. Stop giving people allow group X to manage all-resources in tenancy. Write policies per compartment and per service, and keep the wide grant only for the break-glass group.
7. Move workloads to instance principals and dynamic groups. Create a dynamic group with a matching rule for your compute instances or functions, then grant it only the permissions the workload needs. Applications then authenticate without a stored user key.
8. Point the tenancy contact email at a shared mailbox. Change the contact address on the tenancy record to a monitored group inbox, not one person's account. Password resets, policy notices and billing alerts all arrive there.
9. Turn on Cloud Guard and export the audit log. Enable Cloud Guard against the root compartment so identity problems surface as items you can assign and close. Add a Service Connector Hub rule that copies Audit events to Object Storage or Streaming, because the console keeps a limited window.

How to check it worked

Use the Audit service under Identity and Security. Filter for tenancy-level events such as CreateUser, UpdatePolicy, CreateApiKey and DeleteApiKey, and read the principal column. You want to see named humans and services doing routine work, not the owner account.

Test both paths while you still have a rollback. Sign in as a federated administrator, confirm the MFA prompt appears and that you land in the right groups. Then sign in once with the break-glass account, confirm it still works, and put the device back in the safe.

Check that a user removed from your IdP group loses access at the next sign-in, and that a session opened before the removal dies within your session timeout. That second check is the one teams skip.

Set a reminder to repeat the credential inventory in 30 days and every quarter after that. Keys and tokens have a habit of reappearing when someone runs a quick script.

Mistakes to avoid

Enrolling break-glass MFA on a personal phone. When that person leaves, the way back in leaves with them. Use a hardware key or a TOTP seed kept with the password, both under company control.

Treating federation as finished when the first SAML login succeeds. Group mapping and deprovisioning decide who gets in next quarter. If removing someone from an IdP group does not remove their Oracle Cloud access, you have moved the problem, not solved it.

Deleting an API key that a nightly job depends on. Find the callers first: check Object Storage access, CLI profiles in the .oci config directory, and any CI system holding credentials. Move the job to an instance principal or a dedicated service user with a narrow policy, then delete the key.

Assuming the audit trail is permanent. Oracle Cloud keeps audit events for a limited window, so copy them to Object Storage or Streaming with a Service Connector Hub if you need history during an investigation. If you want an outside read before you start, the Cloud security review from Cloudverg is a fixed price of $6,500 and runs 2 to 3 weeks, one option among several.

Frequently asked questions