Multi-factor authentication adds a second proof of identity on top of a password. For an AI control plane — where a single session can authorize agents to read production data, trigger webhooks, or spend budget — MFA is not optional hardening. It is the first meaningful barrier between a stolen password and a significant incident. TOTP-based second factors and single-use backup codes, combined with forced enrollment and step-up verification for sensitive operations, close the most common attack paths against administrative credentials.

Why AI platforms need MFA more than most

Credential theft is the most common initial access vector in cloud breaches. In a conventional SaaS application, a compromised account typically exposes one user's data. In an AI control plane, the blast radius is larger: an attacker who logs in as an administrator can re-configure agent trust policies, redirect webhooks, alter spending limits, or query audit logs that cover the whole organization.

Passwords alone are insufficient not because they are inherently weak but because they are so frequently reused, phished, or leaked from unrelated services. A second factor that is tied to a physical device — and expires every 30 seconds — breaks the most common attack chains. Even if a credential database is breached, the attacker cannot replay captured passwords without also controlling the authenticator device.

That asymmetry is why security-conscious teams adopt MFA as a baseline, not an advanced option. For a broader look at how stolen credentials are exploited once an attacker has them, see Threat Model: Agent Credential Theft.

How TOTP works

TOTP (Time-based One-Time Password, defined in RFC 6238) generates a short numeric code from two inputs: a shared secret known to both the server and the authenticator app, and the current Unix time rounded to a 30-second window. Because the window is synchronized to the clock, a code is valid for at most one time step. An attacker who intercepts a code after it has been verified cannot reuse it.

Enrollment works like this:

  1. The server generates a random shared secret and encodes it into a QR code that the user scans with an authenticator app (Google Authenticator, Authy, 1Password, and others all implement the standard).
  2. The user enters the first code the app generates to prove the secret was stored correctly.
  3. The server persists the secret and the enrollment is complete.

From that point on, login requires the password plus the current six-digit code. The server validates the code against the expected value for the current time window (with a small tolerance for clock skew), then marks that time step as consumed so the same code cannot be submitted twice.

That last point — single-use enforcement — is critical. Without it, a code captured in transit could be replayed within the same 30-second window.

Backup codes: the recovery path you actually need

TOTP depends on physical access to the enrolled device. If a user loses their phone, breaks it, or is locked out of their authenticator app, they cannot log in — ever — unless an alternative recovery mechanism exists.

Backup codes are the standard answer. At enrollment time, the server generates a small set of one-time codes (typically eight to ten). The user is shown them exactly once and instructed to store them somewhere safe — a password manager, a printed sheet in a secure location, or an encrypted vault. Each code can be used in place of a TOTP code, but only once: the server marks it consumed on first use.

This creates a recovery path that does not require resetting the second factor entirely, which would require administrator intervention and leave a window without MFA protection.

Backup codes should be stored securely on the server side too. Storing them in plaintext is equivalent to storing passwords in plaintext — if the database is exposed, all the backup codes are compromised simultaneously. The correct approach is to hash each code before storing it, verify by comparing hashes at use time, and never log or return plaintext values after the enrollment screen.

Forced enrollment and organizational policy

Individual MFA adoption is incomplete adoption. An organization that allows some users to opt out of MFA effectively has no MFA policy: attackers simply target the accounts that skipped enrollment.

A well-designed control plane supports mandatory MFA at the organization level. When a member of an MFA-required organization logs in without a second factor enrolled, they should not receive full access — they should be directed through the enrollment setup flow before proceeding to any protected resource.

Praesidia implements this through a separate enrollment path. A user in an MFA-required organization who has not enrolled is directed through the setup flow before they can access any protected resource — enrollment must be completed before normal access resumes. The enforcement is structural rather than advisory.

Step-up authentication for high-risk actions

Standard MFA gates the login checkpoint. But some operations within an already-authenticated session are sensitive enough to warrant re-verification — disabling MFA itself, regenerating backup codes, changing a recovery email, or approving a large budget increase.

The pattern is called sudo mode or step-up authentication, borrowed from Unix's sudo command model. The user has an active session but must re-prove their identity (typically password plus second factor) before performing the specific sensitive action. The step-up verification is time-bounded: once confirmed, it authorizes a short window of elevated actions without requiring re-entry for every click.

This matters because session hijacking (via XSS, stolen session cookies, or a logged-in shared workstation) does not give an attacker the user's TOTP device or password. Step-up auth limits what a hijacked session can accomplish on its own.

Praesidia applies this model to write operations on MFA configuration — disabling a second factor requires both the account password and a valid TOTP or backup code, even within an active session. Backup code regeneration is rate-limited and similarly gated.

Per-user lockout and replay prevention

Two additional controls close the gaps that basic TOTP leaves open.

Replay prevention. As noted above, a TOTP code that has already been verified must not be accepted again within the same time window. Praesidia enforces single-use semantics on verified codes, making replay attacks ineffective even if an attacker intercepts a code in the same 30-second window.

Brute-force lockout. Without a lockout, programmatic guessing of TOTP codes is feasible. Praesidia enforces a failure threshold: after a configurable number of failed attempts, the account's second-factor verification is locked for a cooling-off period. The lockout mechanism fails closed — if verification state is unavailable, the conservative behavior is to block rather than allow.

These controls are sometimes treated as implementation details, but they are what separates a compliant MFA deployment from one that looks correct on paper but can be defeated by a determined attacker.

Registering and managing authenticators

From a user perspective, the lifecycle looks like:

  • Enroll: scan the QR code with an authenticator app, enter the first code to confirm, save backup codes.
  • Use: enter the six-digit code at login alongside the password.
  • Recover: use a backup code if the authenticator device is unavailable.
  • Regenerate backup codes: request a new set (rate-limited) after using several or suspecting exposure.
  • Disable: if no longer needed, disable MFA with password and current TOTP or backup code verification.

Each of these operations is available in the profile security settings. For guidance on how these controls fit into a broader identity strategy, see how to authenticate AI agents, security policies for passwords, sessions, and IP restrictions, and SSO and SCIM: Enterprise Identity for AI Tools.

Common questions

What if I lose my authenticator device and have used all my backup codes?

Contact your organization administrator. Administrators can reset a user's MFA configuration after verifying identity through an out-of-band process your organization defines. This is why backup codes should be stored in multiple secure locations at enrollment time — they are the self-service recovery path, and exhausting them before losing a device eliminates that option.

Can I use a hardware key (like a YubiKey) instead of TOTP?

TOTP is the standard time-based code method. Hardware security keys use the WebAuthn/FIDO2 protocol, which is a separate authenticator type. Passkey-based authentication is a distinct, phishing-resistant second factor alongside TOTP — see Passkeys and WebAuthn for AI Platforms for a deeper comparison of these two approaches.

How are backup codes stored on the server?

Each code is hashed before persistence using a strong one-way function. Praesidia never stores backup codes in plaintext after enrollment. The codes shown during setup are the only time they appear in cleartext, and they are not logged. If you suspect your backup codes are compromised, use the regenerate function immediately — this invalidates all existing codes and issues a new set.