Role Based Access Control - old draft

1. Overview of RBAC in CERTInext

1.1 What Is Role-Based Access Control?

Role-Based Access Control (RBAC) is a security model that determines what each user can see and do inside CERTInext. Instead of giving every user identical access, the system assigns each person a role - and that role controls which menus appear, which actions are available, and which records are visible.

Think of it like a set of keys. An Administrator holds a master key that opens every door. A Basic User holds only a few keys - enough to manage their own certificates and orders, but not to configure the whole account. RBAC ensures that the right people can do the right things, and nothing more.

1.2 Why RBAC Matters

Without role-based access controls, any user could accidentally - or intentionally - modify another user's certificates, view confidential billing data, or alter system-wide settings. RBAC prevents that by enforcing the principle of least privilege: every user is given only the access they need to do their job.

In a certificate management platform like CERTInext, this matters especially because:

• Certificates are tied to real-money transactions and security infrastructure.

• Billing details and invoice history may be commercially sensitive.

• Revoking or mis-configuring a certificate can cause service outages.

• Audit logs must reliably track who did what - RBAC makes those logs meaningful.

1.3 How Roles Work in CERTInext

CERTInext provides eight built-in default roles. Their permissions are fixed and cannot be changed. In addition, an Administrator can define custom roles with a hand-picked set of permissions, giving organisations the flexibility to map access to their own internal job titles.

A role is assigned to a user at the moment of account creation and can be changed later by an Administrator or Manager. As soon as the role changes, the user's access updates immediately - no restart or re-login required.

Beyond roles, CERTInext provides two additional layers of access control that work alongside roles:

• Group-Level Access Controls - Each permission can operate at one of three scopes: Own (the user's own records only), Group (records within the user's assigned group), or All (every record in the account). Administrators can also configure which groups are accessible to users in a given group on a cross-functional basis. See Section 7.

• Account-Level Group Isolation - An account-wide setting that, when enabled, automatically restricts all non-Administrator users to their designated group only - regardless of what their role technically allows. Administrators always retain full access. See Section 8.

★ NEW	Group-Level Access Controls and Account-Level Group Isolation are new capabilities introduced as part of the upcoming RBAC enhancement release. They provide greater flexibility in designing access-control policies while enabling stronger governance and separation of duties across teams.

1.4 The Permission Framework

CERTInext's permission system comprises more than 350 granular permissions organised across 19 functional modules, including Dashboard, Orders, Certificates, Discovery, Provisioning, Reports, Billing, Settings, and others. Each permission is identified by a code (for example, certificates.certificate.view_all) and a plain-language description.

Permissions within many modules are offered at three visibility scopes:

• Own - The user can act on records they personally created or own. Example: certificates.certificate.view_own.

• Group - The user can act on records belonging to any member of their assigned group. Example: certificates.certificate.view_group.

• All - The user can act on every record in the account, regardless of who created it or which group it belongs to. Example: certificates.certificate.view_all.

A role may be granted all three scopes for a given action, or only some. For example, the Manager role is granted view_all, view_group, and view_own for certificates, meaning a Manager can see every certificate in the account. A Basic User, by contrast, is only granted view_own and can therefore only see their own certificates.

1.5 Key Terms

Term	Plain-language meaning
Role	A named bundle of permissions assigned to a user (e.g., Manager, Basic User).
Permission	A single action a role is allowed to perform (e.g., View all certificates, Add credits).
Default Role	One of the eight built-in roles with fixed, pre-defined permissions.
Custom Role	A role created by an Administrator with a freely chosen set of permissions.
Group	An organisational unit used to cluster users and their associated records. A user can belong to one or more groups. Groups are the foundation for group-level access controls.
Scope (Own / Group / All)	The reach of a permission. Own = the user's own records. Group = records within the user's group(s). All = every record in the account.
Group Isolation	An account-wide setting that restricts all non-Administrator users strictly to their designated group, overriding any broader scope a role might otherwise grant.
Cross-Group Access	A configuration that allows users of one group to access resources belonging to another specified group.
Activation	The step a newly created user must complete to set their password and gain access.
Separation of Duties	A governance control that ensures no single user has all the permissions needed to complete a sensitive end-to-end process. RBAC enforces this by assigning minimal, role-appropriate permissions.

