> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-nl/cerrix-functionaliteiten/admin-settings/authentication-and-user-provisioning/multi-factor-authentication-mfa.md).

# Meerfactorauthenticatie (MFA)

## Multi-factor-authenticatie (MFA)

Deze pagina legt uit hoe multi-factor-authenticatie werkt voor CERRIX-gebruikers: welke MFA-mogelijkheden het platform biedt, welke rol uw identiteitsprovider speelt, en hoe MFA zich verhoudt tot IP-whitelisting.

### Hoe MFA werkt in CERRIX

CERRIX maakt onderscheid tussen twee soorten aanmeldingen, en MFA werkt voor elk daarvan anders:

* **SSO-aanmeldingen**: gebruikers die inloggen via Single Sign-On verifiëren zich bij uw eigen identiteitsprovider (bijvoorbeeld Microsoft Entra ID of Okta). MFA voor deze gebruikers wordt afgedwongen door uw identiteitsprovider, met behulp van de MFA-beleidsregels die u daar configureert. Dit is de aanbevolen manier om MFA voor CERRIX-gebruikers af te dwingen.
* **Lokale aanmeldingen (gebruikersnaam en wachtwoord)**: CERRIX ondersteunt momenteel geen volledige MFA-afdwinging voor lokale accounts. Voor deze accounts biedt CERRIX een controle met een e-mailverificatiecode op basis van het IP-adres van waaruit de gebruiker inlogt (zie hieronder).

{% hint style="info" %}
Gebruikers die via SSO inloggen, slaan de controle met de CERRIX-e-mailverificatiecode over. Hun tweede factor wordt volledig afgehandeld door uw identiteitsprovider.
{% endhint %}

### MFA voor SSO-gebruikers

Wanneer SSO is geconfigureerd voor uw omgeving, vindt de controle van wie inlogt plaats in uw identiteitsprovider. Elke MFA-vereiste (authenticator-app, hardwaretoken, enzovoort) wordt daar geconfigureerd en afgedwongen — CERRIX voegt geen eigen factor toe boven op een SSO-aanmelding.

Zie de SSO-installatiegids voor hoe u uw identiteitsprovider met CERRIX verbindt.

### E-mailverificatiecodes voor lokale accounts

Voor gebruikers die inloggen met een gebruikersnaam en wachtwoord kan CERRIX een verificatiestap inschakelen op basis van de inloglocatie:

* Wanneer deze controle is ingeschakeld en een gebruiker inlogt vanaf een **onbekend IP-adres**, stuurt CERRIX de gebruiker een verificatiecode per e-mail die op het aanmeldscherm moet worden ingevoerd voordat de aanmelding kan doorgaan.
* Zolang een verificatieverzoek voor dezelfde combinatie van account en IP-adres nog **actief** is, wordt er bij herhaalde inlogpogingen geen nieuwe code per e-mail verstuurd. Als u een code verwacht maar geen nieuwe e-mail ontvangt, controleer dan de code die bij de eerste poging is verzonden; opnieuw inloggen nadat het eerdere verzoek niet meer actief is, activeert een nieuwe e-mail met code.

Deze verificatiestap wordt per omgeving door CERRIX ingeschakeld. Als u deze voor uw omgeving wilt aanzetten (of uitzetten), neem dan contact op met CERRIX-support.

{% hint style="warning" %}
Deze e-mailverificatiecode is een controle van de inloglocatie voor lokale accounts. Het is geen volledige MFA-implementatie zoals een authenticator-app, en deze is niet van toepassing op SSO-aanmeldingen.
{% endhint %}

<figure><img src="https://2540748892-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FEeL4xdXxYZ2fsPsMzsYF%2Fuploads%2Fgit-blob-fc3a2fb09605175ec55263d26e63dac31e4ec99b%2Flogin-new-location-toast.png?alt=media" alt="The notification shown after logging in from a new location"><figcaption></figcaption></figure>

### Hoe lang een geverifieerd IP-adres geldig blijft

Wanneer de controle met de e-mailverificatiecode is ingeschakeld, onthoudt CERRIX het IP-adres dat een gebruiker heeft geverifieerd, zodat de gebruiker niet bij elke aanmelding vanaf die locatie om een nieuwe code wordt gevraagd. Twee instellingen bepalen hoe lang dat zo blijft:

