Phishing-Resistant MFA: Why It Matters for Stopping Account Takeovers, BEC, and Ransomware

Password-based security is no longer enough, and traditional multi-factor authentication (MFA) is increasingly being bypassed through phishing, social engineering, and token theft. In this article, you’ll learn what phishing-resistant MFA is, why it matters for ransomware prevention for small business, how it reduces business email compromise risk, and how to implement it in a practical, phased way.

Why MFA Still Matters—But Not All MFA Is Equal

Most organizations understand that MFA is important. Requiring a second factor beyond a password can stop many common attacks, especially those involving stolen or reused credentials.

But attackers have adapted.

Today, many phishing campaigns are designed specifically to bypass basic MFA. Instead of only stealing a username and password, attackers may trick users into approving login prompts, entering one-time codes into fake websites, or granting access through a malicious authentication flow.

That does not mean MFA has failed. It means organizations need stronger forms of MFA.

This is where phishing-resistant MFA comes in.

Phishing-resistant MFA is designed so that a user cannot easily be tricked into giving an attacker the authentication secret. The authentication process is cryptographically tied to the legitimate website or application, making fake login pages and many credential theft techniques far less effective.

For organizations facing ransomware, business email compromise, healthcare data protection obligations, cyber insurance requirements, or compliance expectations, phishing-resistant MFA is becoming a critical security control.

What Is Phishing-Resistant MFA?

Phishing-resistant MFA is multi-factor authentication that is resistant to common phishing techniques because the authentication method verifies the legitimate service and does not rely on users manually entering reusable codes into a web page.

In simpler terms: even if an employee clicks a phishing link, a properly configured phishing-resistant MFA method should not allow the attacker to reuse the authentication response on a fake site.

Common examples include:

• FIDO2 security keys
• WebAuthn-based passkeys
• Platform authenticators, such as device-bound biometrics or hardware-backed authentication
• Smart cards or Personal Identity Verification (PIV) cards, where appropriate

These methods use public-key cryptography. The private key stays on the user’s device or hardware token, while the public key is registered with the legitimate service. During login, the authenticator proves possession of the private key without exposing it.

Just as important, the authenticator checks the website or application origin. This helps prevent users from authenticating to a fake site controlled by an attacker.

Why Traditional MFA Can Still Be Phished

Traditional MFA is still better than passwords alone, but some methods are more vulnerable than others.

Common MFA Methods That Can Be Phished or Abused

Examples include:

• SMS text message codes
• Voice call codes
• Email-based codes
• Time-based one-time passwords, often called TOTP codes
• Push notifications without number matching or additional safeguards
• Security questions, which should generally not be treated as strong MFA

These methods can be exploited in several ways.

Fake Login Pages

An attacker sends a phishing email that links to a fake sign-in page. The user enters their username, password, and MFA code. The attacker immediately uses those credentials and the code on the real service.

This is commonly called real-time phishing or an adversary-in-the-middle attack when a proxy is used to relay the session.

MFA Fatigue Attacks

In an MFA fatigue attack, the attacker already has the user’s password and repeatedly sends push approval requests. The user may approve one out of annoyance, confusion, or because they think IT is testing something.

This is especially dangerous when push notifications only ask “Approve” or “Deny” without showing context such as location, application, or a number-matching challenge.

Token and Session Theft

In some attacks, the goal is not just to steal a password or MFA code. The attacker attempts to steal a session cookie or token after the user successfully authenticates. If successful, the attacker may access the account without needing to repeat MFA.

Phishing-resistant MFA reduces some of this risk, but it should be paired with conditional access, device security, endpoint detection, session controls, and monitoring.

Social Engineering of Help Desks

Attackers may call a help desk pretending to be an employee who lost access to their MFA device. If the help desk resets MFA enrollment without strong identity verification, the attacker may register their own device.

Phishing-resistant MFA is powerful, but enrollment and recovery processes must also be secure.

Why Phishing-Resistant MFA Matters for Business Email Compromise

Business email compromise, often abbreviated as BEC, is a type of cyberattack where an attacker gains access to or impersonates a business email account to commit fraud, redirect payments, steal data, or launch additional attacks.

BEC is especially dangerous because it often does not begin with malware. It may look like normal email activity from a trusted account.

An attacker who compromises an executive, finance employee, HR staff member, IT administrator, or vendor-facing account may be able to:

