MFA Isn’t Enough Anymore: How Token Theft Bypasses Your Sign-In Protection

Multi-factor authentication remains one of the most important security controls a business can enable. It prevents many attacks that rely on stolen or guessed passwords and makes ordinary account compromise significantly more difficult.

However, MFA is not a complete defence.

Modern attackers increasingly target what happens after a user has successfully completed the sign-in process. Instead of repeatedly entering the stolen password and attempting to defeat the MFA prompt, the attacker steals the authenticated session token created after MFA has already been approved.

That token can act like temporary proof that the user has signed in. When an attacker successfully replays it, the service may treat the attacker’s browser as an already authenticated session. Microsoft describes token theft as the compromise and replay of tokens issued after a user has satisfied authentication requirements, including MFA. 

This guide explains how session and token theft works, why conventional MFA may not stop it and what businesses can do to strengthen their Microsoft 365, cloud and web application security.

What Is Multi-Factor Authentication?

Multi-factor authentication requires a user to provide more than one type of evidence before an account is opened.

The factors normally fall into broad categories:

• Something the user knows, such as a password
• Something the user has, such as a mobile phone or security key
• Something the user is, such as a fingerprint or face
• Contextual evidence, such as an approved device or location

Common MFA methods include:

• SMS codes
• Telephone calls
• Authenticator app codes
• Push notifications
• Number matching
• Hardware security keys
• Passkeys
• Certificate-based authentication
• Biometrics linked to a device

MFA is much stronger than relying on a password alone, but not every MFA method provides the same level of resistance to phishing, interception and social engineering. NIST now requires phishing-resistant options to be offered at Authenticator Assurance Level 2 and encourages their use whenever practical. 

Why MFA Still Matters

The phrase “MFA isn’t enough” does not mean MFA is pointless.

MFA continues to reduce the risk from:

• Password guessing
• Credential stuffing
• Reused passwords
• Basic phishing pages
• Leaked password databases
• Unauthorised password resets
• Opportunistic account attacks

Removing MFA because it can be bypassed in certain circumstances would make an organisation considerably less secure.

The correct conclusion is:

MFA should be treated as an essential security layer, not the entire identity-security strategy.

Businesses now need stronger authentication methods, device controls, session monitoring and rapid incident-response procedures in addition to MFA.

What Is an Authentication Token?

After a user enters a password and completes MFA, the service normally needs a way to remember that the person has already authenticated.

Without this mechanism, the user might be asked to complete MFA every time they:

• Open an email
• Change a page
• Access a document
• Move between connected applications
• Refresh the browser
• Perform another routine action

The service therefore issues a session cookie or token.

NIST describes browser cookies as the predominant mechanism used to create and track web sessions. Although a session cookie is not itself considered an authenticator, it functions as a short-term secret that maintains the authenticated session. 

Depending on the platform, tokens may provide access to:

• Email
• Cloud storage
• Collaboration tools
• Business applications
• Administrative portals
• Customer data
• Shared documents
• Connected services

Some tokens are short-lived. Others can be renewed or remain useful until they expire, are revoked or encounter a policy requiring reauthentication.

How Token Theft Bypasses MFA

The attacker does not necessarily defeat the MFA challenge itself.

Instead, the attack may follow this pattern:

1. The user receives a convincing phishing message.
2. The link opens a fake or attacker-controlled sign-in page.
3. The page passes the user’s requests to the genuine service.
4. The real service asks for the password and MFA.
5. The user completes the genuine MFA challenge.
6. The service returns a valid authenticated session token.
7. The attacker captures that token.
8. The attacker replays it from another browser or system.
9. The service may accept the attacker as an authenticated user.

Microsoft explains that adversary-in-the-middle phishing can capture the session cookie after the victim completes authentication. Because the stolen cookie represents an authenticated session, the attacker may gain access regardless of the sign-in method used during that session. 

This is why the user may truthfully say:

“I never approved an MFA request for the attacker.”

They approved the MFA request for what appeared to be the legitimate sign-in process, while the attacker intercepted the resulting session.

Adversary-in-the-Middle Phishing

One of the most important token-theft techniques is known as adversary-in-the-middle, often shortened to AiTM.

In an AiTM attack, the malicious website acts as a proxy between the victim and the genuine service.

