How to Enable Two-Factor Authentication

Two-factor authentication (2FA) adds a TOTP-based second factor — the kind of code generated by an authenticator app — on top of the password every user already has. Atender supports it two ways: a tenant owner/admin can require it for their own workspace, or a superadmin can enforce it across every tenant regardless of each tenant’s own setting. Either way, once required, users who haven’t enrolled are blocked from the app until they do.

Turning on the policy for your tenant

If you’re an owner or admin, the requirement is a tenant-level policy:

1. Go to Settings → Users.
2. Turn on Require two-factor authentication.
3. Save.

From that point, every member of the tenant — including you — must have a TOTP authenticator enrolled to keep using the app. There’s no grace period or “enroll within N days”; the check runs on the next authenticated request.

This setting can be viewed at any time, even by a user who is currently blocked for not being enrolled yet — that’s intentional, so the screen that tells you to enroll can actually render. Changing it, however, always requires being past the block yourself.

Superadmin-enforced policy

A superadmin can also require 2FA for a tenant (or across all tenants) independently of that tenant’s own toggle. This is the org-wide enforcement path — useful when a workspace’s admins haven’t turned the tenant policy on themselves, but the requirement still needs to apply. The same enrollment flow and the same blocking screen apply either way; users don’t see a difference between “your tenant required this” and “a superadmin required this for you.”

If a superadmin is impersonating a tenant to help with support, they’re held to the same rule: if the enforcement is on, the superadmin’s own session needs its own second factor first. Impersonating someone doesn’t borrow their exemption.

Enrolling a TOTP authenticator app

Once 2FA is required — for your tenant or org-wide — each user enrolls individually:

1. Open an authenticator app on your phone (any standard TOTP app works — the kind that generates a rotating 6-digit code).
2. In Atender, go to the two-factor enrollment screen (this is what you land on automatically if the requirement is on and you’re not yet enrolled — see below).
3. Scan the QR code (or enter the setup key manually) in your authenticator app.
4. Enter the code the app generates to confirm the pairing.

Once confirmed, your session is treated as fully verified and you can use the app normally. If you ever need to re-enroll — say, you got a new phone — you can remove the old factor and add a new one from the same screen, as long as you’re not left with zero factors while the policy is on.

What happens if you haven’t enrolled

If the requirement is on and you haven’t set up an authenticator app, Atender blocks you at the app shell level: instead of your workspace, you land on a screen asking you to enroll. You can’t dismiss it or work around it by navigating elsewhere — every authenticated route behaves the same way until you enroll.

A couple of things stay reachable even while you’re blocked, on purpose, so the block doesn’t lock you out of clearing itself:

• Your own account info still loads (needed to render the enrollment screen at all).
• The enrollment/verification exchange itself, obviously.

What does not stay reachable is the policy setting itself in a way that would let you turn the requirement off from a blocked, password-only session. If you’re blocked, the way out is to enroll — not to disable the policy.

Recovering from a lost device or lockout

If a user loses the device their authenticator app was on, they can’t generate new codes and are stuck at the enrollment/verification screen. There are two ways out:

• Remove the lost factor and re-enroll. If the user can still get into a session that’s otherwise valid (they just can’t produce a code), a superadmin can reset their 2FA enrollment, clearing the old factor so the user can add a new authenticator app from scratch.
• Superadmin-mediated recovery. Because superadmins can act on a tenant regardless of that tenant’s own 2FA state, support can step in to reset a locked-out user’s factor even if the whole tenant is currently blocked. The superadmin doing the rescuing must be enrolled themselves if enforcement applies to them too — so recovery depends on at least one enrolled admin existing somewhere in the chain.

There’s no self-service “I lost my phone, let me back in” flow that bypasses a second factor entirely — by design, since that would be the same hole 2FA is meant to close. If you’re locked out, contact an owner/admin or Atender support rather than trying to work around the block.

Removing your own last factor

You can remove an authenticator app from your own account at any time. If 2FA is required and it’s your only factor, the UI will warn you that removing it leaves you unenrolled — and the very next request after you do it, you’ll land back on the enrollment screen. This warning is a courtesy, not a server-side lock: if you remove it anyway, the block is the intended outcome, not a bug.

Current scope limits

A few things worth knowing before you treat 2FA as covering every door into the app:

• The mobile API path is not yet covered. Signing in through the mobile app login currently authenticates with a password only and does not yet ask for a second factor, even when the tenant (or a superadmin) requires 2FA everywhere else. This is a known gap, not a setting you can change — don’t rely on 2FA as a complete control until it’s closed.
• 2FA is a login/session requirement, not a per-action step-up (yet). There’s currently no “step up for this specific sensitive action” flow — enrollment and verification happen once per session, the same way password auth does.

If your security requirements depend on 2FA covering every access path without exception, factor the mobile gap into your risk assessment until it’s addressed.