Multi-factor authentication

Flowtly Editorial Team4 min

Multi-factor authentication (MFA) asks for a second proof of identity when you sign in, on top of your password: a six-digit code from an authenticator app on your phone. You set it up yourself under Profile → Security, and an administrator can require it for everyone in the organization.

Setting up an authenticator app

Under Profile → Security, choose Start setup. Flowtly shows a QR code and the secret behind it — scan the code with your authenticator app, or type the secret in by hand if you cannot scan it. Then enter the six digits the app shows and choose Verify and enable.

Codes are six digits and change every 30 seconds. The code from either side of the current one is still accepted, so a phone clock that drifts by a few seconds does not lock you out.

MFA is switched on only once you have entered a correct code. Until then, nothing about your sign-in changes.

Recovery codes

Confirming your authenticator gives you ten recovery codes. Each one works once, in place of a code from your app, and they exist for the day you no longer have the phone.

They are shown once and cannot be shown again. Save them somewhere safe, or use Download codes to keep them as a file. Setting an authenticator up again issues a fresh ten, and the previous ten stop working.

If your organization requires MFA

An administrator can require MFA for everyone. If that is switched on and you have not set up an authenticator yet, the sign-in screen takes you through setup: scan the code, enter the six digits, save the recovery codes, and you are signed in.

You do not need to ask an administrator, and nobody is locked out by the requirement being switched on.

Trusted devices

When you enter a code you can tick Trust this device. Flowtly then stops asking for a code in that browser for 30 days. It is per browser rather than per person: another browser, a private window or a second computer asks again.

Profile → Security lists the devices you have trusted and when each was last used, and lets you revoke any of them — or Revoke all, which is what to reach for when a laptop is lost or stolen.

Email as a fallback

You can switch on an email fallback, so a one-time code can be sent to your address when the authenticator is not to hand. That code is valid for ten minutes.

The fallback is weaker than an authenticator app, because it is only as safe as the mailbox behind it. An administrator can switch it off for the whole organization, and when they do it is off for everyone, whatever the individual setting says.

Replacing or switching off your authenticator

Profile → Security → Reset switches MFA off for your account. It asks first for a current code from your app or one of your recovery codes, so nobody can do it from a session they should not have.

Resetting clears more than the app. The secret, every recovery code, any pending email code and every trusted device all go, and the email fallback is switched back off. That is what makes it the right move for a phone that was lost or compromised. You then set an authenticator up again from scratch — and if your organization requires MFA, you are asked to do that at your next sign-in.

Requiring MFA for everyone

Settings → Security carries a single control: require MFA for the organization. It is the only setting on that page — there are no password policies and no session timeouts.

With it on, everyone signs in with a second factor, and members who have not set one up are taken through setup on the sign-in screen rather than being refused. Switching it on therefore strands nobody.

Demo accounts cannot have MFA enabled.

Example use cases

  • Protect an account that can see payroll, invoices and bank data with something more than a password.
  • Meet a client's or an insurer's security requirement by turning MFA on for the whole organization in one place.
  • Keep a shared office computer signing in cleanly by trusting it for 30 days, while a laptop that travels is asked every time.
  • Recover access from a recovery code when the phone with the authenticator is lost, then reset and set up the new phone.

Connection map

Refers toPart ofFulfils
Documented hereDocumented elsewhere
audit-log records person. setting defines attribute. org-document access governed by setting. subscription gates setting. setting requires second-factor. second-factor held by person. recovery-code stands in for second-factor. trusted-device waives second-factor.recordsdefinesaccess governed bygatesrequiresheld bystands in forwaivesAAudit trail — The record of who did what and when. It is how a user action is investigated after the fact, and what compliance is demonstrated from.Audit trailPPerson — An employee. The central record the rest of the workforce data hangs off — profile, documents, leave, benefits, rates.PersonSSetting — Platform-wide configuration — behaviours, permissions, security.SettingAAttribute — A custom data field defined once and collected across the platform, so an organisation can record what Flowtly does not ship a field for.AttributeDDocument — An organisational file, stored with control over who can reach it.DocumentSSubscription — The plan the organisation is on, and what it is billed for.SubscriptionSSecond factor — The extra proof of identity asked for at sign-in on top of the password — a six-digit code from an authenticator app, changing every 30 seconds.Second factorRRecovery code — One of ten single-use codes issued when an authenticator is confirmed. Each stands in for a code from the app once, for the day the phone is gone.Recovery codeTTrusted device — A browser a person has chosen to trust, which is not asked for a second factor again for 30 days. Per browser, not per person.Trusted device