OktaOverview
While adopting MFA is a great step forward, some factors are safer than others. As you might imagine a code (OTP) sent through SMS or email, which is still prone to phishing attacks, is considerably less secure than a biometric factor for example.
Remediation guidance
Consult the Okta documentation and, depending on your security requirements, disable certain factors from the Authenticators page and/or edit the rules of your authentication policies from the Authentication Policies page.
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
Okta
Use tenant-wide sign-on policies, MFA policies, admin-role governance, and identity lifecycle automation so the control is enforced centrally.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
MFA is configured with strong factors
Connectors
Covered asset types
Expected check: eq []
oktaPolicies(where: { type: "MFA_ENROLL", OR:[{allowedFactors_INCLUDES: "phone_number"}, {allowedFactors_INCLUDES: "security_question"}, {allowedFactors_INCLUDES: "okta_email"}]}) {...AssetFragment}