• Send fraudulent wire transfer instructions
• Redirect payroll deposits
• Change vendor payment details
• Access sensitive attachments
• Search email for invoices, contracts, tax forms, or patient information
• Create forwarding rules to monitor communications
• Launch internal phishing from a trusted account
• Reset passwords for other services connected to email

Traditional MFA can reduce BEC risk, but if attackers can phish MFA codes or trick users into push approvals, email accounts remain exposed.

Phishing-resistant MFA helps by making it much harder for attackers to use stolen credentials to access cloud email platforms, administrative portals, collaboration tools, and financial systems.

For many organizations, email is the front door to the business. Protecting it with phishing-resistant MFA is one of the most practical ways to reduce account takeover risk.

Why Phishing-Resistant MFA Matters for Ransomware Prevention for Small Business

Ransomware attacks often involve more than malicious attachments. Many incidents begin with compromised credentials.

For small businesses, account takeover can be a direct path to ransomware. Attackers may use stolen credentials to access:

• Remote access services
• Cloud email
• File-sharing platforms
• Virtual private networks, known as VPNs
• Remote monitoring and management tools
• Administrator consoles
• Backup systems
• Accounting or line-of-business applications

Once inside, attackers may attempt to escalate privileges, disable security tools, move laterally, steal data, and deploy ransomware.

For ransomware prevention for small business, phishing-resistant MFA is particularly valuable because it addresses a common and practical attack path: stolen credentials.

Small businesses often have limited IT staff, shared administrative responsibilities, and cloud-heavy environments. A strong authentication strategy can provide significant risk reduction without requiring a large security operations team.

Phishing-resistant MFA should not be the only ransomware defense, but it should be part of a layered program that also includes:

• Reliable offline or immutable backups
• Endpoint protection and monitoring
• Timely patching
• Least privilege access
• Secure remote access
• Email security controls
• Security awareness training
• Incident response planning
• Vendor and managed service provider oversight

Why This Matters in Healthcare and Regulated Environments

Healthcare organizations and their vendors face heightened risks because compromised accounts may expose sensitive health information, disrupt care operations, or affect billing and business systems.

For organizations subject to the Health Insurance Portability and Accountability Act (HIPAA), the HIPAA Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards for electronic protected health information, known as ePHI. Relevant Security Rule provisions include, among others, risk analysis and risk management requirements under 45 CFR 164.308(a)(1) and access control requirements under 45 CFR 164.312(a).

The HIPAA Security Rule is scalable and flexible. It does not prescribe one specific authentication technology for every organization. However, organizations should evaluate authentication risks as part of their risk analysis and document reasonable and appropriate safeguards.

Other frameworks and requirements may also influence MFA expectations, depending on the organization, contract, payer, state law, cyber insurance policy, or framework version. Examples may include:

• NIST Cybersecurity Framework
• NIST Special Publication 800-53
• NIST Special Publication 800-63
• CIS Critical Security Controls
• PCI DSS, where payment card data environments are involved
• State privacy or security laws, where applicable
• Contractual security requirements from customers, payers, or business partners

Requirements vary by state, payer, contract, and framework version, so organizations should validate which obligations apply and consult qualified counsel where legal interpretation is needed.

What Makes MFA “Phishing-Resistant”?

Not every MFA method is phishing-resistant. A method is typically considered phishing-resistant when it has two key properties.

1. Cryptographic Authentication

The authenticator uses cryptographic keys instead of shared secrets or user-entered codes. The private key remains protected on the user’s device, security key, smart card, or secure hardware.

The service verifies the authentication response using the registered public key.

This means there is no one-time code for the user to type into a fake website and no reusable password-like secret for an attacker to steal.

2. Origin or Channel Binding

The authentication response is tied to the legitimate website or application. If a user is tricked into visiting a lookalike domain, the authenticator should not produce a valid response for the real service.

For example, a security key registered to login.example.com should not authenticate to login-example.com or another attacker-controlled domain.

This is one of the major advantages of FIDO2 and WebAuthn-based authentication.

Common Phishing-Resistant MFA Options

FIDO2 Security Keys

FIDO2 security keys are physical hardware tokens that users plug into a USB port, connect by NFC, or use via Bluetooth depending on the model and environment.

They are often a strong choice for:

• Administrators
• Executives
• Finance staff
• HR staff
• Healthcare leadership
• Users with access to sensitive systems
• Shared workstation environments, when carefully designed
• Organizations that want a portable, hardware-based factor

