Setup

Adding your team, roles and multi-factor authentication

Inviting internal users, choosing between password and code sign-in, deciding which second factors to allow, and understanding what each role can reach.

7 min read

Access in Pental is decided by your database rather than by the interface, so getting roles and factors right at the start is worth ten minutes. This guide covers inviting people, the sign-in modes and the MFA options.

Choose how people sign in

By default everyone signs in with an email address and a password, followed by a mandatory second factor. New users receive a link to choose their password, and passwords are hashed and stored only in your own database. If you would rather not have passwords at all, one setting switches the sign-in page to emailed one-time codes instead, still followed by the second factor.

Whichever mode you pick, the second factor is not optional and is enrolled before the portal opens for the first time.

Decide which factors to allow

You choose which methods your firm accepts: passkeys, authenticator apps, or both. Passkeys are the stronger option and worth defaulting to for internal staff. Requiring a specific method is available where a client contract or your own policy demands it.

Single sign-on

Google and Microsoft SSO can be enabled if your firm already centralises identity there. It sits alongside the other modes rather than replacing them, so an account that cannot use SSO still has a route in.

Roles

Internal roles are graded by seniority and decide what a user can see and change across the platform.
A sales role exists for people who work on proposals and clients without needing engagement detail.
Client accounts are locked to their own organisation. A client sees its own record, its own assessments and only the findings you have released.

None of that is enforced by hiding buttons. The rules live in row-level security policies evaluated by Postgres on every query, so a request that fails one receives no rows at all.

Sessions

Sessions are per-device rows you can list and revoke, with a configurable timeout and a stale sweep. When someone leaves, revoking their sessions takes effect immediately rather than at the next token expiry.

A sensible starting policy

Passkeys allowed and encouraged, authenticator apps as the fallback.
Session timeout matched to how your team actually works, not to the longest anyone might want.
Client accounts created only when an engagement is ready for them to see something.
A quarterly look at the user list, which takes about two minutes and catches the accounts everyone forgot.

Also worth reading