Identity Is the New Perimeter (And MFA Isn’t Enough)

Check out this blog from Secure Nexus which explores identity security and the limitations of MFA.

For years, cyber security strategies were built around a clear boundary. Systems and data sat inside the corporate network, protected by firewalls, while threats remained outside. That boundary has largely disappeared.

Today, people work from home, on the move and across multiple devices. Business-critical data sits in Microsoft 365 and other software-as-a-service platforms. Suppliers, contractors and automated services may all require access. In this environment, the identity of the person, or system, requesting access has become the new perimeter.

Many organisations believe they have addressed this risk because multi-factor authentication (MFA) is enabled. MFA remains one of the most valuable security controls an organisation can deploy, but it should be treated as a foundation, not a finish line.

The reality is that attackers do not always need to defeat MFA. Increasingly, they steal the trusted session created after MFA has already succeeded.

How attackers get around conventional MFA

When a user signs in to Microsoft 365, they enter their credentials and complete an additional verification step. Once that process succeeds, the service issues a session token. This token allows the user to move between applications without repeatedly entering a password or approving another prompt.

That convenience is essential to how modern cloud services work. It also creates an opportunity: if an attacker obtains a valid session token, they may be able to impersonate the user without completing the original sign-in process again.

One common method is adversary-in-the-middle, or AiTM, phishing. The victim follows a link to what appears to be the genuine Microsoft sign-in page. Behind the scenes, the attacker’s infrastructure acts as a proxy, relaying information between the user and Microsoft in real time. The victim enters the correct password and completes MFA; Microsoft validates both. The attacker then captures the authenticated session token returned afterwards.

This is why the phrase “MFA bypass” can be misleading. In many cases, MFA has worked exactly as designed. The attacker has simply stolen the proof that authentication was successfully completed. Microsoft’s own incident-response guidance confirms that a stolen token may be replayed even where the legitimate user has satisfied MFA.

Once inside, an attacker may read email, search SharePoint or OneDrive, monitor conversations and create inbox rules to conceal their activity. They may use the compromised account to launch convincing internal phishing messages or insert fraudulent payment details into a genuine email chain. Because the activity takes place through a trusted identity, it can be more difficult to distinguish from normal work.

Not all MFA provides the same protection

This does not mean organisations should abandon MFA. It means they should examine which methods they use and what controls surround them.

SMS codes, one-time passcodes and push notifications provide significantly more protection than a password alone, but they can still be phished, relayed or approved by mistake. The UK National Cyber Security Centre explicitly notes that not all MFA methods offer equal protection and recommends phishing-resistant approaches where appropriate.

Passkeys, FIDO2 security keys and certificate-based authentication are stronger because authentication is tied to the legitimate service. They are designed to resist a user being tricked into authenticating through a fraudulent website. Microsoft Entra ID can also use authentication strengths within Conditional Access policies, allowing organisations to require phishing-resistant methods for administrators, finance teams and other sensitive roles.

The goal should be progressive improvement, not paralysis. An organisation using passwords alone should enable MFA urgently. One already using app-based approvals should begin moving its highest-risk users and actions towards phishing-resistant authentication.

Protect the whole session, not only the login

An identity-first approach asks more than “Did this person pass MFA?” It continuously considers whether the access request makes sense.

Conditional Access can evaluate signals such as the user, device, application, location and level of risk before granting access. A business might require that sensitive information can only be accessed from a managed and compliant device, block legacy authentication, apply stronger controls to privileged accounts, or demand fresh authentication when risk increases.

Device trust is particularly important. If access is allowed from any browser on any unmanaged device, possession of valid credentials or a stolen session may be enough. Requiring a compliant or appropriately joined device connects identity security with endpoint security: the organisation is assessing both who the user is and whether the device itself can be trusted.

Microsoft also provides token protection controls intended to reduce replay attacks by binding supported sign-in session tokens to the device for which they were issued. This is not a universal solution. Support varies by platform, application and token type, but it demonstrates the direction identity security is moving: a token should not automatically be trusted simply because it is valid.

Monitoring must continue after authentication. Organisations should look for impossible or unusual travel, unfamiliar devices, anomalous sign-in properties, suspicious inbox rules, unexpected changes to MFA methods and unusual access to cloud data. These signals need a defined response process; alerts that nobody reviews are not an effective control.

Five practical priorities

Organisations do not need to redesign their entire environment overnight. They can begin with five practical steps:

1. **Understand the current position.** Identify which accounts have MFA, which methods are registered, where legacy authentication remains and whether any privileged or service accounts fall outside policy.

2. **Strengthen privileged access first.** Separate administrative accounts from everyday user accounts, minimise standing privilege and require phishing-resistant authentication for administrators and other high-impact roles.

3. **Use Conditional Access deliberately.** Build policies around risk, device compliance, application sensitivity and authentication strength. Deploy changes carefully, using report-only modes and maintaining protected emergency-access accounts.

4. **Reduce session risk.** Review session lifetime and reauthentication settings, revoke sessions promptly during an incident, and assess where device-bound token protection is supported and appropriate.

5. **Monitor identities as closely as endpoints.** Bring sign-in, audit, email and cloud-application telemetry into active monitoring, with clear thresholds and tested response procedures.

A change in mindset

The old security perimeter assumed that being inside the network meant being trusted. The modern equivalent is assuming that a successful login means the user can be trusted for the rest of the session. Both assumptions are now too weak.

MFA remains essential, but a tick beside “MFA enabled” should not create false confidence. Effective identity security combines phishing-resistant authentication, Conditional Access, device trust, least privilege, session protection and continuous monitoring.

The key question is no longer simply, “Has this user logged in securely?” It is: “Should this identity, on this device, under these conditions, still have access right now?”

That is what it means to treat identity as the new perimeter.

Further reading

– [Microsoft: Defeating adversary-in-the-middle phishing attacks](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/defeating-adversary-in-the-middle-phishing-attacks/1751777)

– [Microsoft: Token theft playbook](https://learn.microsoft.com/en-us/security/operations/token-theft-playbook)

– [Microsoft: Token Protection in Conditional Access](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection)

– [NCSC: Recommended types of MFA](https://www.ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa)