For a small team, phishing-resistant MFA and a tested recovery route belong in the same account-protection plan. Start with email, domain registration, and administrator accounts. Use supported phishing-resistant authentication where available, then check how an authorized colleague would recover access if the normal device were lost.
October is a useful point in the calendar to review accounts. The most revealing question is often ordinary: if the owner’s phone disappeared this afternoon, who could still renew the domain, access business email, or stop a compromised integration?
Why “MFA enabled” is not the whole answer
NIST SP 800-63B-4 distinguishes phishing-resistant authentication from methods that rely on manually entered codes. A code can be relayed through an impostor site; a cryptographic authentication method can bind the response to the legitimate verifier. This distinction does not mean that every MFA deployment is equivalent.
The FIDO Alliance’s passkey guidance explains public-key authentication and passkeys. Some passkeys sync through a provider; others remain device-bound. Availability, recovery behavior, and organizational controls depend on the service and deployment. A passkey is not a promise against every attack, including compromised devices or stolen sessions.
Make a short list of accounts that can stop the business
Do not begin by collecting everyone’s passwords. Record account names, service owners, authentication methods, recovery ownership, and the date of the last check. Keep credentials and recovery material in approved secure storage, separate from this working inventory.
- Business email: it often receives reset messages for other services.
- Domain registrar and DNS: control here can affect the website and email.
- Cloud hosting and administrator accounts: these can change systems or access.
- CRM and customer-support tools: these hold customer conversations and operational records.
- Advertising and social accounts: these can spend money or publish in the business’s name.
Choose priorities by consequence, not by how often a service is used. An account opened only once a year can still be the one that keeps the business online.
Separate everyday access from recovery authority
Where supported, give authorized staff individual accounts and the least access needed. Avoid making a shared owner login the default way to work. Check whether the provider allows multiple registered authenticators or a second authorized administrator, and document who approves their use.
For each critical service, answer three questions: what can restore access, who can use that route, and where the instructions can be found if email is unavailable? A recovery document stored only inside the locked account does not help during the lockout.
NIST describes several recovery mechanisms, including saved codes, recovery contacts, and identity proofing. Its guidance also treats recovery notification as a control. These are useful reference points; the publication is not a blanket legal requirement for every small business.
Run a recovery rehearsal without creating an outage
- Pick one service. Read its current recovery documentation and identify the authorized owner.
- Check access to the instructions. An approved backup person should be able to find them without borrowing the owner’s unlocked device.
- Verify registered methods. Confirm that backup authenticators or recovery contacts are current using the provider’s supported controls.
- Use a safe test route. Prefer a test account or a documented non-disruptive check. Do not deliberately lock out a production administrator.
- Record the result. Note what was verified, what remains untested, and who will close the gap.
If a recovery code is actually consumed, follow the provider’s replacement procedure. Never paste codes into tickets, chat threads, screenshots, or this inventory. A rehearsal record should show that recovery works without exposing the means to recover the account.
Include joiners, leavers, and connected AI tools
When someone changes roles or leaves, review their account access, enrolled devices, recovery contacts, and connected applications. Removing one login may leave an integration token active. Likewise, a newly connected AI tool can create a separate route into business data that MFA on the human account does not fully describe.
Our small-team AI inventory guide is a useful companion for recording those connections. Keep account recovery and tool permissions in the same operational review, while storing secrets only in the approved system.
A realistic first outcome
A useful first review ends with a prioritized account list, known authentication methods, named recovery owners, and one safely verified recovery route. It does not end with a claim that the business is “phishing-proof.” Repeat the review when people, devices, or service settings change.
Source and scope note: NIST and FIDO materials were reviewed on October 2, 2026. The inventory and rehearsal sequence are Opslumo recommendations. Follow each service’s current supported recovery process.