Most businesses can say they use multi-factor authentication. Far fewer can say where it is not turned on. The first rollout usually covers email and maybe the remote access connection, then attention moves elsewhere, and a year later an accounting portal, a remote management console, and a handful of shared accounts are still protected by a password alone. Attackers do not need every door open. They need one.
“Every business system” is the hard part of the job, and it is mostly a project management problem rather than a technology problem. The steps below follow the order that tends to work: find everything, pick the right method for each type of account, roll out in phases, support people through the change, and keep exceptions from piling up.
Start With an Inventory, Not a Tool
Enabling a tool before knowing what needs protecting is how coverage gaps get built in. A useful inventory goes well beyond the applications the IT team set up personally. It should include:
- Email and productivity suites, including every mailbox and shared mailbox
- Remote access, VPN, and any remote management or support tools
- Administrator and privileged accounts for servers, firewalls, and cloud platforms
- Line-of-business applications such as accounting, payroll, CRM, and case or practice management
- Vendor and partner portals where staff sign in with company credentials
- Backup consoles, domain registrar accounts, and DNS management
- Social media and marketing platforms that can damage a brand if taken over
The accounts people forget are often the ones that matter most. Logins for former employees that were never disabled, accounts created for a one-off project, and vendor portals set up by someone who has since left all tend to surface during discovery. Many businesses lean on IT security services Denver teams or similar outside providers to run that discovery, because sign-in logs and identity reports reveal accounts that no one remembers creating.
Choose the Method to Fit the Risk
Not every second step provides the same protection, and the differences matter most for the accounts attackers want badly. A quick comparison helps set a standard before anyone starts enrolling users.
| Method | Strengths | Watch-Outs | Best Fit |
| Authenticator app with number matching | Blocks stolen-password logins, easy for most staff | Weaker if users approve prompts without reading them | Default for most employees |
| One-time codes from an authenticator app | Works without a data connection | Codes can be typed into a convincing fake login page | Backup option |
| Text message codes | Simple, nothing to install | Exposed to SIM swapping and interception | Temporary fallback only |
| Hardware security keys and passkeys | Resist phishing because they verify the real site | Cost to distribute, needs a lost-key process | Administrators, finance, executives |
A practical approach is to set tiers. Privileged and finance accounts get the strongest method available, everyone else gets an authenticator app, and text messages are allowed only as a short-term fallback with a date attached for retiring them.
Roll Out in Phases
Trying to flip every system at once overloads the help desk and gives users a bad first impression. A phased order keeps risk falling from the first week while the process gets smoother.
- Administrators and privileged accounts. These carry the most damage if taken over, and the group is small enough to support closely.
- Email and remote access. Stolen mailbox logins and remote connections are two of the most common ways in, so they come next.
- Everyone else and line-of-business applications. Work through applications in order of how sensitive the data is, not alphabetically.
- The stragglers. This phase is where most programs stall, so it deserves its own plan.
The stragglers are usually older mail connection methods, service accounts, and shared logins. Older mail protocols that cannot prompt for a second step can let a password work on its own even when multi-factor authentication is enabled elsewhere, so they should be blocked once the business confirms nothing depends on them. Service accounts used by software cannot answer a prompt, so they need tightly limited permissions, long random credentials, restricted sign-in locations, and monitoring. Shared logins are best replaced with individual accounts or delegated access, because a shared account means nobody can say who actually signed in.
Prepare People Before Flipping the Switch
Technology rarely derails a rollout. Surprise does. Employees who learn about a new login step on the morning it starts tend to assume something is broken, and they call the help desk or look for ways around it.
A short notice explaining why the change is happening, what users will see, how to enroll, and who to contact goes a long way. Enrollment sessions or a one-page guide with screenshots reduce the volume of questions further. Plan for lost and replaced phones in advance, with a documented identity check before anyone resets a second step. Attackers know the reset process is often the weakest point, and a rushed help desk call is where they tend to try.
Teach one habit above all: never approve a prompt you did not trigger, and report it right away. Requiring number matching makes blind approval harder, and reporting turns an annoying prompt into an early warning that someone has the password.
Questions to Confirm Coverage Is Real
- Can the business produce a list of every system and whether multi-factor authentication is enforced on it?
- Are older sign-in methods that skip the second step blocked?
- What happens when someone loses a phone, and who verifies the request?
- Are service and shared accounts documented, with extra controls around them?
- Does every new application require multi-factor authentication before it goes live?
Keep Exceptions From Eroding the Program
Exceptions are inevitable. A specialized device cannot support a prompt, a vendor requires a shared login, or an executive complains loudly. The danger is exceptions with no end date. Each one should be approved by a named person, documented, given an expiry, and paired with a compensating control such as network restrictions or extra monitoring.
Keep a small number of emergency administrator accounts in case the normal sign-in process fails. Protect them with strong credentials stored separately, test them on a schedule, and set alerts so any use is noticed immediately. Then review coverage on a regular cycle. Pull sign-in reports for accounts without a second step, check for newly added applications, and confirm that offboarding removes devices and methods along with access.
Coverage Is Something to Measure
A multi-factor authentication rollout is not a single switch that gets flipped and forgotten. The businesses that stay protected treat coverage as a number they track: how many accounts, how many systems, how many exceptions, and how that picture changes every quarter. When the answer to “where is it not turned on” is a short, documented list rather than a shrug, the program is doing its job.