RBAC Best Practices

When multiple users share a Tenable One instance — especially across geographic or business boundaries — controlling who can see and do what becomes critical. Without a deliberate access strategy, users may encounter data they shouldn't see, accidentally modify scan configurations, or open support tickets for behavior that is working as designed.

This topic describes recommended practices for configuring and maintaining RBAC in Tenable Vulnerability Management. It covers how to organize users, structure scan folders to enforce access boundaries, manage credentials securely, and keep your RBAC configuration healthy over time.

If you are new to RBAC and have not yet completed your initial configuration, see Get Started with Role-Based Access Control before continuing.

Use the Least-Privilege Model

Assign the lowest role that enables a user to perform their job. This reduces the impact of a compromised account, limits accidental changes, and simplifies compliance auditing.

  • Use Tenable-provided roles wherever possible. The six Tenable-provided roles — Read-Only, Basic, Scan Operator, Standard, Scan Manager, and Administrator — cover the majority of real-world use cases. Evaluate them before reaching for a custom role.
  • Create custom roles only when necessary. Custom roles are powerful but require ongoing maintenance. Before creating one, ask: which areas of the product should this user access, which navigation items within each area, and which actions within each item? This three-level check prevents over-provisioning.
  • Avoid the Administrator role for routine work. Administrator users have full, implicit access to all assets and platform functions. Assign this role only to users who genuinely need to manage users, system settings, or authentication configuration.

For a complete reference of role privileges, see Tenable-Provided Roles and Privileges and Custom Role Privilege Application.

Use Groups, Not Individual Assignments

Assign permission configurations to user groups rather than to individual users. This makes it significantly easier to onboard new staff, reassign responsibilities when team membership changes, and audit who has access to what.

Structure your groups to reflect your organization. Common strategies include:

  • Geography (e.g., US-East, EMEA, APAC)
  • Business unit (e.g., Finance, Engineering, HR)
  • Asset type (e.g., Databases, Web Servers, Workstations)
  • Criticality (e.g., Production, Development, DMZ)

When a new analyst joins the EMEA team, you add them to the EMEA group — their access is already correctly scoped. When they move to a different team, you change their group membership. No individual permission reconfiguration is required.

Note: Misconfigured user groups can cause scan failures and asset or vulnerability gaps in dashboards and reports. Review group membership and permission configurations periodically, particularly after organizational changes.

For more information, see User Groups in the Tenable Vulnerability Management User Guide.

Leverage Tag Automation

Tag automation rules automatically assign assets to tags when they match defined criteria. This keeps your permission scopes accurate without manual intervention as your asset landscape changes.

  • Define tag automation rules at deployment time. Manual tag assignment is error-prone at scale. Automation rules ensure that new assets discovered by scans are immediately assigned to the correct tags — and therefore fall within the correct permission scopes.
  • Review automation rules when your asset inventory changes significantly. Major changes — such as a cloud migration, acquisition, or decommissioning of an environment — may require updates to your tag criteria.
Tip: A group is made up of a collection of permissions. The diagram in Get Started with RBAC illustrates how different users can hold a single role while belonging to one, several, or no groups. Well-structured tags and automation rules are what make that group model scale.

For more information, see Tags in the Tenable Vulnerability Management User Guide.

Implement a Folder Structure for Scan Organization

A well-organized folder structure does more than keep things tidy — it enforces access control at the scan level. When you assign access groups to folders, users see only the scans in folders their group permits. This prevents accidental cross-contamination of scan data between teams, regions, or business units, and makes it easier to audit who has access to what.

Tenable recommends creating a folder hierarchy that mirrors your access group structure. This makes it intuitive for users to understand why they see what they see, and simplifies administration when groups or responsibilities change.

To create a folder hierarchy:

  1. In the top navigation bar, click Scans > Folders.
  2. Create folders that match your access groups, for example:
    • Production Assets
      • Web Infrastructure
      • Database Systems
      • Critical Applications
    • Development Assets
    • Third-Party/Vendors
  3. After creating your folders, assign the appropriate access groups to each one.

Users see only the scans in folders that their access group permits.

Note: Folder-level permissions take precedence over any custom role privileges applied.

Configure Managed Credentials Securely

Authenticated scanning gives you significantly deeper vulnerability visibility than unauthenticated scanning — but it also means storing and managing privileged credentials within Tenable Vulnerability Management. Handling credentials carelessly can introduce serious risk. The following best practices help you get the full benefit of authenticated scanning while keeping your credentials secure.

  1. Use managed credentials for authenticated scanning. Managed credentials are stored centrally and can be assigned to scans without exposing the underlying credential values to scan operators. This separates the act of scanning from the act of administering credentials.
  2. Organize credentials by category to keep management organized and auditable:
    • Host credentials (SSH, Windows, etc.)
    • Database credentials (Oracle, MySQL, PostgreSQL)
    • Cloud credentials (AWS, Azure, GCP)
  3. Apply least-privilege principles to credentials. Scanning does not require write or administrative access to target systems. Credentials should have read access only.
  4. Limit credential visibility to authorized users only. Use permissions to ensure that only the users who need to assign or manage credentials can see them. Consider creating a dedicated credential-manager user group.

For more information, see Managed Credentials in the Tenable Vulnerability Management User Guide.

Control Scan Result Visibility

Scan policies have their own access controls that are independent of tag-based permission configurations. If a scan policy is shared without a Default: No Access setting, users who can access the policy can see all scan results associated with it — regardless of their tag-based permission scope.

Caution: Always set Default: No Access on scan policies in environments where RBAC is enforced. This prevents users from viewing scan results for assets outside their permission scope by accessing a shared scan policy.

Additionally, when a scan runs, Tenable Vulnerability Management evaluates target permissions based on the scan owner's permissions, not the user who launched the scan. Ensure that scan ownership is assigned to the appropriate user or service account.

Maintain Your RBAC Configuration

RBAC is not a set-and-forget configuration. As your organization grows and changes, your access controls need to keep pace.

  • Audit role and permission assignments regularly. Periodically review who holds which roles and which permission configurations are assigned to which users and groups. Remove access that is no longer required.
  • Test before deploying changes at scale. Validate any new permission configurations with a test account before applying them broadly, to avoid unintended access gaps or over-exposure.
  • Revisit custom role definitions periodically. As your product usage evolves, verify that custom roles still reflect your organization's least-privilege goals and have not accumulated unnecessary privileges.
  • Monitor activity logs. Tenable Vulnerability Management's activity logs (available to Administrators) provide an audit trail of user actions. Review them as part of your regular security hygiene.

Summary Checklist

Use the following checklist to verify your RBAC implementation is complete and aligned with best practices:

  • Roles assigned reflect the least privilege required for each user's responsibilities.
  • Tenable-provided roles are used where possible; custom roles are used only where necessary.
  • The Administrator role is assigned only to users who need full platform control.
  • Permissions are assigned to groups, not individual users.
  • User groups are organized to reflect your team or asset structure.
  • Tags are defined and automated to scope permission configurations accurately.
  • Scan folders mirror the access group structure.
  • All scan policies are set to Default: No Access.
  • Managed credentials are organized by category and restricted to authorized users.
  • RBAC configurations are reviewed and updated periodically.