Advantages:

• Strong phishing resistance
• Simple user action, such as touching the key
• Works across many modern identity platforms and browsers
• Good option for high-risk users

Considerations:

• Users can lose keys
• Organizations need spare key and recovery processes
• Some legacy applications may not support them directly
• Procurement, inventory, and lifecycle management are needed

Platform Passkeys

Passkeys are credentials based on FIDO standards that may be stored on a device or synced through a platform account, depending on implementation. They often use device biometrics, such as fingerprint or facial recognition, or a device PIN.

Advantages:

• Convenient user experience
• Strong resistance to common phishing attacks
• Reduces password use
• Works well for cloud applications that support passkeys

Considerations:

• Some passkeys are device-bound, while others may sync across devices depending on platform design
• Organizations need policies for enrollment, recovery, device loss, and offboarding
• Support varies across applications and identity providers
• Shared devices and clinical workflows require careful planning

Smart Cards and PIV-Based Authentication

Smart cards and PIV-based authentication are common in some government, defense, and high-assurance environments. They can provide strong authentication when properly implemented.

Advantages:

• Mature technology for high-assurance environments
• Can support physical and logical access use cases
• Strong identity proofing and certificate-based authentication options

Considerations:

• More complex infrastructure
• Certificate lifecycle management is required
• User training and support needs may be higher
• May be excessive for some small business use cases

Where to Use Phishing-Resistant MFA First

Most organizations cannot change every system overnight. A risk-based rollout is usually more successful.

Start with the accounts and systems where compromise would cause the most damage.

Priority 1: Administrators and Privileged Users

Administrative accounts should be first. This includes:

• Global administrators
• Domain administrators
• Cloud tenant administrators
• Security administrators
• Help desk users with password reset rights
• Backup administrators
• Network administrators
• Remote monitoring and management administrators
• Electronic health record system administrators, where applicable
• Finance system administrators

If an attacker compromises an administrative account, they may be able to disable security controls, create new accounts, access sensitive data, or deploy malware.

Priority 2: Email and Collaboration Platforms

Cloud email and collaboration accounts are frequent targets because they contain sensitive information and can be used to impersonate trusted users.

Prioritize phishing-resistant MFA for:

• Executives
• Finance and accounting
• Human resources
• Legal and compliance
• IT and security
• Employees with access to sensitive customer, patient, or payment data
• Users who frequently communicate with vendors or approve payments

Priority 3: Remote Access

Remote access systems are high-value targets for ransomware operators and credential-based attackers.

Apply strong MFA to:

• VPNs
• Virtual desktop infrastructure
• Remote desktop gateways
• Cloud management portals
• Remote monitoring tools
• Privileged access workstations
• Third-party access portals

Avoid exposing remote desktop services directly to the internet. Use secure remote access architectures, restrict access by role and device health where possible, and monitor authentication events.

Priority 4: Financial and Payment Workflows

BEC often becomes costly when attackers manipulate payments.

Use phishing-resistant MFA and process controls for:

• Wire transfer approval
• ACH changes
• Vendor bank account updates
• Payroll changes
• Invoice approval systems
• Purchasing systems
• Accounting platforms

Security should not rely only on authentication. Require out-of-band verification for payment changes, such as calling a known phone number already on file—not a number provided in an email request.

Priority 5: Systems Containing Sensitive or Regulated Data

For healthcare and other regulated environments, prioritize systems that store or transmit sensitive data, including:

• Electronic health record systems
• Patient portals
• Billing systems
• Claims systems
• Document management platforms
• Secure messaging systems
• Cloud storage
• Data warehouses
• File transfer systems

Practical Implementation Checklist

Use this checklist to plan a phishing-resistant MFA rollout.

Governance and Planning

• Identify the business owner, IT owner, and security owner for the MFA program.
• Define which MFA methods are approved.
• Document which systems require phishing-resistant MFA.
• Prioritize privileged, high-risk, and sensitive-data users.
• Establish enrollment, recovery, and offboarding procedures.
• Review cyber insurance and contractual requirements.
• Confirm any healthcare, privacy, or compliance obligations that apply.
• Create exceptions criteria and expiration dates for exceptions.
• Develop a communications and training plan.

Identity and Access Management

