Account security and 2FA

Can we require every team member to enable 2FA at the tenant level?

Not today as a tenant-wide enforcement toggle. 2FA is per-user opt-in — each member decides whether to enrol and the system doesn't reject sign-ins from a member who hasn't enrolled.

Practical recommendation: have the owner and everyone with manager or any financial / refund permission enrol explicitly. The 2FA settings page calls out the recommendation in the in-product banner. Tenant-enforced require-2FA is a roadmap-conversation feature — talk to us if a policy enforcement is load-bearing for your store.

Why TOTP and not SMS-based 2FA?

SMS-based 2FA is widely supported but meaningfully weaker than TOTP for the threats it's meant to defend against. SIM-swap attacks (where an attacker convinces a mobile carrier to port your number to their device) bypass SMS 2FA entirely; high-value targets have lost accounts this way repeatedly over the past decade. TOTP secrets are bound to your physical authenticator app — they can't be redirected by a carrier social-engineering attack.

The cost is the UX learning curve — first-time TOTP users have to install an authenticator app, scan a QR, and remember to grab a code at signin. That cost is real and is why the in-product banner explicitly recommends it without forcing the user through the setup. Once enrolled, the daily flow is one extra tap.

I lost my phone with the authenticator app and haven't saved my backup codes. Help.

Contact support with your account email. Account recovery from this state involves an identity verification step (we need to confirm the account actually belongs to you before disabling 2FA); expect that to take longer than a typical support ticket because the verification is intentionally not fast — the same path would otherwise be the attacker's recovery path.

The lesson the next time around: save backup codes the moment you see them. Treat them like a second password; print them, store them in a password manager, do not skip the “Save these codes” step. The system shows them in plaintext exactly once for a reason — every other recovery path has friction.

My authenticator app is on the same phone I use to sign in to Nexpura. Is that fine?

It's acceptable but it weakens the security posture slightly. The two-factor model is strongest when the “something you have” (the authenticator) is on a different device from where you sign in — if the same phone is compromised, both factors are compromised together.

In practice for a small jewellery business, the same-phone setup defends against the most common real-world threat (a stolen / leaked password) and that's the threat the recommendation is built around. A more elaborate posture (authenticator on a separate device, hardware key) is available to anyone who wants it, but isn't required.

How does this interact with manager-PIN? Do I need both?

They're separate mechanisms with different jobs. 2FA gates account sign-in — “is the person signing in really you?”. Manager-PIN gates a specific elevated operation (refund overrides outside the 30-day window or without an originating sale) — “is the person at this terminal authorised to do this specific thing?”. Both can be enabled independently.

Typical posture: enable 2FA for everyone who has access to anything financial. Set a manager-PIN for every member who might be authorising refunds — the owner, every manager, and any staff who has canProcessRefunds enabled. Manager-PIN details on team-and-roles.

What are the password requirements?

Passwords must be at least 8 characters and include all four character classes: an uppercase letter, a lowercase letter, a number, and a special character (e.g. !@#$%). The strength meter on the signup form shows in real time which requirements are still outstanding. Longer is stronger — the meter rewards 12+ characters as a bonus.

In addition, every password is screened against the Have-I-Been-Pwned breach corpus — if your chosen password has appeared in a known leak it's rejected regardless of length. Practical tip: a memorable phrase plus a digit and a symbol (e.g. “Sunset!42”) clears the requirements comfortably and is far easier to remember than a random string.

Password update fails with “Current password is incorrect” even though I'm sure it's right

Symptom: you enter your current password and the new password, click Update, get the incorrect-current-password error. Cause: usually a recently-changed password that the browser's password manager hasn't updated yet — autofill drops in the old saved value. Sometimes a stuck capslock; rarely a real account issue. Fix: click into the current-password field and TYPE the password manually rather than letting autofill populate it. Verify capslock is off. If still failing, sign out, sign back in to confirm the password works for signin (it should), then retry the change.

Authenticator app codes are all being rejected at signin

Symptom: every TOTP code your authenticator generates returns “Invalid code” at the 2FA step of signin. Cause: the most common cause is clock drift on the device running the authenticator — TOTP relies on the device clock matching the server clock to within about 30 seconds. A few minutes of phone clock drift breaks every code. Fix:on the phone, open Settings → Date & Time and enable “Set automatically”. After the clock corrects, the authenticator's codes will start matching again — try the next code from the app. If clock is correct and codes still fail, use a backup code to sign in, then disable + re-enrol 2FA to get a fresh secret.

QR code on the 2FA setup page won't scan

Symptom:the QR renders but your authenticator app can't capture it cleanly. Cause: usually screen brightness too low or the camera angle is off; sometimes a screen filter / privacy film distorts the contrast. Fix:brighten the screen, move the camera until the focus locks, try again. If still failing, use the manual entry path — copy the plaintext secret string shown underneath the QR, open your authenticator app, tap “Enter a setup key” or similar, paste the secret. The TOTP secret itself is the same; the QR is just a visual encoding.

Used a backup code at signin but it says “Invalid”

Symptom: you entered one of your saved backup codes at the 2FA signin step and got Invalid code. Cause:the code was already consumed on a previous recovery signin (backup codes are one-time-use). Or you copied the code with extra whitespace / a stray character. Or you regenerated backup codes after saving the batch you're trying to use, which invalidated the older batch. Fix:try the next unused backup code from your saved list (do this carefully — each failed attempt isn't consumed, but each successful one is). If every code rejects, the batch is no longer valid (e.g. from a regenerate-after-save), and you'll need to recover via the lost-phone support path described in Common questions.

I disabled 2FA, but signin still asks for a code

Symptom: after clicking Disable 2FA, the next signin still prompts for a TOTP code. Cause:the disable likely didn't complete server-side — either the confirm dialog was cancelled or the API call failed silently. The 2FA page's “2FA is Enabled” banner on next load confirms the current state. Fix: sign in with a backup code (or TOTP if you still have the authenticator), return to /settings/two-factor, confirm 2FA shows as Enabled, click Disable 2FA again, confirm the dialog. The next signin should be password-only. If the disable still fails, contact support — there's a backend cleanup path that support can run.