The response itself is part of what gets checked
Account enumeration infers which accounts genuinely exist by observing subtle differences in how a system responds to valid versus invalid identifiers — a login form returning 'incorrect password' for a real account but 'no such account' for a fictitious one leaks exactly this distinction, even though neither response reveals the actual password. An attacker can use these differences to build a list of real accounts to target with further attacks, entirely without guessing a single correct credential along the way.
The same pattern shows up beyond login forms specifically: a password-reset flow, an invitation system, or any endpoint that behaves detectably differently for existing versus nonexistent identifiers can leak the same kind of information, even where the endpoint's primary access-control logic is otherwise entirely correct.
Uniform responses as the direct fix
The fix is to make the observable response — the message, and ideally the timing — identical regardless of whether the identifier in question corresponds to a real account, so that the response itself carries no distinguishing information either way. This sometimes trades a small amount of user-facing clarity (a user genuinely uncertain why their reset request didn't arrive) for the security benefit of not handing that same information to anyone probing the system at scale.