Organizations, users & roles¶

Tenant and child organizations¶

Your tenant (workspace) is your whole CertIntel account. Inside it, child organizations are the unit almost everything else is scoped to: monitored targets, certificates, API keys, install tokens, and DNS delegations each belong to one child organization, or - for select resources, at a tenant administrator's discretion - are left tenant-wide (visible/usable across every organization in the tenant).

A small account might run everything in a single default organization. A larger one splits by team, business unit, region, or customer, so that e.g. an organization administrator in one team can't see or touch another team's certificates and keys. A managed service provider runs one workspace with an organization per client; see MSP mode.

The organization selected in the dashboard's top bar is pre-selected in every "create" form (targets, keys, install tokens, delegations, trusted CAs), so check it before saving. Credential creation shows the affected scope before saving. An administrator confined to a child organization cannot create a workspace-wide credential or manage another organization's inventory. Tenant suspension blocks user access, machine reporting, delegated DNS updates/answers, scheduled probes, and notifications until the workspace is resumed.

Deleting an organization¶

Organizations → Edit → Delete removes an empty child organization. An organization that still owns anything - monitored targets, API keys, members, DNS delegations, internal endpoints, CT-watched domains, identity providers, AD CS templates, agents, alert destinations, trusted or ignored CAs, or ACME accounts - is refused with a message naming what blocks it, for example 'Team A' still owns resources (2 targets and 1 DNS delegation). Type PURGE Team A to force. Move or delete those resources first, or type PURGE <name> in the confirmation box to delete the organization together with everything it owns. The API returns 409 with the same list.

Tenant appearance¶

On supported plans, tenant administrators can choose Brutal, Classic Blue, Liquid or Phosphor, customize dashboard colors, choose a comfortable or compact layout density, and upload a logo and favicon from Tenant appearance. That is the default for everyone in the tenant; each user can pick their own theme, light/dark mode and density under My appearance, and enrolled Windows Agents follow the tenant theme unless a server administrator enables Tenant override in Agent settings. See Branding & themes. With MSP mode, a client organization can also carry its own name and logo (co-branding) next to the tenant's branding.

MSP mode¶

On plans that include MSP (the Enterprise plan; entitlement msp), a managed service provider runs its clients from one workspace: the workspace (tenant) is the MSP and each child organization is a client. There is no model that spans several tenants. MSP mode adds client co-branding, an audited switch into client and the Clients page; an organization's limit override can turn it off for one client.

Client co-branding¶

A user with workspace-wide branding.update (a tenant administrator, or a custom role granted workspace-wide) opens Organizations, then Co-branding on a client's row:

Save co-branding confirms Co-branding for '' saved. and writes organization.branding_updated to the activity log. While the dashboard shows only that organization (selected in the top bar, or after switching into it), its users see the client's name and logo beside the workspace branding. The logo is served only to signed-in users of the workspace who can reach that organization. Emails and scheduled reports for that organization read for in their header, as text only; emails carry no logo. Without the plan feature the form is not shown and a save is refused (Your plan does not include MSP co-branding.).

Switch into a client¶

On the Clients page, Switch into shows the dashboard as that client only. It is for workspace-wide accounts (tenant administrators and workspace-wide roles); others get Switching into a client is for workspace-wide accounts.

• A banner reads Viewing as with Return to all clients**, which also replaces the organization switcher in the top bar.
• While switched, every other organization is out of reach, also by its direct address: pages and API calls made with the dashboard session answer not found for another organization's resources.
• The switch belongs to the signed-in session and ends at sign-out.
• Both directions are audited: organization.switch_into ( switched into the client organization .) and organization.switch_out ( returned from the client organization to all clients.).

The ordinary organization switcher in the top bar is unchanged: it narrows lists and forms but is not audited and does not block a direct address to another organization. Switching into a client is not acting as a tenant: a platform operator's time-boxed act-as session (see Delegation is bounded) is a platform-side support session, while switching into a client is a workspace user narrowing their own view.

The Clients page¶

Clients (/msp, in the Monitor section of the navigation) lists every client organization by what needs attention: Every client organization in this workspace, by what needs attention. Tiles show Clients needing attention, Expired certificates, Expiring certificates and Renewal failures (7 days). Client priorities has one row per organization:

A co-branded pill marks co-branded clients, and each row has Switch into (or Current client). The page needs workspace-wide reach and organizations.read; every count covers only organizations you can read. The API is GET /api/v1/msp/organizations, returning organization_id, name, co_brand_enabled, expiring, expired, renewal_failures_7d, served_mismatches, offline_agents and ct_new_name_sets per organization.

