Authenticator settings and MFA enrolment policy
Turn a whole factor type off for the organisation, and require, allow or forbid it per group with ordered rules. Both are wired into real sign-ins today, TOTP end to end.
Two separate controls decide what happens with a second factor in your organisation, and this article covers both because one is meaningless without the other. Identity → Authenticators is a per-org on/off switch for each factor type. The MFA enrolment layer of Identity → Session policies is an ordered rule set that says who must, may or must not enrol which type. Disabling a type at the first screen removes it everywhere; requiring a type at the second screen only makes sense for a type the first screen has not disabled.
Identity -> Authenticators: the on/off switch
Six factor types, each with an Available to sign in and enrol toggle: TOTP, WebAuthn (passkeys and security keys), push, SMS, email, and recovery codes. A type nobody has touched here stays enabled — the setting is stored per org only when you actually change it, so a tenant that never opens this screen keeps exactly the behaviour it had before the screen existed.
| Type | Extra fields |
|---|---|
| SMS, Email | Code length in digits (4-10) and how long a code stays valid, in seconds (30-900). |
| TOTP, WebAuthn, Push, Recovery codes | No extra fields today — the toggle is the whole setting. |
The MFA enrolment layer: who must enrol what
Identity → Session policies has three layers, switched with the segmented control at the top: Global session, Per app, and MFA enrolment. The third is row D8's own policy type, MFA_ENROLLMENT, and it uses the identical rule engine described in Sign-on policies and the decision trace — the same ordered, first-match-wins evaluation, the same condition types (users, groups, user type, network, risk, device, expression), and the same per-evaluation trace. Only what the winning rule's outcome means differs: instead of allow/step-up/deny, an MFA_ENROLLMENT rule's Requirements carry an enrollment_factors map.
Editing a rule on this layer shows an extra panel the other two layers do not: one dropdown per factor type — TOTP, WebAuthn, push, SMS, email, recovery code — set to Required, Optional or Disabled, plus a choice of when a required factor is asked for: at first sign-in, or only when later prompted by something like a step-up rule.
| Setting | Effect |
|---|---|
| Required | This factor is demanded. Whether it is actually offered end-to-end at first sign-in depends on the factor type — see the TOTP-only caveat below. |
| Optional | Neither required nor forbidden. The default for a type a rule does not mention. |
| Disabled | This rule forbids the factor for whoever it matches — the same effect as row E19's org-wide switch, but scoped to this rule's condition instead of the whole organisation. A factor disabled by either surface is refused; the two do not need to agree, and either one alone is enough to block it. |
An organisation with no ACTIVE MFA_ENROLLMENT policy gets the pre-existing default: every factor reads as optional for everyone, exactly as before this row existed. Write your first rule on this layer the same cautious way Sign-on policies and the decision trace recommends for the global layer: add it inactive, confirm its position, then activate it.
The one honest gap: TOTP is enforced end to end, the others are not yet
How the switch and the policy combine
Both surfaces feed the same function, authenticatorAllowed, which is why disabling a factor at either one is enough — you do not need to touch both to block something. In order:
- Is this factor marked
Disabledby the winning MFA_ENROLLMENT rule for this person? If so, it is refused, regardless of the organisation-wide switch. - Otherwise, is this factor's organisation-wide switch (Identity → Authenticators) turned off? If so, it is refused.
- Otherwise, the factor is allowed — offered for enrolment, listed as a step-up option, and accepted if presented.
A factor named by neither surface, or an organisation that has never opened either screen, behaves exactly as the product did before either row existed: every type available, no enrolment requirement. Nothing about adding these controls changes a tenant that ignores them.
Endpoints and permission
GET .../authenticators iam:auth_policies:read
PUT .../authenticators/{type} iam:auth_policies:writeThis reuses iam:auth_policies — the same permission the MFA_ENROLLMENT and global session policy screens use, and the device-assurance policies alongside them — rather than a new permission of its own. The MFA enrolment rules themselves live under the same auth-policies CRUD surface the other two layers use; there is no separate endpoint family for the enrolment layer, only a different type value on the same policy resource.
What to do with this
- If you need to retire SMS or email as a second factor across the board — the honest recommendation in Password policy and lockout and Recovery codes is to favour a real second factor over relying on complexity or codes alone — turn it off at Identity → Authenticators rather than merely discouraging it; the switch actually removes it from enrolment and step-up.
- If you want administrators specifically to carry a phishing-resistant factor, write an MFA_ENROLLMENT rule requiring WebAuthn for the
admingroup — it takes effect the same way the seeded (but inactive) sign-on-policy rule for administrators does, per Sign-on policies and the decision trace; enrol your administrators' keys before you activate it, for the identical reason that rule ships inactive. - Do not build a rollout plan that assumes requiring push, SMS or email at the enrolment layer will prompt people to add one on their next sign-in — today, only a TOTP requirement does that.