KSI-IAM-MFA—Enforcing Phishing-Resistant MFA

LOW

MODERATE

Formerly KSI-IAM-01

>Control Description

Enforce multi-factor authentication (MFA) using methods that are difficult to intercept or impersonate (phishing-resistant MFA) for all user authentication.

>NIST 800-53 Controls

>Trust Center Components
4

Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.

From the field: Mature implementations express MFA quality as a security metric — adoption rates by method type (FIDO2 vs. TOTP vs. SMS), migration progress toward phishing-resistant authenticators, and enforcement status tracked as dashboard indicators. IdP APIs verify enforcement status continuously, with MFA bypass exceptions tracked and minimized.

MFA Implementation Documentation

Product Security Features

How MFA is implemented and enforced — supported methods, phishing-resistant authenticator requirements, and enforcement mechanisms

MFA Adoption Metrics

Dashboards

Dashboard expressing MFA posture — adoption rates by method type, phishing-resistant migration progress, and enforcement status

Automated: IdP APIs verify MFA enforcement status and phishing-resistant method adoption

Authentication Security Features

Product Security Features

Additional auth security features — session management, impossible travel detection, risk-based auth

Multi-Factor Authentication Policy

Policies

Human-readable MFA policy requiring phishing-resistant MFA — documents intent behind IdP enforcement configuration

>Programmatic Queries

Beta

Identity

CLI Commands

List enrolled factors for a user

curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" "https://${OKTA_DOMAIN}/api/v1/users/<userId>/factors" | jq '.[].{type:.factorType,provider:.provider,status:.status}'

List FIDO2/WebAuthn enrollments

curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" "https://${OKTA_DOMAIN}/api/v1/users/<userId>/factors" | jq '.[] | select(.factorType=="webauthn")'

Check authenticator policy enforcement

curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" "https://${OKTA_DOMAIN}/api/v1/policies?type=MFA_ENROLL" | jq '.[].settings.authenticators'

Okta Documentation

>20x Assessment Focus Areas

Aligned with FedRAMP 20x Phase Two assessment methodology

Completeness & Coverage:

•Are all user authentication paths protected by phishing-resistant MFA (FIDO2, WebAuthn, PKI-based), or are there paths that still allow SMS, TOTP, or push-based MFA?
•Does phishing-resistant MFA enforcement apply to all user populations — internal employees, contractors, agency users, and federated identities?
•Are there any exception or fallback paths that allow authentication without phishing-resistant MFA (e.g., account recovery, help desk resets), and how are those secured?
•How do you ensure phishing-resistant MFA covers all authentication surfaces — web, CLI, API, mobile, VPN, and privileged access management tools?

Automation & Validation:

•What technical enforcement prevents a user from authenticating if they have not registered a phishing-resistant authenticator?
•How do you detect and block MFA downgrade attacks — attempts to fall back from phishing-resistant to weaker factors?
•What happens when a user loses their FIDO2 security key or device — what is the recovery process, and how do you prevent that recovery path from being a phishing vector?
•Do you run simulated phishing attacks against your authentication system to validate that phishing-resistant MFA actually prevents credential theft?

Inventory & Integration:

•What identity provider(s) enforce phishing-resistant MFA, and how do you ensure all applications authenticate through them rather than maintaining local credentials?
•How do you track which users have registered phishing-resistant authenticators and which have not yet enrolled?
•What tools manage FIDO2 security key inventory, distribution, and replacement?
•How does your phishing-resistant MFA integrate with conditional access policies (device trust, location, risk score)?

Continuous Evidence & Schedules:

•What percentage of authentication events currently use phishing-resistant MFA, and what is the target for 100% coverage?
•Is MFA method data per authentication event available via API or security logs for ongoing verification?
•How do you detect when new authentication paths are introduced that do not enforce phishing-resistant MFA?
•What evidence demonstrates that no successful authentication occurred without phishing-resistant MFA over the past 90 days?

Update History

2026-02-04Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

Ask AI

Configure your API key to use AI features.