Passwords and two-factor authentication

This article covers everything an organization needs to harden the email-and-password sign-in path: setting the password policy, enabling two-factor authentication for individual users, requiring 2FA across the organization, and recovering an account when a user has lost their device.

If your organization is on the Agentic plan and you have configured SSO, the IDP-managed users do not use this path — their password and 2FA policy are enforced in your IDP. The break-glass admin account, however, still relies on these controls.

Password policy

Password rules apply to every user who signs in with email and password, including newly invited users when they accept and pick a password.

Defaults

Rule	Default
Minimum length	12 characters
Required character classes	At least three of: lowercase, uppercase, digit, symbol
Maximum length	128 characters
Reuse	Last 5 passwords blocked
Common-password check	Top compromised passwords (haveibeenpwned-style list) blocked
Personal info	Cannot contain the user's email local part or display name
Expiration	None by default (industry guidance is to rotate only on compromise, not on a schedule)

Defaults satisfy NIST 800-63B "memorized secret" guidance for the typical knowledge-worker tenant.

Adjusting the policy

Org admins can adjust the policy at:

Settings -> Security -> Password policy

You can:

• Increase the minimum length (cannot lower it below 12).
• Require all four character classes instead of three.
• Turn on rotation (30, 60, 90, or 180 days). Most organizations should leave this off.
• Tighten reuse history (up to last 24).

Saving the policy applies it to all future password choices. Existing passwords are not invalidated unless you turn on rotation, in which case users are prompted to change at next sign-in if their password is older than the new threshold.

Lockout and rate limiting

After several consecutive failed sign-in attempts on the same email, that account is temporarily blocked from new attempts. The block resets after a short cool-down. The counter is also tracked per IP address to slow distributed guessing. Failed attempts are recorded in the audit log.

If a user has been locked out and cannot wait, an org admin can clear the lockout from Settings -> Members -> [user] -> Reset login attempts.

Resetting your password

End-user flow:

1. Click Forgot password? on the sign-in page.
2. Enter your email address. A reset link is sent if the address belongs to a Performance Blocks account. (For privacy, the page reports success either way.)
3. Open the email and click the link. Reset links are single-use and expire after a short window.
4. Choose a new password that meets the policy. Submit.
5. You are signed in. Sessions on other devices are revoked, so you will need to sign in there again.

If the user does not receive the email, see Troubleshooting below.

Org admins can also trigger a password reset on a member's behalf from Settings -> Members -> [user] -> Send password reset.

Two-factor authentication (2FA)

Performance Blocks supports time-based one-time password (TOTP) two-factor authentication. Enabling 2FA means that, after entering the correct password, the user is asked for a 6-digit code from an authenticator app on their phone. Without that second factor, the password alone is not enough.

Supported authenticators

Any standards-compliant TOTP app works. Common choices:

• 1Password
• Bitwarden
• Authy
• Google Authenticator
• Microsoft Authenticator
• Apple Passwords (built into iOS / macOS Sequoia)
• Yubico Authenticator (with a YubiKey)

Hardware-security-key-only (WebAuthn) sign-in is not yet a separate option in this article — TOTP is the supported second factor.

Enabling 2FA on your account

1. Open Account settings -> Security -> Two-factor authentication.
2. Click Enable two-factor authentication.
3. Confirm your password. You will be asked for it again so that an attacker who finds an unattended browser cannot enable 2FA on top of an account they don't own.
4. A QR code is displayed. Open your authenticator app and scan it. The app shows a 6-digit code that rotates every 30 seconds.
5. Enter the current 6-digit code in Performance Blocks to confirm the pairing.
6. Performance Blocks displays backup codes (typically 10). Save them — see below.
7. 2FA is now enabled. From the next sign-in onward, you will be asked for a code after your password.

Backup codes

Backup codes are single-use codes that let you sign in without your authenticator app — for example, if your phone is lost. Each code works once.

You should:

• Save the codes immediately after enabling 2FA. They are shown only at that moment (and when explicitly regenerated).
• Store them somewhere safe and offline: your password manager (separate vault from the password if possible), a printed copy in a desk drawer at home, or a secure note.
• Treat them with the same care as the password itself.

If you run out of codes or believe they have been exposed, regenerate them from Account settings -> Security -> Two-factor authentication -> Regenerate backup codes. Regenerating invalidates the old codes.

Disabling 2FA

A user can disable 2FA from the same settings page after re-confirming their password and a current 2FA code. Disabling immediately removes the second-factor requirement. Backup codes are deleted.

If the org admin has enforced 2FA (see below), the user cannot disable it themselves.

Enforcing 2FA across the organization

Org admins can require 2FA for all members.

1. Go to Settings -> Security -> Two-factor authentication.
2. Toggle Require 2FA for all members on.
3. Choose the grace period (default 7 days). Existing users who have not yet enabled 2FA will be prompted to do so on their next sign-in and have until the end of the grace period to comply.
4. Save.

