You are sitting in your Connecticut office when an employee calls.
“I keep getting login approval requests,” they say. “I must have clicked something by accident. Should I just approve one so they stop?”
That moment is where a small inconvenience can become a major incident.
An attacker may already have the employee’s password. They may be testing whether repeated MFA prompts will eventually wear the person down. Or they may be calling the help desk and pretending to be the employee who needs a password reset.
Multifactor authentication is still one of the highest-leverage security improvements an SMB can make. It can block many account takeover attempts even after a password has been stolen. But MFA is not a single checkbox that makes an organization secure.
The details matter.
A weak MFA method, an unprotected VPN, an overlooked service account, or an untrained help-desk employee can leave a gap attackers know how to exploit.
That is the focus of this article. During Cybersecurity Awareness Month, we are looking at seven common MFA mistakes Connecticut small and midsize businesses make, and the practical steps you can take to fix them.
CISA’s 2026 theme is “Securing the Next 250.” The National Cybersecurity Alliance is using a complementary message: “Don’t Make It Easy For Them.”
For a law firm in Hartford, a dental practice in New Haven, an accounting firm in Stamford, or a nonprofit serving communities across Connecticut, those messages are practical advice:
Make the easiest path into your business harder to use. Start with MFA, then verify that it is configured correctly everywhere it matters.
Why MFA should be a priority for Connecticut SMBs
Passwords remain one of the most common ways attackers get started. They are stolen through phishing, malware, password reuse, data breaches, infostealers, and social engineering.
The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation became the leading known initial access vector, appearing in 31% of breaches. CISA's Scattered Spider advisory, Microsoft's SMS and voice retirement guidance, and NIST SP 800-63B provide further detail on these threats and standards throughout this article. Credential abuse was identified as the initial vector in 13% of breaches, but credential abuse remained pervasive throughout the attack chain, appearing in 39% of breaches overall.
That distinction matters. Attackers may enter through an unpatched system, but stolen credentials often help them move through the environment, access cloud services, reach sensitive files, or take over administrator accounts.
Multifactor authentication (MFA) strengthens account security by requiring two or more distinct authentication factors. This can involve a password combined with another factor, or passwordless authentication using a cryptographic credential protected by a PIN or biometric verification.
Authentication factors generally fall into three categories:
- Something you know, such as a password or PIN.
- Something you have, such as an authenticator app, smartphone, or hardware security key.
- Something you are, such as a fingerprint or facial recognition, generally used together with a device or authenticator.
A time-based one-time password generated by an authenticator app is typically a possession-based factor, even though the user manually enters the resulting code. These categories follow the guidance in NIST SP 800-63B.
The strongest MFA methods make it much harder for an attacker to impersonate the legitimate user. The weakest methods can still be bypassed through phone-number theft, phishing, or human manipulation.
Here are seven mistakes to look for in your environment.
Mistake #1: Treating SMS codes as strong MFA
Many businesses say, “We have MFA enabled,” when what they really mean is, “We send a six-digit code by text message.”
That is better than password-only access. But it should not be treated as the long-term security standard for important accounts.
SMS codes are vulnerable to SIM swapping. In a SIM-swap attack, a criminal convinces a mobile carrier to transfer a victim’s phone number to a SIM card controlled by the attacker. Once that happens, text-based login codes may go directly to the criminal.
SMS codes are also vulnerable to phishing. An attacker can create a fake Microsoft 365, Google Workspace, payroll, banking, or VPN login page and ask the user to enter both their password and their texted MFA code.
CISA ranks text and email codes among the weakest common MFA methods. Microsoft is also moving away from native SMS and voice authentication in Microsoft Entra ID. Beginning September 1, 2026, Microsoft Entra ID started automatically enabling passkeys and encouraging registration for users configured for SMS or voice authentication. Microsoft-provided SMS and voice authentication will be retired on February 1, 2027, for most users, followed by Global Administrators and external users on July 1, 2027. Organizations that have a legitimate need to retain SMS or voice authentication may use supported third-party telephony providers. Microsoft recommends transitioning to phishing-resistant authentication methods such as passkeys whenever possible.
How to fix it
Create a migration plan rather than waiting for a forced change.
For general users, move from SMS to:
- An authenticator app using number matching.
- Time-based one-time passwords from an authenticator app.
- Passkeys supported by the user’s device.
- Windows Hello for Business.
- FIDO2 security keys for higher-risk users.
Reserve SMS for limited fallback situations where stronger methods are genuinely unavailable. Document those exceptions and review them regularly.
Also teach employees one simple rule:
Never approve an unexpected MFA request and never share an MFA code with someone who calls or messages you.
A legitimate IT provider should not need your one-time code to “verify” your account.
Mistake #2: Using push notifications without protecting against MFA fatigue
Push-based MFA can be convenient. A user receives a notification and taps “Approve.”
The problem is that attackers can abuse the same convenience.
In an MFA fatigue attack, sometimes called push bombing, the attacker repeatedly attempts to log in using a stolen password. Each attempt generates another approval request on the employee’s phone.
The attacker hopes the employee will eventually:
- Approve the request by mistake.
- Approve it to make the notifications stop.
- Assume the requests are a technical glitch.
- Approve it after receiving a convincing phone call from someone pretending to be IT.
These social-engineering risks gained widespread attention following the 2023 cyberattacks involving MGM Resorts and Caesars Entertainment. Attackers associated with Scattered Spider, as described in CISA's advisory updated in 2025, have used techniques including help-desk impersonation, credential theft, MFA manipulation, SIM swaps, and repeated authentication prompts. The incidents illustrate why employee training and strong identity-verification procedures are essential.
How to fix it
If you use push authentication, enable number matching wherever the platform supports it. Number matching requires the user to enter a number displayed on the login screen instead of simply tapping "Approve." Microsoft Authenticator already enforces number matching in its supported push authentication flows, so most Microsoft 365 environments have this protection by default, but other platforms may still need it turned on.
Then add policies around unexpected prompts:
- Employees should deny any prompt they did not initiate.
- Employees should report repeated prompts immediately.
- IT should investigate repeated prompts instead of simply telling the user to ignore them.
- Administrators should be alerted when a high-risk account generates multiple failed MFA attempts.
- Push approvals should not be the preferred method for privileged accounts.
Number matching is a useful improvement, but it is not the final destination. A sophisticated attacker may still use social engineering to persuade a user to enter the displayed number.
For administrators, finance employees, and people with access to sensitive client or patient information, use phishing-resistant MFA wherever possible.
Mistake #3: Not using phishing-resistant MFA for administrators and finance users
Not all MFA methods resist phishing.
A phishing-resistant method verifies more than the code or approval. It verifies that the user is authenticating to the legitimate website or application.
The most common examples are:
- FIDO2 security keys, such as a hardware key that plugs into or taps a device.
- Passkeys, which use cryptographic credentials stored on a device, password manager, or security key.
- Windows Hello for Business, when properly configured.
A passkey does not work like a password copied into a box. It uses a cryptographic key pair. The private key stays protected on the user’s device or security key, while the public key is registered with the service.
This makes passkeys resistant to phishing, replay attacks, and SIM swapping.
By contrast, an attacker-in-the-middle phishing kit, often described as an Evilginx-style kit, can sit between a user and a legitimate login service. The victim sees a convincing page. The attacker relays the login in real time and may capture the password, session cookie, or MFA response.
A security key or passkey is much harder for the attacker to relay because it is bound to the legitimate website or domain.
How to fix it
Start with your highest-impact accounts:
- Microsoft 365 or Google Workspace administrators.
- Domain administrators.
- Accounting and payroll administrators.
- Banking and payment portal users.
- Employees who can approve wire transfers or change vendor payment information.
- VPN and remote-access administrators.
- Users who manage electronic health records or other regulated systems.
- Employees with access to large volumes of legal, financial, or personal information.
Give these users two phishing-resistant methods where practical. For example, a primary passkey plus a backup FIDO2 security key.
Require stronger authentication for sensitive actions, not just the initial login. Where an application supports it, changing a bank account, creating a new administrator, exporting client data, or registering a new MFA device should require additional verification.
A Connecticut accounting firm may not have a large security department, but it can still protect the small number of people who control tax records, payroll, client portals, and financial systems.
The goal is not to make every employee use the most expensive security hardware on day one. The goal is to apply the strongest controls where one compromised account could cause the most damage.
Mistake #4: Leaving legacy protocols and service accounts outside MFA
An MFA rollout often looks complete from the user’s perspective while older systems remain unprotected.
Common examples include:
- Legacy email protocols such as older IMAP or POP configurations.
- Basic authentication used by outdated applications.
- Older VPN configurations.
- Remote Desktop or remote-management tools.
- Shared administrator accounts.
- Service accounts marked “MFA exempt.”
- Automated applications using stored passwords.
- Vendor accounts that were created years ago and never reviewed.
Attackers actively look for these gaps. If modern sign-in requires MFA but an old protocol still accepts a password, the old protocol may become the easiest way in.
Legacy authentication methods remain a security risk when systems still accept passwords without modern authentication controls. Although Microsoft has retired Basic authentication for Exchange Online POP and IMAP access, businesses should review older applications, on-premises mail servers, VPNs, remote-access platforms, and third-party services that may still permit password-only authentication. The objective is to eliminate authentication paths that bypass modern security requirements, not necessarily to eliminate every older protocol.
Service accounts create a different challenge. They may not support interactive MFA, but leaving them permanently exempt is not a security strategy. A compromised service-account password can provide persistent access without generating the same user-facing warning as a normal login.
How to fix it
Begin with an account and authentication inventory.
For every account, record:
- Who owns it.
- What system it accesses.
- Whether it is interactive or non-interactive.
- What permissions it has.
- Whether it is still needed.
- Whether it has MFA.
- When its credentials were last rotated.
- What happens when the responsible employee leaves.
Then:
- Disable legacy authentication where possible.
- Replace shared accounts with named accounts.
- Reduce service-account permissions to the minimum required.
- Use managed identities, certificates, workload identities, or other modern alternatives when supported.
- Rotate service-account secrets on a documented schedule.
- Alert on interactive login attempts involving service accounts.
- Remove accounts that no longer have a business purpose.
Do not accept “the application cannot use MFA” as the end of the conversation. It should trigger a design review, compensating controls, or a replacement plan.
Mistake #5: Turning on MFA without conditional access
MFA answers an important question:
Can this person prove they control a second factor?
Conditional access asks additional questions:
- Is the sign-in coming from an approved device?
- Is the device managed and encrypted?
- Is the location unusual?
- Is the user traveling unexpectedly?
- Is the IP address associated with a suspicious network?
- Is the application high-risk?
- Is the request coming from an outdated operating system?
- Is the user attempting an impossible or highly unusual login?
Without conditional access, MFA may be required equally for a normal login from a managed office laptop and a suspicious login from an unfamiliar device halfway around the world.
Location policies are not perfect. Attackers can use VPNs, residential proxies, and compromised devices. But conditional access adds useful friction and context. It can require stronger authentication, block risky sign-ins, or prevent access from unmanaged devices.
How to fix it
Work with your IT team or managed service provider to create policies that reflect how your business actually operates.
In Microsoft 365 environments, advanced Conditional Access policies require appropriate licensing. Microsoft 365 Business Premium includes Entra ID P1 capabilities, while automated risk-based policies generally require Entra ID P2. Businesses without these licenses can still improve security with available baseline features, including Security Defaults, while evaluating whether advanced policies are appropriate.
A practical starting point might include:
- Require MFA for supported cloud applications and remote-access systems.
- Require compliant or managed devices for sensitive cloud applications.
- Block outdated authentication protocols.
- Require phishing-resistant MFA for administrators.
- Block sign-ins from countries where your business has no employees or customers, after reviewing legitimate travel needs.
- Require additional verification for risky sign-ins.
- Limit administrative access to approved devices.
- Prevent downloads of sensitive files to unmanaged devices.
- Require a secure VPN or zero-trust access path for internal applications.
Be careful with broad location blocking. A Connecticut employee may travel to New York, Massachusetts, or another state for work. A rigid policy that blocks legitimate travel can lead to workarounds.
Conditional access should reduce risk without encouraging employees to bypass security.
Mistake #6: Protecting email but forgetting SaaS, remote access, VPNs, and third parties
Many SMBs enable MFA for Microsoft 365 or Google Workspace and consider the project complete.
But business access is spread across dozens of systems:
- Payroll.
- Accounting.
- Customer relationship management.
- Electronic health records.
- Legal case-management platforms.
- Cloud file storage.
- Design and project-management tools.
- Payment processors.
- Insurance portals.
- Vendor portals.
- Remote desktop tools.
- Backup platforms.
- VPNs.
- Managed service provider portals.
A Connecticut dental practice might protect email while leaving its practice-management platform or imaging system behind a shared password.
A law firm may use MFA for Microsoft 365 but forget its document-management platform.
A nonprofit may secure its main office while a fundraising or payment platform is managed by an outside volunteer using an account that nobody reviews.
Third-party risk is especially important because your vendor’s account may connect directly to your environment or contain your data.
How to fix it
Create a list of every application that stores, processes, or provides access to business information. Include systems used by contractors and external vendors.
Prioritize MFA for:
- Email and identity management.
- Remote access and VPN.
- Financial and payroll systems.
- Backup and disaster-recovery consoles.
- Cloud file storage.
- Regulated applications.
- Administrative and domain-management tools.
- Security, monitoring, and remote-management systems.
- Customer and patient portals.
- Third-party applications with access to internal data.
For each application, ask:
- Does it support MFA?
- Does it support SSO?
- Does it support security keys or passkeys?
- Are former employees still listed?
- Are vendor accounts named and time-limited?
- Can administrators review sign-in activity?
- Can access be restricted to managed devices?
MFA must follow the data and the access path, not just the company’s primary email platform.
Mistake #7: Treating MFA as a one-time rollout instead of an ongoing process
MFA fails in two directions when it is treated as a one-time project.
First, employees may not understand what they are being asked to approve. Second, the business may not have a safe process for enrollment, recovery, offboarding, or monitoring.
That creates two dangerous conditions:
- Employees approve malicious prompts because they were never trained.
- Help-desk staff reset MFA too easily because there is no documented identity-verification process.
The second risk is growing. Help-desk vishing attacks involve an attacker calling or messaging support and pretending to be an employee who lost a phone, replaced a device, or cannot sign in.
CISA’s Scattered Spider advisory describes attackers posing as employees to persuade help-desk staff to reset passwords or transfer MFA tokens. A helpful support process can become an attacker’s shortcut if it relies only on information that can be found online or stolen from previous breaches.
How to fix it
Build MFA into the employee lifecycle.
During enrollment
- Give employees clear instructions before enrollment begins.
- Explain what a legitimate MFA prompt looks like.
- Demonstrate how to deny and report an unexpected prompt.
- Require enrollment from a trusted, verified session.
- Register a backup authentication method.
- Record who owns each administrator account and security key.
During recovery
Use an identity-verification process that does not rely solely on the caller’s name, username, phone number, or personal information.
Consider requiring:
- A callback to a verified number already on file.
- Manager approval for higher-risk accounts.
- Confirmation through a separate trusted channel.
- A temporary, limited recovery code.
- A second administrator to approve changes.
- Documentation of who requested the reset and why.
Never let a caller pressure staff into bypassing the process because the situation is “urgent.”
During offboarding
- Disable the user account promptly.
- Revoke active sessions and tokens.
- Remove registered authentication devices.
- Transfer ownership of files and applications.
- Rotate shared or service credentials the employee could access.
- Review administrator and vendor access.
- Confirm that backup, payroll, banking, and SaaS permissions were removed.
During training
Security awareness training should cover more than email phishing. Include:
- MFA fatigue.
- Fake IT-support calls.
- Suspicious Teams or chat messages.
- Fake password-reset pages.
- Requests for one-time codes.
- Requests to install remote-access software.
- Social-media information attackers may use to sound convincing.
This is where IT security awareness training for Connecticut businesses can support a broader security program.
Build a backup path, but not an easy bypass
A user who loses a phone or security key needs a recovery option. Without one, employees may pressure the help desk to disable MFA entirely.
Create a controlled recovery path with:
- Two registered authentication methods for critical users.
- Spare security keys for administrators.
- Documented identity verification.
- Separate approval for privileged-account recovery.
- Emergency access accounts protected and monitored.
- A tested process for locked-out employees.
The recovery path should be reliable for legitimate users and difficult for attackers to manipulate.
The missing control: monitor MFA events
MFA can automatically prevent many unauthorized sign-ins, even when nobody is actively monitoring authentication activity. However, MFA alone cannot tell your security team whether someone is repeatedly attempting to access an account, whether credentials have been compromised, or whether an attacker is trying to manipulate an employee. Monitoring authentication activity helps organizations identify threats, investigate suspicious behavior, and respond before an attempted compromise becomes a larger incident.
A business may have MFA enabled and still miss:
- Repeated login failures.
- Dozens of push notifications.
- New MFA devices being registered.
- A user signing in from an unfamiliar location.
- A service account attempting interactive access.
- A new administrator being created.
- A password reset followed by a new authentication method.
- A successful login immediately followed by mailbox rules or file downloads.
Configure your identity platform, firewall, endpoint tools, and cloud applications to log authentication activity. Then decide who reviews the alerts and what happens after hours.
A simple escalation rule can help:
Repeated MFA prompts are not noise until proven otherwise. Treat them as a possible active attack.
Network monitoring and security operations can help connect the dots between identity activity, device behavior, remote access, and unusual network traffic. MFA is one layer in a broader defense in depth cybersecurity strategy that should also include secure configurations, endpoint protection, vulnerability scanning, patch management, backups, and incident response.
A practical MFA action plan for this week
You do not need to solve every identity problem in one afternoon. Start with the highest-risk gaps.
Day one: Inventory
List:
- Administrators.
- Finance and payroll users.
- Email and identity systems.
- VPN and remote-access tools.
- Cloud file storage.
- Backup consoles.
- Critical SaaS applications.
- Third-party and vendor accounts.
- Service accounts.
- Legacy authentication methods.
Day two: Protect the highest-risk accounts
Require the strongest available MFA for:
- Global administrators.
- Domain administrators.
- Finance leaders.
- Payroll administrators.
- Banking users.
- Backup administrators.
- Remote-access administrators.
Prefer passkeys or FIDO2 security keys. If those are not yet available, use authenticator apps with number matching as an interim step.
Day three: Remove obvious bypasses
Check for:
- SMS-only users.
- Accounts with undocumented or unnecessary MFA exemptions, while separately reviewing emergency-access accounts and noninteractive service identities.
- Disabled MFA on administrator accounts.
- Legacy protocols.
- Shared accounts.
- Dormant users.
- Former employees.
- Unmanaged vendor accounts.
- Service accounts with excessive permissions.
Day four: Review policies
Review your authentication and access policies. Where licensing permits, configure Conditional Access policies. Otherwise, verify that available baseline protections, such as Microsoft Entra Security Defaults, are enabled and functioning appropriately. For organizations using Conditional Access, consider policies covering the following areas:
- External access.
- Unmanaged devices.
- High-risk sign-ins.
- Administrator accounts.
- Remote access.
- Sensitive applications.
- Unusual geographic locations.
Day five: Train and test
Tell employees:
- Never approve an unexpected MFA prompt.
- Never share a one-time code.
- Never install remote-access software because an unsolicited caller requests it.
- Report repeated prompts immediately.
- Contact the help desk through the known company channel, not through a link in an unexpected message.
Then test your recovery process with a low-risk account. Confirm that legitimate users can recover access without giving support staff an easy way to bypass identity verification.
MFA is powerful, but it is not the whole security program
MFA can block many attacks, but it cannot patch an exposed firewall, detect a compromised endpoint, restore encrypted files, or stop an employee from giving an attacker remote access.
That is why MFA works best as part of a complete security program.
For Connecticut SMBs, that may include:
- Managed IT services.
- Network security and firewall management.
- Vulnerability scanning.
- Network monitoring.
- Endpoint protection.
- Microsoft 365 and cloud security.
- Backup and disaster recovery.
- Security awareness training.
- Access reviews and offboarding.
- Incident response planning.
- IT infrastructure optimization.
FoxPowerIT helps small and midsize businesses build these layers around their real operations. A law firm, medical practice, accounting office, or nonprofit should not have to choose between practical support and stronger security.
Our approach is based on transparency, integrity, and reliability. We do not treat cybersecurity as a collection of confusing products. We work to understand how your people, systems, vendors, and clients connect, and then help you reduce risk in a way your business can maintain.
Final takeaway
The question is no longer whether your business has MFA.
The better questions are:
- Is MFA protecting every important access path?
- Are your strongest accounts using phishing-resistant methods?
- Can an attacker bypass MFA through a legacy protocol or service account?
- Can your help desk verify a caller safely?
- Will someone notice repeated MFA prompts?
- Can legitimate users recover access without creating a security hole?
During Cybersecurity Awareness Month, take CISA’s message seriously: secure the next 250 by securing the systems your business depends on today.
And remember:
MFA is not a checkbox. It is a process that must be designed, monitored, tested, and improved.
For additional guidance, review FoxPowerIT’s resources on security management, vulnerability scanning, and managed IT services.
