Short answer: Ask which accounts use phishing-resistant authentication, which fallback methods remain, and who can recover access when a device disappears. “We have MFA” is the start of the conversation. It is a lousy place to end it.
The checkbox is doing too much work
October is a good time to ask a less comfortable security question: what happens after someone types their credentials into a convincing fake login page?
NIST distinguishes phishing-resistant authentication from methods that rely on people spotting an impostor. Manually entered one-time codes do not provide that protection. A founder does not need to memorize authentication standards. You do need to stop treating every second step as the same security control. NIST authentication guidance
The UK's NCSC recommends prioritizing passkeys for important business accounts where available. It also advises strong, unique passwords and two-step verification where passwords remain. This is a practical improvement project, not permission to leave an unsupported service unprotected while you shop for perfection. NCSC small organisation guidance
Start where a stolen account hurts
For your next technical meeting, ask for one page covering email administration, cloud administration, code hosting, domain registration, payroll and your identity provider. Add the systems your business actually depends on.
Give each system five columns: business owner, administrators, allowed sign-in methods, recovery method and last tested date. Include contractors. If the answer is “Dave probably knows,” you have found the first action item.
Do not collect passwords, recovery codes or private keys in that document. Record where approved recovery material is controlled and who is authorized to use it. An access inventory should not become a handy welcome packet for an attacker.
Pilot before the grand announcement
Pick one important service and a small group of users. Confirm which supported phishing-resistant option fits your devices and identity platform. Agree on an owner, a support route and a way to recover from a failed enrollment before changing enforcement.
Test normal sign-in, a replacement device and the departure of someone with administrative access. Check that the policy applies to the accounts and applications you meant to protect. Ask the team to show the result, not merely the purchase receipt.
Then expand in manageable groups. Keep exceptions visible with an owner, a reason and a review date. “Temporary” without a date is just permanent wearing a fake mustache.
Recovery deserves its own meeting
A stronger front door does not help if the forgotten side entrance still works. Ask which alternate methods, help-desk resets and emergency accounts can restore access. Review those paths with the same care as everyday sign-in.
Run a controlled lost-device exercise with a test account. Time how long it takes, record who approves recovery, and check what evidence they require. Protect the business from both account takeover and accidental lockout. Follow your provider's supported recovery procedure; do not improvise on the only production administrator.
This week's assignment
Choose three critical services. Name the owner of each. Demonstrate the current sign-in and recovery process using approved test accounts. Bring back the coverage gaps, one pilot proposal and a date to review the outcome.
That is a useful leadership decision. “Everybody has an authenticator app” is a sentence that needs follow-up questions.
Straight answers
Are all MFA methods phishing-resistant?
No. NIST's authentication guidance distinguishes phishing-resistant protocols from methods such as manually entered one-time codes. Ask which methods your actual service permits, including alternatives and recovery paths.
Should we switch every account at once?
Start with a controlled pilot and a tested recovery process. Prioritize critical accounts, confirm device and service support, then expand with named owners and documented exceptions.
Need a straight answer about access risk?
Take the Frickin Assessment or bring the problem. A useful plan names the next action and the person responsible for it.