Skip to main content

Multi-Factor Authentication

Qpher supports multi-factor authentication (MFA) for both the SaaS Portal and the Vault iOS app. MFA reduces the blast radius of a compromised password: even if a password leaks, an attacker still needs the second factor to sign in or to perform a sensitive action.

This page is a posture overview for enterprise administrators evaluating Qpher. For the user-facing enrollment steps, see Account & Settings. For the API surface, see API Reference — Authentication.

What MFA Protects​

MFA raises the cost of two realistic attacks:

  1. Credential stuffing — reused passwords from unrelated breaches are the most common account-takeover vector. A second factor makes a stolen password insufficient by itself.
  2. Session hijack escalation — even with a live session, Qpher requires a second proof of presence (step-up re-verification) before any action that changes account posture.

MFA does not replace our other controls. Tenant isolation, the fail-closed Policy Engine, and encrypted-at-rest private keys remain in effect regardless of authentication state. See Threat Model.

Supported Factors​

  • TOTP (RFC 6238) — 6-digit code from any compatible authenticator app (Google Authenticator, 1Password, Authy, Microsoft Authenticator). No SMS.
  • Recovery codes — 10 single-use codes issued at enrollment. You can regenerate the set from the Portal or Vault; regenerating invalidates all previously issued codes.
  • Email OTP (fallback only) — a 6-digit code delivered to the account email. Only offered after two failed primary-factor attempts on the same login challenge, and never listed as a primary option. This closes the support hole when a user loses both their authenticator device and recovery codes.

SMS-based OTP is deliberately not supported — NIST SP 800-63B restricts its use and SIM-swap is the standard bypass. Passkeys / WebAuthn are on the roadmap.

Step-Up Re-Verification​

Sensitive actions require a second proof of presence taken immediately before the action — even inside an already-authenticated session. A short-lived token is issued after the step-up check and consumed on the action request.

The following actions require step-up today:

ActionSurface
Subscription checkout or cancelPortal
Rotate an API keyPortal
Remove a team memberPortal + Vault admin
Change passwordPortal + Vault
Rotate a PQC key (KMS)Portal

What a user sees: a dialog asks for the TOTP code (if MFA is enabled) or the current password (if MFA is not enabled) before the action succeeds. The step-up token is single-use and lasts five minutes; if the user cancels, no state changes.

API keys are not affected by step-up

Step-up applies to human sessions (Portal JWT). API-key integrations and SDK clients never receive a step-up prompt or an ERR_MFA_013 response. API keys are already the highest-trust credential; adding a second factor at the API-key tier does not meaningfully change the threat model.

Enterprise Policy (Enterprise / Enterprise+)​

Enterprise administrators can require MFA for every member of the organization:

  • require_mfa = true on the tenant policy rejects any login from a member who has not enrolled.
  • New members joining after the policy is enabled must enroll on first login.
  • Existing members get a 7-day grace period (default) to enroll before they are locked out.
  • Changes to the policy are written to the audit log with critical severity.

The policy row is a single source of truth: the same setting drives enforcement on both the SaaS Portal and the Vault iOS app for members of the same org.

Cross-Product Behavior​

Qpher runs two deliberately separate account systems — a SaaS account (tenants, billing, API keys) and a Vault account (iOS app, personal encrypted storage). The same email can hold both accounts; MFA state is tracked independently on each. A user enrolled on one product is not automatically enrolled on the other.

The exception is Enterprise org membership. If an Enterprise org enables require_mfa, that policy applies to the member's Vault iOS login as well, because the org controls the shared tenant that the Vault app operates on.

Threat Model (brief)​

ThreatMFA impact
Password reuse / credential stuffingBlocked by TOTP factor
Phishing of a passwordBlocked unless attacker also controls the authenticator
Session-cookie theft that bypasses loginPartially mitigated — any sensitive action still requires step-up
SIM swapNot applicable — no SMS OTP
Phishing of a TOTP code in real timeReduced by single-use step-up and short token TTL; WebAuthn / Passkeys will close this fully when shipped
Device loss with recovery codes lostEmail OTP fallback — only after two primary failures on the same challenge

For the full threat model, see Threat Model.

Audit and Observability​

Every enrollment, verification, failure, recovery-code use, regeneration, and disable emits a persistent audit event. Enterprise customers can export the full log — see Zero Trust for how audit flows through the Policy Engine.

Standards Alignment​

  • NIST SP 800-63B — TOTP is a permitted authenticator type; SMS is not used.
  • SOC 2 CC 8.1 (Authentication) — readiness in progress. MFA enrollment, verification, and regeneration events provide the evidence trail required by the Common Criteria.

Learn More​