Identity as an Anchor: why "we have MFA" is not a security statement

Introduction

In many organisations the conviction still lives that "we have MFA, so we are fine".
But anyone who regularly digs into Microsoft 365 environments knows that this is usually not a security statement, but rather an assumption without proof.

In practice we see environments where MFA is mandatory on paper, but where:

• exceptions exist because employees expect that the employer is "not allowed to use" their private smartphone
• BYOD devices are insufficiently controlled or even fall completely outside compliance
• Windows Hello for Business is "available" but not enforced
• admins have exceptions that are actually not defensible

The reality is: identity is only an anchor point when controls are enforceable, provable and measurable.
Without those three principles, MFA remains a checkbox, not security.

Technical deep dive

MFA coverage ≠ MFA enforcement

Figure 1: Entra ID - Authentication Methods - Monitoring - Activity

In Microsoft Entra ID almost any environment can show that x% of users have registered an MFA method. But that is not proof of security.

Enforcement only happens when Conditional Access actually prevents a user from getting in without strong authentication:

• Authentication Strengths
  → enforceable phishing-resistant paths
• Policy evaluation (CA)
  → which combinations of user/device/location/app are effectively allowed
• Risky sign-ins & user risk
  → where Entra ID actively computes signal-based risk
• Device compliance
  → essential to counter cookie theft and token replay

That last one is crucial: without device compliance, identity security is always half work.
It becomes technically very hard for an attacker to abuse a refresh token when that token is bound to a compliant device and TPM hardware. This is exactly why WHfB, Cloud Kerberos Trust and modern token binding form a cornerstone of a phishing-resistant path.

Figure 2: Entra ID - Conditional Access - Authentication Strengths

Admins and privilege flows

Different rules apply to admin accounts than to regular users. One mistake or one misleading click can compromise an entire tenant. Therefore:

• no BYOD
• no weak MFA methods
• no exceptions
• no mailbox or Teams account on the admin profile
• restricted internet use (only necessary whitelisted Microsoft endpoints)

An admin account is not a "work account". Communication, lookups, email and browsing always happen from a regular user account. The admin account stays sterile and is only used for administration.

Minimum requirements:

• phishing-resistant portable credential (such as FIDO2 or passkey)
• local credential such as Windows Hello for Business
• strict Conditional Access, tuned to privilege level
• PIM governance, so admin rights only exist temporarily

What we observe in practice

Time and again we see the same patterns:

• MFA is "mandatory", but only for the 80% who agreed to an authenticator app
• the remaining 20% have exceptions that are not compensated
• BYOD devices sit in a grey zone without compliance
• WHfB is on, but nobody checks whether users actually use it
• no single group has a phishing-resistant enforcement policy
• Conditional Access policies are "report-only" instead of blocking

This kind of risk usually only becomes visible when you have the environment systematically analysed through a security audit.

Figure 3: Entra ID - Users - Sign-In Logs - Filter

Why this is a real risk

When identity is not an enforceable anchor point:

• MFA can be bypassed via legacy sign-in paths
• token/cookie theft remains possible on non-compliant devices
• users with exceptions form direct attack routes
• admins become a too-weak link
• risk signals in Entra ID are ignored because they are not linked to CA handling
• shared devices create token exposure
• CA policies do not cover scenarios at OS level (iOS vs Android vs Windows)

The problem therefore is not whether MFA exists, but whether identity is consistently used as a legal, technical and operational source of proof.

What a mature approach looks like

A mature identity strategy is not a list of settings, but a consistent model. The power lies in coherence.

1. Identity is the anchor point

• device compliance is mandatory
• tokens are hardware-bound
• no access without modern, traceable authentication
• non-compliant devices get maximally restricted access

Figure 4: Entra ID - Devices - All Devices - Filter

2. Users are classified in personas

As Microsoft recommends:

• admins & highly regulated users
• non-admins

Each persona gets:

• a preferred portable credential
• a local credential (WHfB, Secure Enclave, passkeys and so on)
• applicable CA policies

3. Enforceability above configuration

Not: "We have enabled passkeys."
But: "All users in group X may only sign in via phishing-resistant authentication."

4. No BYOD unless heavily restricted

BYOD without compliance means identity can never be a reliable anchor point.

5. Exceptions are deliberate, limited and compensated

Not the other way around: no exceptions that undermine the model.

Reflection & conclusion

• Practice shows that "MFA for everyone" often fails on the basis of perception, union pressure or BYOD expectations. That is why enforcing 80% is better than enforcing 0%.
• Device compliance is an essential part of identity security because cookie theft hardly works on a TPM-bound token.
• For admins, phishing-resistant is the only acceptable option, without exceptions.
• MFA coverage says nothing: only enforceability, identity signals and measurable policies form a hard anchor point.

The future of identity security therefore does not revolve around "having MFA", but around evidential value, traceability and enforceable standards.

Many of these risks only become visible when your identity configuration is systematically reviewed, precisely where a thorough security audit makes the difference.