Which Business Accounts Should You Protect With MFA First?

Start with the accounts that could do the most damage if someone else signed in: administrator accounts, business email, remote access, and accounts that control payments or sensitive records. Then work through the rest of your applications and document any gaps. The goal is to require multifactor authentication (MFA) where it is supported and know how employees can regain access when a device is lost.

MFA checks more than one kind of evidence at sign-in. For example, a service might ask for a password and proof that you have an enrolled security key. NIST’s small-business guidance recommends inventorying the systems that offer MFA and prioritizing stronger protection for sensitive accounts and users with elevated privileges.

Start with accounts that can change other accounts

Make a list of people who can reset passwords, grant access, change security settings, or add administrators. Include the consoles for your business sign-in service, email, domain and website, backups, and remote support tools. An account that is rarely used can still be important if it controls a critical service.

Review your IT provider’s access as well as your own. Ask who has administrator privileges, how each person signs in, and how access is removed when responsibilities change. Where your platform supports it, use a named administrator account for administrative work and a separate account for everyday email and files.

Protect the logins employees depend on

After mapping the administrative accounts, prioritize the logins that expose the most business information or allow consequential changes. A short starting list:

• Business email and shared files: Consider who can read customer communications, access working documents, or receive password reset messages for other services.
• Remote access: Include the systems that let staff and vendors connect to company devices or internal applications from outside the office.
• Payments and sensitive records: Check banking, payroll, accounting, and any industry applications that hold confidential information. Include people who can change payment destinations or grant others access.
• Applications with their own passwords: Ask whether the service can still be entered directly even when most staff sign in through your company account.

For example, a hypothetical contractor with dispatch staff in Weatherford and estimators working remotely might protect its shared sign-in service first, then find that the separate job scheduling portal has its own administrator login. Add that login to the plan so the main sign-in policy does not give a false sense of coverage.

Choose a sign-in method people can use reliably

Ask which applications support phishing-resistant methods, such as compatible FIDO security keys or passkeys. Start there for administrators and other sensitive roles where the method fits the service and devices. Ask IT to confirm the configuration and what alternatives the service still accepts.

NIST’s authentication guidance explains why manually entered one-time codes do not count as phishing-resistant: a fake sign-in page can capture a code and relay it to the real service. If an application only offers a code-based option, document that limitation and ask the vendor about stronger options.

Plan for the people using the system. An employee who works from a shared workstation, uses an accessibility tool, or cannot use a personal phone for work may need a different approved method. For remote employees, make sure the chosen method is available before you enforce the requirement.

Plan for a lost phone or key before you enforce MFA

Decide who can verify the employee’s identity and approve recovery, how they can be contacted if email is unavailable, and how IT will remove the missing device from the account. If the service supports a backup key or recovery codes, arrange secure storage and an authorized way to retrieve them. Keep the recovery instructions separate from the secrets themselves.

Walk through the recovery process with a test account or an approved pilot. Ask what would happen if the only person who can reset staff logins were traveling or lost their own device. A workable answer should identify another authorized route and how it will be checked, without making it easy for someone to impersonate an employee.

Verify coverage with a small rollout

Pilot with people from different roles and locations. Give them a trusted enrollment link and a support contact. Verify actual sign-ins after the policy takes effect, then expand in groups. Teach staff to report an unexpected sign-in prompt through a known channel instead of approving it to make it disappear.

Track the application, account owner, accepted sign-in methods, whether MFA is required, and the next action for any exception. Enrollment and enforcement are separate questions: seeing a registered method does not tell you whether the service requires it on all intended sign-in routes. Review the gaps in your monthly IT report and include enrollment in your onboarding process and access removal in your offboarding checklist.

Make the first conversation specific

Ask your managed IT provider to name the accounts it would protect first, explain how employees recover access, and show how coverage will be checked. For businesses in Fort Worth, Weatherford, West DFW, or working remotely across the U.S., IronLink IT’s free Business IT Review is a 20-minute conversation with a one-page summary of three priorities. No logins, scans, or system access are required.