MFA security decision boundary

Status: accepted on 2026-08-25.

LeapView does not implement application-managed multi-factor authentication in the current authentication model. Deployments that require MFA for people must enforce it at the configured OIDC or Entra identity provider with provider-side conditional access. Local password authentication is not an MFA-capable production profile; retain it only where single-factor access is explicitly accepted or as a controlled, monitored break-glass path.

This is a deliberate fail-closed scope decision. It is not a claim that an upstream login satisfied MFA, and LeapView does not currently authorize sensitive operations from acr, amr, or other provider-assurance claims.

Current boundary

Interactive browser authentication has two entry paths:

  • OIDC verifies the authorization response, issuer, signature, state, and nonce, resolves the stable issuer-subject identity, and creates a browser session.
  • Local authentication verifies the stored password credential and creates the same kind of browser session.

The durable browser-session record binds a token to a principal and expiration. It does not record authentication method, authenticator identity, assurance level, authentication time, or a step-up deadline. Desktop sessions add instance, profile, client, idle, and absolute-lifetime boundaries, but do not add authentication assurance. CLI authorization sessions and API tokens are separate credential classes.

Authorization therefore receives an authenticated principal, not evidence that a particular factor combination was completed. Adding a TOTP prompt only to local login would leave OIDC callbacks, desktop completion, session restoration, recovery, and sensitive-operation step-up outside a coherent assurance model.

Why minimal local TOTP is rejected

A secure MFA implementation is a lifecycle and authorization feature, not an extra form field. A minimal TOTP secret and challenge would leave material gaps:

  • no recent-authentication proof and confirmation ceremony for enrollment or removal;
  • no encrypted authenticator storage, key rotation, device naming, or multiple-device lifecycle;
  • no single-use recovery-code storage, recovery ceremony, or recovery notification;
  • no challenge replay protection, clock-skew policy, attempt budget, or distributed rate-limit contract;
  • no assurance attributes on browser, Desktop, or CLI sessions;
  • no step-up policy for credential, principal, grant, token, or security-setting changes;
  • no session revocation rule after authenticator reset or administrative recovery;
  • no complete audit vocabulary for enrollment, challenge, recovery, reset, and factor removal.

Shipping only the challenge would create a bypassable control and could encourage operators to claim an assurance level the application cannot prove. The current architecture is safer when it names the limitation and delegates MFA to a mature external provider.

Production operating decision

For a production deployment that requires MFA:

  1. Use OIDC or Entra for human browser authentication.
  2. Enforce phishing-resistant MFA or the organization's approved factor policy at that provider.
  3. Apply provider conditional access to the exact LeapView client and intended users.
  4. Verify the policy with a non-administrator account and preserve provider sign-in evidence alongside LeapView audit events.
  5. Keep any local break-glass account individually attributable, vaulted, monitored, tested, and rotated after use.

Do not describe local password login as MFA. Do not treat API tokens, service-principal credentials, or a second network hop as a second human factor. If the application itself must cryptographically require and inspect a provider assurance value, the current release does not meet that requirement.

Requirements before application-managed MFA

Future implementation starts only after the session and recovery boundaries are designed together. The minimum architecture must include:

  • WebAuthn/passkeys as the preferred phishing-resistant authenticator, with an explicit decision on any TOTP fallback;
  • durable authenticator identity and lifecycle records with protected secret material where applicable;
  • recent-authentication enrollment, confirmation before activation, named devices, and safe factor removal;
  • single-use hashed recovery codes and an attributable administrative recovery process;
  • replay-safe challenges, bounded attempts, clock handling where applicable, and production rate limits;
  • session evidence containing authentication method, assurance level, authentication time, and step-up expiry;
  • one issuance policy shared by local browser, external browser, Desktop, and CLI completion paths;
  • exact issuer-specific rules for accepted acr or amr values if upstream assurance is consumed, with missing or unknown values failing closed;
  • step-up requirements for security-sensitive operations rather than only at initial login;
  • revocation of affected interactive sessions after factor reset, recovery, or removal while keeping machine credentials an explicit independent class;
  • audit events and operator notifications that contain stable identifiers but no authenticator secrets or recovery material;
  • accessible enrollment, challenge, recovery, and device-management flows with tested browser and multi-device behavior.

Acceptance requires bypass tests across every session-creation path, recovery and factor-reset tests, replay and rate-limit tests, provider-claim tests, direct authorization tests for step-up operations, and an operational runbook. A future implementation must update this decision instead of silently weakening it.

Revisit triggers

Revisit this boundary when a supported deployment requires local users with MFA, LeapView introduces step-up authorization for sensitive actions, or a provider-assurance contract must be enforced inside the application. Until then, external provider enforcement is the supported MFA boundary.

See OIDC, Local authentication, and Roles, grants, and policies for the surrounding identity and authorization controls.