Administer

MFA configuration

Every privileged-access system ships with MFA; the meaningful question is where the challenge sits. Wardengate can either trust your IdP to handle MFA (most common) or enforce factors natively at sign-in and at step-up. This page walks through both paths, the factor choices, and the policy knobs that turn them on.

IdP-chained MFA vs native MFA

The default and recommended posture is IdP-chained. Your IdP has already invested in factor enrollment, recovery, and step-up, and Wardengate can honour the strength signal your IdP emits. In SAML this is the AuthnContextClassRef — in OIDC it is the acr and amr claims.

Switch to native MFA when you need a factor your IdP does not support, when you need step-up for an event the IdP has no visibility into (say, opening a specific database target), or when the IdP's own factor configuration is weaker than you want for privileged access.

Supported factors

WebAuthn and platform authenticators earn the "phishing-resistant" label because the credential is bound to the origin — nobody can coax a user into completing the challenge against a look-alike hostname. For privileged access this is the only factor class we recommend for default daily sign-in.

The MfaPolicy resource

Native MFA is expressed as an MfaPolicy. Policies bind to subjects (users or groups) and trigger on events: initial sign-in, connection to a target, or a sensitive action in the admin console.

apiVersion: wardengate/v1
kind: MfaPolicy
metadata:
  name: privileged-daily
  organization: acme
spec:
  subjects:
    groups: ["sre", "platform-eng"]
  triggers:
    - event: login
      cache: 12h
    - event: connect
      targetSelector: "env=prod,tier=critical"
      cache: 30m
    - event: admin-action
      actions: ["account.rotate", "role.create", "idp.update"]
  factors:
    required:
      - fido2
      - platformAuthenticator
    fallback:
      - push
    denied:
      - sms
  lockout:
    failures: 5
    window: 10m
    cooldown: 30m

Step-up MFA

Step-up means "I already authenticated earlier, but this next action deserves another factor challenge right now." The mechanics are the same as login MFA — the difference is that step-up is scoped: successful step-up issues a short-lived token that authorises the specific action, then expires. A user who stepped up to connect to prod-db-01 does not automatically earn the right to connect to prod-db-02.

Risk-based MFA

Wardengate collects contextual signals on every sign-in and every connection attempt: source IP reputation, geographic novelty, device posture as reported by the device's management tool, time of day, and the user's own baseline. A risk score between 0 and 100 is attached to the session and can gate MFA.

apiVersion: wardengate/v1
kind: MfaPolicy
metadata:
  name: risk-adaptive
  organization: acme
spec:
  subjects:
    groups: ["everyone"]
  triggers:
    - event: login
      when: "session.riskScore >= 40"
    - event: login
      when: "session.riskScore >= 70"
      factors:
        required: [fido2]
        fallback: []
  factors:
    required: [push, totp]

Risk scoring is a dial, not a verdict. We recommend starting in audit-only mode — Wardengate will compute and log the scores without enforcing — and tuning thresholds against two or three weeks of real traffic before you turn enforcement on.

Enrollment

Users enrol factors in the console. WebAuthn uses the browser's native registration ceremony; TOTP shows a QR code; push binds a mobile client; smart cards enrol on first use. Wardengate does not allow a user to complete their first privileged session without at least one phishing-resistant factor on file — the console intercepts the flow and forces enrolment.

For mass enrolment during a rollout, use an enrolment ticket:

wgctl mfa ticket create \
  --group sre \
  --ttl 14d \
  --require fido2
# issues a one-time URL per member of the group, sent via the
# notification channel attached to the group.

Factor reset and recovery

A lost factor is a recurring operational case. The recovery path is deliberately asymmetric with sign-in:

• A user can reset their own TOTP or push binding by completing a WebAuthn challenge. If they hold no WebAuthn credential, they cannot self-serve.
• An operator with mfa.reset permission can reset on behalf of a user, but only through an approval flow — the operator cannot unilaterally wipe someone's factors.
• Recovery codes are supported but off by default. If you turn them on, require an approval on every use and cap their lifetime.

Per-target MFA

Most MFA is per-login. Per-target MFA — challenging on connect, not on sign-in — is a strong fit for crown-jewel assets like root DBs, domain controllers, or customer-data systems. The cost is extra prompts; the benefit is that a stolen session cookie does not transparently open a connection to those targets.

Audit events

Every challenge, success, failure, lockout, enrolment, reset, and ticket issuance is an audit event. MFA events live in the same audit stream as session events so correlations — for example, "did a step-up challenge precede this production shell?" — are a single query.

Related

• Identity providers — how IdP-emitted MFA signals are consumed.
• Session policies — pairing step-up MFA with target-level controls.
• Approval workflows — the other half of defence-in-depth for privileged actions.