Roles and permissions

The viewer, member, admin and owner roles, scoping staff to individual customer workspaces, inviting people, and the mandatory multi-factor requirement.

A role says what somebody may do inside an organization. In an organization that manages other workspaces, a second setting says where they may do it.

Roles are enforced in the database through row-level security, not only in the interface. A request the browser would not offer is refused server-side too.

The four roles

Roles are cumulative: each includes everything below it.

Role	Can
Viewer	Read only. See certificates, agents and domains; change nothing.
Member	Day-to-day work: certificates, domains, agents and groups. Cannot configure deploy targets.
Admin	Everything a member can do, plus deploy targets.
Owner	Full control, including billing, members, single sign-on, and deleting the organization.

Settings > Organization > Roles shows the same table in the product. Custom roles do not exist.

Why deploy targets are an admin privilege

A deploy target can run a reload command, or a custom script, as root or LocalSystem on every agent host it is applied to. Configuring one is therefore closer to a code deployment than to a certificate setting, and it is separated from ordinary certificate work for that reason.

A member can issue and renew certificates all day using deploy targets that already exist. Creating or editing one is what needs admin.

Where a role applies

In an organization that manages customer workspaces - an MSP, or any organization that has them - each member also carries a customer access setting.

Customer access	What it means
All customers	Every workspace this organization manages, at the role above. The default.
Selected customers	Only the workspaces assigned to this person, each with its own role in that workspace.
No customers	This organization only. Nothing managed on behalf of anyone else.

The role in an assigned workspace is chosen per workspace and is independent of the role held in the organization itself. Someone who is a member internally can be admin in one customer and viewer in another; nothing is inherited between the two.

Both settings are on the member's row under Settings > Organization > Members, and both can be set when the invitation is created, so a new colleague never briefly holds more than intended.

Owners always reach everything

Customer access applies to admins and below. An owner can edit memberships - including their own - so a narrowed owner would be a restriction they could lift in one click. The product does not pretend otherwise: owners are always "all customers".

Removing somebody from an organization also removes their customer assignments, so re-inviting them later starts from nothing rather than quietly restoring old access.

Ownership inherited, and ownership of your own

Somebody can be an owner of a workspace in two ways: by a membership in it, or because they are an owner of the organization that manages it. The two are equivalent for everyday administration - that is the point of managing a workspace.

They are deliberately not equivalent for decisions about the management relationship itself: which of your customers another organization may see, whether to accept management, and whether to end it. Those need an owner of that organization, so the party on the other side of the relationship cannot make them on your behalf.

Adding and removing people

Invite by email under Settings > Organization > Members. The role - and, where the organization manages customer workspaces, the customer access - is chosen at invite time and can be changed afterwards. The invite is a single-use link, valid for seven days, and also shown in the app as a fallback if the mail does not arrive.

Inviting somebody never creates an extra organization. They join the one that invited them, whether or not they already had an account. If the invited address has no aethercert account at all, the invitation also clears the invite-only sign-up gate, so they can sign up without a separate code.

Removing a member, or revoking an unaccepted invite, takes effect immediately. There is no shared secret to rotate afterwards - which is the practical reason to invite people rather than share a login.

The last owner cannot be demoted or removed. Promote somebody else first, or use Transfer ownership under Settings > Organization > Danger zone.

Action	Who can do it
Invite a member, set or change a role	Owner
Set a member's customer access, assign customers	Owner
Remove a member, revoke an invite	Owner
Reset another member's second factor	Owner
Configure single sign-on	Owner
Transfer ownership, detach from an MSP, delete the organization	Owner
Share a customer workspace with another organization	Owner, by their own membership
Accept or end management by another organization	Owner, by their own membership
Create or edit a deploy target	Admin and above
Everything else operational	Member and above

Multi-factor authentication

Every session is multi-factor. This is not optional and cannot be switched off.

There are three ways to satisfy it, and the sign-in page offers whichever apply once you have entered your email address:

Method	Why it counts as two factors
Password plus an authenticator code	Something you know, plus something you have. Any TOTP app works.
A passkey	The device, plus the biometric or PIN that unlocks it. Skips both the password and the code.
Microsoft Entra SSO	Your own tenant's Conditional Access policies govern it, in an organization that has chosen to rely on them.

At least one authenticator app always stays enrolled, so no single method is ever the only way in. You can keep several authenticators and as many passkeys as you like; removing every passkey just puts you back on password plus code.

Sensitive, irreversible actions re-check the requirement server-side rather than trusting the browser. Changing how you sign in also asks for a fresh code even in a session that did not need one, so a stolen session cannot quietly swap the second factor out.

Repeated wrong passwords are throttled server-side. After 10 failed attempts an account is locked for 5 minutes, and each further failure doubles the next lockout up to a 24-hour ceiling. The same applies per source address at a higher threshold - 50 attempts. A quarter of an hour with no failure and no active lock resets the counter, and a successful sign-in clears it. While a lock is in effect the request is refused before it reaches the identity provider, and the attempt - address, browser, approximate location, count - is recorded.

If somebody loses their second factor

An owner resets it from the members list. That member enrolls a new one at their next sign-in. Both the request and the confirmation are recorded in the event log.