Audit the whole authentication path, not one login screen
A strong-looking login screen does not describe the whole authentication mechanism. Account access also depends on how a factor is enrolled, how the service verifies routine login, when it asks again before a sensitive change, how long sessions continue, how recovery works, and how a lost factor is replaced. Build an authentication-path map with seven columns: enrollment, routine login, added verification, sensitive-action recheck, session control, recovery, and retirement or replacement. For each column record the authenticator, who verifies it, which channel carries the prompt, what the user sees, what fallback exists, and what observable result confirms completion. This separates account authentication from a local phone unlock and reveals when a convenient method silently falls back to a weaker path.
Name every role, factor, and entry point
Start with the account identifier, credential service or identity provider, verifier, companion app, registered authenticators, recovery contacts, trusted devices and active sessions. NIST's digital identity model treats proofing, authenticators, verifiers, federation and sessions as related but distinct functions. A password is something known; a registered device or cryptographic key is something held; a fingerprint can activate an authenticator on a device without becoming a remote account credential by itself. Record what the current product actually offers instead of assigning a security label from its icon. Include web login, mobile app, third-party sign-in, password reset, device approval and support-assisted recovery. Unknown paths remain unknown until current official documentation or a controlled test answers them.
Compare routine login with sensitive-action checks
List the actions that change account control: adding or removing an authenticator, changing recovery email, exporting data, disabling added verification, linking an external identity, viewing recovery codes, deleting the account or signing out all sessions. Check whether the app requests fresh authentication before each supported action and which factor it accepts. OWASP's authentication guidance treats reauthentication for sensitive changes, recovery and session handling as separate controls. A phone already unlocked five minutes ago is not evidence that an account-control change was freshly verified. Use harmless settings and your own account; do not repeatedly trigger recovery or lockout. Record the exact prompt, destination, factor used, cancellation behavior and whether other sessions received any visible change.
Inspect authenticator properties without reducing them to a ranking
For every offered method, note enrollment prerequisites, device binding, synchronization, backup, phishing resistance, user verification, replacement and revocation. NIST explains that passwords are not phishing-resistant and that manually entered one-time outputs are not considered phishing-resistant because an impostor verifier can relay them. Some cryptographic authenticators bind an output to a verifier name or protected channel. This does not make one method a universal answer: availability, supported devices, recovery and shared-device boundaries still matter. CISA recommends MFA where available, but two prompts are useful only when they are genuinely distinct and the fallback is not an unexplained bypass. Record the method's documented property, not a marketing adjective such as advanced or secure.
Trace sessions and recovery as separate state machines
After successful authentication, a session may remain valid until expiry, sign-out, risk event or server-side revocation. Recovery may establish a new authenticator, reset a password, restore a federated entry or involve support. Draw both sequences step by step. Test whether signing out one device affects another, whether changing a factor closes old sessions, and whether the session list distinguishes browser profiles from physical devices. Then inspect recovery prerequisites and notifications without completing unnecessary resets. A recovery mailbox that is no longer controlled, a phone number about to be retired or a backup code stored in ordinary notes can undermine an otherwise careful login path. Never place credentials, temporary codes, recovery links or exact private answers in the audit record.
Run three bounded transition tests
First, perform a routine sign-in on a device you control and record factor, prompt origin, resulting session and visible account identity. Second, open a harmless sensitive setting, cancel at the fresh-verification prompt and confirm the setting and sessions remain unchanged. Third, add or replace a nonessential authenticator only if the service documents a reversible path; verify it once, then remove the test factor and confirm it no longer works. If replacement is not safely reversible, inspect rather than execute it. Record app version, device, timestamp, expected state, observed state and unresolved questions. A passed test covers only that path and version; it does not establish invisible server behavior.
Decide using the weakest transition, not the strongest screenshot
Summarize each path as intended, observed, unavailable or unknown. A polished passkey prompt does not compensate for recovery that accepts an old mailbox without a second check. MFA on routine login does not answer whether factor removal asks for fresh verification. A complete checklist should show at least one maintained recovery route, a way to review or close sessions, clear notices for account-control changes, and a documented method to retire lost authenticators. If a crucial path is unknown, avoid placing highly sensitive material in the account while seeking current official support. Revisit the map after changing the main device, recovery contact, identity provider, authenticator type or app version—not on a schedule that adds activity without new evidence.
Common questions
Is an app lock the same as account authentication?
No. A local lock can gate one device while remote account sessions and recovery follow separate controls.
Does MFA automatically make every account change safer?
Not automatically. Check which factors protect routine login, recovery, factor removal and sensitive changes.
Should I test account recovery repeatedly?
No. Inspect prerequisites and perform only a bounded, documented test when the service provides a safe reversible route.