Permissions

This page describes the permission models used by Tenable products to control access to specific resources and features:

• Vulnerability Management and Web App Scanning Permissions
• Container Security Permissions
• Identity Exposure Permissions
• Security Center Permissions

---

Vulnerability Management and Web App Scanning Permissions

Tenable Vulnerability Management and Tenable Web App Scanning use the following permissions types to control access to specific resources (such as scans, scanners, and credentials):

• Agent Permissions
• Credential Permissions
• Vulnerability Management Scan Permissions
• Web App Scanning Scan Permissions
• Scan Template (Policy) Permissions
• Scanner Permissions
• Shared Collections Permissions

Agent Permissions

Credential Permissions

Vulnerability Management Scan Permissions

Web App Scanning Scan Permissions

Scan Template (Policy) Permissions

Scanner Permissions

Shared Collections

---

Container Security Permissions

Container Security in Tenable Enclave Security has its own permission model. Each Container Security permission can be set to true (enabled) or false (disabled) on a per-role basis. Administrators can create custom roles and assign specific permissions to control access to Container Security features. For more information about the default roles and their enabled permissions, see Roles.

---

Identity Exposure Permissions

Tenable Identity Exposure has its own permission model. A role grants an action on an entity: Read, Edit, or Create on security profiles, domains, Indicators of Exposure, and so on. Each Identity Exposure endpoint states the permissions it requires. For the roles that hold these permissions, see Identity Exposure Roles.

In the API, a permission is an action and an entityName, which this documentation writes as action:entityName — for example, read:profile. To set a role's permissions, use the Replace role permissions endpoint. For how to set permissions in the interface, see Set Permissions for a Role in the Tenable One Identity Exposure SaaS User Guide.

How Identity Exposure Permissions Work

• Actions are hierarchical. Edit includes Read, and Create includes Edit and Read. When you save a role, Tenable adds the lower actions for you.
• Create also governs deletion. There is no separate delete permission: deleting a security profile, for example, requires create:profile.
• Data endpoints check related entities. An endpoint that returns data scoped to a security profile, a domain, or an Indicator also requires Read on each of those entities. Without them, the request fails with 403 and the error names them: Missing permissions on related entities (profile, directory, checker).
• A denial names the missing permission. The 403 response has the code RBAC_RESTRICTION and a title such as Missing permission: read:license:*. When the request targets a specific object, the title includes its ID: edit:dashboard:42:*.
• A permission can apply to specific entities. Set entityIds to a list of IDs to limit a permission to those objects, or to null to apply it to every object of that type. Each ID must exist, or saving the role fails with 400 INVALID_RBAC_RULES, and an empty list grants nothing. A request for an object outside the list returns 403, and the error title names the object's ID.
• Interface entities do not govern the API. The ui- entities control which parts of the interface a user sees. No endpoint requires one.

🛑

Caution

If a change to a role leaves a user without edit:api-key, Tenable revokes that user's API key. Restoring the permission does not reactivate the key: the user must generate a new key with the Create API key endpoint. Sessions started with a sign-in token are not affected.

Permissions Every Role Holds

Every role holds the following permissions, and Tenable keeps them when you replace a role's permissions. Because they cannot be removed, endpoints that check only these permissions are available to every user, and their documentation states that no additional permission is required.

Permission Dependencies

Tenable rejects a role that holds some permissions without the permissions they depend on. The request fails with 400, the code INVALID_RBAC_RULES, and a title that names the missing relation, such as Invalid RBAC (MISSING_RELATION) on permissions read:directory:* and related entities infrastructure.

Identity Exposure Entities

The following entities govern the Identity Exposure endpoints, in addition to the ones in Permissions Every Role Holds. The Interface Entity column gives the name on the Permissions Management pane of a role, where the user guide lists one. The option entities hold the Indicator options staged on a security profile and have no entry of their own in the user guide.

📘

Note

Changing the default roles for new users through the Update application settings endpoint also requires edit:role.

---

Security Center Permissions

Tenable Security Center has its own access model, with two kinds of account:

• The administrator manages Security Center itself: organizations, repositories, scanners, scan zones and configuration. The administrator cannot see or manage organization data such as scans, assets, queries and reports.
• Organization users work inside one organization, under a role. A role is a set of permissions, each enabled or disabled, and the role decides what the user can create and manage. Groups then decide which objects the user can see: a user can use objects shared with their group, and manage the objects of users in groups they can manage.

Each Security Center endpoint states which account it requires and, for organization users, the permission the role needs. For how to set up roles in the interface, see User Roles in the Tenable Security Center User Guide.

How Security Center Permissions Work

• A denial returns 403 with error code 163. The error_msg names the reason, such as No permission to create Policies. or The currently logged in user is not an administrator. Security Center returns almost every error as 403, so read error_code rather than the status. A few other errors also use 163, such as a debug log download when no archive exists, so read the message too.
• The Security Manager role holds every permission an organization user can have, and it cannot be customized. A user who creates users or roles cannot give them permissions they do not hold themselves.
• Permissions do not grant access to objects. A user whose role allows them to create scans can still edit or launch only their own scans and those of users in groups they manage.
• Managing users depends on groups, not on a permission. An organization user can create, edit and delete the users of the groups in its managed user groups (managedUsersGroups), whatever its role. No role permission grants it.

Security Center Role Permissions