2. Default Roles and Their Access

2.1 The Eight Default Roles at a Glance

CERTInext ships with eight assignable default roles (the Approver role exists in the system but is inactive and cannot be assigned). The table below summarises what each role is designed for and how many permissions it holds.

Role	# Permissions	Designed for…
Administrator	367	Full control. Can do everything - create users, manage CAs, billing, settings, reporting, and group configuration. Retains full access even when Account-Level Group Isolation is enabled.
Manager	164	Day-to-day account management: certificates, orders, billing statements, user management, settings, and reporting. Can view and edit group configuration but cannot enable group isolation.
Discovery User	93	Specialist for certificate discovery. Full discovery module access. Limited access to certificates and orders; no billing. Subject to group-level scoping.
Finance Manager	79	Billing and financial operations: credits, sub-accounts, price lists, invoices, financial reports.
Standard User	64	Regular team member with broad visibility (All scope for viewing) but limited write access (Own scope for modifications).
Sub-Account User	39	Scoped to a sub-account context: own orders, own certificates, sub-account price-list access.
Basic User	38	Minimum viable access: own orders, own certificates, own API keys.
Custom Role	Varies	An Administrator-defined role with individually selected permissions and scopes.

ℹ NOTE	The Administrator role is the only role that automatically receives every new permission added to the system, and the only role unaffected by Account-Level Group Isolation. All other roles must be explicitly updated if you want them to gain new capabilities after a system upgrade.

2.2 Module-by-Module Permission Summary

The table below shows which modules each default role can access and at what scope. 'All' = account-wide access. 'Group' = within the user's group. 'Own' = the user's own records only. '-' = no access.

Module	Admin	Manager	Discovery User	Finance Manager	Standard User	Sub-Acct User	Basic User
Dashboard	Full	Full	Basic	Basic	Basic	Basic	Basic
Certificates	All	All	-	All (view)	All (view) / Own (act)	Own	Own
Orders	All	All	All (view)	All (view/track)	All (view) / Own (act)	Own	Own
Discovery	Full	View bots & certs	Full (All scope)	-	View All	-	-
Cert. Authorities	Full	Manage (no create)	View	Edit	View	-	-
Domains	All	All	All (view)	All (view)	All (view)	-	-
Organisations	All	All	All (view)	All (view)	All (view)	-	-
Integrations / APIs	Full	CA Connectors, DNS, APIs	CA Connectors, DNS, View APIs	-	Own API keys	Own API keys	Own API keys
Billing	Full	Add credits, statements, invoices	-	Full	Own invoices / statements (view)	Own invoices	Own invoices
Sub-Accounts	Full	View list & price lists	-	Full	-	View price lists	-
Reports	Full	All reports (view)	-	Most reports (view+export)	-	-	-
Settings	Full	Account Config, Users (edit), Groups, Tags, IP Restrictions (view)	View Users, Licence	Account info, Groups	View Users, Groups	-	-
Keys / Provisioning	Full	View certs, bots, key profiles & store	View certs, bots, key profiles & store	-	View all keys	-	-
My Profile	Full	View, Edit, Change Password	View, Change Password	View, Edit (account info)	View, Change Password	View, Change Password	View, Change Password
Tools Page	Yes	Yes	Yes	Yes	-	-	-

ℹ NOTE	Note on scopes: 'All (view) / Own (act)' in the table above means the role can see all records (broad view scope) but can only perform actions - such as revoke, renew, or reissue - on records they personally own. This pattern gives Standard Users a good overview of the account without giving them broad write access.

2.3 Detailed Role Descriptions

Administrator

