Monosign MFA: design, rollout and troubleshooting
What changed
Every content update is versioned. Select a version to compare it with the one before.
Version 9 → 10
UpdateNew module on access decisions and recovery: access restrictions and policy definitions, passkeys and passwordless sign-in in operation, Kerberos and MFA, password recovery, account unlock, the Windows logon tiles and identity verification.
3 lessons updated
Content update. Enrolled learners were notified.
Monosign has two tools that decide whether a sign-in may proceed. They look similar and behave very differently.
| Tool | What it does | Typical use |
| --- | --- | --- |
| Access restriction | Allows or denies one object, such as a user, on one application | Block a single account, or keep it out at certain hours |
| Authentication policy | Decides which factors and steps a sign-in needs, by scope and priority | MFA outside the office, a passkey for administrators |
A restriction never asks for MFA. It only lets the sign-in through or refuses it.
### Access restrictions
Management → Security → `Restrictions`, or the tab `Access Restrictions` on a user. A row has an `Object`, `Access Types` (`Allow` or `Deny`), a `Scope Object` (the application), `Start Date`, `End Date` and an optional `Cron`.
Three rules explain most support tickets:
- **Checked at sign-in only.** A new `Deny` does not end a session that is already open. During an incident, add the restriction and also close the user's sessions in Management → `Sessions`.
- **The first matching `Allow` wins.** Evaluation stops there, and a later `Deny` row is ignored. Before you add a `Deny`, review the rows the user already has.
- **The scope must be the application the user signs in to.** A row scoped to another application has no effect on that sign-in.
::diagram mfa-restriction-evaluation
`Cron` limits a `Deny` to a time-of-day window. Its hours are **UTC**, not the server's or the user's local time. An office in Istanbul (UTC+3) that wants to block 18:00 to 08:00 local time writes `0 15-23,0-4 * * *`. Since v2026.10 the window is applied as written. On earlier releases a `Deny` with a `Cron` and a lifetime of more than one day blocked around the clock, so test such rows again after an upgrade.
`Remove` ends a row by setting its end date. The row stays as history.
### Policy definitions
Management → Security → `Policies` holds the definitions. The conditional access lab builds a full policy set; these are the rules of the editor itself:
- **`Type` is chosen once.** It can be selected only while you create the definition. `Generic` is for filtering only; a sign-in flow needs `Authentication`. A definition cannot be cloned and its type cannot be changed, so one saved with the wrong type is replaced by a new definition.
- **An `Authentication` definition needs at least one `Scope` item and one `Flow` item.** The flow items are on the `Actions` tab.
- `Priority` runs from 1 to 10, and each definition needs a unique name.
- A definition that an access package uses can be neither disabled nor removed. Detach it from the package first.
Passkeys are the strongest factor in the catalog, and they bring their own operational rules. Plan these before the rollout, not after the first ticket.
### Enrollment belongs to the user
A passkey is enrolled in the Account app, inside the user's own session. An administrator cannot enroll one on a user's behalf from Management, and the helpdesk cannot prepare passkeys for a team in advance. Plan for people to enroll themselves: a short guide, a time window, and a second passkey or another factor as a way back in.
### Removing the last passkey
When a user deletes their last passkey, the `Passkeys` method is deactivated for them. If it was their only factor, they have no MFA factor until they enroll again. Nothing falls back automatically. Add this to the device retirement process: enroll on the new device first, then remove the old one.
### Every sign-in address must be a tenant host
A passkey is bound to the web address it was enrolled on, and Monosign derives that address from the account tenant hosts. If users reach the sign-in pages through a host name that is not registered as an account tenant host, the browser refuses the passkey step, while password sign-in on the same host still works. The API log then shows `Tenant host not found for host`.
So when the customer adds a new host name, check that it is registered as an account tenant host first. Also note that a passkey enrolled on one host is not accepted on another.
### `Passwordless Login` and what it replaces
With `Passwordless Login` on, a user can sign in with a passkey alone. That sign-in counts as MFA for the **user's own** two-factor setting. It does not satisfy an **authentication policy** that asks for a second factor: on an application covered by such a policy, the user is still asked for MFA after the passkey. A pending password change is also still requested. Explain this to the customer, or the first passkey users will report it as a fault.
### Kerberos is different again
Kerberos sign-in on domain-joined devices removes the password prompt, but unlike the other passwordless sign-ins the session is not treated as MFA-verified. A user with MFA enabled, or an application whose authentication level requires MFA, still gets the MFA challenge after the ticket. This is expected behaviour. If a customer wants no prompt for a specific application, that is a decision about the application's MFA setting, not a Kerberos fault.
::diagram mfa-passwordless-and-mfa
> Tip: `Passkeys` is the method to use for both platform passkeys and FIDO2 security keys. Leave the legacy `Security Key` row disabled.
Users who cannot sign in are the largest share of helpdesk calls. Monosign has self-service paths for them, and each has limits the helpdesk should know.
### Password recovery
A user who forgot their password starts on the boarding page with `I don't remember my password`, identifies themselves and proves who they are with an MFA factor, with security questions, or both. The switches are under System → `Configurations` → tab `Boarding`.
Two behaviours cause tickets:
- **SMS is hidden when another factor exists.** If the user has more than one verified factor, the SMS factor is not offered on the recovery page. A user whose app was reset or whose phone was replaced cannot fall back to SMS there, and the helpdesk has to assist. Take this into account when you decide which factors users must enroll.
- **A code may already be on its way.** Recovery shares the resend cooldown with sign-in, as the lesson on delivering codes explains.
### Account unlock
A locked user can unlock the account from the same page with a one-time code sent by SMS or mobile push. The limits:
- Unlock **clears the lock only**. It does not reset the password, and it does not re-enable an account that is disabled for another reason, for example by HR or an administrator. Such a user completes the unlock and still cannot sign in.
- The code is valid for one hour. Since v2026.09, wrong codes are capped at five per request.
- Only SMS and push are offered, and only to users who have already enrolled and verified them.
### At the Windows logon screen
A user locked out of Windows has no browser to reach these pages. The Monofor Identity Client adds separate tiles to the logon screen, and each has one job:
| Tile | Purpose |
| --- | --- |
| `Monosign MFA Credential Provider` | Windows password, then Monosign MFA |
| `Monosign QR Login`, `Monosign Push Login` | Passwordless logon with the Monofor Identity app |
| `Self Service Portal` | Password reset and account unlock from the lock screen |
For field staff without a second device, `Self Service Portal` is the feature to select in the installer. The other tiles do not reset a forgotten password.
::diagram mfa-self-service-paths
### Identity verification
Some access needs more than a factor: proof that the person is who they claim to be. Under Identity → `Verification` you connect an identity proofing vendor as a source. The user completes document and selfie proofing in the vendor's hosted flow from the Account app and returns with an assurance level from `IAL1` to `IAL3`, stored on the user.
There are two ways to require it:
- **For one user, now**: the user's `Identity Assurance` panel → `Request identity verification`.
- **For everyone a policy matches**: the policy action `Require Identity Verification` in an authentication policy. At sign-in it raises a request when the user's level is below the required one.
Monosign does not check documents itself; the vendor does. Security questions, magic links and access restrictions are not a substitute for proofing.