Why can an app password or a machine identity's client secret never present a second factor?
answer
- No human, no prompt
- A substitute for the interactive flow
- Separate object, separate revocation
- Enrolment count never sees these
- Scope and source, not challenge
basics
~20 sNeither has a human at the other end to prompt. An app password is issued as a substitute for the whole interactive flow the challenge lives in, and a machine identity authenticates with a secret alone. Both are separate credentials that outlive a user password rotation.
solid answer
~50 sA second factor requires an interactive conversation: a surface that can render a challenge and a person who can answer it. An app password exists precisely because a client cannot hold that conversation — it is a generated secret that stands in for the entire interactive flow, so it bypasses the challenge by design, not by misconfiguration. A non-interactive machine identity is the same shape with no user behind it at all: it presents a client secret or certificate and is done. The practical consequences matter more than the definition. These credentials are separate objects with their own lifecycle, so rotating the user's password does not retire them — they must be revoked individually. And the only controls that bite are ones that do not need a prompt: narrow the permissions, restrict the source, prefer a certificate over a shared secret, and give it a dated end.
go deeper
Know what an app password is for: a client that cannot perform modern authentication needs a credential that stands in for the interactive flow, so no challenge appears. Recall that it must be revoked separately from the account password.
Explain the structural requirement for a challenge — a rendering surface, a person, and a partially-authenticated protocol state — and why neither credential type has any of the three.
Demonstrate the operating consequences: inventorying these credentials, scoping and source-restricting them, preferring certificates, and knowing exactly what a password reset does and does not retire.
Own the argument that a user-enrolment metric structurally cannot see these paths, and be ready to justify the cost of migrating clients off them against leaving them scoped and dated.
## What a second factor structurally requires A challenge needs three things: a **surface** that can render it, a **participant** who can answer it, and a **protocol state** that says "credential accepted so far, still not authenticated". Interactive sign-in has all three. The two credential types in this question are defined by lacking them. ## An app password An app password is a long, randomly generated secret that a directory issues for one client that cannot perform modern authentication — an older desktop mail client, a device that only speaks a legacy protocol. The client sends it exactly where it would have sent the account password. The crucial point is the *purpose*: **it is not a password that happens to skip the factor, it is the mechanism by which the factor is skipped.** It exists so that an enrolled user can still use a client that has no way to challenge. Asking "why doesn't the app password require MFA?" is like asking why a spare key does not ring the doorbell. Three properties follow, and they are what interviewers probe: - **It is a separate credential object.** Rotating or resetting the user's sign-in password does not automatically retire an app password; it has to be revoked in its own right. Anyone who treats a password reset as a full credential reset for that account is wrong. - **It typically grants the same reach as the account.** It is a substitute for the user's credential, not a scoped-down one, so a leaked app password is close to a leaked account. - **It cannot be conditioned on anything interactive.** Device compliance, a location prompt, a re-challenge on a risky sign-in — none of these have a surface to appear on. ## A non-interactive machine identity A service principal, workload identity or machine account authenticates with a **client secret** or a **certificate**. No user is present, by design: this is a program calling an interface at 03:00. There is nobody to answer a challenge, so the credential *is* the authentication. Candidates often propose "enrol the service account in MFA". This is the wrong answer this question aims at, and it is wrong for a structural reason rather than a policy one. There is no interactive session to challenge and no human to respond, so the enrolment either cannot be completed or produces a factor nothing will ever request. Worse, some estates then record that identity as *enrolled*, which inflates the very metric that was already misleading. ## The line this leaf turns on **The enrolment percentage is not the enforcement percentage.** Every app password and every machine identity is a path that structurally cannot be enforced, and each one is invisible in a user-enrolment count. An estate can be at 100% enrolment and still expose dozens of credentials that will never meet a challenge in their lifetime. This matters to an adversary for a specific reason: these credentials are **stable**. A user's password changes on a schedule, may be reset after a scare, and is tied to a person who may leave. A client secret sits in a configuration file, a build variable or a device's settings page, expires on a date somebody set years ago, and survives every event that would have disturbed a user credential. For an operator who wants a way back in that outlives the noise, that is the more valuable object. ## Controls that work without a prompt Since "require a factor" is unavailable, the effective control classes are the ones that reduce what the credential is worth or where it works: - **Least privilege on the identity itself** — the credential should reach exactly one mailbox, queue or API surface, and never inherit a person's full access. - **Source restriction** — accept the credential only from the addresses or network the workload genuinely uses. - **Certificate over shared secret** — a private key that never leaves a keystore is harder to copy out of a configuration file than a string. - **Short, dated lifetime with a named owner** — an unowned secret with a five-year expiry is a permanent path. - **Retire the app password entirely** by moving the client to modern authentication, which is the only step that removes the path rather than pricing it. A good answer ends by pointing at the inventory problem: nobody can scope credentials they have not enumerated, and app passwords in particular are usually created by users, one at a time, without anyone recording why.
- An engineer proposes enrolling the service principal in MFA. What do you tell them?That there is no interactive session to challenge and no human to answer, so the enrolment either cannot complete or registers a factor nothing will ever request. Worse, it can make the identity look protected in an enrolment count. Point them instead at scoping the identity's permissions, restricting its source, replacing the shared secret with a certificate and giving it a dated expiry.
- Why is a client secret often more valuable to an adversary than a user's password?Because it is stable. A user password rotates on a schedule, gets reset after a scare and dies when the person leaves. A client secret sits in configuration, expires on a date somebody chose years ago, is rarely owned by anyone, and is untouched by every event that disturbs a user credential — so it is a way in that outlives the disturbance.
- After resetting a compromised user's password, what else must you retire?Any credential issued beside the password rather than being it: app passwords generated for that account, any machine identity secrets the user created, and delegated access they granted. Each is a separate object with its own revocation. Session and token invalidation is a related but distinct step and does not follow from the password change either.
saying these in an interview costs you the question
- Proposes enrolling a service principal in MFA
- Thinks a password reset invalidates app passwords
- Assumes an app password is scoped narrower than the account
- Calls a non-challenging path a misconfiguration rather than a design
- Counts machine identities in a user enrolment figure