Start your MFA rollout with business email, administrator accounts, and remote access. A stolen password to one of those systems can give an attacker access to other accounts or sensitive work. Then extend coverage to the remaining applications that support it.
Multi-factor authentication checks more than one type of evidence when someone signs in. A password plus possession of an enrolled authenticator is one example. Two passwords are not two independent factors. NIST’s authenticator guidance distinguishes authentication factors and describes phishing resistance.
Choose the method deliberately
Methods differ in both usability and resistance to attack. CISA recommends planning a move to phishing-resistant MFA. For supported services, consider options such as FIDO security keys or passkeys under a policy that matches your account and device needs.
Authenticator codes and push prompts can still improve on password-only access, but they can be tricked or intercepted in some attacks. Do not tell staff that any second factor makes phishing impossible. If you use push approval, teach people to reject unexpected prompts and report repeated requests.
Availability varies by application and account plan. Record the supported methods before choosing a company-wide standard.
Inventory the accounts first
Build a short list with the application owner, account type, MFA method, and enforcement status. Include:
- Email and the identity provider used to recover other accounts.
- Administrator access to cloud services, hosting, and domain registration.
- Remote access and business applications.
- Contractors and guest users, where your organization controls their access.
- Recovery accounts and any exceptions.
Service accounts and automated jobs may need a workload identity or another application-supported authentication method. Do not enroll them as if a person will be available to approve a prompt at every run.
Prepare recovery before enforcement
Decide how someone proves their identity after losing a phone or security key. Where supported, enroll a suitable backup method and store recovery material under controlled access.
Help-desk staff need a documented verification process. An urgent caller should not be able to bypass MFA simply by knowing an employee's name. Emergency administrator access also needs a separate, monitored procedure.
Pilot, then expand
Choose a small group representing office staff, remote users, and administrators. Test enrollment, normal sign-in, device replacement, and account recovery. Include any older software that signs in without a modern browser.
After the pilot, give the next group clear enrollment instructions and a support contact. Schedule enforcement so someone can resolve access problems. Confirm the policy actually applies to the intended accounts; enrollment alone does not prove that MFA is required.
Check the remaining gaps
Review sign-in records, exceptions, and recovery changes. Remove obsolete access methods where the service supports it, and investigate unfamiliar devices or repeated failed prompts.
MFA does not remove excessive permissions, patch devices, or stop every form of session theft. Combine it with regular access reviews and clear rules for delegated access.