Once enforced:

• Users without 2FA are walked through enrollment on their next sign-in.
• After the grace period, users who still have not enrolled cannot complete sign-in until they do.
• Newly invited members are required to set up 2FA during their first sign-in.

Users authenticated through SSO are exempt — their MFA is enforced in the IDP. The break-glass admin account, which is not SSO-managed, must have 2FA enabled.

Why TOTP and not SMS

Performance Blocks deliberately does not support SMS as a second factor. SMS-based 2FA is widely understood to be weaker than TOTP because mobile carriers are vulnerable to SIM-swap attacks, message interception in some networks, and number-recycling. TOTP authenticator apps generate codes locally on the user's device with no dependence on a third party to relay them, which makes them resistant to those attack classes.

If your organization has a policy that mandates a stronger factor still (e.g. WebAuthn / hardware keys), let your account team know — that is a feature on the roadmap and they can flag your requirement.

Multiple authenticator devices

Many authenticator apps now sync the seed across the user's devices (1Password, Bitwarden, Apple Passwords). For users who own more than one device, syncing is the simplest way to ensure that losing a single device does not lock them out.

If your authenticator app does not sync, the supported recovery path is the backup codes flow described above.

Trusted devices and session length

Performance Blocks does not currently offer a "trust this device for 30 days" toggle for 2FA. Each new sign-in requires the second factor. This is deliberate: trusted-device cookies are a common pivot for attackers and the 2FA prompt adds only a few seconds to a sign-in that already happens at most once per session.

Default session length and idle timeout are set globally by the platform. An org admin can request shorter session lifetimes for the organization through their account team if your security policy requires it.

A user can see and revoke all of their active sessions from Account settings -> Security -> Active sessions. An org admin can revoke any member's sessions from Settings -> Members -> [user] -> Revoke sessions.

Recovery: user has lost their second factor

When a user loses access to their authenticator (lost phone, factory reset without restoring backups, etc.) and does not have backup codes, they need help to recover.

User-side recovery

If the user has any of:

• Backup codes,
• Their previous device with the authenticator app and a working seed,
• A multi-device authenticator (such as 1Password) syncing to another device,

they can sign in normally.

Admin-side recovery

If the user has none of the above, an org admin can disable 2FA on the account so the user can sign in with the password and re-enroll.

1. Verify the user's identity out of band. Do not accept the request only by email or chat. Confirm via a phone call, video call, or in-person, ideally to a number or face you already know. This step matters because resetting 2FA on an account is exactly what an attacker who has stolen the password is trying to do.
2. Go to Settings -> Members -> [user] -> Two-factor authentication -> Reset 2FA.
3. Confirm. The user's TOTP secret and backup codes are deleted. An audit log entry records the action with your user id as actor.
4. Tell the user (over the same out-of-band channel) that they can now sign in with their password alone, and that they should re-enroll 2FA immediately afterward.

The user's existing sessions are revoked as part of the reset.

What if the only org admin has lost their second factor?

If the account owner is the only admin and has been locked out, contact support via the company website. They will work with you through identity verification (typically using the billing contact and out-of-band proof) and reset 2FA on the owner account. Plan ahead by:

• Always having at least two org_admin users for redundancy.
• Storing the break-glass admin's backup codes somewhere a second person can access.

Communication and education

Rolling out 2FA enforcement is rarely a technical problem — it is a change-management problem. The team that has done it twice already finds it easy; the team being asked to do it for the first time finds it confusing if the announcement is unclear.

A few practices that help:

• Send a short announcement two weeks before enforcement begins with screenshots of the enrollment page, a list of supported authenticator apps, and a note about backup codes.
• Schedule one or two open office hours where IT helps members enroll. Most members enroll in five minutes; the long tail is users who do not have a personal phone they wish to use.
• Make sure your help desk has a short script for the lost-device case so the response is consistent and identity-verified.
• Provide the break-glass admin's location to a second person on the IT team in a sealed envelope or secure password vault, so a single team member's absence does not make recovery impossible.

If your organization issues phones to employees, work with the device-management team to push the chosen authenticator app to managed devices ahead of the rollout date. That removes one common point of confusion.

Best practices

A short list to share with your members:

• Use a reputable password manager. Generate a unique, long password for Performance Blocks rather than reusing one.
• Enable 2FA the day you accept the invite. Do not wait for the org-wide enforcement deadline.
• Save backup codes in your password manager (or somewhere offline) the moment you generate them.
• Do not paste the QR code or the secret into a chat or email when troubleshooting. If support asks you to verify enrollment, they will use a different mechanism.
• Sign out of shared or borrowed devices when you are done — Account settings -> Security -> Active sessions -> Revoke.

Troubleshooting

"Code is invalid or expired"

