skip to content

With every user MFA-enrolled, how can one valid password still open a mailbox?

level: juniorimportance: must knowfreq 68%

answer

  1. Enrolled is not the same as enforced
  2. Count paths, not users
  3. Which endpoint can even prompt?
  4. One command, one answer, no second step
  5. Block is the only enforcement there

basics

~20 s

Enrolment is counted per user; enforcement is a property of each authentication path. A legacy mail protocol endpoint using basic authentication has no step in which a factor can be demanded, so the password alone succeeds there while the browser sign-in still challenges.

solid answer

~50 s

Because "MFA is on" is a statement about accounts, not about paths. Enrolment says how many users have registered a factor; enforcement asks, for each way of authenticating to this tenant, whether a factor can be demanded at all and whether it actually is. An interactive sign-in redirects to the identity provider, which can render a challenge. A legacy mail endpoint speaking `IMAP`, `POP3` or `SMTP AUTH` with basic authentication takes a username and password in one command and answers `OK` or `NO` — there is no message in that exchange that means "now prove a second thing", and no user agent to redirect. So a policy saying "require MFA" either does not evaluate on that path or degrades to allow-or-block. For an initial-access broker holding one valid password, that path is the whole product: a working mailbox, on an account the tenant believes is protected.

code

text · 10 lines
text
interactive sign-in (modern authentication)
  client -> identity provider : authorization request
  provider -> user           : password prompt
  provider -> user           : second-factor challenge   <-- a factor can be demanded here
  provider -> client         : token issued

legacy mail endpoint (basic authentication)
  client -> server : a1 LOGIN [email protected] Summer2026!
  server -> client : a1 OK LOGIN completed                <-- no step exists that could demand one
  ...

go deeper

for a junior

Be ready to state the distinction in one sentence: enrolment counts users, enforcement is per authentication path. Know that basic authentication on a mail endpoint has no step where a factor could be requested.

for a middle

Explain the exchange itself — one command carrying username and password, one success or failure reply, no redirect and no rendering surface — and why a require-a-factor rule can only allow or block there.

for a senior

Show how you would enumerate every enabled path in an estate and state the enforcement figure honestly, including which paths you would block outright and what breakage you would expect from doing so.

for a principal

Own the framing for leadership: the reported metric is measuring the wrong object. Be able to explain why replacing it with a path-level measure changes what the organisation funds.

## Two different numbers that sound like one "Multi-factor is on for everyone" is almost always a **user count**: how many accounts have at least one second factor registered in the directory. That number can honestly be 100%. **Enforcement is a property of an authentication path**, not of a user. For each distinct way of proving identity to this tenant, two separate questions apply: 1. Can this path present a second-factor challenge *at all*? 2. If it can, is it actually configured to? A tenant with 100% enrolment and one enabled legacy path has an enforcement figure well below 100%, and nobody is lying — they are quoting the wrong measurement. ## What a path is, concretely **Interactive sign-in with modern authentication.** The client hands the user to the identity provider. The provider owns a rendering surface (a browser or a native prompt), so it can ask for a password, then ask for something else, then issue a token. A factor is *possible* here because there is a conversation with a human in it. **A legacy mail protocol endpoint with basic authentication.** The client opens a connection and submits the whole credential in a single command: ``` a1 LOGIN [email protected] Summer2026! a1 OK LOGIN completed ``` The protocol defines success and failure. It defines no state between them that means "partially authenticated, awaiting a second proof", and there is no redirect and no rendering surface. **The password is not merely sufficient by policy; it is sufficient by protocol design.** The same is true of `POP3` `USER`/`PASS` and of `SMTP AUTH LOGIN`/`PLAIN`. ## Why the policy engine does not save you Contextual access rules are normally authored with interactive sign-in in mind: require a factor, require a compliant device, require a known location. Evaluated against a path that cannot challenge, "require a factor" has no meaningful satisfaction — the engine can only permit the sign-in or refuse it. **On a path that cannot prompt, blocking is the only enforcement that exists.** Any rule that stops short of blocking leaves the password as the sole gate. This is why the honest question to an IT lead is never "is MFA on?" but "which paths into this tenant are enabled, and which of them can challenge?" A useful enumeration: | Path | Can it challenge? | |---|---| | Interactive web or native sign-in | Yes | | Legacy mail protocol with basic authentication | No | | App password issued for an older client | No | | Non-interactive machine identity with a secret | No | ## Why the adversary cares about exactly this An **initial-access broker** is an operator whose entire business is obtaining a working way in and reselling it. They are not trying to escalate, move sideways, or stay for months; those are somebody else's costs. Their product is a credential that *works*, and the value of the product collapses the moment the buyer meets a challenge they cannot answer. So a password harvested from a breach corpus is worth very little against an estate where the only way in demands a factor — and a great deal against the same estate if one non-challenging path is still enabled. **The gap between enrolment and enforcement is the difference between a dead password and a saleable one**, which is why this is the first thing worth checking rather than a footnote. It also explains something that surprises people: the account being enrolled makes no difference to the broker. The factor is registered against the user; the path they use never asks for it. ## What actually removes it Only two control classes touch a path that cannot challenge: - **Remove the path.** Disable basic authentication at the endpoint, tenant-wide, and let the failures tell you who still depended on it. This is the real fix and it is the only one that removes the adversary's dependency rather than raising its price. - **Reprice the credential.** Where a path genuinely cannot be retired yet, make what it reaches worth less: a separate identity, no read access it does not need, restricted to known source addresses, short-lived, with a dated end. Notice that a longer password, a stricter rotation interval and a breach-screening list all raise the cost of *obtaining* the password. None of them change what happens once somebody has it. On a path with no second step, the password is the whole authentication decision.

  • Which authentication paths in a typical tenant structurally cannot present a factor?
    Legacy mail protocol endpoints using basic authentication (`IMAP`, `POP3`, `SMTP AUTH`), app passwords issued for clients that predate modern authentication, and non-interactive machine identities authenticating with a client secret or certificate. All three hand over one credential in a single step with no human at the other end, so there is nothing to prompt and nobody to answer.
  • If you block the legacy endpoint tenant-wide, what breaks?
    Whatever still speaks it: multifunction scanners and printers that send mail, older desktop mail clients, monitoring and ticketing integrations that poll a shared mailbox, and scripts nobody owns. That inventory is the point of the exercise — the breakage list is the list of paths you did not know you were trusting.
  • Does a password rotation close this path?
    For the account's own password, yes — the same secret is used on both paths, so rotating it invalidates the legacy path too. It does not touch credentials issued *beside* the password, such as app passwords or a machine identity's client secret; those are separate objects and must be revoked separately.

Counting how many staff have been issued a badge tells you nothing about the loading bay, where a key still works and no guard is standing.

saying these in an interview costs you the question

  • Says MFA is on, so a reused password no longer matters
  • Quotes the enrolment percentage as the enforcement percentage
  • Assumes contextual access rules evaluate on every protocol
  • Believes basic authentication is safe because the transport is encrypted
  • Thinks the factor being registered protects every path to that account

context

resolving links…