The attacker may not need to create a completely fake copy of every sign-in page. Instead, the proxy relays the real website to the user while observing the information travelling between both sides.

The victim may therefore see:

• Genuine branding
• The correct MFA prompt
• Their real account information
• A legitimate-looking login flow
• A successful sign-in message

Meanwhile, the attacker captures:

• Username
• Password
• Authentication responses
• Session cookies
• Other browser data

Google’s threat-intelligence team describes browser-in-the-middle tooling as placing an attacker-controlled server between the victim and the intended website so authentication traffic and session tokens can be captured. 

A Simple Token-Theft Example

Imagine an employee receives an email stating:

A secure document has been shared with you. Sign in to review it.

The employee opens the link and sees a Microsoft 365 sign-in page.

They enter:

• Email address
• Password
• Authenticator approval

The document then fails to open, or the user is redirected to the genuine Microsoft 365 home page.

From the employee’s perspective, the sign-in may simply appear to have been unreliable.

In the background, however, the attacker may have captured the authenticated session token.

The attacker can then attempt to:

• Open the victim’s mailbox
• Search previous conversations
• Read financial correspondence
• Download files
• Create inbox rules
• Send messages as the victim
• Launch further phishing campaigns
• Reset passwords for connected services
• Request fraudulent payments

The attacker may no longer need to request another MFA approval until the session expires or a security policy forces reauthentication.

Is Token Theft a Vulnerability in MFA?

Usually, no.

The MFA process may have worked exactly as designed.

The genuine user provided the correct password and completed the second factor. The service then issued a valid session token.

The attacker’s objective was not necessarily to forge the second factor. It was to steal the result of the successful sign-in.

Microsoft specifically notes that AiTM cookie theft is not a vulnerability in MFA itself. The attacker obtains an authenticated session on the user’s behalf by capturing the resulting session cookie. 

This distinction matters because simply enabling more frequent MFA prompts may not fully solve the problem.

The organisation must protect:

• The authentication process
• The browser session
• The user’s device
• The issued token
• The applications that accept the token
• The response process when compromise is suspected

Other Ways Tokens Can Be Stolen

AiTM phishing is an important technique, but it is not the only route.

Malware on the Device

Information-stealing malware may extract:

• Browser cookies
• Saved credentials
• Local tokens
• Authentication databases
• Browser profiles
• Password-manager data

The attacker may obtain the session after the user has signed in normally.

Malicious Browser Extensions

An unsafe or compromised extension may be able to observe:

• Web traffic
• Page content
• Sign-in activity
• Cookies
• Session information

Browser extensions should be controlled in business environments rather than treated as harmless personal customisations.

Remote Access or Screen-Sharing Abuse

Attackers may persuade a user to install legitimate remote-support software.

Once connected, they may:

• Control the browser
• Access an existing session
• Download files
• Change security settings
• Register another authentication method

Recent threat reporting continues to show attackers abusing legitimate remote-access and screen-sharing tools after social engineering users. 

Compromised Devices

A device without current security patches or endpoint protection may allow attackers to access local authentication material.

OAuth Consent Attacks

Instead of stealing a normal browser cookie, an attacker may persuade a user or administrator to authorise a malicious application.

The application may then receive permission to access:

• Email
• Files
• Contacts
• Calendars
• User profiles

Changing the user’s password may not automatically remove every malicious application authorisation.

Stolen Refresh Tokens

Some platforms issue refresh tokens that allow applications to request new access tokens without asking the user to sign in repeatedly.

Threat actors continue to target session cookies, OAuth tokens and other long-lived identity artefacts because they can provide access beyond the initial authentication event. 

MFA Methods Are Not Equally Secure

A business may technically have MFA enabled while still relying on methods that are vulnerable to phishing or social engineering.

SMS Codes

SMS is better than a password alone, but risks can include:

• Phishing
• SIM swapping
• Message interception
• Telephone account compromise
• Users entering codes into fake pages

Telephone Calls

Attackers may pressure users into approving calls or exploit weaknesses in telephone-based identity verification.

One-Time Passcodes

Authenticator app codes are stronger than many SMS implementations, but a user can still enter the code into an AiTM phishing page.

The code may expire quickly, yet the attacker only needs to use it during the proxied sign-in.

Push Notifications

Push prompts can be abused through:

• MFA fatigue
• Repeated prompts
• Social engineering
• Accidental approval
• Users approving without checking the context