• Inventory identity providers and applications.
• Identify applications that support FIDO2, WebAuthn, passkeys, smart cards, or federated login.
• Centralize authentication through a primary identity provider where feasible.
• Enforce single sign-on for supported applications.
• Disable legacy authentication protocols that bypass MFA.
• Apply conditional access policies where available.
• Require phishing-resistant MFA for administrators.
• Require strong MFA for all remote access.
• Monitor risky sign-ins and impossible travel alerts where supported.

Enrollment and Recovery

• Verify user identity before MFA enrollment.
• Require users to register at least two approved authentication methods where appropriate.
• Issue backup security keys for high-risk users.
• Store spare keys securely with documented chain-of-custody.
• Define help desk procedures for lost devices or keys.
• Require stronger verification for MFA resets than for routine password resets.
• Log and review MFA reset events.
• Immediately revoke access for terminated users.
• Test recovery procedures before a real incident.

Endpoint and Device Readiness

• Confirm user devices support selected authentication methods.
• Update browsers and operating systems.
• Validate support for mobile, desktop, and shared workstation workflows.
• For healthcare, test clinical workflows where users move between workstations.
• Consider device compliance checks for managed endpoints.
• Ensure endpoint detection and response tools do not interfere with authentication.
• Train users on how to recognize legitimate authentication prompts.

Monitoring and Response

• Alert on suspicious MFA registration changes.
• Alert on new device enrollment for privileged users.
• Monitor repeated failed login attempts.
• Review administrative sign-ins regularly.
• Investigate logins from unusual locations or anonymizing services.
• Correlate identity logs with endpoint and email activity.
• Include identity compromise in incident response playbooks.
• Test incident response steps through tabletop exercises.

Example Rollout Plan for a Small Business

A small business does not need to solve everything at once. A phased approach can provide meaningful protection quickly.

Phase 1: Protect the Most Dangerous Accounts

Start with:

• Business owner accounts
• IT administrator accounts
• Email administrator accounts
• Finance and payroll users
• Remote access users
• Backup administrator accounts

Require phishing-resistant MFA for these groups before expanding to the broader workforce.

Phase 2: Lock Down Email

Implement:

• Phishing-resistant MFA for email access where supported
• Strong spam and phishing filtering
• Domain-based email authentication controls such as SPF, DKIM, and DMARC
• External sender warnings where appropriate
• Alerts for suspicious inbox rules and forwarding
• User reporting for suspected phishing emails

DMARC, SPF, and DKIM help protect email domains from spoofing, but they do not replace MFA. They should be part of a broader email security strategy.

Phase 3: Secure Remote Access and Cloud Apps

Require MFA for:

• VPN
• Cloud admin portals
• Remote desktop gateways
• Accounting platforms
• Customer relationship management systems
• File sharing platforms

Where phishing-resistant MFA is not supported, use the strongest available option and document the limitation. Consider compensating controls such as IP restrictions, device compliance, session monitoring, and reduced privileges.

Phase 4: Improve Recovery and Incident Response

Many organizations focus on login but overlook recovery. Attackers know this.

Strengthen:

• Password reset procedures
• MFA reset procedures
• Help desk identity verification
• Backup access procedures
• Emergency administrator access
• Account lockout and reactivation processes

Create an incident response checklist for suspected account compromise.

Phase 5: Expand and Optimize

After high-risk users and systems are protected, expand phishing-resistant MFA to additional users and applications.

Track:

• Percentage of users enrolled
• Percentage of privileged accounts protected
• Number of exceptions
• Number of MFA reset requests
• Failed phishing tests involving credential capture
• Account compromise attempts
• Help desk ticket volume related to MFA

Use this data to improve training, support, and policy design.

Hypothetical Example: Preventing BEC and Ransomware Exposure

Consider a hypothetical example involving a 75-person professional services firm with a small internal IT team and a managed service provider.

The firm uses cloud email, a remote access tool, an accounting platform, and a file-sharing system. MFA is enabled, but most users rely on push notifications. One employee receives a phishing email that appears to come from a trusted document-sharing service. The employee enters their password into a fake login page and approves a push notification.

The attacker accesses the mailbox and creates an inbox rule to hide replies from the finance team. They review recent invoices and send a vendor payment change request from the compromised account. They also attempt to use the same credentials to access the firm’s remote access portal.

Now imagine the firm had taken the following steps before the attack:

• Required phishing-resistant MFA for finance, executives, IT, and remote access users
• Disabled legacy authentication
• Required number matching for remaining push-based MFA
• Alerted on suspicious inbox rule creation
• Required verbal verification for vendor banking changes using known contact information
• Monitored remote access attempts from unusual locations
• Protected backup administration accounts with hardware security keys

In that scenario, the attacker may still obtain the password, but they are far less likely to access the email account or remote access portal. Even if they attempt payment fraud, the business process control may stop the financial loss. If they try to pivot toward ransomware, stronger remote access and administrative protections reduce the opportunity.

This example is hypothetical, but the lesson is practical: phishing-resistant MFA works best when combined with process controls, monitoring, and least privilege.

Common Mistakes to Avoid

Mistake 1: Treating All MFA as Equal

SMS codes, authenticator app codes, push notifications, passkeys, and hardware keys do not provide the same level of protection.

Do not simply ask, “Do we have MFA?”

Ask:

• Which MFA methods are allowed?
• Which users have the strongest protection?
• Can our MFA be phished?
• Are administrators required to use phishing-resistant MFA?
• Are there applications that bypass MFA?

Mistake 2: Leaving Legacy Authentication Enabled

Legacy authentication protocols may allow access without modern MFA. These protocols are often unnecessary but remain enabled due to old applications or default configurations.

Review and disable legacy authentication wherever feasible. If a business-critical application still requires it, document the risk and create a migration plan.

Mistake 3: Weak MFA Reset Procedures

If attackers can trick the help desk into resetting MFA, strong authentication can be undermined.

Require stronger verification for:

• New MFA device registration
• Lost phone or lost key replacement
• Administrator MFA reset
• Emergency access requests
• Changes to recovery email or phone numbers

Mistake 4: Not Protecting Break-Glass Accounts

Organizations often maintain emergency accounts for use during outages. These accounts are sometimes excluded from MFA or monitoring.

Break-glass accounts should be:

• Strictly limited
• Protected with strong credentials and, where feasible, strong authentication
• Excluded from routine use
• Monitored closely
• Tested periodically
• Documented in incident response plans

Specific implementation depends on the identity platform and operational requirements.

Mistake 5: Forgetting Third Parties

Vendors, contractors, billing partners, outsourced IT providers, and managed service providers may have access to sensitive systems.

Review:

• Which third parties have access
• Whether MFA is required
• Whether phishing-resistant MFA is available
• Whether access is time-limited
• Whether accounts are named and attributable
• Whether vendor access is logged and reviewed
• Whether contracts address security expectations

Third-party access is a common blind spot.

How to Handle Applications That Do Not Support Phishing-Resistant MFA

Many organizations still depend on applications that do not support modern authentication. This is common in healthcare, manufacturing, local government, and small business environments.

When phishing-resistant MFA is not available, consider compensating controls.

Possible Compensating Controls

• Put the application behind a modern identity provider or secure access proxy.
• Require VPN or zero trust network access with strong MFA.
• Restrict access to managed devices.
• Limit access by network location.
• Use role-based access control.
• Reduce standing administrative privileges.
• Monitor logins and administrative actions.
• Require separate approval for sensitive transactions.
• Segment the application from other systems.
• Plan for replacement or upgrade.

Document the limitation and the decision-making process. For regulated environments, include the issue in risk analysis and risk management activities.

User Training: What Employees Need to Know

Phishing-resistant MFA reduces reliance on user judgment, but training is still necessary.

Employees should understand:

• Why MFA is required
• Which login prompts are legitimate
• How to report suspicious prompts
• What to do if a security key is lost
• Why they should not approve unexpected MFA requests
• Why IT will not ask for passwords or MFA codes
• How payment change requests must be verified
• How to report suspected email compromise

Keep training practical. Employees do not need a cryptography lecture. They need clear instructions for real situations.

Simple Message for Employees

A useful training message might be:

> “If you receive a login prompt you did not initiate, deny it and report it. If a website asks you to enter a code or approve access unexpectedly, stop and contact IT. Do not approve payment changes based only on email.”

Avoid blaming users. The goal is to create a culture where reporting is easy and fast.

Technical Controls That Strengthen Phishing-Resistant MFA

Phishing-resistant MFA is most effective when integrated into a broader security architecture.

Conditional Access

Conditional access policies evaluate context before allowing a login. Context may include:

• User role
• Device compliance
• Location
• Application sensitivity
• Sign-in risk
• Network
• Session behavior

