> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Two-factor authentication

> Enforce TOTP or passkeys across your organization — the HIPAA-right default.

<Info>
  Denialbase requires 2FA for every account that accesses PHI. As an admin, you can enforce it at the organization level so no user can sign in without it.
</Info>

## Enabling organization-wide 2FA

<Steps>
  <Step title="Settings → Security → 2FA policy">
    You need the `admin` role.
  </Step>

  <Step title="Choose a policy">
    * **Recommended**: Require 2FA for all PHI-accessing users.
    * **Stricter**: Require passkeys only (phishing-resistant).
    * **Loosest (not recommended)**: Optional 2FA.
  </Step>

  <Step title="Set a grace period">
    Existing users get 7 days to enroll before being locked out.
  </Step>

  <Step title="Communicate">
    A default communication is drafted for you — edit and send from the same screen.
  </Step>
</Steps>

## Supported methods

<CardGroup cols={2}>
  <Card title="Passkeys (WebAuthn)" icon="fingerprint">
    **Recommended.** Phishing-resistant. Works with Touch ID, Face ID, Windows Hello, and hardware keys (YubiKey, Titan).
  </Card>

  <Card title="TOTP" icon="mobile">
    Compatible with Authy, Google Authenticator, 1Password, Bitwarden, and any RFC 6238 app.
  </Card>

  <Card title="Backup codes" icon="rotate-left">
    10 one-time codes generated at enrollment. Store these somewhere safe — they let you sign in if you lose your primary factor.
  </Card>

  <Card title="SSO IdP 2FA" icon="google">
    If your organization uses SSO with 2FA enforced at the IdP, that satisfies Denialbase's 2FA requirement.
  </Card>
</CardGroup>

## Resetting 2FA for a user

If a user loses their 2FA device:

<Steps>
  <Step title="Verify identity">
    Confirm the request out-of-band (phone, in-person). Don't rely on email alone.
  </Step>

  <Step title="Admin → Settings → Team → [user] → Reset 2FA">
    The user is flagged to re-enroll on next sign-in. A verification email goes to their address.
  </Step>

  <Step title="Audit-logged">
    The reset is recorded in the security audit log with your user ID as the actor.
  </Step>
</Steps>

## What happens under the hood

* Passkeys use the WebAuthn standard — cryptographic keys stored on your device or hardware authenticator.
* TOTP secrets are encrypted in the database and only decrypted at verification time.
* Rate limiting on 2FA endpoints (5 / min for setup, 10 / min for passkey operations) prevents brute force.
* Every 2FA event — enroll, use, reset, disable — is in the security audit log.

## Bypass controls (admin break-glass)

In rare cases (ransomware on a user's device, forgotten backup codes) an admin may need to temporarily bypass 2FA to help a user recover.

* **Settings → Security → Break-glass bypass** — grants a single 15-minute window for a specific user.
* Every use is audit-logged with elevated severity and notifies the Security Officer.

## Policy ideas

* **Require passkeys** for admin roles and providers (stronger than TOTP).
* **Block SMS as a factor** — we don't support SMS at all; don't let users think it's an option.
* **Require re-auth** for sensitive actions (user deletion, bulk PHI export, 2FA reset).

*See the underlying security rationale at [Authentication & access control](/trust/authentication).*