Multi-factor authentication, or MFA, combines different kinds of proof that a person is allowed to sign in. A password plus a code is one example. A properly configured passwordless method can also satisfy MFA. For a small business, the rollout needs to cover everyday sign-in, lost devices, administrative access, and the applications employees depend on.
Choose the verification method deliberately
A code or approval prompt adds protection, but it can still be phished. FIDO2 passkeys and security keys provide phishing-resistant authentication when supported and correctly configured. An authenticator app may offer several methods; an app-generated code and a passkey in that same app do not offer identical protection.
Choose methods your platform supports, then test them with the devices and workflows your team uses. Give administrators and other high-consequence accounts priority when moving to phishing-resistant sign-in.
| Method | What to understand |
|---|---|
| Text or voice code | Can add a factor to a password; not phishing-resistant. Review whether a stronger supported method is practical. |
| Authenticator code or push approval | Adds verification, but codes and ordinary approval prompts remain vulnerable to phishing. Check which mode the app is using. |
| FIDO2 passkey or security key | Phishing-resistant. Check device compatibility, enrollment, recovery, and the platform's policy requirements. |
Protect the accounts with the largest consequences first
Begin with administrative accounts, email, financial platforms, payroll, cloud storage, remote access, and password-management systems. A compromise in one of these areas can lead to broader access, payment fraud, data exposure, or account recovery problems across the business.
Keep an inventory of human accounts, automated integrations, and emergency administrative access. They serve different purposes and should not all receive the same sign-in rules. For each, identify the owner, permissions, dependencies, and supported protection before changing policy.
- Global and tenant administrators
- Email and cloud-storage accounts
- Banking, payroll, and accounting systems
- Remote access and VPN accounts
- Domain, DNS, and website administration
Handle emergency access and automation separately
An emergency administrator account must remain usable when normal administrative access fails. Microsoft Entra's guidance calls for strong, phishing-resistant emergency access, controlled storage, monitoring, and regular validation. It also identifies specific Conditional Access exclusions needed for that recovery design. This is a planned recovery arrangement, not a blanket instruction to remove authentication protection.
Automated services may not be able to answer a human sign-in prompt. Review each integration's supported identity and credential model with its vendor, use only the permissions it needs, and assign an owner to credential changes. Do not turn an unexplained automation failure into a permanent exception for ordinary user accounts.
Prepare recovery before enforcement
The rollout is incomplete if nobody knows what happens when a phone is lost, replaced, or unavailable. Record at least two approved verification or recovery methods where the platform allows it. Store emergency recovery codes securely, and make sure the person approving a reset can verify the employee's identity.
Avoid tying the entire recovery process to one administrator's personal device. The business should retain administrative ownership and have a second authorized path for urgent recovery. Test that path before enforcing MFA across everyone.
Roll it out in a sequence employees can follow
A short pilot catches problems before they affect the whole team. Start with administrators and a small group using the same devices and applications as everyone else. Confirm enrollment, daily sign-in, mobile access, shared workstations, travel scenarios, and account recovery. Then expand in manageable groups.
Tell employees what will change, when it will happen, which app or device they need, and where to get help. A five-minute explanation prevents many failed enrollments. Set a deadline, but leave enough time to resolve people who are traveling, changing phones, or using unusual workflows.
Confirm that the policy is actually enforced
Enrollment reports can create false confidence. An employee may have registered a method while older protocols, legacy applications, or excluded locations still allow password-only access. Review the policy itself, its exclusions, and sign-in logs after rollout.
Keep MFA alongside unique passwords where passwords remain in use, protected administrator accounts, device encryption, timely account removal, reliable backups, and user awareness. Confirm the intended protection with a test account and sign-in evidence rather than assuming every enrolled user is covered.
Related case studies
Continue reading
Sources and further reading
These references support the technical details or service terms above. Check the current documentation when planning a change.