Number Matching

Number matching improves push-based MFA because the user must enter a number shown during the sign-in flow.

It helps reduce accidental approvals and basic push bombing, but it does not necessarily prevent a user from completing a challenge through a sophisticated AiTM phishing session.

FIDO2 Security Keys and Passkeys

FIDO2 security keys and properly implemented passkeys are designed to be phishing-resistant.

They use cryptographic verification tied to the genuine website or service. A credential created for the legitimate domain cannot simply be submitted to an attacker’s lookalike domain in the same way as a password or one-time code.

CISA and NIST recommend phishing-resistant authentication, particularly for privileged and high-value access. 

What Does Phishing-Resistant MFA Mean?

Phishing-resistant authentication is designed so that the user cannot easily provide valid authentication material to an impostor service.

A phishing-resistant method normally uses cryptographic proof bound to:

• The genuine service
• The registered device or security key
• The intended authentication request

Examples may include:

• FIDO2 hardware security keys
• Passkeys
• Platform authenticators
• Certificate-based authentication
• Smart cards in suitable environments

This is different from a password or six-digit code, which can be typed into any convincing page.

Phishing-resistant MFA significantly strengthens the sign-in process, but businesses must still protect sessions and endpoints. Malware operating inside an already authenticated device, for example, may attack the live session rather than tricking the user into authenticating to a false domain.

Why Security Keys Help Against AiTM Phishing

A hardware security key does not merely provide a reusable code.

During authentication, it verifies the website’s identity and creates a cryptographic response appropriate to that service.

When a user visits a fake domain, the key should not generate the response required by the genuine domain.

This helps break the attacker’s proxy workflow at the authentication stage.

Security keys are especially appropriate for:

• Global administrators
• Finance staff
• Senior executives
• IT administrators
• Security teams
• Payroll users
• Legal teams
• Employees with access to sensitive customer data
• High-risk remote users

Start With Privileged Accounts

A complete rollout of phishing-resistant authentication may require planning, hardware and user training.

When an immediate organisation-wide rollout is not practical, begin with:

• Microsoft 365 administrators
• Domain administrators
• Cloud administrators
• Finance approvers
• Payroll administrators
• Backup administrators
• Security administrators
• Help-desk staff with password-reset authority
• Executives
• High-risk external access

Compromising one privileged account may allow an attacker to weaken protections for many other users.

CISA guidance repeatedly recommends phishing-resistant MFA for critical systems and privileged access. 

Conditional Access

Conditional Access evaluates the circumstances of a sign-in or session before allowing access.

Depending on the identity platform, policies may consider:

• User identity
• Group membership
• Application
• Device compliance
• Operating system
• Location
• Network
• Sign-in risk
• User risk
• Authentication method
• Session risk
• Requested action

A policy could require:

• Phishing-resistant MFA for administrators
• A managed device for financial systems
• Reauthentication for risky sessions
• Access to be blocked from unsupported countries
• Additional controls for unmanaged browsers
• Stronger authentication for sensitive applications

Microsoft recommends combining identity-risk detection with Conditional Access to challenge or block sessions when risk changes, helping disrupt the use of stolen tokens. 

Device Compliance Matters

A valid username, password and MFA approval should not automatically grant unrestricted access from every device.

For sensitive business systems, consider requiring:

• A company-managed device
• Full-disk encryption
• Supported operating-system versions
• Current security updates
• Endpoint protection
• Screen locking
• Approved browser configuration
• No known high-risk state

This makes stolen-token replay more difficult because the attacker’s device may not satisfy the same access conditions.

Token Protection

Some identity platforms support token-protection mechanisms that bind a token to the device or cryptographic key that originally obtained it.

The aim is to make the stolen token less useful when copied to another device.

Microsoft describes token protection as a way to prevent copied session tokens from being replayed elsewhere, even when malware has extracted the token. 

Availability and supported applications vary, so organisations should review current platform documentation and test carefully before deployment.

Continuous Risk Evaluation

Traditional access decisions often happen only at the initial sign-in.

Modern systems can continue evaluating the session after authentication.

They may detect changes such as:

• An impossible or unusual location
• A different device
• An unfamiliar IP address
• Suspicious browser behaviour
• Known malicious infrastructure
• User-risk alerts
• Malware detection
• Changes to account security information

The platform may then:

• Block the request
• Require reauthentication
• Revoke the session
• Require a compliant device
• Alert the security team

This turns access control into an ongoing decision rather than a one-time checkpoint.

Shorter Sessions: Useful but Not Sufficient

Reducing token lifetime can shorten the window in which a stolen token remains useful.

However, very short sessions may:

• Frustrate users
• Increase support requests
• Encourage careless MFA approvals
• Interrupt business applications
• Affect mobile and legacy workflows

Session limits should be proportionate to risk.

For example:

• Administrative portals may require frequent reauthentication.
• Low-risk internal tools may allow longer sessions.
• Sensitive actions may trigger step-up authentication.
• Unmanaged devices may receive shorter sessions.

Shorter token life is one layer, not a complete solution.

Secure the Endpoint

A secure sign-in cannot compensate for a badly compromised computer.

Endpoint controls should include:

• Managed antivirus or endpoint detection and response
• Current security updates
• Browser patching
• Application control
• Restricted local administrator rights
• Controlled browser extensions
• Disk encryption
• Device-health monitoring
• Protection against credential and cookie theft

When malware runs as the user, it may be able to access the user’s existing browser session without performing a new login.

Control Browser Extensions

Business browsers should not allow unrestricted installation of extensions.

Review:

• Which extensions are approved
• Which permissions they request
• Whether the publisher is trusted
• Whether the extension is still maintained
• Whether it can read or modify page data
• Whether it is required for business use

Use central browser policies to:

• Block unapproved extensions
• Allow only approved extension IDs
• Remove known-risk extensions
• Keep browsers updated
• Disable unnecessary password storage

Improve Phishing Defences

Token theft frequently begins with a message designed to make the victim open an attacker-controlled link.

Useful controls include:

• Email authentication
• Attachment and link scanning
• URL-rewriting and detonation
• Domain monitoring
• External-sender warnings
• Blocking newly registered or high-risk domains
• Disabling risky legacy authentication
• Security awareness training
• Simple reporting buttons
• Rapid investigation of reported messages

No email filter catches every attack. Staff should know how to report suspicious messages quickly rather than simply deleting them.

Teach Users to Inspect the Sign-In Context

Users should be taught to pause when:

• A link asks them to sign in unexpectedly.
• A document request creates urgency.
• The browser address is unfamiliar.
• The request arrives from an unusual sender.
• MFA appears during an activity that should not require it.
• The login repeats unexpectedly.
• The final page fails to show the promised content.
• A website asks them to install software or an extension.
• Someone calls and tells them to approve a prompt.

Training should not rely solely on spotting spelling mistakes. Modern phishing pages may look polished and can relay genuine content.

Password Managers Can Provide a Warning

A password manager normally autofills credentials only on the domain associated with the saved login.

When the password does not autofill on what appears to be a familiar page, the user should treat that as a warning.

However, password managers are not a complete defence against every AiTM implementation, and users may still copy and paste credentials manually.

The stronger solution is phishing-resistant authentication.

Protect Help-Desk Processes

Attackers may contact support teams and claim to be employees who:

• Lost their phone
• Replaced a device
• Cannot access MFA
• Need a password reset
• Need a new security key
• Are travelling urgently

Help-desk staff should not rely on easily researched personal details.

Strong processes may include:

• Manager verification
• Known-device checks
• Video or in-person verification
• Formal identity-proofing procedures
• Delayed high-risk changes
• Alerts to the original user
• Separate approval for administrators
• Audit logging

A weak MFA-reset process can undermine a strong MFA method.

Monitor for Suspicious Token Use

Potential indicators include:

• Sign-ins from unexpected countries
• Impossible travel
• New inbox rules
• Sudden email forwarding
• Access from unfamiliar devices
• Large file downloads
• Unusual OAuth applications
• Repeated access to financial email
• Security information changes
• New MFA methods
• Access outside normal working patterns
• Anomalous administrative activity

A single unusual event may be legitimate. Several together may indicate account compromise.

Audit Mailbox Rules

Attackers frequently create or modify inbox rules to:

• Hide replies
• Delete security alerts
• Move payment messages
• Forward information externally
• Conceal fraudulent conversations

Review for rules that:

• Forward externally
• Delete messages automatically
• Move messages containing financial terms
• Hide replies from customers or suppliers
• Use unfamiliar names
• Were created around the suspected compromise time

