Cybersecurity & Identity · THE NO-PANIC PLAN
Audit organization MFA coverage and exceptions
An MFA policy is not proof that every important account is protected. Coverage can vary by application, identity provider, access path, user group, and authentication method. This workflow is for authorized organization administrators reviewing a workforce or cloud environment. It focuses on coverage and evidence, not on bypassing controls or collecting secrets. Prefer phishing-resistant methods where the platform and risk allow, preserve a tested emergency-access procedure, and review service identities separately because human MFA may not apply to them. NIST SP 800-63B-4 is the current NIST authentication guidance, but it is written for digital identity systems and assurance levels; it does not automatically define every organization's policy.
MISSION Review whether an organization's human accounts and critical applications are covered by enforced multifactor authentication, prioritize stronger methods for privileged access, and document remediation and time-limited exceptions.
Review privileged accounts and verify MFA enforcement across each in-scope applicationTHE REAL-WORLD BIT
What happens outside this browser tab?
Set a scope and risk priority; define the required coverage and method baseline; inventory human identities, applications, privileged roles, and supported authentication paths; compare actual enrollment and enforcement evidence with that baseline; record unsupported systems and approved exceptions with owners and expiry; pilot and remediate in controlled waves with recovery safeguards; test sign-in, lockout, emergency access, and logs; then repeat the review as accounts, apps, and methods change.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Set the review scope and rank the accounts that matter most
Name the identity tenant or system, review date, accountable identity owner, applications in scope, and workforce or contractor groups included. Start with administrator and privileged accounts, remote access, email, finance, customer-data systems, and other high-impact services; then expand across remaining human users. Separate human accounts from service principals, managed identities, shared accounts, test tenants, and external guests so each receives an appropriate control review. Record exclusions with a reason and owner rather than silently omitting them. Use your organization’s current risk assessment and obligations to define priority; a generic checklist or NIST publication does not determine your business-specific risk tolerance.
- 02
Define the expected MFA coverage and acceptable methods
Write down which account groups and applications must require MFA, where the control is enforced, the authentication methods allowed, and how exceptions are approved and retired. Prioritize phishing-resistant methods such as FIDO2/WebAuthn or platform-supported passkeys for privileged and high-risk access where feasible. If stronger methods are not yet available, document the interim control, upgrade plan, owner, and review date rather than treating all MFA factors as equivalent. Include more than one approved method or a safe recovery route where the identity platform supports it. CISA recommends aiming for phishing-resistant MFA, while NIST SP 800-63B-4 describes authenticator properties and assurance requirements; choose controls for the actual platform and risk.
- 03
Build a complete account, role, and application inventory
Export the minimum approved inventory from the identity provider and application owners: unique account ID, account type, role, application, access path, MFA policy, enrolled methods, last review, and status. Include federated applications, VPN or legacy protocols, emergency accounts, guest access, and direct local accounts that may bypass central policy. Use Privileged Access Review to structure a human check of privileged accounts and assignments; it does not query your tenant or prove that MFA is enabled. Reconcile identity-provider data with application and network inventories, record the source and timestamp of each list, and track systems that cannot report enrollment or enforcement evidence.
- 04
Compare enrollment with actual enforcement evidence
For every in-scope group and application, confirm both that users have an approved method enrolled and that policy requires it on the intended sign-in path. Review current policy assignments, conditional-access rules, legacy authentication, exclusions, authentication-strength settings, and sign-in logs. Enrollment alone does not prove that a challenge occurs, and a policy that protects one cloud portal may not cover another application or protocol. In Microsoft Entra deployments, Microsoft's current guidance recommends defining methods, conditions, registration, and rollout; use the equivalent current controls and logs for other providers. Sample successful and denied sign-ins through an authorized test account, and keep screenshots or exports in a restricted evidence store.
- 05
Document gaps, unsupported systems, and time-limited exceptions
Classify findings as not enrolled, enrolled but not enforced, weaker method than policy, bypass path, unsupported application, service identity, or evidence missing. For each gap, assign an accountable owner, compensating control if approved, target date, and escalation path. Require an explicit security owner to accept any exception, state its scope and reason, and set a review or expiration date; do not create permanent blanket exclusions for administrators or emergency accounts. If a legacy application cannot enforce MFA, assess whether it can be isolated, moved behind a modern identity gateway, or restricted to a controlled network path while it is replaced. The tracker is a review aid only; final risk acceptance stays with the authorized decision-maker.
- 06
Pilot changes and test recovery before enforcing broadly
Deploy policy changes to a small representative group first, including administrators, standard users, remote workers, and relevant application types. Test the normal sign-in, new-device enrollment, method replacement, lost-authenticator recovery, service-desk identity checks, and emergency-access procedure using approved test accounts. Confirm break-glass accounts are monitored, strongly protected, and tested under a documented process; avoid an unreviewed exclusion that creates an unprotected route. For Microsoft Entra, follow its current deployment and conditional-access guidance, including staged rollout and report-only evaluation where appropriate. Have support staffing and rollback criteria ready before expanding waves, and stop if users are locked out or an unexpected access path appears.
- 07
Verify coverage after rollout and schedule the next review
Reconcile the final account and application inventory against policy, confirm required methods are enforced in sign-in evidence, and close or reassign each gap. Check that departed users, changed roles, stale methods, and expired exceptions are removed or reviewed. Monitor denied and anomalous authentication events through approved security processes, and route suspected compromise to incident response rather than treating an MFA prompt as proof the account is safe. Record the policy version, evidence sources, sampled test results, exceptions, approver, and next review date. Repeat after identity-provider, application, access-path, method, or regulatory changes; coverage degrades when accounts and integrations change.
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10