Is there a way to require multi-factor authentication to get into the ADMIN portion of OKTA, but not for standard use? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Shawn SaucierShawn Saucier 

Is there a way to require multi-factor authentication to get into the ADMIN portion of OKTA, but not for standard use?

We would like to require the use of MFA when going to the ADMIN portion of OKTA, but not for standard usage.

I know one way to do this would be to have a different set of credentials for admin and normal user, but with SSO implemented, it's a pain to manage and use multiple user accounts.  
Eric KarlinskyEric Karlinsky (Okta, Inc.)

Hey Shawn,

That's currently not supported directly. What we recommend is to have an Okta Sign-On Policy for Admins that is a bit more stringent. For example, you may choose to prompt admins for MFA every time they log into the Okta portal. In addition you can configure a sign-on rule which reduces the session duration for Admin users. This allows you to improve security without impacting standard end users.


api-workday api-workdayapi-workday api-workday
Hi Shawn, while you cannot do it directly i've done it in a round about way by creating alternate users. As you mention this is a bit of a pain (see

Something I haven't gotten around to doing is having those users created and linked with okta's org to org cababilities. It would remove some of the manual elements and ensure that your admin accounts are termed if a normal account is termed.

I started to kick the tires with this in my preview org a few months back but never wrapped it up.

At a high level
  • Assign an org2org app to your regular users that need admin rights​
    • Create a username transformation on that app that creates unique identifable admin accounts
  • Assign required admin rights to those admin users (org 2 org will create them)
  • Configure org 2 org app to send saml assertions to your own okta org
  • Apply MFA to the org 2 org app
It is a tweak on the informaiton provided in the blog post, i'm not 100% sure it will work but it certainly should.

svcOKTAprd (svc - do not use for anything but AD integration)svcOKTAprd (svc - do not use for anything but AD integration)
I am trying to enable MFA at the OKTA admin page.  I don't want to create seperate admin users.  I am trying to follow the blog too.  In step "2. Enable Inbound SAML" it asks to " In a new tab or window Login to Okta as a Super Admin and Navigate to Security->Authentication->Inbound SAML".  
In my org this option does not exist.  Anyone else have the "Inbound SAML" option?
I've implemeted the work around that Matt came up with (thanks Matt!). It works, but damn is it an annoying bit of work everytime we have to add an admin. It is also less than ideal security wise, as now we have local objects we need to clean up everytime an admin leaves the company (I haven't attempted the org to org bit yet). Considering that the Admin portal is the most critical "application" that is "integrated" with Okta; MFA has to be natively supported. 

Please upvote this idea so that Eric and team get around to MFA'ing the Admin button:
Alex ShchukinAlex Shchukin
We use DUO Security for 2FA on Admin access
Andre Dupre KuiperAndre Dupre Kuiper
@Jonathan I have a similar problem. I believe the menu options have changed since that guide ( was created. I found the option under Security > Identity Providers > Add Identity Provider. Unfortunately this screen also differs slightly from what is referenced in the guide. Step 2.2.7 says to "
Leave the 'Transform Username' as 'username'". However, in our current Okta console the IdP Username field is blank and the transforms from the drop down box don't offer username (pic attached).

@Mark Potosky, did you see these same menus and what settings did you use?

I get "400 bad request [general_failure]" which is a malformed request error. I suspect it is because I am not transforming the username correctly? Anyone have any ideas or specifics on how they succeeded in implementing this?
m26618 Dyerm26618 Dyer
Well what we're doing is using SAML into Okta for users, but Okta admins log in directly via [host]/login/default (pw authentication).  I don't know that that specific bit matters really for the MFA component, but for setting up the MFA part I just have an administrators group, and a Sign-on policy under Security/Authentication (Sign On tab) defined to require users in that group to use MFA every time they log in to Okta.  We also specifically require SecurID for admins (more restrictive than MFA options for normal users, configured in MFA policies).

The result is Okta admins log in via pw and SecurID in order to access the administrator functions.  Pretty straightforward.  I think the Sign On policy probably ought to work for SAML-authenticated users as well though.  You'd SAML in to Okta, then being in the specific administrator group, you'd match the Sign On policy that requires an Okta MFA authentication as well.  That would trigger MFA registration/authentication.