- Verify effective policies for representative accounts instead of relying on enrollment counts.
- Treat recovery and emergency access as distinct controls with tested procedures.
- Check workload identities and direct application logins outside ordinary user MFA.
A tenant can show widespread MFA enrollment while a sensitive application still accepts a weaker sign-in path. The review needs to connect the account, application, effective policy, and observed result.
Start with controlled test accounts and approved changes. Identity hardening can lock people out, so preserve a tested emergency access path and a rollback procedure before changing production enforcement.
Review the policy that actually applies
In Microsoft Entra ID, inspect Conditional Access scope, excluded identities, targeted resources, grant controls, and policy state. A policy in report-only mode provides evaluation results; it does not enforce its proposed restriction. Microsoft's report-only documentation explains how to use those results during deployment.
In Okta Identity Engine, review application sign-in policy rules and their relationship to enrollment and session policies. Okta's phishing-resistant policy guidance describes the relevant constraints. Confirm capabilities for your edition and configuration instead of assuming a rule label guarantees the intended assurance.
For each platform, test an ordinary employee, privileged user, supplier, and exception account against a representative sensitive application. Record the successful path and an expected denial. Check the log for the effective policy and authentication method. Also inspect direct application accounts that may bypass federation.
Reduce administrative reach without losing recovery
Export high-impact role assignments and identify the owner and purpose of each. Separate daily user access from administration where appropriate. Remove obsolete assignments through approved change control, and use limited-duration privilege where supported and operationally suitable.
Review emergency accounts separately. They need protected authentication, monitored use, and a tested purpose during an identity outage. Do not blindly apply a blanket policy change that disables the only recovery route. Conversely, do not let an emergency exclusion become a routinely used administrator account.
Exercise factor replacement
Ask support to walk through a lost-device request using a test identity. Determine what proves the requester's identity, who can approve a privileged reset, and how the legitimate user is notified. Check factor enrollment and recovery events in the audit trail.
For a hypothetical exception, a contractor is excluded from a device requirement to finish a project. Record the application scope, sponsor, expiry, and alternate controls. Verify the exclusion ends. A broad group exclusion with no owner can outlive the original project indefinitely.
Check identities that do not use interactive MFA
Service principals, API integrations, and other workloads need appropriate credential or federation controls, scoped permissions, and ownership. A human MFA policy is not proof that these identities are protected.
List who can create credentials or change grants, how unused access is detected, and how the integration is revoked. Review lifecycle events too: disabling the directory user may not terminate every application session or remove a separately managed account. Test downstream results for a controlled leaver scenario.
Finish with a findings record that includes the affected path, observed evidence, intended behavior, business impact, corrective owner, and retest. Avoid reporting "MFA fixed" until the sensitive application paths, recovery exceptions, and relevant logs have been checked.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.