A team-wide MFA rollout needs an account list and a recovery plan as much as it needs a new sign-in setting. Start by deciding who owns the work and what counts as complete. Then move through the accounts in a deliberate order, checking that people can sign in before enforcing a requirement more widely.
CISA describes multifactor authentication as a layered approach that requires two or more ways to verify identity. It makes it harder for an attacker to enter an account even after a password is stolen. For a small team, the practical task is to apply that protection consistently while keeping legitimate access workable.
1. Inventory the accounts people actually use
Assign one person to coordinate the rollout and ask each team member to identify the services they use for work. Start with email and the tools that hold important business information. Include finance services, website administration and any account that manages access to other accounts. Ask about occasional tools as well as daily ones.
Create a working list with one row per account or manageable account group. Record the service, business owner, administrator and current MFA status. Add the enrollment method, recovery owner and a date for checking completion. Keep passwords and recovery codes out of this shared list; it is a work tracker, not a store of sign-in secrets.
- Which person can change the account’s security settings?
- Is access individual, or do several people share a login?
- Does the account belong to a current employee, a contractor or someone who has left?
- What MFA methods does the service actually offer?
- Who can help recover access if the usual device is unavailable?
Mark unanswered questions as open work. A shared login needs review with the service owner before anyone changes its sign-in process. An account whose administrator is unknown needs an owner. Do not mark either one complete merely because the team has enabled MFA on its main email system.
2. Choose methods that the team can support
Look at the options in each service’s own settings and help material. Depending on the service, choices may include security keys, passkeys, an authenticator application or another verification method. Availability and setup differ, so write instructions for the actual service instead of treating every account as identical.
NIST SP 800-63B-4 covers authentication and authenticator management, including authenticator types and assurance levels. It is a useful reference for a technical administrator assessing options according to the organization’s risk. Using it as a reference does not by itself establish that the team meets any particular assurance level.
For the rollout, document a preferred supported method and a fallback where appropriate. Check what equipment each person needs and how replacements would work. If a plan depends on an employee’s personal phone, resolve that expectation before enrollment. Staff should have a clear contact for equipment or accessibility questions.
Have the administrator review how the selected method and recovery options work together. Recovery deserves the same attention as first-time setup. Write down who may authorize a reset and how that person will verify the request. Store recovery material in a location appropriate to its sensitivity, with access limited to those who need it.
3. Start with email and administrative accounts
Use a small pilot to test the instructions before asking everyone to follow them. Include the person coordinating the rollout and an administrator who can resolve problems. Schedule a time when the participants can finish setup and test a fresh sign-in. Keep an agreed recovery route available while changing administrator access.
Email and administrative accounts are a practical first group because they are central to the team’s daily access and account management. Review the inventory to identify the specific accounts involved. Where a person has separate ordinary and administrator logins, track both. Completion of one does not settle the other.
After enrollment, ask the pilot users to sign out and sign in through the normal trusted route. Check that the expected verification step appears and that the instructions match the screen. Have the administrator confirm the account’s enrollment status using whatever management view the service provides.
Record any friction before widening the rollout. A confusing instruction is worth fixing once. An unsupported device or missing account owner needs a separate task with a responsible person. Avoid turning on a broad enforcement setting while those questions remain hidden in individual conversations.
4. Enroll everyone and rehearse recovery
Give staff a short notice explaining the change, the enrollment date and where to ask for help. Send setup instructions through a familiar internal channel. Tell people to open the service through their usual trusted route, then navigate to its settings. This also avoids training the team to follow unexpected sign-in links without checking them.
Arrange enrollment in groups small enough for the available support. Each person should complete setup, test a normal sign-in and learn how to request help. Confirm recovery arrangements before calling the account finished. Where backup authenticators or codes are supported, the administrator should explain the chosen approach and its storage requirements.
Rehearse a lost-device request as a discussion. Who does the employee contact? What information will the administrator use to verify them? Who approves any reset? The team does not need to disable a working account to discover that nobody knows the recovery contact. Update the written procedure when that discussion exposes a gap.
Include new starters and departures in the same process. A new employee’s account setup should include MFA and recovery instructions. When someone leaves, the account owner should follow the organization’s access-removal process and review any shared responsibilities. The rollout becomes useful ongoing administration when those events have named owners.
5. Check coverage against the original list
Compare the inventory with the available administrator reports and enrollment records. Separate “instructions sent,” “person says complete” and “administrator checked.” Use the strongest evidence the service provides, and label self-reported entries honestly where no central view exists. A clear exception list is more useful than an unsupported claim that everyone is covered.
For each gap, record the reason, owner and next review date. Some accounts may need a plan change or a different supported method. Others may turn out to be unused. Ask the business owner to decide how to handle those cases, and keep the decision visible until the account is resolved.
One hypothetical worked example
Imagine a six-person design office with business email, a file service and an invoicing account. Its office manager creates the inventory and discovers that the owner alone administers invoicing. The team agrees to begin with email and its administrator login, then schedule the other services after the pilot.
The pilot reveals that one employee needs an alternative to the proposed phone-based setup. The manager resolves that equipment question before enrollment day. Everyone then completes a sign-in check, and the owner records how invoicing access would be recovered. The shared tracker contains status and ownership, while recovery material stays in its designated protected location.
At the final review, the file service still has an old contractor account. The manager assigns that account to the service owner for review rather than excluding it from the list. The rollout closes when the team has checked its active accounts and documented any remaining exceptions with next actions.
Keep the inventory available for future changes and set a recurring review appropriate to the team. The next immediate step is smaller: enroll the email and admin accounts this week.