Users, roles, permissions¶
User management is administrator-only. There are two kinds of account, and the difference is a trust boundary, not a preference.
Internal accounts¶
Internal accounts are the pentesters and leads who work on the internal surface. An internal account has a role (administrator or pentester), and TOTP is mandatory: the requirement lives in the database schema, so no route, script or migration can create an active internal account without a second factor. Recovery codes are issued for the second factor, stored only as hashes and invalidated on use; a lost device is recovered through them or an administrator reset.
Client accounts¶
Client accounts reach only the portal, where they read what has been published and released to their own client and write exactly one thing, that client's fix declaration. They are password-based. The intended deployment sits behind an edge that can enforce a second factor (for example Cloudflare Access), so a portal account is a lower-value credential by design: no internal fields, no exploitation steps, and no reach into the internal surface at all.
They are administered on the client they belong to, not on this screen. A portal account cannot exist without a client, and revoking one is something you do at the end of an engagement, on that client -- so the client's own edit drawer is where you invite one, see the ones that exist, revoke access, restore it, and send a fresh activation link. This screen is internal accounts from end to end.
What the client's list shows is what revoking and reviewing turn on: the address, the name, whether access is active, whether the person enrolled a second factor, and when they last signed in. A revoked account stays in that list, marked revoked, because "was this client's access revoked?" is a question an audit has to be able to answer, and an account that vanished answers it the same way as an account that never existed.
Revoking takes effect immediately, not at the person's next sign-in. The portal checks the account on every request and the revocation closes the sessions that are already open, so a browser signed in a minute ago is signed out on its next click. You can revoke at the end of a meeting and close the laptop.
Re-sending the activation link closes that account's open sessions too, and the old link stops working. That is deliberate: somebody re-sends a link precisely when they are no longer sure who is holding the old one.
Inviting an account¶
There is no default credential. You invite an account, and PEART issues a single-use enrollment link the person redeems to set their password and, for an internal account, enrol TOTP. The link is built from the configured public URL of the right surface (the internal surface for an internal account, the portal for a client), so it points where the person will actually reach the system. If that public URL is not configured, PEART refuses to fabricate a link and hands you the raw token with an instruction, rather than printing a host that would not resolve.
Deactivating and deleting¶
An account can be deactivated (kept, but unable to sign in) or deleted. The protection against locking the installation out of its last administrator lives on the server, which refuses the operation rather than relying on the interface to predict it. Deleting an account is refused when it has history that must be preserved (a lead assignment, finding authorship), so the interface offers the action and the server decides.