For example, an administrator logging in from a new country on an unmanaged device may be blocked or required to complete stronger authentication.

Privileged Access Management

Privileged access management reduces the risk of administrator compromise by limiting when and how elevated access is used.

Consider:

• Just-in-time administrator access
• Separate admin accounts
• Approval workflows for sensitive roles
• Session recording where appropriate
• Strong authentication for elevation
• Regular access reviews

Least Privilege

Users should only have access needed for their jobs. If an account is compromised, least privilege limits the damage.

Review access to:

• Email mailboxes
• Shared drives
• Cloud storage
• Financial systems
• Patient records
• Administrative consoles
• Backup systems
• Security tools

Email Security Controls

To reduce phishing and BEC risk, implement:

• Anti-phishing filtering
• Malware scanning
• URL rewriting or detonation where appropriate
• Attachment sandboxing where appropriate
• SPF, DKIM, and DMARC
• External sender banners, if useful
• Alerts for suspicious forwarding rules
• Mailbox audit logging

Backup Protection

Ransomware operators often target backups.

Protect backup systems with:

• Phishing-resistant MFA for administrators
• Separate backup credentials
• Immutable or offline backup copies where feasible
• Backup network segmentation
• Regular restore testing
• Monitoring for deletion or encryption attempts

Metrics Leaders Should Ask For

Business leaders do not need every technical detail, but they should ask for measurable progress.

Useful metrics include:

• Percentage of users covered by MFA
• Percentage of privileged accounts using phishing-resistant MFA
• Number of applications integrated with single sign-on
• Number of accounts exempted from MFA
• Age and owner of each MFA exception
• Number of legacy authentication attempts
• Number of MFA reset requests
• Time to disable access after termination
• Number of suspicious inbox rules detected
• Percentage of critical vendors using MFA
• Backup restore test results

For ransomware prevention for small business, leaders should also ask whether remote access, administrator accounts, and backups are protected by strong authentication.

Phishing-Resistant MFA Readiness Checklist

Use this quick checklist to assess readiness.

Executive Questions

• Do we require phishing-resistant MFA for administrators?
• Do executives, finance, HR, and IT use stronger MFA than standard users?
• Are payment change requests verified outside of email?
• Are cyber insurance and customer security requirements mapped to our controls?
• Do we know which systems do not support phishing-resistant MFA?
• Do we review exceptions regularly?
• Can we restore from backups if ransomware occurs?

IT and Security Questions

• Are legacy authentication protocols disabled?
• Are MFA registration and reset events logged?
• Are new authenticator enrollments reviewed for privileged users?
• Are break-glass accounts monitored?
• Are conditional access policies in place?
• Are unmanaged devices restricted from sensitive systems?
• Are remote access tools protected with strong MFA?
• Are vendor accounts named, monitored, and time-limited?
• Are mailbox forwarding and inbox rule changes monitored?
• Are incident response playbooks updated for identity-based attacks?

Conclusion and Clear Next Steps

Phishing-resistant MFA matters because attackers increasingly target identity, not just endpoints. Traditional MFA can still help, but methods based on codes and simple push approvals can be phished, proxied, or socially engineered.

For organizations concerned about business email compromise, ransomware prevention for small business, healthcare security, or regulated data protection, phishing-resistant MFA is one of the most practical ways to reduce account takeover risk.

Start with the highest-risk accounts: administrators, executives, finance, HR, remote access users, and systems containing sensitive data. Then expand coverage, improve recovery processes, monitor authentication events, and address legacy applications that cannot support modern authentication.

Next Steps Checklist

1. Inventory all MFA methods currently allowed.
2. Identify privileged and high-risk users.
3. Require phishing-resistant MFA for administrators first.
4. Expand to email, finance, HR, remote access, and sensitive-data systems.
5. Disable legacy authentication where feasible.
6. Strengthen MFA enrollment and reset procedures.
7. Monitor suspicious sign-ins, inbox rules, and authenticator changes.
8. Test account compromise response procedures.
9. Review third-party access.
10. Document risks, exceptions, and compensating controls.

How ThornShield Can Help

ThornShield Technologies helps organizations evaluate identity security, MFA readiness, ransomware exposure, and compliance-related security risks through practical, vendor-neutral assessments. If you want a clear view of where your authentication and account takeover defenses stand, explore our [Full Security Assessments](https://www.thornshield.tech/services/security-assessments).

This article is general information and not legal advice.