The Administrator role has access to all 367 active permissions in CERTInext. This includes every action available to every other role, plus exclusive abilities such as adding new users, creating Certificate Authorities, managing provisioning bots, configuring Single Sign-On and Two-Factor Authentication, setting IP restrictions, enabling Account-Level Group Isolation, and deleting records. There should be at most one or two Administrators per account; this role should not be assigned routinely.

Manager

The Manager is the most powerful non-Administrator role, with 164 permissions covering almost every day-to-day operational task. A Manager can view and manage all certificates, orders, and domains across the account; edit user profiles (but not add new users); configure account-wide settings; view billing statements and add credits; manage CA connectors; produce reports; and view group configurations. Managers cannot create new users, create private CAs, configure IP restrictions, or enable group isolation.

Discovery User

The Discovery User role (93 permissions) is purpose-built for teams responsible for discovering and cataloguing certificates. A Discovery User has full control over the Discovery module and can view provisioning bots, provisioned certificates, and CA connectors. They have limited, read-only access to orders and organisations. When group isolation is enabled, a Discovery User will only see discovered certificates and bots belonging to their own group.

Finance Manager

The Finance Manager role (79 permissions) covers financial and sub-account administration: adding credits, managing sub-accounts, creating and managing price lists, viewing billing statements and invoices, and accessing financial reports. They cannot manage certificates directly or change system-wide settings.

Standard User

The Standard User (64 permissions) can view all certificates, all orders, all domains, and all organisations, but can only act on their own records (renew, reissue, revoke their own certificates and orders). They can manage their own API keys and access basic billing invoices. If group isolation is enabled, their 'view all' access is restricted to their group.

Sub-Account User

The Sub-Account User (39 permissions) is for users associated with a sub-account. They can view their own orders and certificates, submit new certificate requests, and view price lists.

Basic User

The Basic User (38 permissions) provides the minimum access level: submit certificate requests, view and download own certificates, manage own orders, manage own API keys, and view own invoices.

Custom Role

An Administrator can create a Custom Role with any combination of available permissions and scopes. See Section 6 for full instructions. Note that custom roles are subject to group-level access controls and account-level group isolation in the same way as default roles.

3. Assigning a Role While Creating a New User

3.1 Who Can Create Users?

Only the Administrator role can add new users to an account (permission: settings.users.add). Managers can invite users but cannot create them directly.

ℹ NOTE	The steps in this section use the Manager role as the primary example, and reference the Discovery User role as a second example. The procedure is identical for all eight default roles - simply select a different role in Step 6.

3.2 Before You Begin

Before adding a user, confirm you have:

• The user's full name.

• The user's email address (this becomes their login ID).

• The user's mobile phone number (optional, recommended for 2FA).

• The role you want to assign (refer to Section 2 if unsure).

• Whether the user should be limited to specific groups (see Group Access, Step 7 below, and Section 7 for the full group-access model).

3.3 Step-by-Step: Adding a New User

1. Log in to CERTInext as an Administrator. If your email is associated with more than one account, click Proceed next to the relevant account on the 'Choose your account to Sign in' screen.

[SCREENSHOT: Multi-account sign-in selection screen - Administrator clicking Proceed on the target account -- insert here]

2. In the left-hand navigation menu, click Settings to expand it, then click Users & Roles.

[SCREENSHOT: Settings menu expanded, showing Users & Roles highlighted -- insert here]

3. The Settings :: Users page opens showing all existing users with their email addresses, roles, creation dates, and statuses. Confirm the new user does not already exist.

[SCREENSHOT: Settings > Users page showing existing users (e.g., one Administrator listed as Active) -- insert here]

4. Click the + Create User button in the top-right corner of the page.

5. The Add User page opens. Fill in each field as described in the tables below.

[SCREENSHOT: Add User form - all fields visible, Manager role selected -- insert here]

USER INFORMATION