Expiry severity settings¶

On Organizations, open a child organization's Edit form. Administrators can set these Expiry severity overrides:

Blank fields inherit the platform's defaults. Clearing all three removes the organization override. Days must be nonnegative whole numbers. Expiry severity overrides can only be set from the dashboard; the REST API's organization update accepts the name, slug and identity-provider flag only.

These settings affect certificate severity and expiry notification evaluation. They do not choose when an Agent renews a certificate. See how lifetime scaling works and Agent renewal windows.

Built-in roles¶

Roles are assigned per-user, either within one organization or, for a tenant administrator, across the whole tenant. The built-in roles below grant access within their assigned organization scope.

Open Access → Roles to see exactly which permissions each built-in role holds.

A user can hold tenant administrator authority in addition to (or instead of) an organization role - that's what lets someone manage every organization, create tenant-wide resources, and grant roles to other users.

Who can manage whom¶

Creating users needs users.create - Administrators (within their organization), tenant administrators, or a custom role that holds it - and opening the Users page needs users.read; other roles get Your role does not have access to this page. A new local user must change their password at first sign-in and cannot submit anything else in the dashboard until they do. Email addresses are unique within the tenant (A user with that email already exists in this tenant.), and only a tenant administrator can grant tenant-wide authority (Only a tenant administrator can grant tenant-wide authority.).

Users with tenant-wide authority - tenant administrators, holders of a tenant-wide (global) role, and platform administrators - can only be managed by a tenant administrator. An organization Administrator cannot see, reset the password of, disable, or change the roles of such a user, even if that user also has a membership in the administrator's organization; those users simply do not appear in that administrator's user list.

A tenant always keeps at least one active tenant administrator. You cannot disable or demote your own account, and no surface (API, dashboard, or platform console) will disable, demote, or delete the last active tenant administrator; promote a successor first. The error reads The last active tenant administrator cannot be disabled. (or demoted / deleted). A disabled or still-invited administrator does not count as active.

Demo accounts are always treated as read-only Viewers with redacted data, whatever roles they hold.

The same rules decide who may Reset two-factor for a user (Users → Manage, users.update): an administrator who can reset a user's password can also remove their two-factor sign-in, never their own and never while acting as another user. The workspace's two-factor policy is a Security setting (security.update).

Demo accounts¶

An administrator can mark an existing, active local account as a demo account (Users → Manage → Edit profile → Demo account: Yes — cannot change own password). A demo pill appears next to the account. Demo users cannot change their password (This is a demo account, changing password is not supported.), the forgot-password form silently does nothing for them, and an administrator's password reset does not force them to change it afterwards. You cannot change the demo setting on your own account.

Permissions¶

Every permission is resource.action. Viewing, creating, editing and deleting are separate actions on every resource, so a role can allow exactly what a team needs - for example see notification channels but change nothing, or add and edit public endpoints but never delete one. A few resources have an extra verb for an action that is more sensitive than an ordinary edit.

Workspace-level resources (roles, security, tenant appearance) belong to the whole tenant - your workspace - not to one organization. Their permissions only take effect when the role is assigned across the whole workspace (or the user is a tenant administrator); granting them inside a single organization does nothing. The built-in Administrator preset deliberately leaves them out, so an organization administrator can never change settings that belong to the whole workspace: a tenant administrator reaches them through that status, and anyone else needs a custom role that includes them, granted workspace-wide. The same rule applies to workspace-wide notification channels, scheduled reports and trusted CAs: an organization-scoped role can manage the ones in its organization, a workspace-wide role or a tenant administrator can manage the shared ones.

Database backups and component release manifests are platform-wide concerns handled by the platform operator; they never appear in a tenant's permission matrix and cannot be put in a custom role.

Custom roles¶

Access → Roles lists every built-in role and lets a tenant administrator (or anyone holding roles.create workspace-wide) define custom roles: give the role a name and description, tick the permissions in the matrix, and save. The box under each column heading (read, create, …) ticks or clears every permission in that column you are allowed to grant, so a read-only role is one click. The role is then offered on the Users page in both pickers - per organization and workspace-wide - exactly like a built-in role, and through the API as GET /api/v1/roles / POST /api/v1/users.

Rules the editor enforces:

• You can only grant permissions you hold yourself, everywhere the role applies. A tenant administrator can grant anything. Anyone else building a role that applies to all organizations must hold each permission workspace-wide; a role confined to particular organizations only needs them held in each of those organizations. The greyed-out boxes in the matrix are the ones outside your own reach. Lifting a role's organization restriction, or adding an organization to it, is checked the same way.
• Permissions marked with a small ▲ in the matrix (users.create, users.update, roles.*, api_keys.create / update / admin, identity_providers.create / update) let their holder delegate authority: assign roles, mint API keys, define roles, or map identity-provider claims. See Delegation is bounded for what a holder can and cannot hand out. Pairing one of these with a narrow permission set is safe; pairing it with Administrator-level permissions makes its holders able to appoint further administrators.
• Platform permissions and the reserved role names (administrator, platform_*, …) are never available.
• A role's key (alert_desk, derived from the name you typed) is fixed once created, because identity-provider mappings and API clients refer to it. Rename or re-permission the role freely; the key stays.
• Deleting a role removes it from every user who held it and from every identity-provider mapping that named it. The users themselves are untouched; a user whose only role was deleted simply has no access until another is granted.
• Every create, edit and delete is written to the activity log (role.create, role.update, role.delete) with the full permission list and the organizations the role applies to.

Delegation is bounded¶

Granting someone the ability to manage users, keys or identity providers never lets them make anyone - themselves included - more powerful than they are. CertIntel applies the same guardrail most platforms do (GitLab will not let you grant a role above your own, Discord only lets you assign roles below your highest one, Keycloak and Azure RBAC bound which roles a delegate may hand out):

• Hold it yourself. A role you assign to a user in an organization may only carry permissions you hold in that organization; a workspace-wide grant needs workspace-wide holdings. The same applies to identity-provider claim mappings and fallback roles, which are standing grants to whoever signs in. The API answers 403 naming the missing permissions.
• Not on your own account. Only a tenant administrator may change their own roles, whatever users.update they hold.
• API keys carry only what you have. A dashboard key acts as an Operator plus activity reads and an admin key as an Administrator, so creating, rotating or re-enabling one requires holding every permission of that scope in the key's organization - the person who learns the secret inherits the key's authority. A key that is allowed to request private-CA certificates can only be rotated by someone holding private_ca.update (or api_keys.admin) there.
• Not while acting as a tenant. A platform operator inside a time-boxed act-as session cannot create API keys or users, reset passwords, grant tenant-wide authority, or map a claim to it; those would outlive the session. Act-as keys cannot be rotated or re-enabled by anyone.

Tenant administrators are exempt from the first three rules: they can already do anything in the tenant.

Confining a role to particular organizations¶

Below the permission matrix, Applies to decides which organizations the role can ever reach:

• All organizations (the default) makes the role behave like a built-in one: granted in an organization it covers that organization; granted workspace-wide it covers every organization.
• Only these organizations confines the role to the organizations you tick. Granted workspace-wide, it covers exactly those organizations and no other - so a role that "lets the team work in A and B but not C and D" is one role, scoped to A and B, assigned once from the Users page. Granted per organization, it can only be granted inside the organizations it names; the Users page offers it only there, and the API answers 409 elsewhere.

The custom roles table shows what each role applies to. Narrowing a role later takes effect for every holder at their next request; if every organization a scoped role named is deleted the role reaches nothing until you edit it (it never silently widens to the whole workspace). Only someone with workspace-wide roles.update authority can change the restriction - the same rule as for the permissions themselves.

The REST API mirrors the page: GET /api/v1/permissions returns the catalogue grouped as the matrix shows it, POST /api/v1/roles creates a role from {"name", "description", "permissions": ["targets.read", …], "organizations": ["ops-a", "ops-b"]} (organization slugs or ids; omit or send null for all organizations), and PATCH / DELETE /api/v1/roles/{id} edit or remove it. In a PATCH, leaving organizations out keeps the current restriction, a list replaces it and an explicit null lifts it. Every role answers with organization_scoped and the organizations it is confined to. Built-in roles are read-only and answer 404 to edits.

SSO and roles¶

If your organization signs in through an identity provider, role assignment is driven by claims in the provider's token instead of - or alongside - roles assigned directly in CertIntel, and is fully resynced on every login. See OIDC / SSO overview for the full model, including the CertIntel.* claim convention that maps directly to the roles above.

Plans and limits¶

Each tenant has an entitlement plan controlling limits on the number of public endpoints, internal certificates, Delegated DNS-01 records, users and organizations, and features such as alert destinations, Certificate Transparency monitoring, SSO, activity-log retention, Appearance and MSP (client co-branding, switch into client, client dashboard; see MSP mode). The dashboard Overview shows a Plan usage & limits table with the number allowed and used for each limit type and an At limit marker. If an action is blocked by a plan limit, the error explains which limit was hit; contact your CertIntel administrator or provider to adjust it.