Skip to content

Security & access

Plutus supports single sign-on, two independent multi-factor authentication methods, a three-tier role hierarchy per account, and org invites for adding members. Access changes take effect immediately — a role change, a removed member, or a deactivated user is enforced on that person’s very next request, not after their session eventually expires.

Sign in with a Google or GitHub account instead of a password, from the login page’s “Continue with Google” / “Continue with GitHub” buttons.

The first sign-in with a given provider account creates a Plutus user linked to it. If a user with that email already exists, the linked identity is added to it, not a new duplicate account.

Google requires the Google account’s email to be verified before Plutus accepts it. GitHub uses your public email if you have one set, or fetches your primary email from your GitHub account if not.

Two independent methods, and you can enable either one, both, or neither:

  • Authenticator app (TOTP) — scan a QR code with an app like Google Authenticator or Authy, then confirm a code to turn it on.
  • Email code — a 6-digit code sent to your account email at login time.

Enabling your first MFA method generates a set of one-time recovery codes. These are shown once, at the moment you generate them — save them somewhere safe, since Plutus can’t show them to you again. Each code works once, as a fallback if you lose access to your authenticator app or your email.

Turning off an MFA method requires your current password. Recovery codes are only cleared once both methods are off.

Setting up MFA and using it to log in are different steps. Enabling, confirming, or disabling a method happens from your profile while you’re already logged in. Logging in with MFA happens after your password is accepted: Plutus asks for a code (from your authenticator app, your email, or a recovery code) before finishing the login. A partial login — password correct, MFA not yet provided — doesn’t grant access to anything.

At the MFA prompt, checking “Remember this device” skips the MFA challenge on that browser for 30 days on future logins. Your password is still required every time — this only waives the second factor, never the first. Each browser you trust is tracked separately, so you can revoke one from your profile’s device list without affecting the others.

A trusted device’s remaining sessions are revoked automatically if you turn off your last MFA method or change your password.

Every account member has one role, and the role applies per account — if you belong to more than one account (your own plus any orgs you’ve been invited to), your role can differ in each one.

Role Can do
Viewer View dashboards, cost/event/usage explorers, budgets, alerts, the audit log, and existing settings. Can’t create, edit, or delete anything.
Member Everything a viewer can do, plus connect and manage cost/event/usage sources, create and edit budgets, alerts, cost tags, teams, and unit metrics.
Admin Everything a member can do, plus invite and remove org members, change member roles, manage billing, and delete the account.

The hierarchy is cumulative: admin includes everything member can do, and member includes everything viewer can do.

An admin adds a member to an org from the account’s Team page:

  1. Enter the invitee’s email address and pick a role (member or viewer — invites can’t grant admin directly; promote the member to admin afterward if needed).
  2. Plutus sends an invite email with a signup link.
  3. The invitee either signs up fresh (if they don’t have a Plutus account yet) or accepts the invite while already logged in (if they do). Either way, they land in the org with the role the admin set.

An invited member’s email counts as verified once they accept — clicking the invite link already proves they control that address, so there’s no separate email-verification step for them.

Admins can also list pending invites and revoke one before it’s accepted.

A role change, a member removal, a deactivation, or a password reset takes effect on the affected person’s very next request — not after their current login eventually expires.

For example: an admin demotes a member from admin to viewer. The next action that member takes — even one already in flight in their browser — is checked against their current, live role, so the demotion applies immediately rather than after they log out and back in.

The same immediate effect applies if:

  • a member is removed from the account entirely,
  • a user is deactivated,
  • an account is suspended (every member of that account is blocked from using it until it’s reactivated), or
  • a user resets their password or logs out (their prior login stops working right away).

Every account keeps a log of actions its own admins and members take: creating, editing, or deleting a budget, alert channel, or alert subscription; connecting or disconnecting a cost or event source; inviting or removing a member or changing someone’s role; and minting or revoking an API key. Any role can view it — viewers included — since it’s a read-only record.

The log page supports filtering by action, target type, and which member performed the action, plus a date range, and can be exported to CSV.

Entries are kept for as long as your plan’s data retention period, the same window that applies to cost and usage data — see Data retention.