Adding Your Team, Roles and Multi-Factor Authentication

Access is decided in the database. Every table carries row-level security, and the policies read the role on your profile and, for anything sensitive, whether the session has passed a second factor recently. An account with the wrong role does not see a disabled button, it sees nothing, because the rows never come back.

The roles

Multi-factor

Two methods are supported: an authenticator app, and a security key or passkey. Under Settings, then Security, you choose which methods are allowed and whether one is enough or both are required.

Whichever policy you pick, enrolling a passkey also asks for an authenticator app as a backup. A passkey only works on the device and browser it was created on, so without a second method one lost laptop is one lost account.

Inactivity

The same screen sets what happens when a session goes idle: either require MFA re-verification, which keeps the person signed in but makes them prove the second factor again before touching data, or sign them out entirely. The first is the usual choice for a working day; the second suits shared machines. You can also see and revoke other active sessions from there.

When somebody loses their factor

An admin resets it from the user list, and that requires a signed-in admin of your own portal. Pental cannot do it: the provisioning credential we hold deliberately cannot clear MFA, which is what stops a convincing support request becoming a route into your data. If you somehow lose every admin, recovery is through your own database project, because it belongs to you.

Worth doing on day one

• Enrol your own second factor before inviting anybody.
• Set the policy and the inactivity rule now, not after ten people have enrolled under the old one.
• Add a second admin. One admin plus one lost phone is a bad afternoon.