It is tempting to define MFA as any two successful challenges. That definition is easy to implement, but it hides an important question: what would an attacker need to compromise to satisfy both challenges?
Count independent evidence, not screens
A password and another knowledge secret are not the same as a combination of different factor types. Likewise, two possession-based methods may add friction and reduce some risks, but do not automatically provide the same assurance as two distinct factor types. The benefit depends on what independent evidence the second step adds.
The protocol name is not enough. Examine how an authenticator stores its secret, how the user proves possession, whether phishing can relay the response and what the server can verify. Avoid classifying a method based on the visual shape of its prompt.
Use the distinction to design policy
Some applications may accept an entry-level factor for low-risk activities while a privileged action requires two distinct types or a phishing-resistant method. The policy should reflect the assets at stake and the threats to address, and it must remain understandable to operators who troubleshoot access.
WebFrolic documents an assurance model that distinguishes factor combinations and introduces intermediate product-specific levels for certain combinations. That can express practical requirements, provided administrators do not confuse an intermediate product level with a formal standard level.
Avoid a false sense of security
If an attacker can control the same device or phishing session used for both steps, adding a second prompt may provide less benefit than expected. Factor independence is one part of assurance; phishing resistance, device binding, recovery strength and session security also matter.
Ask concrete questions: what can an attacker do with a stolen password? What if a code can be relayed in real time? What if a session is hijacked but the attacker cannot enrol a new factor? These scenarios yield better tests than simply counting prompts.
Explain the decision plainly
Each assurance level should have a short operational explanation: which credentials qualify, which actions require them and why the combination is considered sufficient. Keep the configuration description and audit evidence aligned so an allow/deny result can be traced to a rule.
Review policy when protocols or enrolment options change. A new method changes the combinations that may satisfy a level; it should not accidentally lower assurance for a privileged operation.
In practice
List factor types and attacker capabilities for every authenticator.
Do not equate two challenges with two distinct factors.
Document accepted combinations for each assurance level.
Test phishing, session-hijack and new-factor scenarios.