> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/user-roles-and-access-control/role-based-access-control.md). # Role Based Access Control Role-Based Access Control (RBAC) is the security model that governs what every user can see and do inside CERTInext. Rather than assigning identical access to everyone, the platform assigns each person a defined role, and that role determines which navigation 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, while a Basic User holds only a handful of keys, enough to manage their own certificates and orders but nothing more. CERTInext ships with eight built-in default roles whose permissions are fixed by the platform. In addition, an Administrator can define custom roles with a hand-picked combination of permissions, giving organisations the flexibility to map platform access to their own internal job titles and responsibilities. A role is assigned to a user at the moment of account creation and can be changed at any time by an Administrator or Manager. The access change takes effect immediately - no logout or system restart is required. ### Why RBAC Matters Without role-based access controls, any user could accidentally or intentionally modify another person's certificates, view confidential billing data, or alter system-wide settings. RBAC prevents this by enforcing the principle of least privilege: every user receives only the access they need to perform their job, and nothing beyond that. In a certificate lifecycle management platform like CERTInext, this principle is especially important. Certificates are tied to real-money transactions and security infrastructure. Billing details and invoice history may be commercially sensitive. Revoking or misconfiguring a certificate can cause service outages. Audit logs must reliably track who did what - and meaningful audit trails are only possible when every action is attributed to a user with a clearly defined access scope. ### The Permission Framework CERTInext's permission system comprises 367 granular permissions organised across 14 functional modules: Dashboard, Orders, Certificates, Certificate Authorities, Discovery, Provisioning, Reports, Billing, Settings, Domains, Organizations, Integration, Keys, and Sub-Accounts. Each permission is identified by a canonical code (for example, `certificates.certificate.view_all`) and a plain-language description. Permissions within most modules are available at three visibility scopes. The **Own** scope restricts the user to records they personally created or own. The **Group** scope extends their reach to records belonging to any member of their assigned group. The **All** scope grants access to every record in the account, regardless of who created it or which group it belongs to. 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 granted only `view_own` and can therefore only see their own certificates. This scoping model, combined with group-level access controls described later in this article, gives administrators precise control over both what users can do and which records they can reach. ### Default Roles at a Glance CERTInext provides eight assignable default roles. The table below summarises each role, its total permission count, and its primary design purpose.
RolePermissionsDesigned For
Administrator367Full platform control. Can perform every action available in CERTInext, including creating users, managing Certificate Authorities, configuring billing, managing settings and reporting, and defining group controls. Retains full access even when Account-Level Group Isolation is enabled.
Manager164Day-to-day account management. Covers certificates, orders, billing statements, user management, settings, and reporting. Can view and edit group configuration but cannot enable group isolation.
Discovery User93Certificate discovery specialists. Full Discovery module access including bots, CT log monitoring, and discovered certificates. Limited access to certificates and orders. No billing access.
Finance Manager79Billing and financial operations. Full billing control, sub-account management, price list management, invoices, and financial reports.
Standard User64Regular team members with broad view access. Can see all records across the account but can only act on their own, following a broad-view, narrow-write design.
Sub-Account User39Sub-account operations. Access is limited to own orders, own certificates, certificate requests, and sub-account price list access.
Basic User38Minimum access level. Can manage own orders, own certificates, and own API keys.
Custom RoleVariesOrganisation-specific requirements. Permissions and scopes are individually selected by an Administrator.
> **Note:** The Administrator role is the only role that automatically receives every new permission added to the system after a platform upgrade. All other roles must be explicitly updated to gain new capabilities. The Administrator role is also the only role unaffected by Account-Level Group Isolation. ### Detailed Role Descriptions #### Administrator The Administrator role carries 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 LDAP connectors and role mappings, setting IP restrictions, enabling Account-Level Group Isolation, managing custom fields and reporting tags, and deleting records across every module. Within the Dashboard module, only the Administrator can see the Certificates Issued chart, the Expiring Certificates chart, and the Discovery summary charts. Within the Discovery module, the Administrator is the only role that can scan discovered certificates for vulnerabilities, download CSRs from discovered certificates, and access the full detail view of any discovered certificate. Within the Orders module, exclusive capabilities include approving EV validation requests, recovering S/MIME private keys, bulk-downloading certificates, and bulk-revoking certificates. Within the Keys module, the Administrator has exclusive control over KMIP client management and KEK configuration, and is the only role that can create, rotate, and delete cryptographic keys. There should be at most one or two Administrators per account. This role should not be assigned routinely and should be reserved for platform owners or designated security administrators. #### Manager The Manager role holds 164 permissions and is the most powerful non-Administrator role. It is designed for users who run day-to-day certificate operations across an account without needing the platform's most sensitive administrative controls. Within the **Certificates** module, a Manager can view, download, revoke, and suspend certificates at all three scopes - own, group, and all - giving them complete visibility and action capability across the account's certificate inventory. Within the Orders module, a Manager can view all orders, approve pending requests at both group and account scope, cancel and renew orders, reissue certificates, and export order lists. Within the Billing module, a Manager can add credits, view and download statements and invoices at all levels, and download credit notes, though they cannot redeem vouchers or manage Discovery subscriptions. Within the Domains module, a Manager can add new domains, edit any domain, delete any domain, and trigger domain control validation. Within the Organizations module, a Manager can edit and delete any organisation and manage authorised representatives. Within the **Settings** module, a Manager can view and edit account configuration, edit any user's profile, invite and approve user invitations, export user lists, manage group credit allocations, view custom roles, manage IP restriction rules, view custom fields and reporting tags, view and manage the platform licence, and view scheduled tasks. Within the Integration module, a Manager has access to view all REST API keys and ACME EAB credentials, manage all supported CA connectors (emSign, emCA, Microsoft AD CS, DigiCert, Sectigo, EJBCA, Let's Encrypt), manage DNS connectors, view EST credentials, create new API credentials, and view API credential history. Managers cannot create new users, create private CAs, configure LDAP connectors, enable group isolation, or access IP restriction editing. #### Discovery User The Discovery User role holds 93 permissions and is purpose-built for teams responsible for discovering and cataloguing certificates across an organisation's infrastructure. Within the **Discovery** module, a Discovery User has near-complete access — they can view discovered certificates at all scopes, add certificates and CA certificates to the Discovery index, edit and delete discovered certificates, manage CA certificates, create and configure discovery bots, run and stop bot scans, pause and deactivate bots, monitor CT logs, add domains to CT log monitoring, manage CT log entries, and manage discovered certificates via deployment bots. The only Discovery capabilities exclusive to the Administrator are deleting own or group discovered certificates, scanning for vulnerabilities, downloading CSRs, and accessing the full certificate detail page. Within the **Integration** module, a Discovery User can revoke any REST API key or ACME EAB credential, view and revoke EST credentials, manage all CA connectors (emSign, emCA, AD CS, DigiCert, Sectigo, EJBCA, Let's Encrypt, and DNS connectors), and view API credential history. This broad integration access enables Discovery Users to operate and maintain the connectors that power their scanning infrastructure. Within the **Keys and Provisioning** modules, a Discovery User can view all keys, key profiles, and the key store, and can view all provisioned certificates and provisioning bots. Their Orders access is limited to viewing all orders and starting new certificate requests. Discovery Users have no access to the Billing or Sub-Accounts modules. When Account-Level 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 holds 79 permissions and is designed entirely around financial and sub-account administration. Within the Billing module, a Finance Manager has complete access - they can add credits, view and download ledger statements, view and download all invoices, download credit notes, redeem voucher codes, manage Discovery subscriptions, and submit credit withdrawal requests. No other non-Administrator role holds this level of billing control. Within the Sub-Accounts module, a Finance Manager can view the sub-accounts list, create and edit sub-accounts, allocate and withdraw funds, create and manage price lists, and deactivate price lists. Within the Reports module, they can view and export Orders Reports, Overall Statistics, Commission Reports, All Certificates Reports, and Sales Summary reports. Within the Settings module, a Finance Manager can edit account information (name, phone, address), invite and approve user invitations, view groups, allocate credits to groups, view and access the Tools page, and view Audit Logs. A Finance Manager can view all certificates, view group certificates, and view all expiring certificates, but they cannot revoke or suspend certificates. They can view and track all orders and submit CSRs, but they cannot approve, cancel, or renew orders. They cannot manage certificates directly or change system-wide configuration. #### Standard User The Standard User role holds 64 permissions and is designed for regular team members who need a broad view of the account but limited write access. A Standard User can view all certificates, all orders, all domains, all organisations, all discovered certificates, all provisioned certificates, and all keys across the account. This broad visibility gives them a complete operational picture without granting them the ability to make changes at that same scope. When it comes to acting on records, a Standard User is restricted to their own: they can revoke, renew, reissue, and submit CSRs only for orders and certificates they personally own. They can generate their own REST API keys and ACME EAB credentials, and they can view all API keys and credentials. Within Settings, a Standard User can view all users, view groups, view custom roles, and change their own password. They cannot modify other users, edit groups, or access account configuration. They have no access to the Billing administrative functions beyond viewing their own invoices. When Account-Level Group Isolation is enabled, a Standard User's "view all" scope is reduced to their own group, limiting their visibility to records owned by members of their assigned group. #### Sub-Account User The Sub-Account User role holds 39 permissions and is intended for users who operate within a sub-account managed under the main CERTInext account. Their access mirrors the Basic User in most respects - they can view and download their own certificates, start new certificate requests, manage their own orders (view, edit, renew, reissue, recall, track, attach documents), submit and replace CSRs, manage their own API keys and ACME EAB credentials, view and download their own invoices, and change their own password. The distinguishing capability for a Sub-Account User is access to price lists: they can view and edit price lists, which allows them to operate within the pricing framework established by the parent account. #### Basic User The Basic User role holds 38 permissions and is the minimum access level available on the platform. A Basic User can submit new certificate requests, view and download their own certificates (including interim DV certificates), revoke their own certificates, and manage their own expiring certificate notifications. On the orders side, they can view, edit, renew, reissue, recall, and track their own orders, submit and replace CSRs, manage SANs, generate public order links, and attach documents to their own orders. They can generate and view their own REST API keys and ACME EAB credentials, view and download their own invoices, and access the basic profile and password settings. A Basic User cannot see other users' certificates, orders, or records. They have no access to billing administration, reports, settings beyond their profile, or any management capability. #### Custom Role An Administrator can create a Custom Role with any combination of the 367 available permissions and their corresponding scopes. Custom roles are useful when none of the eight default roles precisely 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. Custom roles are subject to the same group-level access controls and group isolation rules as all default roles. See the section on Creating a Custom Role later in this article for step-by-step instructions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.certinext.io/documentation/user-roles-and-access-control/role-based-access-control.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.