Overview
This article answers frequently asked questions about the Multi-Factor Authentication (MFA) enforcement for the Admin Console.
For full details on this requirement, refer to Okta will require Multi-Factor Authentication (MFA) to access the Okta Admin Console.
Solution
Break-Glass Account
Q: My administrator password is in a vault and rotated upon every use. We use this "single factor password only" access for break-glass situations. What is Okta’s recommendation here?
A: It is great that the admin password is in a vault and rotates on every use. However, Okta is a cloud service, and the admin console is accessible from the cloud. Protecting it with a single factor is not sufficient.
Okta recommends enrolling a security key as another factor on this account and using this along with the password. If there is more than one admin user who must have access to the break-glass account password, the recommendation is that each of the admins who must have access enroll in their own security key instances. This is possible with the product today, where multiple security keys can be enrolled as additional factors on the same account. It is also possible to enroll multiple webAuthN authenticators and SMS phone numbers as MFA factors for the same account.
Okta Support can also provide temporary access to the admin console if an admin user is unable to provide MFA during a break-glass situation. With this temporary access, an admin can log in to the admin console for a limited time period with a password only. This capability is automatically revoked at the end of the designated period.
Shared Admin Accounts
Q: We have shared accounts to create API tokens from the admin console. Using MFA on these shared accounts is cumbersome. What should we do?
A: Okta recommends that customers avoid creating multiple API tokens under the same Okta Admin account, as this creates a single point of failure for applications that are using these tokens. If SSWS tokens are required, use one Okta Admin account for each integration that is using these tokens (and protect that account with strong MFA). If possible, move away from API tokens overall and use OAuth service accounts instead, as these remove the human element. We understand this can take time, and certain Okta features do require API tokens.
If you must have a shared admin account, we recommend enrolling a security key as another factor on this account and using this along with the password. If there is more than one admin user who must have access to this account, we recommend each of the admins enroll in security key instances. This is possible within the product today, where multiple security keys can be enrolled as additional factors on the same account. It is also possible to enroll multiple webAuthN authenticators and SMS phone numbers as MFA factors for the same account. Even though the password would be shared across the different admins, each would have their own MFA factor, and would satisfy MFA to access the admin console.
Agent Accounts
Q: We have service accounts for agents. Is there an impact?
A: There is no impact to normal AD/LDAP agents’ operations due to this change. If you use the same service account to log in to the admin console, then MFA will have to be completed to access the admin console
Test Automation
Q: We have a number of automated tests where we log in to the admin console with a username and password. How can the automated test complete MFA?
A: You can enroll the test user in a TOTP Factor and use the shared secret from the enrollment response to generate the time-based OTP value to complete MFA.
Inbound Federation
Q: Our admins Federate into the admin console from another IDP and have already completed MFA on that IDP. We cannot request them to enroll in an additional factor on the current tenant to satisfy MFA. What should we do?
A: Enforcing MFA to access the Admin Console significantly increases our customers’ security posture. Okta has a feature that honors MFA completed at an external Okta IDP org and third-party identity provider (IDP). Please see Configure claims sharing | Okta Developer for details.
- Define a custom SAML attribute session.amr that sends the authentication claims. In case of Entra IDP SAML integration, a custom SAML attribute “session.amr” must be defined that sends the authentication claims as outlined in Define custom attributes - Microsoft Entra External ID. Also, the attributes would need to be added to the token claims as outlined in Add attributes to token claims - Microsoft Entra External ID.
- Use OpenID Connect integration instead of SAML.
For more details, please refer to Configure claims sharing | Okta Developer and select the right topic under the Instructions for dropdown option:
Q: I am already completing password verification at Okta and authentication at an external IDP. How can I make these two count as MFA?
A: If you have configured your IDP usage for "SSO only" under Security > Identity Provider > <Name of IdP configured>, the verification at this IDP counts as a knowledge factor. Changing IDP usage to be "Factor Only" and configuring it as an IDP authenticator makes it count as a possession factor. When this IDP verification and password verification are completed successfully, MFA assurance will be met.
Post MFA enforcement lockout and recovery
Q: I am locked out of the admin console. What can I do now?
A: If you have other authenticators enabled in your org, you can go to the Settings app on the Okta End User Dashboard and enroll in an MFA factor before accessing the admin console. Please contact support for further assistance.
Related References
- Okta will Require Multi-Factor Authentication (MFA) to Access the Okta Admin Console
- Product Update - Upcoming Okta Security Enhancements
- Multi-Factor Authentication
- Enable MFA for the Admin Console
