Only some vendors expose MFA status through their API. For the full, current list of which integrations pull MFA (and any license requirements), see Integrations that pull Multi-factor Authentication (MFA).

HR and payroll integrations do not pull MFA. If a vendor is not on the list, that is a limitation of the vendor's API, not Secureframe.

The most common causes are: the user is not covered by a policy that requires MFA, the user has not completed MFA registration for a method Secureframe can read, the vendor requires a specific license tier to expose MFA data, or Secureframe has not yet synced the updated status.

Start by confirming policy coverage and registration in the source system, then run a manual sync on the integration in Secureframe and allow the test to re-evaluate. Compare the failing user to a user who passes the same test to spot the difference.

This test is categorized as an integration test because MFA status can potentially be pulled automatically through SSO integrations such as Google Workspace, Microsoft Entra ID, or Okta. Not every provider supports that level of data retrieval, so when automatic data is unavailable the test relies on manual evidence upload instead.

A user can have MFA configured in Okta but still fail if they are not covered by an authentication policy that requires MFA, or if Secureframe has not yet received updated MFA status for that user.

Check the following in Okta:

Back in Secureframe, manually re-sync the Okta integration (Integrations → Okta → Sync) and allow time for the test to re-evaluate.

Both are possible. Secureframe reads whether MFA is required and satisfied for each synced user. If a user is not in a group tied to an MFA-requiring policy, or has not finished enrolling an authenticator under that policy, they will fail even when MFA appears configured elsewhere. Align the failing user's group and enrollment to match a user who passes, then re-sync.

After correcting policy or enrollment in Okta, run a manual sync on the Okta integration and give the test time to re-evaluate. If the user matches a passing user's policy coverage and enrollment but still fails after a fresh sync, contact [email protected]. Support can verify whether Secureframe is reading stale MFA data for that user and investigate further.

Secureframe checks MFA registration using Microsoft's supported /reports/authenticationMethods/userRegistrationDetails report. Common causes of failure are: the user is not registered for any MFA method, the user is excluded from a Conditional Access MFA policy, or the user uses a method Secureframe cannot verify through the report (for example a third-party solution such as Duo).

A Microsoft Entra ID Premium P1 (or higher) license is required for Secureframe to read MFA registration data through Microsoft Graph, and the connection must be created by a user with the Global Reader role. If your tenant does not have the required license, use Pass with upload on the test and attach manual evidence of MFA enrollment.

After updating MFA policies or user registrations, run a manual sync on the integration and re-check the test.

Secureframe determines MFA status from the Microsoft Graph registration report, which reflects whether a user has registered MFA methods. Conditional Access can enforce MFA at sign-in, but if a user has not registered an eligible method, or is excluded from the policy, the registration report can still show them as not covered. Confirm the user is both in scope for a Conditional Access MFA policy and has registered a supported method.

In the Microsoft Entra admin center, open Protection → Authentication methods → User registration details (also surfaced under the Authentication methods activity reports). This view shows whether each user is registered for MFA and which methods they have. It reflects the same registration data Secureframe reads through Microsoft Graph, so it is the best place to confirm a user's status before contacting Support.

If a new hire has registered MFA but still fails, confirm they are in scope for the Conditional Access or per-user MFA policy, that they registered a method Secureframe can read, and that the Office 365 or Entra integration has synced since enrollment. Run a manual sync and re-check. If registration looks correct in the User registration details report but the user keeps failing, contact [email protected] so we can check for stale registration data.

A few configurations can cause this:

For federated apps (where Google Workspace is the SAML identity provider), the user's Google account must have 2-Step Verification enabled for connected apps to show MFA as enforced. After making changes, run a manual sync on the Google Workspace integration.

In the Google Admin console, go to Security → Authentication → 2-Step Verification to capture the enforcement setting for your organization or org unit, and capture the user list showing 2-Step Verification status. Include the date and your organization name in the capture. Attach this as evidence using Pass with upload if the automated test cannot read the status.

Heroku only exposes the MFA data Secureframe needs on the Heroku Enterprise plan. On non-Enterprise plans, Secureframe cannot read MFA status through the API, so the related test cannot pass automatically. This is a limitation of Heroku's API tier, not Secureframe.

Use Pass with upload on the test and attach manual evidence showing MFA is enabled and enforced (for example a screenshot of the provider's MFA or 2FA settings). This satisfies the control when automatic verification is not available. You do not need to upgrade the vendor plan solely to pass the test.

Use it when Secureframe cannot read MFA status automatically, typically because the vendor does not expose MFA through its API or your license tier does not include the required data. Attach evidence that MFA is enabled and enforced for the in-scope users.

Capture the provider's MFA or 2FA enforcement setting and, where possible, the list of in-scope users showing MFA is enabled. Include enough context to identify the provider, the organization, and the date. Confirm acceptable evidence formats with your auditor before the audit if you are unsure.

Platform login MFA (enrollment, authenticator apps, backup codes, and resets) is covered in Multi-Factor Authentication (MFA) and FAQs: Passwords and MFA.

When ingesting personnel data through a Custom Integration, map the source mfa_status and role fields to the two_factor_enabled and roles target fields. See Create Custom Integrations.

MFA Delete requires root-user actions per bucket and cannot be applied org-wide from a management account. See FAQs: Amazon Web Services (AWS).