Setting Up Multi-Factor Authentication for Your Firm

Pental supports two second factors: a passkey, which is the fingerprint reader or security key on the device in front of you, and an authenticator app producing a six-digit code. Which of them your firm accepts is a setting, and the setting is enforced in your database rather than in the screen, so a modified browser cannot skip it. Security covers how the rest of the portal leans on that check.

Choose which methods you accept

Settings, then Security, under MFA Methods; administrators and seniors set it. You are choosing two things: the Allowed methods (Authenticator app, and Security key / passkey), and the Required methods, either At least one method (recommended) or Both methods (strict). The default is both allowed and at least one required, which is the right answer for most firms. Enrolments already made stay valid if you later disallow a method, but nobody can newly enrol it.

Requiring both is not paranoia if your people carry client data on laptops. It does mean every new colleague sets up twice before they can work, so decide it before you invite anybody rather than after.

A passkey always brings a backup authenticator with it, whichever policy you pick, unless authenticator apps are not allowed. The enrolment screen says why: a passkey works on the device and browser it was made on. It is also tied to your portal’s address, so moving the portal to a new domain, or back to your Pental subdomain, clears passkeys, and anyone who used one signs in with an emailed code once and sets up a new one. Authenticator apps keep working through a change of address.

What a person sees on their first sign-in

They sign in, and before they reach anything they are asked to enrol. If both methods are allowed they choose; if the policy is Both methods (strict), they are walked through both in turn. Registering the passkey stamps the session as verified, so adding the backup authenticator immediately afterwards does not ask them to prove anything again.

Somebody who registers a passkey and closes the tab is not finished. On their next sign-in they are asked for the passkey first, and then sent straight to the backup step. That order matters: the database refuses to add an authenticator to a session that has not proved an existing one, because a six-digit code only proves possession of the new secret, which whoever stole the session also has.

Set the inactivity windows

Same screen, above MFA Methods. Two numbers decide what happens to a session that sits idle, and a third when its sign-in token is renewed, each with the screen’s own description:

The setup wizard’s security step, which Re-run Setup Wizard at the top of Settings opens again, also asks what happens On inactivity timeout: Require MFA re-verification, which keeps the session and asks for the second factor again, or Sign out immediately, which ends it. The first suits a firm working in long sittings; the second suits shared spaces and machines that are not people’s own.

When somebody is locked out

An administrator or a senior clears a colleague’s second factor with Reset MFA on the Users list (or on a client’s Portal Users, for a client login), which sends them back to enrolment on their next sign-in. They must have passed their own second factor in this session, and can reset only somebody below them; another administrator’s is for the account owner alone.

Nobody at Pental can do this for you. What Pental holds to reach your database (its address, its publishable key and a provisioning credential) cannot clear a second factor, so the reset takes a signed-in administrator or senior of your portal. If every administrator is locked out, your database’s owner runs select public.owner_reset_mfa('person@yourfirm.com'); in Supabase’s SQL editor, or with psql behind a Pental gateway, which has no SQL editor; adding your team has the detail. That is the trade for the data living in your own database, and it is worth telling a client during a security review.

Other sessions

The Active Sessions card on your dashboard lists the devices signed in as you, with where each signed in from and when it was last active, and Revoke on each; administrators also find the list under Settings, Security, with Sign out other devices. Worth doing after a conference, or any time a machine leaves your control.

Every screen above is on your database. If a colleague reports that MFA settings will not save, the first thing to check is that your database is on the current schema: the portal shows an update prompt to administrators when it is not. Changing the portal’s address, moving it to your own domain for instance, clears passkeys, so make that move before people enrol them.