How to enforce MFA for every Oracle Cloud user

Why this matters

An Oracle Cloud tenancy holds a lot: compute, databases, object storage, network, and the policies that connect them. A console password is the only thing between the internet and that control plane for a local user. Passwords get reused, phished, and leaked. Multi-factor authentication (MFA) makes a stolen password much less useful, because the attacker also needs a code or a hardware key.

OCI has more than one kind of user. Local users sign in with a console password stored in the identity domain. Federated users sign in through your identity provider, such as Microsoft Entra ID or Okta. Service accounts are local users that applications use. The MFA setting in the identity domain covers console sign-in for local users. It does not cover API signing keys, auth tokens, customer secret keys, or SMTP credentials. Those are separate credentials with their own risk.

The biggest risk sits with administrators. A Tenancy Administrator or Identity Domain Administrator can create users, change policies, and delete resources. If that account has only a password, one leak can become a full tenancy compromise. Enforce MFA for administrators first, then for everyone else.

Before you start

Find every identity domain in the tenancy. OCI tenancies usually have a Default domain, and some have more than one. Each domain has its own MFA settings, so a policy in one domain does not apply to another. You need the Identity Domain Administrator role, or a role that can manage security settings in the domain.

Inventory the accounts and credentials. List local users, federated users, and service accounts. Export the list of API signing keys, auth tokens, customer secret keys, and SMTP credentials. Note which users hold tenancy or domain administrator roles. This inventory is what you will use to prove coverage later.

Decide which factors you will allow. TOTP authenticator apps work on any phone and are easy to support. FIDO2 security keys are stronger against phishing and are a good fit for administrators. Push notifications through Oracle Mobile Authenticator are convenient. SMS and email are weaker fallbacks; use them only if you have a clear reason.

Prepare for lockouts. Enroll at least two administrators before you enforce the policy. Print bypass codes and store them offline. Write down how a domain administrator resets MFA for a user who loses a phone. Test that reset path on a test account.

How to do it

Work domain by domain. In the OCI Console, open Identity & Security, then Domains, and select the domain you want to change. Open the Security tab and find Multi-factor authentication. This is where you enable factors and set enrollment.

Set enrollment to Required. Choose the factors you decided on. Set trusted device duration to zero if you want a prompt every time, or a short value if you accept some convenience. Review bypass code settings before you save.

Tell users what will happen. On their next sign-in they will be asked to enroll. They can also open My Profile and manage factors there. For administrators, require a security key or TOTP app, not SMS.

After the domain settings are in place, close the other paths. Federated users need MFA at the identity provider. API keys and auth tokens need their own controls. A domain policy alone will not cover either one.

1. List every identity domain. Open Identity & Security, then Domains, and write down each domain name and ID. Check which one holds your administrators and which ones hold application users.
2. Classify every user. For each domain, mark users as local, federated, or service. Note who has administrator roles and who still has a console password.
3. Enable the factors you trust. In the domain, open Security, then Multi-factor authentication. Turn on TOTP and FIDO2 at a minimum, and add push if you support it. Disable SMS or email unless you need a fallback.
4. Set enrollment to Required. Set the enrollment policy to Required for all users. Set trusted device duration to zero or a short period. Save the change and note the time for your audit trail.
5. Configure bypass codes and reset. Set the bypass code policy, generate codes for administrators, and store them offline. Document the exact steps a domain administrator follows to reset MFA for a locked-out user.
6. Roll out to administrators first. Create a group for administrators and confirm every member is enrolled. Then extend the required policy to all users in the domain. This catches problems before the wider rollout.
7. Handle federated users at the IdP. For federated domains, MFA is enforced by your identity provider. Require MFA on the OCI application in Entra ID, Okta, or whichever provider you use. Remove local console passwords from federated users.
8. Close the API key gap. List API signing keys and delete unused ones. Move workloads to instance principals or resource principals. For human CLI access, use oci session authenticate so the session starts with a browser MFA prompt.
9. Record evidence for each domain. Save screenshots of the MFA settings, the user list, and the sign-on policy. Store them with your security review materials so you can show coverage later.

How to check it worked

Test with a real local user in a private browser window. Sign out, sign in, and confirm the factor prompt appears. Try to reach the console without completing the factor. The sign-in should fail.

Open a sample of users in the domain and check their authentication factors. Confirm that every local user with a console password has at least one factor enrolled. Confirm that federated users have no local console password. Check the administrator group first.

Test the API path separately. An API signing key will still work without MFA, which is expected. Confirm that unused keys are gone and that human operators use session tokens. Run oci session authenticate and complete the browser prompt.

Review the Audit service for MFA setting changes and sign-in events. If you use Cloud Guard, check identity findings. Keep the evidence with the date and the name of the administrator who made the change.

Mistakes to avoid

Thinking MFA covers everything. API signing keys, auth tokens, customer secret keys, and SMTP credentials bypass MFA. Treat them as separate secrets with their own rotation and removal process.

Leaving trusted devices on for too long. A long remember-this-device window turns MFA into a one-time check per device. Set it to zero for administrators.

Enforcing in one domain and forgetting the rest. Each identity domain has its own settings. A new domain created later starts with its own defaults, so add it to your checklist.

Leaving local passwords on federated users. If the identity provider is the only path you want, remove the local console password. Otherwise a user can bypass the IdP and its MFA policy.

Using SMS as the only factor. SMS is better than nothing, but it is weaker than TOTP or a security key. Keep it as a fallback, not the primary factor.

Locking out the last administrator. Enroll two administrators, store bypass codes offline, and test the reset process before you enforce the policy.

Not removing leavers. MFA does not revoke access. Disable the user and delete API keys, auth tokens, and other credentials on the day someone leaves.

If you want an outside read on identity gaps, the Cloud security review from Cloudverg is a fixed price engagement at $6,500. It covers identity and access across up to five cloud accounts, ranks findings by risk, and gives the exact fix for each. It is one option among others, such as an internal audit or a specialist consultant.

Frequently asked questions