We have MFA. Why that is not enough

Why "do you have MFA" is not a question

Control of corporate security has moved from the network perimeter to the identity. That changes what an attacker has to acquire. Not a route into your network — an account, or the artefact your identity provider hands out once it has finished checking the account.

The regulation reflects the shift. Article 21(2), point (j) of NIS2 names "the use of multi-factor authentication or continuous authentication solutions ... within the entity, where appropriate" among the minimum measures. Financial entities have Article 9(4)(d) of DORA — policies and protocols for strong authentication mechanisms, based on relevant standards — and Article 21, point (f)(ii) of Regulation (EU) 2024/1774 makes it concrete: strong authentication for remote access to the network, for privileged access, and for ICT assets supporting critical or important functions or publicly available.

So an organisation switches MFA on, answers the questionnaire, and satisfies the auditor. The attacker is unaffected by any of that, because none of it was a test.

Read point (f) of the same NIS2 paragraph: "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". The directive asks for the control and, in the next breath, asks whether it works. DORA Article 25(1) is more explicit still, listing scenario-based tests and penetration testing inside the resilience testing programme. The obligation to verify is already written down. It is the part that is usually absent.

This distinction between a declared control and an exercised control informs my practical approach. My author profile links to the doctoral record and research publications; a result in one environment is not proof that another environment is protected.

What "we have MFA" usually leaves out

Start with coverage. Review the following authentication paths and their actual configuration.

Basic authentication and other single-factor paths. Check the authentication mechanism, not just the protocol name: a protocol may support modern OAuth authentication. Find password-only access that bypasses the intended policy and establish how to retire or protect it.

Service and application identities. Non-interactive workloads need workload-appropriate controls: managed identities or protected credentials, limited permissions and monitoring. An interactive MFA prompt is not a universal solution for unattended jobs. Review human accounts being used as service identities separately.

Emergency access accounts. Design them to survive normal access failures, with independent phishing-resistant authentication and monitored use. Exclusion from blocking Conditional Access policies does not mean leaving them with a password alone. Follow the identity provider’s current emergency-access guidance and test recovery.

Guest and partner identities. Check resource-tenant policies and cross-tenant trust settings. The receiving organisation can require MFA or accept appropriate claims from the home tenant; do not assume either outcome without checking.

Remote access outside the identity provider. A VPN concentrator with local accounts, an appliance with its own user database, a remote support tool with a separate login. None of them see your Conditional Access rules.

Third-party administrative access. The supplier console, the managed service provider's account, the vendor supporting the ERP — which belongs in the conversation with a bank or an essential entity as much as in your own review.

Four ways past MFA that is switched on

The phishing page that is the real login page. An adversary-in-the-middle kit does not imitate the login screen; it relays it. The victim sees the genuine page, because it is the genuine page, arriving through the attacker's proxy. The password is correct, the second factor is correct, the service issues a session cookie — and the proxy keeps a copy. The attacker replays it and is inside, with no prompt at all. ENISA's Threat Landscape 2025 puts phishing at 60% of intrusion and names FlowerStorm, a phishing-as-a-service kit mimicking Microsoft 365 portals and bypassing MFA. The second factor was completed correctly. That is the point of the technique.

Token theft and replay. The same outcome without any phishing. Malware on an endpoint reads the browser's cookie store or the token cache and exports it; ENISA describes info-stealers as primarily facilitating credential theft, session hijacking and access brokering. ATT&CK carries it as T1550.004: the session is already authenticated, so the authentication step is skipped. If sessions are long and nothing checks where a token is used from, the theft is worth more than the password ever was.

OAuth consent. An application can receive delegated access after an apparently legitimate approval. The resulting permissions and grant may remain even when a password changes; investigate grants, credentials and issued tokens separately. Check your tenant’s consent policy and existing applications rather than assuming every user can approve every application.

Push fatigue, enrolment and recovery. Repeated approval prompts until somebody accepts one, at two in the morning or during a meeting; ATT&CK records it as T1621. The human factor here is not stupidity, it is the design: the prompt asks a person to make a security decision with no context, dozens of times a week, and trains them to clear it. Enrolment and recovery are softer still. A convincing caller asks the service desk to reset a lost factor and enrols their own. SMS and voice codes add SIM swap and signalling-network abuse — CISA's fact sheet lists both, and ENISA reports continued exploitation of SS7 and Diameter.

