Identity Domains: MFA policies and admin-safe rollout

Problem

Turning on MFA is the right call, and it is also the change most likely to produce a locked-out admin at 5 p.m. on a Friday. Automation that signs in as a user can break as well.

My goal was a rollout order that protects administrators first, leaves one deliberate escape hatch while things settle, and then closes that hatch.

Options and trade-offs

• Default MFA settings alone: simple, but they may not cover administrator-specific rules, so validate which factors are really enabled.
• Custom sign-on policies: fine-grained control by group and application, at the cost of more configuration.
• The pre-seeded console security policy: a good starting point aimed at administrators. It still needs testing and a plan for exceptions.

My recommendation

Enable the factors first, including a phishing-resistant one such as FIDO2 or a passkey. Then enforce through a sign-on policy with the administrator rule at the top and an all-users rule beneath it. Exempt one administrator temporarily, confirm everyone else can sign in, and remove the exemption quickly.

Worked example

The rollout order I use. Rule order matters, because sign-on rules are evaluated from the top.

1. Enable factors: FIDO2/passkey, mobile app notification/passcode.
   Generate a bypass code and store it somewhere offline.
2. Open the sign-on policy for the console (or create one).
3. Rule 1 (top):  group = Administrators  -> require MFA
   Rule 2:        all users                -> require MFA
4. Exclude ONE named admin while you test. Keep a second session open.
5. Sign in with a private browser window as an admin and as a normal user.
6. Remove the exclusion. Re-test enrollment and re-authentication.
7. Confirm service accounts and automation use API keys or a client
   application, not interactive user sign-in.

Before you flip enforcement, check that you can still reach the tenancy through a path that does not depend on the new rule, such as a confidential application that calls the REST API.

Checklist

1. Enable phishing-resistant factors, and keep a bypass code stored offline.
2. Put the administrator rule first, then the all-users rule.
3. Exclude a single administrator temporarily, and remove that exclusion on a set date.
4. Test enrollment and re-authentication in a private window.
5. Write the support steps for a user who loses their device.
6. Watch sign-in failures for the first few days and adjust.

Where this doesn't apply

Non-interactive automation should not go through user MFA. Give it API keys, instance principals or a client application with its own controls.

One honest limitation

Each additional factor adds friction at sign-in and at recovery. I weigh how easy it is to enroll and recover against the security gain, especially for infrequent users.

Sources

• OCI Documentation: Managing Multifactor Authentication in Identity Domains
• OCI Documentation: Managing Sign-On Policies
• OCI Documentation: Security Policy for OCI Console