---
id: NK-ADR-0016
type: architecture-decision-record
title: "MFA Is a User Preference by Default; Workloads Opt In to Requiring It"
status: accepted
owner: net-kingdom
revision: "1"
decided: "2026-09-23"
last_reviewed: "2026-09-23"
review_interval: 12m
---

# ADR-0016 - MFA Is a User Preference by Default; Workloads Opt In to Requiring It

**Status:** Accepted
**Date:** 2026-09-23
**Deciders:** Bernd Worsch, Claude

## Context

The attended Vergabe recipient journey on 2026-09-23 (NK-WP-0036-T05,
NK-WP-0037-T02) completed sign-in and account confirmation without MFA.
KeyCape policy P06 (`key-cape/docs/optional-mfa.md`, deployed 2026-09-14 for
`vergabe-demo-company` and `user-engine-portal`) allowed this. Under P06, AAL1
is permitted when privacyIDEA authoritatively reports no active factor, and
AAL2 is required once one exists.

NK-WP-0037 had been written on 2026-09-12 as "provider-required MFA". The
operator decided against requiring MFA for Vergabe Teilnahme now. The
enrollment and recovery journeys (user-engine U06, factor recovery) have not
yet been accepted from a user's perspective, and requiring MFA before they
work pushes users into support paths.

## Decision

1. **Default: MFA is the user's preference.** For ordinary human sign-in to a
   workload, MFA is offered but not required. A user who activates a factor
   is held to it: later sign-ins require AAL2, and a prior AAL1 session does
   not satisfy it (P06 semantics).
2. **Workloads opt in to requiring MFA,** for all of their features or for
   some of them. A workload states the requirement explicitly, either per
   client registration or per request as a step-up (an explicit AAL2 request
   at the moment a protected feature is used). An explicit workload
   requirement always wins over a user's preference. Authorization decisions
   read it from the normalized `assurance.level` claim (IAM Profile v0.3),
   never from a provider-native claim.
3. **The IAM Profile v0.3 floor is unchanged.** Privileged, destructive,
   platform-root, secret, credential-vending and emergency flows require AAL2
   or stronger, and administration requires MFA even where ordinary sign-in
   does not. This ADR relaxes nothing below that floor.
4. **Usability comes before a mandatory requirement.** The enrollment,
   re-enrollment and recovery journeys must be accepted from a user's
   perspective before any workload's default sign-in is switched to
   required MFA.

## Consequences

- Vergabe Teilnahme keeps P06 optional MFA. NK-WP-0037's "provider-required
  MFA" wording is superseded.
- A workload that needs MFA for part of its feature set needs a step-up path:
  it requests AAL2 when a protected feature is used, and KeyCape answers with
  an MFA challenge that its existing session cannot bypass. The KeyCape and
  application contract for that step-up is follow-up work (NK-WP-0042,
  proposed).
- The user-engine enrollment journey (U06) and factor recovery are
  prerequisites for any workload making MFA mandatory by default.
- A per-client `mfaRequired: false` remains unconditional AAL1 and is not a
  preference mechanism. Use P06 `mfaOptional` for preference-based clients.

## Related

- IAM Profile v0.3 (Human Interactive Flow; Assurance Evidence)
- `key-cape/docs/optional-mfa.md` (P06)
- NK-WP-0036, NK-WP-0037, NK-WP-0041
- user-engine account journeys U06 (voluntary authenticator activation)