What actually denies these attacks

Different controls address different paths. Test the combination against the applications you actually use.

Phishing-resistant authentication. FIDO2/WebAuthn credentials bind authentication to the relying party and origin. This resists a credential-relaying phishing site. It does not make a session token immune to theft after a legitimate login.

Device requirements and token binding. Requiring a compliant device in Conditional Access is not the same as cryptographically binding a token to that device. Microsoft Entra Token Protection has specific platform, application and resource support. Verify that the relevant session is covered before claiming that replay is blocked.

Session lifetime and revocation. Sign-in frequency, continuous access evaluation and token revocation can reduce exposure. Their effect depends on the client, resource and token type. Do not promise immediate revocation everywhere; measure when access stops in your supported applications.

Consent governance. Limit user consent to an approved low-risk scope, establish administrative review for other permissions and review existing grants. Remove unused access only after checking business dependencies.

Detection and reconstruction. Correlate sign-in, device, application consent and mailbox activity. An unfamiliar IP address or “impossible travel” alert is a lead, not proof of compromise. Your SIEM effectiveness assessment should test whether the necessary records are available and whether an alert leads to action.

These are complementary controls. A table of configured settings does not establish their effective coverage.

What verification actually looks like

The useful question is not "do you have MFA". It is: has anyone run the attack against your configuration, and looked at what your telemetry recorded. As a piece of work that has three parts, and a written authorisation before any of them.

First, a controlled test of the bypass paths against your own configuration — the enforcement gaps, a proxied login against your real sign-in page, replay of a session from a second machine, a consent request from an application we control, a factor reset through your documented recovery process. Agreed scope, agreed accounts, an agreed window.

Second, detection. Did anything fire, how long did it take, and did the alert reach a person or a queue nobody reads. A control that fails silently and one that fails loudly are different risks.

Third, reconstruction. Establish which account and application were involved, what the available session and device records show, and which actions can be substantiated. Missing logs may require a new source, additional licensing or retention changes; the work is not necessarily just a setting.

The output is a list of paths that were open, paths that were closed, and what your telemetry saw. Not a score, and no promised outcome: the finding may well be that your configuration holds and your logging does not.

What to do first

1. Review a representative period of sign-in logs by mechanism and account type. Inspect authentication details: a previous MFA claim can satisfy a policy without a fresh prompt. “Single factor” in one event is not, alone, proof of a bypass.
2. List access paths outside the main identity provider and name an owner for each.
3. Test revocation with an authorised test account, agreed applications and a rollback plan. Record how long access continues.
4. Review delegated and application permissions, including their owners and dependencies.
5. Prioritise administrators for phishing-resistant authentication, with tested emergency access before enforcement.
6. Choose log retention based on detection delay, investigation needs, applicable duties, privacy and cost. Confirm that the records can actually be retrieved.

Agree incident decision authority before a test or real event exposes an urgent access decision.

For an account already affected, follow the Microsoft 365 compromise checks. For planned access removal, use the offboarding verification process.

The boundary

This does not cover customer-facing authentication, where the trade-off with abandonment is a different discipline, nor payment authentication under PSD2. Nor does it settle what your supervisory authority will accept: "where appropriate" in NIS2 point (j) is a judgement your management body signs, not a technical setting.

Whether these obligations reach you at all is the prior question — start with the difference between DORA and NIS2. If you need the same controls written up as evidence a supervisor or a client can read, that is an evidence pack. And if identity is your strong side, the rest of the chain may not be: how ransomware actually gets in covers the routes that never touch a login page.

Rollout effort depends on applications, devices, licences and recovery arrangements. Pilot a representative group before committing to a price or a completion date.

If you want the bypass paths run against your configuration and the telemetry examined afterwards, rather than described, that is the practical improvements engagement.

Note. General information, not legal advice. What applies depends on the specific entity, its activity, licence, size, group structure and the national implementation.