Field	What it is	What to do
Full Name *	The person's display name inside CERTInext.	Enter the user's full name as it should appear in the system (e.g., [First Last]).
Email *	The email address used to log in. Must be unique in the system.	Enter the user's work email address. They will receive an activation email here. Example format: [[e-mail]].
Mobile Number	International phone number for SMS-based One-Time Passwords.	Select the country dialling code from the drop-down, then type the phone number (digits only). Example code: +1 (USA).
Employee ID	An internal reference code (optional).	Enter the employee's internal ID if your organisation uses one. Maximum 64 characters. Leave blank if not applicable.

GROUP ACCESS

Field	What it is	What to do
Limit this user to access specific groups	A checkbox that controls whether this user's access is scoped to one or more specific groups, or account-wide.	Leave unchecked to give the user account-wide access (subject to their role's scope). Check it to limit the user to specific groups - additional group-selection controls appear when checked. This setting works in conjunction with the group-level access scopes described in Section 7.

ℹ NOTE

Group access and role scope work together. For example, a Manager role carries 'view all' scope for certificates, meaning a Manager can normally see all certificates in the account. If you additionally check 'Limit this user to access specific groups' and select Group A only, that Manager will see all certificates within Group A but not those in Group B or Group C. See Section 7 for the full explanation of how group-level controls interact with role scopes.

TAGS

Field	What it is	What to do
Restrict this user's access to specific tags	A checkbox that limits the user to records labelled with specific tags.	Leave unchecked unless your organisation uses tag-based access control. Check it to reveal tag-selection controls.

ASSIGN ROLE

Field	What it is	What to do
Role *	The access level this user will have. One option must be selected.	Click the radio button next to the desired role. Options: Administrator, Basic User, Manager, Standard User, Discovery User, Sub-Account User, Finance Manager, Custom Roles (if any exist). Each option has an info (ℹ) icon - hover for a brief description.

ℹ NOTE	Example - Manager role: Select Manager to give the user 164 permissions covering certificates, orders, billing, settings, and reports. Example - Discovery User role: Select Discovery User to give the user full access to the Discovery module (bots, CT logs, discovered certificates) plus view access to orders and organisations, but no billing or settings access.

6. Click Save. CERTInext creates the user record, sets status to 'Pending for Activation', and sends an activation email.

[SCREENSHOT: Users list showing the newly added user with 'Pending for Activation' status -- insert here]

⚠ WARNING	The new user will not have access until they complete the activation process described in Section 4. Their status remains 'Pending for Activation' until they set their password.

3.4 What Happens After You Click Save?

• A row is added to the Users list showing the user's name, email, role, group (All by default), creation date and time, Created By, and status 'Pending for Activation'.

• The system sends an activation email to the user's address.

• The user's account is live but locked until activation is complete.

4. How a New User Activates Their Account

4.1 Overview

After an Administrator creates a user account, the new user receives an activation email. They must follow the link in that email to set a password before they can log in. The experience varies slightly depending on whether the user's email address is already registered in CERTInext.

4.2 Scenario A - Brand-New Email Address

1. Open the activation email and click the activation link.

