> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/onboarding/account/require-mfa.md).
# Requiring MFA
Multi-factor authentication (MFA) adds a second layer of security on top of a user's password. By default, every Stoïk Protect user can enable MFA on their own account from `User settings` > `Security`, in the menu in the lower-left corner of the app.
For compliance reasons (ISO 27001, NIS2, cyber-insurance requirements, internal security policies) administrators can go one step further and **enforce MFA on specific users**: an enforced user is required to set up MFA before they can continue using Stoïk Protect.
## Identify users without 2FA
Before enforcing MFA, you usually want to know who is still unprotected. The `Settings > Users` table has a dedicated `2FA` column:
* :check: : the user has 2FA enabled.
* :xmark: : the user has not enabled 2FA yet.
To get a list of users to follow up with:
1. Go to `Settings > Users`.
2. Open the `2FA` filter at the top of the table.
3. Select `No`.
You now see only users without 2FA. From there, you can either reach out to them directly so they enable it themselves, or open each side panel and tick `Require MFA` to enforce it right away.
## Who can enforce MFA
Only users with the `Manage user rights` permission (i.e. administrators) can require MFA for another user. The `Require MFA` toggle is disabled for users without that permission.
## Requiring MFA for a user
1. Go to `Settings > Users` in Stoïk Protect.
2. Click on the user you want to enforce MFA on. Their side panel opens.
3. In the `Admin` section of the permissions form, tick **Require MFA**.
4. The change is saved with the rest of the permissions form.
{% hint style="info" %}
The same flow lets you turn enforcement off later by unticking the box. Disabling enforcement keeps MFA enabled for the user. They simply regain control over it and can disable it themselves from their settings if they want.
{% endhint %}
## What the enforced user sees
The change applies immediately. As soon as the user interacts with Stoïk Protect, they are sent to the mandatory MFA setup screen and stay there until MFA is fully configured.
* If they are currently using Stoïk Protect, their next click, page change, or refresh takes them to the MFA setup screen. They keep their existing login.
* If they are not currently using Stoïk Protect, they land on the MFA setup screen the first time they open it.
* The setup screen replaces every other page in Stoïk Protect until MFA is configured. The only way forward is to complete the setup.
The setup flow is:
1. **Choose a method**: The user selects between **Authenticator app** (recommended), **Passkey** or **SMS**.
2. **Complete setup**: They follow the steps for their chosen method (scan a QR code for the authenticator app, or enter a phone number for SMS).
3. **Confirm**: They enter a 6-digit code to verify the method.
4. **Done**: They are redirected to the page they were originally trying to reach.
## After MFA is enabled
* They sign in with their password and a second factor (authenticator app code, passkey or SMS code) every time.
* The option to remove their last active MFA method is disabled, with a tooltip explaining that MFA is required by their administrator.
## Edge cases
| Situation | Behaviour |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The user already has MFA enabled when the toggle is turned on | They keep using Stoïk Protect as usual. MFA stays required as long as the toggle is on. |
| An admin turns the toggle on for their own account | Allowed. Their next click, page change, or refresh takes them to the MFA setup screen. |
| The user is currently signed in when the toggle is turned on | They keep their session. Their next interaction takes them to the MFA setup screen; the rest of Stoïk Protect stays out of reach until MFA is configured. |
| A new user is invited with the toggle already on | Right after they create their account, they land on the forced MFA setup screen. |
| The user can no longer access their phone or app | If they set up an authenticator app, they can use a recovery code to sign in. If they set up a passkey, they can use another registered passkey or device. Otherwise, ask their admin to temporarily turn the toggle off. |
## Common questions
What if the user tries to skip the forced MFA setup?
The setup screen replaces every other page in Stoïk Protect until MFA is configured. The only ways forward are to complete the setup or to ask their admin to turn enforcement off.
Which MFA methods are supported?
Authenticator app, SMS, and Passkey are all supported. The authenticator app and passkeys are recommended over SMS: more secure, more reliable, and free to run.
How does the user learn that MFA is now required?
They discover it in-product: the first time they interact with Stoïk Protect after you save the change, they are sent to the forced MFA setup screen.
What happens to their MFA when I turn the toggle off?
Their MFA stays enabled. Turning the toggle off simply gives them back control: they can now disable MFA themselves from their settings if they want.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.stoik.io/onboarding/account/require-mfa.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
