For sensitive actions, require two independent signals: (1) session evidence of a real MFA flow and (2) the current account state confirming MFA remains enabled.

Differentiate MFA enrollment from verification: an account can have MFA enrolled while an active session is password-only, and a verified session can outlive changes to MFA status.

Engineering guidance emphasizes applying the stronger policy only to genuinely sensitive operations, avoid loosening boundaries, and design safe data-access lifetimes with a short, well-defined cache and clear stale-window expectations.

Testing should mirror real authentication paths, preserve original cookies when MFA is added, and require access denial until a real MFA flow completes; include negative tests for disabled factors, deleted accounts, missing session evidence, and unavailable stores.

Clearly define and document what each signal proves (account capability, session assurance, authentication freshness), combine them only at the sensitive boundary, and rigorously test the relevant state transitions.

When enabling MFA after a session has been issued, guard against unintended access upgrades by ensuring session history isn’t rewritten by later account changes.

Adopt a practical policy: require both session evidence and live account state for sensitive operations, using a framework-generated MFA proof and a live check against the account store.

Dual checks are warranted: session evidence prevents history rewriting of authentication, while current account state enables immediate revocation if MFA is disabled or removed.