Security

Setting Up Multi-Factor Authentication for Your Firm

Two methods, an any or all policy, and the rule that a passkey always needs a backup authenticator. Plus what happens to a session that goes idle, and how a locked-out colleague gets back in.

3 min read

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 the database rather than in the screen, so a modified browser cannot skip it.

1. Choose which methods you accept

Settings, then Security. You are choosing two things. Which methods are ALLOWED, and whether a person needs ANY one of them or ALL of them. The default is both allowed, any one required, which is the right answer for most firms.

Requiring all of them 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 demands a backup authenticator, whichever policy you pick. A passkey lives on one device and one browser. Without a second method, a lost laptop is a locked account and only another administrator can clear it.

2. 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 all, 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.

3. Set the inactivity rule

Same screen. When a session has been idle past your timeout, you choose between two behaviours, and they are genuinely different.

What happens when a session goes idle
Require MFA re-verificationThe session stays, and the person proves a second factor again before they can carry on. Less disruptive, and the right default for a firm working in long sittings.
Sign out immediatelyThe session ends. They sign in from the start. Correct if your people work in shared spaces or on machines that are not theirs.

The timeout itself is a separate number on the same screen. Past a longer window the session is over regardless, and an idle screen will sign out rather than offering a code.

4. When somebody is locked out

An administrator can clear a colleague’s MFA from the user list, which sends them back to enrolment on their next sign-in. That action needs the administrator to have verified their own second factor recently, and it is recorded.

Nobody at Pental can do this for you. The reset runs as a signed-in administrator of your database, and the platform holds no credential that can bypass it. That is the trade for the data living in your own project, and it is worth telling a client during a security review because most platforms cannot say it.

5. Other sessions

My Profile lists the sessions currently signed in as you, with the device and when each was last active, and lets you end any of them. 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.

Set This Up on Your Own Database

Every policy on this page is enforced in your own Postgres project, by policies you can read, not by a screen that hides a button.


Also Worth Reading