Removing the rule alone is not enough. The account and active sessions must also be secured.

Review OAuth Applications

Check for applications that have been granted unexpected permissions.

Look for:

• Unknown publishers
• Recently approved applications
• Broad email or file access
• Offline access
• Administrator consent
• Applications unrelated to the employee’s role
• Similar names designed to imitate legitimate tools

Revoke suspicious permissions and investigate the user and administrator activity associated with the application.

What to Do When Token Theft Is Suspected

Treat suspected token theft as an active account compromise.

1. Isolate the Device

When malware may be involved, disconnect or isolate the device through the endpoint-security platform.

Do not allow the user to continue working normally while sensitive sessions remain open.

2. Disable or Restrict the Account

Temporarily block access when the business impact justifies it.

For privileged accounts, urgent containment is particularly important.

3. Revoke Active Sessions

Signing out of the visible browser is not sufficient.

Use the identity platform’s controls to revoke:

• Active browser sessions
• Refresh tokens
• Application sessions
• OAuth authorisations where necessary

Google and Microsoft incident-response guidance both emphasise revoking sessions and tokens when identity compromise is suspected. 

4. Reset the Password

Change the password after securing or replacing the affected device.

A password reset alone may not terminate every active or authorised session, so it must be combined with token revocation.

5. Review MFA Methods

Remove any unrecognised:

• Telephone numbers
• Authenticator registrations
• Security keys
• Passkeys
• Recovery methods
• Temporary access methods

6. Review Sign-In and Audit Logs

Identify:

• First suspicious sign-in
• Source IP addresses
• Applications accessed
• Files downloaded
• Emails read or sent
• Rules created
• Permissions changed
• OAuth grants
• Administrative actions

7. Inspect the Mailbox

Check:

• Sent messages
• Deleted items
• Drafts
• Inbox rules
• Forwarding configuration
• Search activity
• Financial conversations

8. Investigate the Endpoint

Look for:

• Information-stealing malware
• Malicious browser extensions
• Remote-access software
• Suspicious downloads
• New scheduled tasks
• Persistence mechanisms
• Credential dumping
• Browser-profile access

9. Notify Affected Parties

When fraudulent emails or payment instructions were sent, contact recipients through a known trusted channel.

10. Preserve Evidence

Retain relevant:

• Sign-in logs
• Endpoint alerts
• Email messages
• Browser artefacts
• Audit logs
• File-access records
• IP addresses
• Timestamps

Do not wipe the device before the investigation team confirms that necessary evidence has been collected.

Why Changing the Password May Not Be Enough

A password reset protects future password-based sign-ins.

It may not immediately invalidate:

• Existing session cookies
• Refresh tokens
• OAuth grants
• Application-specific tokens
• Sessions in connected services

This is why incident response should explicitly include session and token revocation.

The organisation should also inspect whether the attacker created a separate persistence route before the password was changed.

Do Not Simply Re-Enable the User

Before restoring normal access:

• Confirm active sessions are revoked.
• Reset and verify MFA methods.
• Remove malicious rules and applications.
• Secure or rebuild the endpoint.
• Review account activity.
• Confirm no unauthorised administrator changes occurred.
• Provide the user with targeted guidance.
• Increase monitoring temporarily.

Restoring access too early may allow the attacker to continue using a persistence mechanism that was missed.

A Layered Defence Against Token Theft

A strong identity-security strategy combines several controls.

Authentication

• MFA for all users
• Phishing-resistant MFA for high-risk accounts
• Removal of weak legacy methods
• Strong account-recovery procedures

Device Security

• Managed devices
• Endpoint detection and response
• Current patches
• Restricted local administration
• Browser and extension control

Access Policies

• Conditional Access
• Device-compliance requirements
• Risk-based sign-in controls
• Stronger rules for privileged applications
• Appropriate session limits

Token and Session Protection

• Token binding where supported
• Continuous session evaluation
• Rapid revocation capability
• Monitoring for replay and anomalous sessions

Email and Web Protection

• Phishing filtering
• Link scanning
• Domain protection
• User reporting
• Browser-security controls

Monitoring and Response

• Central identity logs
• Mailbox auditing
• Endpoint alerts
• OAuth application reviews
• Tested account-compromise playbooks

No single control is sufficient by itself.

A Practical Security Priority List

