1. Knowledge Base
  2. Onboarding the NopSec Platform

3. User Management

Create and manage users within NopSec's Unified VRM platform.


In UVRM 5.0 we had two roles. Admin and User. 

In UVRM 6.0 we have introduced 5 roles with each role being configured with a specific set of scopes or actions that give Administrators more control on how to manage user privileges. We will continue add more actions in the future allowing for finer grained control.

The five roles are:

  • Admin: Administrators are given full privileges across all actions.
  • Manager: This is a new role to support large organization needs to have specific manager level actions such as approvals to be delegated down to specific people. The Manager role is similar to Administrators, however, they do not have any Edit privileges across several Admin focused actions such as; Integrations, Settings, and User Management. 
  • Analyst: This is the core role for any non-Admin or Manager user. This role is meant to support our Remediation Team users as well. They are not able to manage users, exceptions, settings, or integrations. In the future as more features are released we will introduce Remediation Team roles. 
  • Exception Manager: For users who need to be given a the specific privilege of Exception reviews. For instance, an Analyst within a team that isn't quite a Manager but needs to be able to help review Exception plans can be given this role. 
  • Default: Very limited read access and no edit access. Used as the default role for new users not assigned to a team.


In UVRM6.0 we are introducing Teams as a way to manage users at scale. 

Each Team can have a unique name set by Administrators, a Role, and a Data Access query that controls which Assets it's members have access to.

Users can be added to a team, becoming members, and upon being added they inherit the Role and Data Access the Team provides. 

Users can exist in multiple teams and the platform will leverage their highest privilege when taking actions and join the data access queries across both teams with an OR statement enabling them to view both team's data.

The moment a user is removed from a Team they lose the Role and Data Access the Team provided. 

For instance, a Team can be:

  • Team A
    • Role: Analyst
    • Data Access: asset.os = "Windows*"
  • Team B
    • Role: Analyst
    • Data Access: asset.os = "Linux*"
  • Team C
    • Role: Exception Manager
    • Data Access: asset.os = ["Windows*", "Linux*"]

The use of Teams should greatly reduce the time and effort for Administrators performing User Management by having them do the work of Role and Data Access once per team rather than per user. 

Note: We understand that in 6.0 the Administrator still needs to determine where a user must be placed. In 6.1 we will support Okta and Azure AD Auto Provisioning through SCIM to enable administrators to sync SSO Groups within UVRM. UVRM Admins will then be able to create a mapping between SSO Groups and Teams. As membership changes within a Group the Team membership changes as well. 

What if a user is in two teams?

This is a common use case as a user may need two or more roles to effectively support the VM program. For instance, being an Analyst and an Exception Manager. Or a user is part of two product teams with access to two different sets of assets.

If a user is in two teams the following will happen:

  • The platform will leverage the highest role across all of their teams for their permissions.
    • If a user was a member of all three teams above the platform would choose Exception Manager when the user takes actions.
  • The platform will join all of the Teams specific data access queries leveraging an OR operator.
    • If a user was a member of all three teams above the platform would join the queries like so:
      • asset.os = "Windows*" OR asset.os = "Linux*" OR asset.os = ["Windows*", "Linux*"]
    • This means if you want to ensure a user does not have access to specific assets they must not be members of Teams with access to those assets.