Making MFA mandatory for securing the admin console front door
Okta is committed to providing our customers with the highest level of security. We were among the first technology providers to pledge our commitment to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA’s) seven Secure by Design principles, and a year ago, we launched the Okta Secure Identity Commitment.
Under these initiatives, we’ve announced and delivered a number of essential features and upgrades for our corporate infrastructure and product portfolio. This includes encouraging customers to use one of the most effective security measures available: a strong and consistent approach to multi-factor authentication (MFA). To help raise the security baseline for everyone, we began enforcing MFA for all Okta Admin Console logins in 2024. It’s a smart, necessary step in our shared commitment to identity-first security.
Today, we’re proud to share that Okta has achieved 100% MFA enforcement to the Okta Admin Console for all existing Okta tenants in one year. And for all new tenants, MFA is a default and immutable requirement for access policies to the Okta Admin Console.
Why is MFA being enforced for the Okta Admin Console?
The Okta Admin Console is the central hub for managing Okta users, Okta-protected applications, and Okta security policies. Unauthorized access to this console can have devastating consequences that include:
- Data breaches: Attackers could access sensitive user information and application data.
- System compromise: Threat actors can alter security settings, create backdoor accounts, and disable critical security features.
- Service disruption: Unauthorized changes can lead to outages and impaired functionality for end users.
- Reputational damage: A security incident can severely impact an organization's business and brand.
MFA significantly reduces the risk of these outcomes by requiring a second verification factor on top of a password, such as a time-based one-time password (TOTP) from a mobile authenticator app, a fingerprint scan, or a hardware token. While Okta only mandates MFA with any two of knowledge, possession, or inherence factors, Okta strongly encourages admins to move away from passwords and enable the most secure authenticators available, which include phishing-resistant authenticators like Okta Verify FastPass and FIDO2 WebAuthn authenticators.
Okta provides robust features to enforce MFA for administrative access. All Okta tenants come with a baseline number of supported factors, such as Okta Verify TOTP, FastPass, and email, in addition to passwords. Okta also provides a flexible policy that allows admins to enforce MFA specifically to the Okta Admin Console.
The application policy for the console has always required MFA by default. However, admins were allowed to downgrade the setting to one-factor authentication (1FA), which many opted to do for various reasons. Now, Okta prevents this default security stance from being downgraded, and we’ve helped all existing customers elevate their security posture with MFA.
How we convinced Okta customers to enforce MFA
Let’s jump into how we helped admins overcome their real and perceived need to maintain 1FA policies and embrace MFA to secure access to the Okta Admin Console. In general, customers accepted that MFA was a good thing to instill. However, there were several common reasons why they believed they had to stay at the 1FA assurance level:
- Admins were unaware that they had policy rules that allowed for 1FA access.
- Admins thought that they did not need MFA since they vaulted their passwords and rotated them upon every use.
- Admins completed MFA with a different identity provider (IdP) than Okta and were federating into the Okta Admin Console.
- Admins had automated test accounts that needed to log in to the console.
- Admins were concerned about Lightweight Directory Access Protocol (LDAP) and Active Directory (AD) agent operations.
We took pains to address each of these hurdles and concerns. That last issue was easy enough to address with a simple confirmation that there would be no impact on normal agent operations.
However, as for the rest, we first published warnings to admins if they had a tenant with any rules allowing 1FA access via our HealthInsights feature.
We also published warnings from the Okta Admin Console policy, highlighting these offending rules.
For admins who believed they didn’t need MFA since they regularly vaulted and rotated their passwords, we reinforced that MFA protection is superior. While customers should continue to vault and rotate their secrets, they should also add an additional factor requirement, specifically a possession or biometric factor. If vaulted passwords were shared with multiple users, we recommended that each user have their own unique account instead.
As for other customers, some have chosen to complete MFA on an external IdP and federate into the Okta Admin Console. Until recently, Okta treated that inbound federation as a single factor. However, we now have a new feature called claims sharing. The IdP can send standards-based AMR claims within the SAML or OIDC response, and Okta will honor the factors completed with the other IdP as satisfactory for MFA assurance. Thus, another hurdle was removed.
For customers with automated test accounts that logged in to the console to complete tests, the admins believed that providing an additional factor would not be possible for such accounts. Okta addressed this issue by recommending that the test accounts enroll in a TOTP factor and vault the shared secret along with the password. After checking out the password, the shared secret can also be checked out and utilized to programmatically generate the TOTP at the time of login.
With all of these customer challenges resolved, our customers were ready to take action.
Preparing to roll out changes
Given the large number of Okta tenants we were dealing with, ranging from free trial and developer tenants to tenants with large and complicated implementations, it was necessary to stagger the rollout to help ensure minimal disruption to normal operations. Therefore, we employed several tactics to enforce MFA to the Okta Admin Console carefully:
- Announce the initiative: In addition to public announcements and blogs indicating imminent MFA enforcement, we published in-product guides and banners on the Okta developer and support portals and sent targeted emails to admins to inform them of the upcoming changes.
- Prevent the creation of all new 1FA access policies: As a first step, Okta rolled out changes to all tenants so that no new 1FA access policy could be established. The idea was to stop the bleeding before the complete fix rolled out.
- Divide customers into cohorts for MFA enforcement: To mitigate the risk of a flood of support tickets to Okta and prevent unnecessary admin lockouts, we rolled out this change by customer cohorts. We first examined each tenant’s configurations and grouped them based on the remediation steps they would require to enforce MFA. Then we selected different enforcement dates for each cohort and prepared specific remediation instructions.
Admins were instructed to modify their Okta Admin Console policies in the following ways:
- Rules with password-only assurance should be modified to require a password and another factor.
- Rules with any 1FA assurance or possession-factor-only assurance should be modified to require any two factors.
Once the change was made, admins were not allowed to downgrade back to 1FA assurance. If an admin did not take action, Okta enforced MFA to the console for that tenant on a clearly communicated date.
Okta customers hit the ground running towards MFA
Within the first four months of the rollout, Okta completed enforcement of MFA on 99% of all applicable tenants. The remaining 1% were tenants that required additional support from Okta, either in the form of feature enhancements, like claims sharing, or time to update various processes to operate at this new required security level. Okta stayed in touch with this group of customers to understand their pain points deeply and collaborate with them until they were confident about moving forward in this new direction.
With 100% MFA enforcement to the Okta Admin Console, admins are now leveraging a variety of factors and authenticators to sign in to the console. The top three factors used include password, Okta Verify push notifications, and Okta FastPass. Common combinations of these factors used to complete an MFA challenge include password and Okta Verify push, as well as password and Okta FastPass.
Today, MFA access to the Okta Admin Console is a non-negotiable requirement for all current and newly onboarded Okta admins. By embracing this secure posture by default, customers benefit from a reduced attack surface and greater protection of critical identity infrastructure.
Learn more about Okta’s MFA product by visiting the Adaptive MFA webpage. Keep tabs on what Okta is doing to fight against identity-based attacks by learning about the Okta Secure Identity Commitment.
