Two-factor authentication: the email sign-in code

Current protects every password sign-in with a second factor: a 6-digit code emailed to the address on your account. It is not optional and there is nothing to enrol in — no authenticator app, no QR code to scan, no recovery codes to print. If you sign in with an email address and a password, you will be asked for a code the first time you use a browser, and then trusted on that browser for 30 days.

Forgot the password itself? On the sign-in page, enter your email, choose the password step, and click "Forgot password?" — a reset link lands in your inbox (check spam). The link opens a set-new-password page and signs you straight in; it works once and expires quickly, so use it soon after it arrives.

Current carries real PSA billing data, partner project data, and your entire CRM. A leaked or reused password shouldn't be enough to get someone into Current, and the emailed code means it isn't.

1. 1
   Sign in with your email and password

   Current checks whether this browser already holds a valid trusted-device token for you. If it does, you go straight to the app and never see a code.
2. 2
   Check your email

   If there's no trusted device, Current lands you on a "Check your email" screen and immediately sends a code. The message comes from Current's notifications address with the subject "Your Current sign-in code" followed by the code itself, so it's easy to spot — and easy to find in a spam folder.
3. 3
   Enter the 6 digits

   Type the code and choose Verify & sign in. The code is single-use: verifying it consumes it, so it can't be replayed.
4. 4
   You're trusted for 30 days

   A successful code issues a trusted-device token that lives in that browser for 30 days. You won't be challenged again on that browser until it expires — or until you switch browsers, switch machines, use a private window, or clear your site data.

The code path is rate-limited on both sides — how fast codes can be requested, and how many times a wrong one can be guessed. Both limits are counted per person on the server, so they survive requesting a fresh code.

• ＋No code arrived — wait 20 seconds, choose Resend code, and check spam and quarantine. The subject line contains the code itself, so a search for "Current sign-in code" usually finds it.
• ＋"Too many attempts — try again in about 15 minutes" — that's the lockout. It clears on its own; there is no admin override to shortcut it. Wait it out rather than hammering Resend code, which counts against the hourly cap.
• ＋"No email address is on file for this account" — your account was created without an email address. A Tenant Admin has to add one before you can sign in; see "Invite team members and assign roles".
• ＋"Two-factor email isn't set up for this workspace yet" — the workspace's email sending isn't finished. Sign-in is refused on purpose rather than waved through. Your admin should complete email setup; see "How Current sends email — and why two mail paths, not one".
• ＋Challenged on every sign-in — the trusted-device token lives in your browser's local storage. Private windows, aggressive privacy extensions, or a policy that clears site data on exit will drop it every time, so every sign-in asks for a code. That's working as designed.
• ＋Stuck on the code screen — there is always a Sign out link on that page. Signing out and starting again is safe.

• ＋There is no per-person 2FA toggle to switch on and no workspace switch to turn it off. Every password session is covered, including the partner portal — a partner signing in with a password gets the same code flow.
• ＋Offboarding is the real control. Deactivating someone in Admin → Users & roles cuts their data access at the database, whatever trusted device they still hold, and drops them on an "access turned off" screen on their next page load.
• ＋If a laptop is lost, deactivate the person (or move the workspace to SSO and let Entra handle revocation). A trusted-device token is bound to the account, so removing the account's access removes the token's value.
• ＋Requiring SSO is a checkbox on the SSO block in Admin → Integrations — "Require SSO for this workspace (admins with a password keep access)". It only appears once an identity provider is actually connected, so you can't bounce your team toward an IdP that doesn't exist.