Multi-factor authentication (MFA) means users must prove their identity in more than one way when they sign in. In Okta, MSPs can configure MFA at the organization or application level. When configured at both levels, users are prompted to confirm their credentials when signing into Okta, and again when accessing applications that have been configured to require it.
In Okta Identity Engine (OIE), factors are referred to as authenticators. There are different types of authenticators, which fall into three categories:
Knowledge — something the user knows, such as a password or the answer to a security question
Possession — something the user has, such as a phone or access to an email account
Biometrics — something the user is, meaning a physical attribute a device can scan, such as a fingerprint or face
At a minimum, MFA in Okta requires two authenticators, each from a different category. See more on the different types of authenticators in Okta. 
BEST PRACTICE
Some authenticators are stronger than others. See Authenticators – MSP best practices for ZeroTek's guidance on choosing and configuring authenticators for MFA, and our MFA Bypass Setup guide for how to handle exception cases safely.
Adaptive MFA (AMFA)
Okta's Adaptive MFA (AMFA) helps MSPs balance strong security with a good user experience for their customers. With AMFA, you can configure Okta policies that adapt the authentication challenge to the level of risk a user presents at the moment of login, based on context like their location, the device they're using, and whether that device meets specific security requirements.
EXAMPLE
A user with an Accounting role and access to a sensitive app containing key payroll and financial data uses a badge to get through security at the office. When the user logs in from this trusted location, Okta policies might allow them to access Okta and most apps with one factor, but still require an additional factor before opening the sensitive app.
However, if Okta detects the user logging in from an IP address outside the office, the user might need to provide several factors before accessing Okta — and might not be able to access the sensitive app at all.
Further layers of security can be added on top of AMFA. For example, global session policies can strictly limit how long an Okta session remains idle when the user is outside the office, and access to sensitive apps can be restricted to sessions initiated on a managed or trusted device that meets specific security requirements. These layered controls also support help-desk workflows like verifying the identity of someone calling your help desk.