Based on the provided knowledge sources, Ory Network does not natively force users to set up 2FA (multi-factor authentication) before allowing them to log in for the first time. The standard flow is that users can log in with their primary factor (e.g., password), and then optionally enable 2FA (such as TOTP, SMS, or email codes) from their account settings. Users are not automatically prompted or required to set up 2FA during their initial login or registration process. Instead, enabling 2FA is a user-driven action after account creation and login, as described in the TOTP and MFA documentation: > In the Ory Account Experience, users are not automatically prompted to enable TOTP for their accounts. To enable TOTP, users must sign in to their accounts and go to the Authenticator App section of the Account Settings page. [Time-based one-time passwords (TOTP)](https://www.ory.sh/docs/kratos/mfa/totp) If you want to enforce 2FA setup before allowing users to access your application, you would need to implement custom logic using Ory Actions or webhooks to check if a user has 2FA configured and, if not, restrict access or redirect them to the 2FA setup flow. However, the knowledge sources do not provide a built-in configuration or a step-by-step guide for this specific enforcement scenario. If strict enforcement of 2FA is required for all users, you may consider using the "strict" MFA enforcement model, which requires the highest available authentication level for sensitive operations, but this still does not force 2FA setup at the initial login—it only enforces its use if configured by the user [Step-up authentication](https://www.ory.sh/docs/kratos/mfa/step-up-authentication). In summary, Ory Network does not currently provide a built-in way to force users to set up 2FA before their first login. Custom implementation would be required to achieve this behavior.

To implement custom logic—such as forcing users to set up 2FA before allowing them to log in—you can use Ory Actions with webhooks. The relevant documentation for configuring and using webhooks in Ory Network is: - [Trigger custom logic and integrate with external systems with webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks): This guide explains how to set up webhooks for various flows (login, registration, etc.), how to configure the HTTP request, and how to use Jsonnet templates to customize the request body. It also covers how to handle webhook responses, including flow-interrupting webhooks that can block or allow user actions based on your external logic. - [Flow-interrupting webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks): This section details how to configure webhooks so that the response from your external service can interrupt (block) the flow, which is useful if you want to prevent login or registration until certain conditions (like 2FA setup) are met. These resources will help you set up the necessary hooks to enforce custom authentication requirements in your Ory Network project.

You're correct that you can use a flow-interrupting webhook on the login flow to enforce custom logic, such as requiring 2FA setup before allowing login. The webhook receives a context (

ctx

) with information about the user and the flow, which you can use to make your decision. What to look for in the webhook context (

ctx

): While the knowledge sources do not provide a full schema of the webhook payload, they do indicate that you can inspect user traits and session information. Typically, you would check if the user has a second factor (like TOTP or another MFA method) configured. If not, you can interrupt the flow and return a message instructing the user to set up 2FA. How to interrupt the flow: Configure your webhook with

response.parse: true

. If your external service returns a 4xx or 5xx HTTP status, the flow will be interrupted, and you can provide a custom error message to the user. See the [flow-interrupting webhooks documentation](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks) for details and example payloads. Settings flow consideration: You are also correct that login hooks may be triggered when a user is redirected to the settings page (for example, to set up 2FA). Blocking access to settings would prevent users from enabling 2FA, creating a deadlock. How to proceed: - In your webhook logic, check the context to determine if the user is trying to access the settings flow for the purpose of setting up 2FA. If so, allow the flow to continue. - Only interrupt the login flow if the user is not in the process of setting up 2FA and does not have 2FA configured. Unfortunately, the knowledge sources do not provide a detailed example of the webhook context or a ready-made solution for distinguishing between a regular login and a login that is part of a settings/2FA setup flow. You may need to experiment with the payload your webhook receives to identify the relevant fields (such as flow type, requested URL, or traits indicating 2FA status). Summary: - Use a flow-interrupting webhook on the login flow. - Inspect the webhook context for 2FA status and flow type. - Allow access to settings for 2FA setup, but block other logins if 2FA is not configured. - Refer to the [webhook integration guide](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks) and [flow-interrupting webhooks](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#flow-interrupting-webhooks) for configuration details. If you need more details about the webhook context structure, you may need to log or inspect the payloads sent to your webhook endpoint during different flows, as the knowledge sources do not provide a full schema.

I'm sorry, but the knowledge sources do not provide a detailed schema or explicit example of the webhook context (

ctx

) that would allow you to reliably determine from the webhook payload whether the user is accessing the settings flow specifically for the purpose of setting up 2FA. The documentation mentions that the

ctx

object includes information about the flow and the identity, but it does not specify which fields (if any) indicate the intent or type of the flow beyond general flow information and user traits. The webhook documentation does show how to access the identity and flow objects in the context, but it does not detail how to distinguish between a login for general access and a login as part of a settings/2FA setup process. You may need to inspect the actual payloads sent to your webhook endpoint to determine if there is a distinguishing field, but this is not covered in the official docs provided here [Define HTTP request](https://www.ory.sh/docs/guides/integrate-with-ory-cloud-through-webhooks#define-http-request). If you need to make this distinction, you may have to experiment and log the incoming webhook payloads during different flows to see if there is a reliable indicator. The knowledge sources do not contain enough information to answer your question with certainty.