Sign In and MFA: TOTP Setup, Recovery Codes and Rate Limits

Sign-in is your credential first — password, Google, or your firm’s SSO — and a time-based one-time password (TOTP) second, when MFA applies to your account. It always applies to Superadmin and Firm Admin; for Analyst, Manager and Partner it applies when you enrol it yourself or when your firm’s security settings mandate it. This page is the sign-in paths, the setup, and the recovery routes.

Ways to sign in

• Email and password. The default path, rate-limited to a handful of attempts a minute per client, behind a captcha check when the platform has it enabled.
• Google. One tap through Google OAuth, then the same session as any other sign-in. A Google identity binds to exactly one account, so it cannot be used to reach someone else’s.
• Firm SSO. A firm can wire Quartyl to its corporate OpenID Connect provider. When a firm enforces SSO for your email domain, the password form refuses and points you at the SSO button instead.

Whichever you use, if the account is MFA-enrolled you still pass the code step; if your role mandates MFA and you have not enrolled, you land in the enrolment wizard. A firm that enforces SSO still honours the mandate.

The sign-in flow

1. Enter your email and password (or use Google / firm SSO).
2. If your account is MFA-enrolled, sign-in pauses into a short-lived verification step (valid for 10 minutes): enter the 6-digit code your authenticator app is currently showing — or a recovery code, if you have lost the app.
3. You are in. The session is an access token plus a refresh token used to renew it silently; there is no server-side session to expire on the device. Tokens minted before a password reset stop working, so a reset logs every old session out.

One legal gate sits outside MFA: when the Terms of Service version you accepted is stale, sign-in stops and asks you to accept the current version before a session is issued.

TOTP parameters, for anyone verifying against their authenticator: issuer “Quartyl”, 6 digits, 30-second time step, and a one-window tolerance on each side for clock drift — which means a code is valid for the current 30-second window and the adjacent ones. If a code is rejected, wait for the next one rather than retrying the stale one.

Enrolling TOTP (first time, or a new device)

1. Open the MFA setup in your account settings — or arrive at it from sign-in or the claim flow, if your role mandates it.
2. You get a provisioning link rendered as a QR code, plus the manual secret. Scan it with any standard authenticator — Google Authenticator, Authy, 1Password, Microsoft Authenticator, or a hardware token app that speaks TOTP — or enter the secret by hand.
3. Confirm with the code the app now shows. MFA is not enabled until that confirmation succeeds, and the secret is generated and held server-side — the app never sends it back.
4. The enrolment issues ten recovery codes, shown exactly once, in 4-4-4 groups (for example A7C2-Q9F3-K4P8). Save them now. Each is single-use; the system stores only a hash of each, so there is no second time to see them. The alphabet drops the ambiguous characters (0/O, 1/I/L), which is why a code is safe to read out over the phone.

Recovery codes: the lockout fallback

Recovery codes exist for the one situation TOTP cannot cover: you no longer have the device that generates codes.

• When to use one — lost phone, new phone before the old one is recovered, an authenticator app you cannot re-open. Enter it in the same box as the 6-digit code; it logs you in once, in place of a TOTP code, and is removed from your account the moment it is spent.
• The habit that matters — after using a recovery code, re-enrol the authenticator. Re-enrolment replaces the secret and issues a fresh set of codes, retiring the ones you were issued before.
• Running out — when all ten are spent and the authenticator is unrecoverable, the path is the platform recovery console: the platform operator clears the account’s MFA enrolment and sets a new password, which they hand over out of band. It is deliberately someone else’s action — MFA reset is a privilege, not a self-serve flow. Your Firm Admin manages the firm’s roster and mandate, not this.
• Turning MFA off — if no mandate covers your role, you can disable your own enrolment with a current code. Mandated roles cannot, by design.

Failed attempts and rate limits

There is no per-account code counter that freezes you out; the protection is rate limiting plus an audit record of every failure.

• The code-verification step is limited to five attempts a minute, so guessing is not a path in — it just wastes your minute.
• Sign-in itself is rate-limited the same way, and the forgot/reset-password pair is limited far harder (a few per hour).
• A rejected code is usually a stale code (wrong 30-second window) or a device with the wrong clock — wait for the next window, and check the device time.
• Every failed code and every spent recovery code is written to the access log with the client IP, which is what the audit trail reads later.

Who must have MFA, and who configures it

Role	MFA	Who decides
Superadmin	Mandatory, always	The platform — cannot be disabled
Firm Admin	Mandatory, always	The platform — cannot be disabled
Analyst / Manager / Partner	Per firm policy, or optional	The Firm Admin, in firm security settings: firm-wide mandatory, or mandatory for named roles. With neither set, enrolment is your choice

A mandated user who has not yet enrolled is not refused at sign-in — the session comes back flagged as needing enrolment and the app routes you into the wizard. Until you enrol, only MFA setup, your own profile, session renewal and sign-out are served; every data-bearing request is rejected. The mandate is enforced on the API, not by blocking the attempt.

FAQ

Which authenticator apps work? Any standard TOTP app: Google Authenticator, Authy, 1Password, Microsoft Authenticator, and hardware tokens that generate TOTP codes. The format is the RFC 6238 standard — there is nothing Quartyl-specific to install. Delivery is never SMS or email: codes are generated on your device.

Can I use two devices? Enrolment persists one secret, and re-enrolment replaces it. Two apps work only if you enter the same secret into both before confirming. The supported pattern is one enrolment, one primary device, and the recovery codes as the fallback — not a second active app.

Does MFA protect the data, or just the session? Practically both: the session is unreachable without the second factor, and the roles that mandate MFA (Firm Admin, Superadmin) are the roles that change security configuration and manage the team — so the mandate follows the privilege, not the inconvenience. Clearing an enrolment sits one level above that, on the platform side, so no firm-side role can quietly strip a colleague’s second factor.

What happens to a study I am processing if I lose my phone mid-review? Nothing to the study — work is tenancy state, not device state. You re-enrol on a new device (or use a recovery code) and pick the study up where the audit trail shows it left off.