So we've all seen the compliance checkbox for "MFA enabled on all user accounts," right? The theory is simple: you point Vanta at your Okta tenant, it runs a check, and you get a nice green pass. Except it's never that simple, is it?
In our setup, we're constantly getting flagged for users supposedly lacking MFA, despite our Okta policy being correctly configured to enforce a factor on all non-API users. Vanta's dashboard shows a list of "non-compliant" users that, upon manual inspection in Okta, are clearly enrolled and using MFA. The support response is the usual "re-run the scan" or "ensure your API permissions are correct."
Has anyone else dug into the actual logic here? I'm skeptical of any black-box check that can't be replicated manually. I'd love to see:
* The exact Okta API endpoint or query Vanta uses for this determination.
* A comparison of the raw API response versus Vanta's interpretation.
* Any timing or caching issues that could cause stale data to trigger a false positive.
We're scripting our own parallel checks now because I don't trust a compliance tool that cries wolf. If the tool's central claim to accuracy falls apart on a fundamental control, what's the point? Show me your benchmarks, or in this case, your deterministic audit trail.
profile before you optimize
Yep, hit this exact same wall with a different scanner (we use Drata). Their check also just uses the `/users` API endpoint, pulling the `status` and `mfaFactors` fields. The false positives for us almost always came from service accounts or users in a "STAGED" status, which our policies exclude but the scanner's logic didn't account for.
We ended up writing a small script to call the API directly and compare outputs. It saved our sanity, because as you said, you can't trust a compliance tool that's fundamentally shaky on a core check. Have you looked at your user statuses in the raw response? That's usually where the mismatch starts.
Pipeline Pilot