The most common cause is clock drift on the phone running the authenticator. TOTP codes depend on the phone clock matching server time within ~30 seconds. Open the system settings on the phone and turn on automatic time, or use an authenticator app that has its own time-sync option.

If a code is correct but rejected, check that you are reading the code for Performance Blocks and not for a different account in the same authenticator app.

"I never received the password reset email"

Check the spam folder and the address you typed for typos. If still missing, the email may be filtered by your mail provider — contact your IT team. As a last resort, an org admin can trigger the reset on your behalf from Settings -> Members.

"I get the verification page but never the QR code"

This happens when the page is loaded over a captive portal or proxy that strips the response. Disconnect from the captive Wi-Fi and try again on a normal connection.

"I enrolled, but the next sign-in says the code is wrong"

Disable and re-enroll. The most common cause is that two devices were paired during enrollment and Performance Blocks stored the seed from one while the user is reading codes off the other.

When to use SSO instead

If your organization is on the Agentic plan and has an identity provider, SSO is the right long-term answer for member authentication. The platform-level password and 2FA controls described in this article still matter for the break-glass admin and any non-SSO accounts (such as test or service accounts), but the day-to-day member experience is simpler when sign-in is delegated.

Consider migrating to SSO when:

• Your member count crosses a threshold where managing per-product passwords is a noticeable cost (often 25–50 members).
• A compliance auditor asks for centralized identity, single sign-out, or directory-driven deprovisioning.
• You want all your applications to share a common MFA factor (e.g. WebAuthn in the IDP rather than per-product TOTP).

See SSO setup for the migration path.

Service and bot accounts

Some organizations want a non-human account for integrations, scripts, or test automation. There are two ways to handle this:

1. API key (Agentic plan): create a scoped API key under Settings -> API. The key authenticates programmatic requests without going through the password sign-in path at all. This is the right answer for almost every automation use case.
2. Dedicated user account: if you need a "bot" that uses the web UI, create a regular member account, give it an email mailbox you control, and enable 2FA on it normally. Treat its credentials like the break-glass credentials — stored in a shared password vault with a documented owner.

Avoid sharing a personal account between two humans. The audit log attributes actions to whoever owns the account, so shared accounts make it impossible to know who did what.

Auditability of password and 2FA actions

Every password and 2FA action is captured in the audit log so an administrator can review who did what.

Action	Audit log entry
Password change (self)	actor = user, action = password.change
Password reset (self)	actor = user, action = password.reset, includes IP and user agent
Password reset (admin)	actor = admin, action = password.reset_for_user, target = affected user
2FA enrolled	actor = user, action = mfa.enable
2FA disabled (self)	actor = user, action = mfa.disable
2FA reset (admin)	actor = admin, action = mfa.reset_for_user, target = affected user
Backup codes regenerated	actor = user, action = mfa.backup_codes.regenerate
Sign-in failure	actor = user (resolved by email), action = auth.sign_in.failed, with reason
Account lockout	action = auth.locked, includes the email and IP that triggered the lockout

These entries are immutable. Pull them when investigating a suspected compromise or when a member reports unexpected sign-in activity. See Audit logs for filtering and export.

Test the recovery path

Before you enforce 2FA org-wide, test the recovery path end to end with a willing volunteer:

1. Have the volunteer enroll in 2FA and save backup codes.
2. Have the volunteer "lose" their device — close the authenticator app and pretend the phone is gone.
3. Use a backup code to sign in.
4. Then exhaust the backup codes (or pretend they are also lost) and walk through the admin-side reset.

This dry run uncovers any gap in your runbook before it matters in production.

Storage of secrets

The TOTP seed used to generate codes is stored encrypted on the server. It is never returned to the client after enrollment — only the QR code is displayed during the brief enrollment window. Backup codes are hashed; they cannot be recovered if forgotten, only regenerated, which invalidates the old set.

Password hashes use a modern, slow, salted hash function (currently a bcrypt-class function) with parameters tuned to take ~100ms per verification on the production hardware. This makes offline cracking expensive even if a hashed password were somehow exposed.

Plan for the unhappy path

A short table to keep next to your runbook:

Situation	Resolution
Member forgot their password.	Self-serve via Forgot password? on the sign-in page.
Member's reset email never arrived.	Admin sends reset from Settings -> Members -> [user].
Member lost phone with TOTP, has backup codes.	Member uses a backup code, then re-enrolls.
Member lost phone, no backup codes.	Admin verifies identity out of band, resets 2FA in Members page.
Account is locked from too many failed attempts.	Member waits for cool-down, or admin clears in Members page.
Account owner has lost both password and 2FA.	Contact support; identity is verified via the billing contact.
You suspect an account is compromised (unfamiliar sign-in audit entries).	Admin revokes sessions immediately, then triggers a password reset and re-enrolls 2FA.

Related

• Security overview
• SSO setup
• Audit logs