--- title: Identity and Access Management slug: rbvm-help/identity-and-access-management createdAt: 2026-10-26T13:51:21.743Z --- **Summary**: High-level overview of the Identity & Access Management (IAM) feature in Ivanti Neurons RBVM/ASPM/VULN KB. ## Overview The new Identity & Access Management (IAM) feature redefines the Ivanti Neurons RBVM/ASPM/VULN KB platform IAM system to allow for more granular control of what users can do, including negating privileges. This update introduced a [new Users page](docId\:S5dPBw7kIntsV8jAFVNna) with new features and improved functionality and a new Roles page that helps users navigate the new Role-Based Access Control (RBAC) implementation. ## IAM Feature Goals - Roll out a [redesigned Users](docId\:S5dPBw7kIntsV8jAFVNna) view with several updates and improvements and a **new Roles view**. - **Enhance the access control system using customer-sourced use cases**, pain points, and challenges. - Rollout a **new IAM system** that includes user and role management. - Adjust the menus to accommodate these **new views**. - Provide an **easier-to-use** and more functional feature. ## Sample Customer Use Cases and Pain Points - I need the ability to restrict any user from uploading data regardless of their role. - Can I prevent users from modifying API integrations (connectors) if they are a manager? - How can I provide someone at the user level the ability to approve a workflow but not gain other privileges? - Is there a way to temporarily restrict the things users can do in the platform for our quarterly audit? - How can I give temporary access as manager and have the user revert to their original role after some amount of time? - Can I give my boss access to the platform and allow them to use dashboards and filters but prevent them from modifying data? - I need to provide some security analysts with the ability to approve false positives without giving them manager access to the platform. - I manage multiple clients within your platform, can you give me a single place to see the users across those clients that allows me to view and manage them without switching between clients? - Can I manage my own users’ access to the clients that I can access, e.g., my production and sandbox clients, without escalating to support\@risksense.com? - Can I limit who can create networks, assessments, and groups within my platform regardless of their role? ## What is Role-Based Access Control? **Role-based access control (RBAC)** uses **privileges** (what a person can do) and associate one or more of these privileges to a **role**. You then **assign users one or more roles** based on their job and scope of work. This system allows you to define what users can and cannot do within the limitations of the system (in this case, RiskSense). A **role** is a configuration of Allowed, Not Allowed, and Not Configured for each system privilege. Each privilege must be set to one of these three values for each role. A privilege is an action or set of actions available in the platform, **represented by the cards** on the **Roles** page. There are two types of RiskSense-provided roles: **foundational **and **supplemental**. **Foundational roles** are a set of uneditable, predefined roles designed to provide a persona set that can use the platform in different ways. Use these foundational roles to give users the full RiskSense platform experience in their own intended ways. **Supplemental roles** are a set of predefined roles designed to provide a specific job function to our customers that can be used in conjunction with other roles to bestow more user privileges without promoting the user to a higher foundational role and giving them additional privileges they should not have. By default, RiskSense offers a mixture of 20+ foundational and supplemental roles. This feature also introduces the ability to create your own roles, allowing you to configure user permissions with more granularity than you could before. **Custom roles** allow you to design a role specific to your needs. This could be like a foundational role or a very specific supplemental role. Use custom roles to give/take specific privileges to/from users, as well. ## Feature Highlights - Select from **two **categories of RiskSense-provided roles, **Foundational **and **Supplemental**. - Previously used roles will **no longer be available** (though similar roles will be provided) as users are migrated to the new system. - Easily see the **roles** and **groups** that a user **has access** to from the **new **Users card view. - **Easily **see what the roles in the platform **can do** using the new **Roles **view found within the **IAM **module. - **Create your own roles** and allow/disallow those roles for each privilege the new system allows you to configure. - **Manage multi-client **users **withoutescalating** to the RiskSense Support team. - **Manage all users** for **all clients** you have permissions to access from a **single redesigned user card view**. - **Negate a privilege** in a role, providing the ability to **take away** things from users easily. - **Expire roles** individually to allow for things like giving **limited time window** additional access to a user for coverage of another team member. - **Tailor **the platform to fit user privileges needs by offering **granular control** over things you can **allow **or **disallow **users to do. ## Legacy vs. Current System Comparison | **Legacy System** | **Current System** | | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | 4 built-in roles |  20+ built-in roles | | No supplemental roles for giving small privilege sets exist | Supplemental roles allow giving of smaller privilege sets to users | | Cannot create your own roles to ensure that you can meet your organization's needs | Can create your own roles that have the privileges that meet your needs | | Cannot negate feature usage in the platform | Can negate (deny) privileges in roles you create | | Has no granular control of platform actions | Has over 50+ privileges to allow/deny users | | Has a technician role that only sees findings assigned to them | Does not have a role that is limited at the vulnerability level | | Users can have only a single role that always determines user privileges | Users can have multiple roles that work together to determine a user’s overall privileges | | Cannot see what a role can/cannot do within the platform | Can visually see and inspect what a role can/cannot do on the platform’s Roles page | | Has no feedback on what you could do to gain access to some action/feature that you currently cannot access | Has feedback in the form of the Roles pages and new mouseovers that tell you what privilege and role you are missing or need to access something you cannot |