Sign-in policies

These settings decide what happens at the Windows sign-in screen. All are per-resource.

Require MFA on

console · rdp · both · none — which session types prompt for the second factor. none is monitor-only. A common rollout is rdp first (the internet-facing risk), then both.

Fail-mode: open or closed

If the machine can’t complete MFA — typically no network to the Dynacop cloud and no offline data — fail-mode decides:

• open (default): allow the sign-in. Availability first; nobody gets locked out by an outage.
• closed: deny the sign-in. Security first; choose it for high-value hosts where “no verification, no entry” is the requirement.

Deliberate states are exempt: a retired or deleted resource never denies because of fail-mode.

Enforce

With Enforce on, the sign-in screen offers no password-only fallback — MFA can’t be bypassed by picking another credential tile. Leave it off during initial rollout; turn it on once people are enrolled. (For emergencies, see offline access & recovery.)

MFA timeout

How long the prompt waits for a code: 10–600 seconds (default 60).

Lockout

After N failed code attempts (default 5), the account on that machine is locked for the lockout duration (default 5 minutes). The audit log shows these as too many attempts (locked).

Unknown user policy

When someone signs in whom Dynacop doesn’t recognize on that machine:

• enroll (default): let them through to be set up properly later — they show up in the panel.
• allow: permit silently (only sensible with monitor-only).
• deny: refuse unknown logins outright.

Enforce grants (zero-trust)

Normally MFA verifies who signs in. With Enforce grants on, Dynacop also requires an explicit access record: a verified person with no access is still denied. This is the strictest mode — recommended once your access map is complete.