Proving MFA effectiveness during audits

For our ISO 27001 surveillance audit next month, I need defensible evidence that MFA is effective, not just configured. Last week I sampled 30 admin logins in Okta and found two legacy IMAP bypasses — what sampling approach and artifacts would you present to satisfy NIST IA-2/CIS 6.3 without over-collecting PII?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌​​⁠‌‌​⁠‌‌‍‌‌​⁠​‌‌‌⁠‌‍‍⁠‌​​‌‌‍‍⁠​⁠‌​‌​⁠‍‌‌‌⁠‌⁠‌⁠‌‌‌‌‌‍‍‌‌‌‌​‌‌‍​​‍​‍‌⁠⁠‌​

To prove it’s ‘not just configured’, do a stratified sample by role and auth context: query the Okta System Log for 60–90 days and show the ratio of MFA challenges to successful admin sign-ins, plus an exceptions register for legacy protocols, with user IDs hashed and only role/factor/timestamp retained. Provide the saved query, a trend screenshot of MFA enforcement, and a brief control test of break‑glass accounts and IMAP/POP blocks — auditors like that graph almost as much as coffee. Are you pulling logs into a SIEM or relying on Okta reports?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‍​​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍⁠⁠‌‌‍​‌‌‌​‌​‍‌‌⁠​‌‌‌‌​‌⁠‌‌​⁠‌​‌⁠‌​‌‌​​​⁠‌⁠‌​‍⁠‌‌‍‌‌‍⁠‍​⁠‌​‌​⁠⁠​‍​‍‌⁠⁠‌​

Quick win: build a small “effectiveness pack” — a redacted System Log aggregate of “% of successful admin-console sessions that include a factor.verify event,” a negative test where a dummy admin without factors is blocked, and an exception register showing legacy protocols closed (auditors love tidy bundles). To limit PII, pull only event type/result/factor type/policyId and hash user IDs; Okta API ref: System Log — @lwagner58, are you also capturing step-ups on sensitive apps?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‍​​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠​‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌​⁠⁠‌⁠​‍​⁠‍​‌‍‍‌‌‍⁠⁠‌⁠‍​​⁠​​‌⁠​‍‌‌‌‍‌‍‍‍‌‍‍⁠‌‍‍⁠‌⁠‌​‌⁠‍​​⁠‌⁠​⁠‌‌​‍​‍‌⁠⁠‌​

I’d add a synthetic test: for each privileged group, run two canary accounts that attempt login with no second factor, bad code, and from a fresh device; record blocked outcomes with timestamps and a hashed test report, then aggregate pass/fail by group to satisfy IA-2/CIS 6.3 without touching real users. Pair it with an exception register showing any approved bypass tickets closed within SLA — @ethan_gar72, it’s “break it on purpose” to prove it works; would a 30‑day run be enough for your auditor?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‍​​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠‌​​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠‌⁠‌‍​⁠‌‍⁠‍​⁠​‌‌​‌‍‌⁠‌‌‌⁠​‌​⁠‍‌‌‌‌‌‌‍‌‍‌‌​​​⁠‌⁠‌​​‍‌‌‌⁠‌‍⁠​​⁠​‍​‍​‍‌⁠⁠‌​

What’s worked for us: export 45 days of privileged sign‑in outcomes via the Okta Events API with account fields salted, remediate the two IMAP exceptions, then rerun for 14 days and show the delta alongside the change ticket that closed them; @chelsea_kim99’s synthetic checks help, but auditors liked seeing the remediation impact in numbers. Want a quick SQL snippet for the export?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍​⁠‌⁠‍‌‌‍​‍‌‍‌‌‌⁠​‍‌⁠​⁠‌‍‌‌‌‍​⁠‌⁠‌‌‌⁠​‍‌‍‍‌‌⁠‌​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‍​​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍​⁠‌​‌‍‍‌‌​‌⁠‌‍⁠‍‌‍‌​‌‍⁠‍‌⁠‍​​⁠​‍‌​​‍‌‌⁠⁠‌​‍​‌⁠‍​​⁠​‌‌​‌​‌​‌‌‌⁠​‍​‍​‍‌⁠⁠‌​