* **De geldigheidsperiode van het geverifieerde IP-adres.** Deze periode wordt per omgeving geconfigureerd en is standaard 24 uur. Een kortere periode — bijvoorbeeld één uur — kan worden geconfigureerd als u wilt dat gebruikers zich vaker opnieuw verifiëren. Neem via de servicedesk contact op met CERRIX-support om dit voor uw omgeving aan te passen.
* **De sessieduur.** Een CERRIX-sessie gebruikt een schuivende vervaldatum van 8 uur: elke interactie met de applicatie vernieuwt de sessie, zodat een actieve gebruiker tijdens het werken niet wordt afgemeld.

De geldigheidsperiode gaat in wanneer de gebruiker de sessie beëindigt door **af te melden**. Zolang een gebruiker blijft werken zonder zich af te melden, blijft de sessie — en daarmee het geverifieerde IP-adres — geldig, ook nadat de geconfigureerde periode is verstreken.

{% hint style="info" %}
Omdat de periode wordt toegepast bij afmelden, heeft een kortere geldigheidsperiode het meeste effect wanneer gebruikers zich aan het einde van een werksessie afmelden in plaats van CERRIX open te laten staan.
{% endhint %}

### MFA en IP-whitelisting

CERRIX-omgevingen kunnen de toegang beperken met een **harde IP-controle**, waarbij alleen toegestane IP-bereiken de omgeving kunnen bereiken. Als alternatief kan de omgeving worden overgezet naar de hierboven beschreven controle met e-mailverificatiecode; in dat geval wordt het harde IP-filter uitgeschakeld en worden IP-adressen per verificatieverzoek op applicatieniveau bijgehouden in plaats van op infrastructuurniveau.

Een veelvoorkomende inrichting is: SSO waarbij MFA wordt afgedwongen in uw identiteitsprovider voor uw eigen personeel, gecombineerd met de controle met e-mailverificatiecode voor de overige lokale accounts, ter vervanging van een harde IP-whitelist. Tussen deze modi schakelen wordt door CERRIX gedaan — neem contact op met CERRIX-support om de configuratie voor uw omgevingen te bespreken en aan te passen. Het is aan te raden om zo'n wijziging eerst op uw acceptatieomgeving te testen.

{% hint style="warning" %}
Overschakelen van een harde IP-controle naar de controle met verificatiecode heeft ook gevolgen voor integraties: IP-adressen die worden gebruikt door API- en SCIM-integraties moeten mogelijk daarna opnieuw op de whitelist worden gezet. Zie het SCIM-probleemoplossingsgedeelte op de pagina Gebruikersprovisioning.
{% endhint %}

### Gebruikers buiten uw identiteitsprovider

Organisaties hebben vaak gebruikers die geen account hebben in de gekoppelde tenant van de identiteitsprovider, bijvoorbeeld collega's van een partner- of dochterorganisatie. Voor deze gebruikers:

* **Momenteel ondersteunt CERRIX geen MFA-afdwinging buiten SSO-authenticatiestromen.** Er is momenteel geen native MFA-optie voor lokale accounts met gebruikersnaam en wachtwoord. Een herziening van het identiteitsysteem die MFA voor niet-SSO-accounts mogelijk zou maken, wordt overwogen, maar er is nog geen tijdlijn beschikbaar.
* **Gastaccounts zijn een beproefde oplossing.** U kunt externe gebruikers als gastaccounts toevoegen in uw eigen tenant van de identiteitsprovider (bijvoorbeeld gastaccounts in Entra ID) en die accounts koppelen in CERRIX. Deze gebruikers kunnen dan via SSO inloggen met hun eigen e-mailadres, waardoor ze onder uw MFA-afdwinging vallen. Deze aanpak is getest en bevestigd als werkend.
* **Voor accounts die lokaal moeten blijven**, pas accounthygiëne toe: roteer referenties regelmatig, controleer toegang regelmatig en houd het aantal lokale accounts tot een minimum beperkt.

Als u gebruikers uit meerdere tenants van identiteitsproviders moet ondersteunen, neem dan contact op met CERRIX-support om de opties voor uw omgeving te bespreken.


---

# 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.cerrix.com/cerrix-documentation-nl/cerrix-functionaliteiten/admin-settings/authentication-and-user-provisioning/multi-factor-authentication-mfa.md?ask=<question>&goal=<user_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.
