A second factor protects the path to your seal

RFC 6238 with 6-digit codes, 30-second steps, ±1-step drift tolerance. Compatible with every mainstream authenticator app.

MFA enrollment is required to seal. The first seal in a session prompts a fresh TOTP (or one-time backup code); subsequent seals within a 10-minute window pass through without re-prompting. The same gate applies to single-doc seals and batch seals — one verification authorizes the batch. Aligns with 21 CFR Part 11 §11.200(a)(1)(i).

AES-256-GCM at rest with redact: true; the shared secret never reaches logs, telemetry, or Inspect output.

Slow-hash storage rate-limits offline brute-force. Single-use marking is atomic at redemption time.

TOTP and backup paths take the same observable time. Failures look identical regardless of code type.

Server-rendered SVG QR; manual base32 entry for environments without a camera.

Device-bound public-key authentication. Phishing-resistant — the credential is bound to the relying party origin and cannot be replayed elsewhere. No shared secret to leak.

Target: enrollment in /settings/security this quarter. Sealing-gate integration follows.

Re-prompt MFA on credential changes, payment-method updates, member role escalation, and SSO config changes. Today's gate is sealing-only; this expands the surface.

Org admins can require a FIDO2 hardware key for sealing, optionally limiting accepted vendors (YubiKey, Feitian, etc.). Locks out TOTP and platform passkeys for the strictest compliance regimes.

An org-level setting that disables TOTP entirely for the org's users, leaving passkeys as the only second factor. For customers running NIST AAL3 environments.

Verify the FIDO2 authenticator's manufacturer attestation at enrollment time so org admins can constrain which physical devices are acceptable.

A risk-scored login (new geo, new device, anomalous time-of-day) triggers a step-up challenge regardless of the operation. Today, sealing is the only step-up trigger.

SS7 attacks, SIM swapping, carrier-side inspection. SMS has been deprecated by NIST as a second factor since SP 800-63B-2016.

Why we rejected it: every "we'll just SMS the code" is a way to ship a known-broken second factor for the convenience of users who do not own a smartphone with an authenticator app. The right answer is: TOTP works on every phone. Passkeys work on every modern device. SMS is a security regression we will not subsidize.

If the email is compromised, MFA is bypassed. Email is a recovery channel, not a second factor.

Why we rejected it: an attacker who has the password very often has the email. Email-as-second-factor collapses to single-factor in those cases. We use email for password recovery — explicitly named as such — and never as MFA.

The most common path to professional account takeover. We do not offer it, even though competitors do.

Why we rejected it: every "remember me" is a prefilled answer to "did you actually verify the human?" For sealing — a legally significant act — the friction of MFA every time is the feature. The cost is one 6-digit code; the benefit is that a stolen session cannot produce a forged seal.

Push fatigue is a documented attack vector — users approve prompts they did not initiate.

Why we rejected it: the 2022 Uber breach is the canonical example. Push approvals are a usability win when paired with number-matching (where the user types a code from the prompt back into the app), and we may revisit number-matched push for non-sealing step-up. As a primary factor, push without number-matching is a regression we will not ship.

Plaintext shared secrets in a database is the textbook example of a horizon-of-failure leak.

Why we rejected it: every "we keep it plaintext for backup recovery" is a way for one breach to compromise every user's second factor. Encrypting it is one extra symmetric operation per verification. We pay it.

Security questions are public information and have been since LinkedIn data leaked in 2012.

Why we rejected it: mother's maiden name, first pet, high school — all of these are findable. Backup codes are unguessable cryptographic random. They are the right primitive for "I lost my authenticator." We do not invent a worse one.