Businesses that have MFA enabled but limited security resources can begin with these priorities:

1. Confirm MFA is enforced for every user.
2. Eliminate legacy authentication.
3. Require phishing-resistant MFA for administrators.
4. Extend phishing-resistant MFA to finance, executives and other high-risk users.
5. Require managed devices for sensitive applications.
6. Configure risk-based access policies.
7. Deploy endpoint detection and response.
8. Restrict browser extensions.
9. Monitor mailbox rules and OAuth consent.
10. Document and test token-revocation procedures.
11. Train help-desk staff against social engineering.
12. Run regular phishing and incident-response exercises.

Questions to Ask Your IT Provider

Ask:

• Which MFA methods are currently allowed?
• Are administrators using phishing-resistant MFA?
• Can users still use SMS or telephone calls?
• Is legacy authentication blocked?
• Are unmanaged devices allowed to access company data?
• Can active sessions be revoked quickly?
• Is token protection available for our applications?
• Are risky sign-ins monitored?
• Are OAuth application permissions reviewed?
• Are mailbox forwarding and rule changes monitored?
• Is endpoint security deployed to every business device?
• Is there a tested account-compromise response plan?
• Are help-desk identity checks strong enough?
• How long are identity and audit logs retained?

Clear answers should be documented rather than based on assumptions.

Common MFA Security Mistakes

Assuming MFA Makes an Account Unhackable

MFA reduces risk but does not eliminate phishing, token theft, endpoint compromise or social engineering.

Allowing Weak Methods Indefinitely

SMS and telephone-based methods may remain enabled long after stronger options become available.

Protecting Only Administrators

Finance, executives, HR and support staff can also be high-value targets.

Trusting Every Authenticated Session

Authentication occurred at one moment. The session may become risky later.

Ignoring Device Health

A compromised laptop can undermine a secure login.

Failing to Revoke Tokens

Changing the password without revoking sessions may leave the attacker connected.

Allowing Uncontrolled Browser Extensions

Extensions may gain broad access to web activity and business data.

Ignoring OAuth Consent

An authorised malicious application may retain access independently of the password.

Weak Help-Desk Verification

Attackers may bypass technical controls by persuading support staff to reset them.

No Tested Response Process

Token theft moves quickly. Teams should not be discovering the revocation process during an active compromise.

MFA and Cyber Insurance

Insurers frequently ask whether MFA is enabled, but a simple yes-or-no answer may not describe the actual security posture.

Organisations should know:

• Which users are covered
• Which applications are covered
• Which MFA methods are allowed
• Whether administrators receive stronger controls
• Whether remote access is protected
• Whether legacy protocols bypass MFA
• Whether device compliance is required
• Whether security controls are monitored

Answer insurance and compliance questions accurately.

“MFA enabled” does not necessarily mean every identity route is protected equally.

Final Thoughts

MFA is still essential, but it is no longer enough to treat the authentication prompt as the final security boundary.

Token theft attacks target the authenticated session created after the user has completed MFA. Through adversary-in-the-middle phishing, malware, unsafe browser extensions, OAuth abuse or compromised devices, an attacker may obtain session material that allows access without repeating the original sign-in process.

The strongest response is layered.

Adopt phishing-resistant authentication, especially for administrators and high-risk users. Require secure, managed devices for sensitive access. Use risk-based Conditional Access, endpoint protection, session monitoring and token-protection features where supported.

Just as importantly, prepare for compromise. Your IT or security team should know how to revoke active sessions, inspect mailbox rules, remove malicious applications and isolate affected devices quickly.

MFA has not failed. The threat has moved beyond the MFA prompt.

Businesses now need to protect the complete identity lifecycle—from the first login request to every token, device and session that follows.

Worried That MFA Is No Longer Protecting Your Business?

Hamilton Group can help you assess how well your Microsoft 365 and cloud identities are actually protected.

Our experts can help you:

• Review your current MFA methods
• Deploy phishing-resistant authentication
• Configure Microsoft Entra Conditional Access
• Secure administrator and finance accounts
• Block legacy authentication
• Strengthen device-compliance controls
• Improve endpoint detection and response
• Review OAuth applications and mailbox forwarding
• Build account-compromise response procedures
• Monitor suspicious sign-ins and token activity
• Train staff to recognise advanced phishing attacks

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to discuss stronger identity protection for your business.