Bypassing AAL2 in Settings Flow Using Email OTP for Both Factors

[AliAli1950]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

With the following configuration:
selfservice:
methods:
code:
mfa_enabled: true
flows:
settings:
required_aal: highest_available
A user who normally requires MFA to access settings ( has available_aal = aal2) can bypass the AAL2 requirement by using email OTP for both factors:
Start account recovery → receive an email OTP (recovery code) as the first factor.
Authenticate with that email OTP.
When prompted for MFA, use another email OTP (mfa email code) as the second factor.
Access the settings flow without providing a distinct second factor.
Questions
Is this expected behavior in Kratos when highest_available is used?
How can we prevent the same factor from being used twice to meet the AAL2 requirement?
Should Kratos enforce a distinct second factor for AAL2?

Reproducing the bug

(A user who normally requires MFA to access settings ( has available_aal = aal2))
Start account recovery → receive an email OTP (recovery code) as the first factor.
Authenticate with that email OTP.
When prompted for MFA, use another email OTP (mfa email code) as the second factor.
Access the settings flow without providing a distinct second factor.

Relevant log output

Relevant configuration

selfservice:
  methods:
    code:
      mfa_enabled: true
  flows:
    settings:
      required_aal: highest_available

Version

v1.3.1

On which operating system are you observing this issue?

None

In which environment are you deploying?

None

Additional Context

No response

[cmmoran]

It appears this is happening because code will provide aal2 when configured with mfa_enabled. code is also one of the options for account recovery; this provides aal1 with the method: code_recovery. The system marks these as distinct methods (or factors) and does not treat them as the same factor of authentication. One possible fix for this will require that if recovery via email is enabled, some other backup MFA must be enforced (e.g., lookup_code) so the MFA options available after account recovery include something other than technically the same option used to gain aal1.