[SCREENSHOT: Password setup screen - 'Welcome! Let's set up your password' with New Password and Confirm Password fields -- insert here]

2. On the password-setup screen, enter a strong password in New Password, then repeat it in Confirm Password.

3. Click Save Password. If the passwords match and meet complexity requirements, the account is activated.

[SCREENSHOT: 'You're All Set!' confirmation screen with Login button -- insert here]

4. A 'You're All Set!' screen appears. Click Login.

5. Enter your email and the password you just set, then click Sign in.

[SCREENSHOT: Sign-in page with Email and Password fields -- insert here]

6. If your email is linked to multiple CERTInext accounts, an account-selection screen appears. Click Proceed next to the target account. The Dashboard then loads.

[SCREENSHOT: 'Choose your account to Sign in' screen listing multiple accounts with Proceed buttons -- insert here]

4.3 Scenario B - Email Already Registered on Another Account

1. Open the activation email and click the activation link. A 'Verify your identity to link this account' screen appears.

[SCREENSHOT: 'Verify your identity to link this account' screen - partially masked email, Password field -- insert here]

2. Enter your existing CERTInext password and click Authenticate.

[SCREENSHOT: 'Account authenticated successfully' green banner and 'You're All Set!' screen -- insert here]

3. A green 'Account authenticated successfully' banner appears. Click Login and sign in normally. The new account now appears alongside your existing ones in the account-selection screen.

ℹ NOTE	After activation, the user's status in Settings > Users & Roles changes from 'Pending for Activation' to 'Active' immediately.

4.4 Changing Your Password After Activation

Any user can change their password at any time via the profile icon in the top-right corner > Change Password:

Field	What to do
Current Password	Enter the password you currently use to log in.
New Password	Enter your new password. The info (ℹ) icon shows the complexity requirements.
Confirm Password	Re-enter the new password to confirm it.

[SCREENSHOT: Change Password screen with Current Password, New Password, and Confirm Password fields -- insert here]

5. Editing an Existing User's Role

5.1 Who Can Edit User Roles?

• Administrator - can edit any user, including changing their role.

• Manager - can edit user details but cannot add new users or assign the Administrator role.

ℹ NOTE	A Manager cannot grant a role that has more permissions than their own. In practice, a Manager cannot assign the Administrator role to anyone.

5.2 Step-by-Step: Changing a User's Role

1. Navigate to Settings > Users & Roles. The Users list is displayed.

[SCREENSHOT: Settings > Users list with users listed as Active -- insert here]

2. Locate the user and click the View button in their Action column.

3. On the user's profile page, click the Edit (pencil) icon.

4. In the ASSIGN ROLE section, click the radio button next to the new role.

5. Click Save. The role updates immediately.

5.3 How Access Changes When a Role Is Modified

Change in Role	Access gained	Access lost
Basic User → Manager	Billing (add credits, statements), all certificates and orders, settings (users, groups), reports, CA connectors, domains.	None - Manager is a superset of Basic User permissions.
Manager → Discovery User	Full Discovery module (bots, CT logs), additional integration views.	Billing, settings management, most reporting, certificate management actions (revoke, suspend, etc.).
Manager → Standard User	-	Add credits, download statements, manage users, account configuration, most CA management.

⚠ WARNING	Downgrading a role immediately revokes access to any modules not included in the new role. Any work the user has in progress in those modules may be interrupted.

6. Creating a Custom Role

6.1 When to Use a Custom Role

Custom roles are useful when none of the eight default roles perfectly matches a job function. For example, a 'Helpdesk Viewer' role that can see all certificates and orders but cannot modify anything, or an 'Auditor' role that can access audit logs and reports only.

ℹ NOTE	Only the Administrator role can create, edit, or delete custom roles. Once created, an Administrator can assign a custom role to any user. Custom roles are subject to the same group-level access controls and group isolation rules as default roles.

★ NEW	CERTInext now provides starter templates for custom role creation, making it faster to build roles that approximate a standard profile. See Method A below.

6.2 Navigating to Custom Roles

1. Log in as an Administrator.

2. Click Settings in the left-hand navigation, then click Users & Roles.

3. Click the Custom Roles tab (third tab after Users and User Invitations).

[SCREENSHOT: Settings > Users & Roles > Custom Roles tab - 'No custom roles have been created yet' -- insert here]

6.3 Method A - Creating a Custom Role from a Template

A starter template is a pre-built permission set based on a common operational profile. Choose the template that most closely fits the role you need, then adjust individual permissions before saving.

1. On the Custom Roles tab, click + Create Custom Role.

2. In the Creation Method field, select Template.

3. From the Template drop-down, select the template that most closely matches your requirement (for example, a template approximating Manager or Standard User).

4. In the Role Name field, type a clear, descriptive name for the custom role (e.g., 'Helpdesk Viewer' or 'Billing Auditor').

5. In the Description field, describe what this role is for so other Administrators understand its purpose.

6. Review the pre-selected permissions grouped by module. Tick any permission you want to add; untick any permission you want to remove. Pay attention to scope suffixes (_own, _group, _all) - choose the minimum scope necessary.

7. Click Save. The new custom role appears in the Custom Roles list.

[SCREENSHOT: Create Custom Role - Template mode, template drop-down selected, permissions pre-filled -- insert here]

✔ TIP	Starting from a template is significantly faster than building from scratch. Use Method A by default and switch to Method B only when no template is close enough to what you need.

6.4 Method B - Creating a Custom Role from Scratch

Use this method when no template approximates your requirements. Every permission must be explicitly selected.

1. On the Custom Roles tab, click + Create Custom Role.

2. In the Creation Method field, select Manual (or Individual Permissions).

3. Enter a Role Name and Description.

4. The full permissions table is displayed with all permissions unchecked. Scroll through and tick every permission you need. Permissions are grouped by module.

When selecting permissions, apply least-privilege principles:

• Use _own scope unless the role explicitly needs access to other users' records.

• Use _group scope when the role needs to oversee a team but not the whole account.

• Use _all scope only for roles that genuinely need account-wide visibility or action capability.

5. Click Save when done.

[SCREENSHOT: Create Custom Role - Manual mode, full permissions table visible, individual permissions being ticked -- insert here]

6.5 Assigning a Custom Role to a User

1. Open the Add User or Edit User form (Sections 3 or 5).

2. In ASSIGN ROLE, click the radio button next to Custom Roles.

3. A drop-down lists all available custom roles. Select the one you want.

4. Click Save.

6.6 Editing and Deleting Custom Roles

To edit: Settings > Users & Roles > Custom Roles > Select > Edit. Changes take effect immediately for all users assigned that role.

To delete: Settings > Users & Roles > Custom Roles > Select > Delete. Reassign all users holding the role before deleting it.

⚠ WARNING	Deleting a custom role that is still assigned to users will cause those users to lose access until reassigned. Always reassign users before deleting a custom role.

7. Group-Level Access Controls

★ NEW	Section 7 and Section 8 document new capabilities introduced in the upcoming RBAC enhancement release. These features are available from the release date onwards.

7.1 What Are Group-Level Access Controls?

Groups in CERTInext are organisational units that cluster users and the resources they own - certificates, orders, domains, and organisations. Group-Level Access Controls let you define not just what a user can do (their role) but which resources they can reach (their group scope).

This two-layer model means you can have two users with the same role - say, Manager - but with completely different visibility. One Manager might see all resources across the whole account; another might see only resources belonging to the teams they manage.

7.2 The Three Visibility Scopes

Every permission in CERTInext that applies to a resource (certificate, order, domain, etc.) is offered at one or more of three visibility scopes:

Scope	What it means	Example
Own	Access to resources created or owned by this specific user only.	A Basic User with certificates.certificate.view_own can only see certificates they personally requested.
Group	Access to resources belonging to any member of the user's assigned group(s).	A Manager assigned to Group A with certificates.certificate.view_group can see certificates owned by any user in Group A - but not certificates in Group B.
All	Access to every resource in the account, across all groups.	A Manager with certificates.certificate.view_all can see every certificate in the account regardless of which user created it or which group that user belongs to.

Most default roles are assigned a combination of scopes to match their intended operational responsibilities. For example, the Standard User role is granted view_all for certificates (so they can see the full picture) but only revoke_own (so they can only revoke their own certificates). This pattern - broad view, narrow write - is a common separation-of-duty design.

ℹ NOTE	The three scopes are cumulative and additive. If a role has view_own, view_group, and view_all, the most permissive (All) applies. CERTInext will always display the broadest set of records the user is entitled to see based on their highest-level granted scope.

7.3 How Group Assignment Interacts With Scopes

When you create a user, you can choose to limit them to specific groups (see Section 3.3, Group Access field). This group assignment acts as a ceiling on their effective scope:

User's role scope	Group assignment	Effective access
view_all (e.g., Manager)	Not limited to specific groups (default - 'All')	Sees all resources in the entire account.
view_all (e.g., Manager)	Limited to Group A only	Sees all resources that belong to users in Group A only.
view_group (e.g., Standard User)	Not limited (default)	Sees resources belonging to their default group.
view_own (e.g., Basic User)	Any group assignment	Sees only their own resources regardless of group assignment.

7.4 Cross-Group Access Configuration

CERTInext now allows Administrators to configure which specific groups may access resources belonging to other groups - enabling controlled, cross-functional collaboration without opening up full account-wide access.

For example, a Security Operations team (Group B) might need to view certificates owned by the Infrastructure team (Group A) for auditing purposes, without being able to see the Sales team's (Group C) certificates. A cross-group access rule can grant Group B visibility into Group A's resources while keeping Group C's data separate.

How to Configure Cross-Group Access

1. Log in as an Administrator.

2. Navigate to Settings > Groups.

[SCREENSHOT: Settings > Groups page showing the list of groups with Group ID, Group Name, User Count, and Action columns -- insert here]

3. Click View next to the group whose members you want to grant cross-group access. The Group Detail page opens.

4. Look for the Cross-Group Access section (or a similar heading within the Group settings). This section lists the groups that members of this group are allowed to access.

[SCREENSHOT: Group Detail page - Cross-Group Access section showing configurable group permissions -- insert here]

5. Click Add or Configure to open the cross-group access controls. Select the groups whose resources members of this group should be able to reach.

6. Specify the permitted scope for each cross-group link (Own, Group, or All for that target group's resources).

7. Click Save. The cross-group rules take effect immediately.

⚠ WARNING	Cross-group access overrides the 'Limit this user to specific groups' setting for the configured groups. Review cross-group rules carefully - granting Group A access to All resources in Group B can expose a large volume of data. Apply the minimum necessary scope.

7.5 Scope Matrix for Key Roles

The table below shows the highest visibility scope each default role holds for the most frequently managed resource types. This can be used as a quick reference when deciding which role to assign to a user with a given group-access requirement.

Resource	Admin	Manager	Discovery User	Finance Mgr	Standard User	Basic User
Certificates (view)	All	All	-	All	All	Own
Orders (view)	All	All	All	All	All	Own
Discovered Certs (view)	All	All	All	-	All	-
Organisations (view)	All	All	All	All	All	-
Domains (view)	All	All	All	All	All	-
Certificates (revoke)	All	All	-	-	Own	Own
Users (view)	All	All	All	-	All	-

ℹ NOTE	When Account-Level Group Isolation is enabled (see Section 8), 'All' scope in the table above is reduced to 'Group' for all non-Administrator users. Administrators always retain the 'All' scope shown.

8. Account-Level Group Isolation

★ NEW	Account-Level Group Isolation is a new capability introduced in the upcoming RBAC enhancement release.

8.1 What Is Account-Level Group Isolation?

Account-Level Group Isolation is a single account-wide switch that, when enabled, forces every non-Administrator user to see and interact with only the resources that belong to their designated group - regardless of what their role's scope would ordinarily allow.

In other words: enabling this setting converts every non-Administrator user's effective scope from 'All' (or 'Group') down to their own group boundary. A Manager who could normally see all certificates across the entire account can suddenly only see certificates in their own group.

Administrators are explicitly excluded from this restriction. An Administrator always retains full visibility and management capabilities across all groups and entities in the account, even when isolation is enabled.

8.2 When to Use Group Isolation

Group isolation is most valuable in these scenarios:

• Multi-team or multi-department accounts - where each team manages its own certificates and should not see or accidentally interfere with another team's work.

• Reseller or partner accounts - where multiple end-customers (each in their own group) operate within a single CERTInext account and must be kept strictly separate.

• Regulatory or compliance requirements - where data segmentation between organisational units is mandatory.

• Reduced risk of accidental changes - restricting users to their group minimises the blast radius of mistakes; a user cannot revoke a certificate they should not be touching.

ℹ NOTE	Group isolation is an account-wide blunt instrument - it applies to all non-Administrator users simultaneously. If you need more nuanced, user-by-user group restrictions, use the 'Limit this user to specific groups' checkbox on the Add/Edit User form (Section 3.3) instead. Both approaches can be used together.

8.3 How Group Isolation Affects Each Role

Role	Normal effective scope (isolation OFF)	Effective scope when isolation is ON
Administrator	All - full account access.	Unchanged - Administrators always retain full access.
Manager	All - can see and manage all certificates, orders, users, etc. across the account.	Group-restricted - can see and manage only resources within their own group. Can still edit users and settings that fall within their group.
Discovery User	All (for discovery) - can see discovered certificates, run bots, and manage CT logs account-wide.	Group-restricted - can only see discovered certificates and run bots for their own group's infrastructure.
Finance Manager	All - can access billing, sub-accounts, and financial reports account-wide.	Group-restricted - financial data visibility limited to their group.
Standard User	All (view) / Own (act) - can see all records but only act on their own.	Group-restricted (view) / Own (act) - view is limited to their group; write access remains limited to own records.
Sub-Account User	Own - already scoped to own records.	Effectively unchanged - own-scope users are unaffected by group isolation.
Basic User	Own - already scoped to own records.	Effectively unchanged - own-scope users are unaffected by group isolation.

⚠ WARNING	Enabling group isolation affects all non-Administrator users immediately. Users who currently have 'All' scope access will lose visibility of resources outside their group. Communicate this change to affected users before enabling it.

8.4 How to Enable or Disable Group Isolation

Group isolation is controlled from the Account Configuration page, which is accessible only to Administrators.

1. Log in as an Administrator.

2. Navigate to Settings > Account Configuration.

[SCREENSHOT: Settings > Account Configuration page - Account-Level Group Isolation toggle visible -- insert here]

3. Scroll to the Group Isolation section (or a similarly labelled section in Account Configuration).

4. To enable isolation, toggle the Account-Level Group Isolation switch to On (or tick the corresponding checkbox). A confirmation prompt may appear; confirm the action.

[SCREENSHOT: Account Configuration - Group Isolation enabled confirmation dialog -- insert here]

5. To disable isolation, toggle the switch back to Off. All non-Administrator users immediately regain the full scope their role entitles them to.

6. Click Save (if required by the form). The change takes effect immediately - no re-login is required for existing users.

ℹ NOTE	Only the Administrator role has the settings.account_config.edit permission required to change this setting. Managers can view the Account Configuration page but cannot edit it.

8.5 Group Isolation and Cross-Group Access Rules

Cross-group access rules (configured in Settings > Groups, as described in Section 7.4) remain active even when group isolation is enabled. This means you can enable isolation as a default while still explicitly opening specific cross-group lanes where collaboration is needed.

For example: Group Isolation is ON for the whole account, but Group B (Security Ops) has a cross-group access rule permitting it to view Group A (Infrastructure) resources. In this scenario:

• Users in Group B can see both their own group's resources AND Group A's resources (as permitted by the cross-group rule).

• Users in Group A can see only their own group's resources.

• Users in Group C can see only their own group's resources.

• Administrators can see everything.

✔ TIP	Think of Account-Level Group Isolation as a default-deny boundary, and cross-group access rules as explicit allow rules punched through that boundary. This combination gives you a secure-by-default posture with controlled exceptions.

8.6 Impact Summary: Isolation On vs. Off

Capability	Isolation OFF (default)	Isolation ON
Non-admin user sees resources in other groups	Yes (if their role scope allows)	No (only their own group, unless a cross-group rule applies)
Administrator access	Full account access	Full account access - unchanged
Cross-group access rules	Active (grants additional access beyond group scope)	Still active - cross-group rules create explicit exceptions to isolation
Per-user group restriction ('Limit to specific groups')	Active - restricts the specific user to listed groups	Both restrictions apply - the more restrictive of the two takes effect
Custom roles	Subject to their configured scopes	Group-isolated - same as default roles; own-scope custom roles unaffected
Audit log visibility	Per role permissions	Audit log access is also restricted to the user's group