--- sourceDocument: Brazil Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Contextual Security Manager # Contextual Security Manager {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Contextual Security Manager Contextual Security Manager enhances data protection in ServiceNow by controlling read, write, create, and delete authorizations with a focus on context-aware and hierarchical security. It replaces legacy role-based security on dictionary entries with ACL-based rules, enabling more granular and dynamic access control based on record content and object hierarchy positions. Show full answer Show less ## Key Features * **Contextual Security:** Secures records by evaluating the contents of the record itself. * **Hierarchical Security:** Applies security rules at any level within the system's object hierarchy, allowing precise control over data exposure. * **Field and Table Security via ACLs:** After activation, security must be configured using ACL rules rather than roles on dictionary entries; dictionary roles are no longer effective. * **Role Management Changes:** Roles are assigned via the Roles related list on users and groups, replacing the previous direct role field on user records. Application and catalog item/module access still uses role arrays. * **Automatic Role Inheritance:** Groups automatically inherit roles granted to them when the inherits flag is enabled. * **Plugins:** * *Contextual Security: Role Management* (com.glide.rolemanagement) -- provides core contextual security functionality and is installed by default. * *Role Management V2* (com.glide.rolemanagement.inhcount) -- addresses duplicate role entries by managing inherited roles more efficiently; automatically installed on new instances and available for upgrades. * Role Management V2 includes audit capabilities that can be enabled via system property configuration to track user role changes. * **Security Attribute Conditions (Vancouver release onwards):** ACL rules can now include Security Attribute Conditions which evaluate user or session properties (like group membership, authentication state, network location) to grant or deny access. These conditions can be local (specific to one ACL) or existing (shared across ACLs). ## Practical Implications for ServiceNow Customers * When Contextual Security Manager is activated, review and migrate all field and table security settings from dictionary roles to ACL rules to ensure proper access control. * Adjust role assignments by using the Roles related list on user and group records rather than the deprecated roles field. * Use the Role Management V2 plugin to prevent duplicate user role entries, especially in environments with complex role inheritance. * Leverage Security Attribute Conditions in ACLs to implement advanced, context-aware security policies based on dynamic session or user attributes. * Enable auditing of role changes through system properties to maintain compliance and track security modifications. By adopting the Contextual Security Manager, organizations gain fine-grained, scalable security controls that reflect real-time user contexts and hierarchical data structures, significantly strengthening data protection and compliance within their ServiceNow environment. Contextual Security Manager protects your data by controlling read, write, create, and delete authorization. ## Key advantages The Contextual Security Manager is aware of the system table hierarchy, enabling you to create specific security rules for a field based on where in the hierarchy it is displayed. Benefits of the Contextual Security Manager include: * Contextual security: Secure a record based on the contents of the record. * Hierarchical security: Apply security rules to any level in the object hierarchy. ## Securing fields and tables With the legacy Simple Security Manager, you could secure fields and tables by adding roles to the appropriate dictionary entry. With the Contextual Security Manager, these dictionary roles are no longer tested. Instead, the system looks for ACL rules on fields and tables. Warning: After you install the Contextual Security Manager, you must secure fields and tables via ACL rules. Even if you [Configuring the form layout](https://www.servicenow.com/docs/access?context=configure-form-layout&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US) the dictionary form and add roles to a dictionary entry, no change in rights occurs. ## Contextual security and roles You can grant roles to users or groups. However, after installing the Contextual Security Manager, the roles field on the user record is no longer checked and no longer appears on your user and group forms. Instead, you must add roles to the Roles related list instead of to the user or group record. Applications and modules contain lists of the roles required to view them. For example, to view the System Definition application, the admin role is required. Security rights for applications and modules are still defined using role arrays. Both catalog items and catalog variables contain lists of the roles required to view them. Security rights for catalog items and catalog variables are still defined via these role arrays. Under the Contextual Security Manager, a group still automatically inherits any role granted to the group when the inherits flag for the role is set to true. ## Activating the Contextual Security Manager The Contextual Security Manager is active in the base system. If there are many duplicate entries in the User Roles table, you may need to upgrade to Contextual Security: Role Management V2 to eliminate duplicate roles. Plugins include: Contextual Security: Role Management \[com.glide.role_management\] : Provides contextual security functionality. This plugin is automatically installed. Contextual Security: Role Management V2 \[com.glide.role_management.inh_count\] : Prevents duplicate entries caused by inherited roles in the User Roles \[sys_user_has_role\] table. This plugin is automatically installed on new instances and can be activated for upgrades. The Contextual Security: Role Management Enhancements plugin is a previous version of this plugin. The Role Management Enhancements plugin does not include the RoleManagementVerify() script. This script returns a list of changes that an upgrade will perform, enabling you to monitor changes made by the plugin. Note: After activating Role Management V2, you must set the glide.role_management.v2.audit_roles system property to allow the Audit Roles table to create audit records related to user roles. To learn more about setting this property and about the Audit Roles table, see: * [Enable role auditing with Contextual Security: Role Management V2](https://www.servicenow.com/docs/W8ehrM3hx796ubgit7ktng "Set a system property to enable the Audit Roles table to create audit records related to user roles."). * [Hardening settings](https://www.servicenow.com/docs/6TbAayAbhaAoHgI9uqOI5g "The ServiceNow Security Center (SSC) hardening settings content contains detailed descriptions and compliance values for the security-related system properties and plugins in the ServiceNow AI Platform. You can set these properties using the hardening settings app in the Security Center.") in Instance Security Hardening Settings. * [Audit user roles](https://www.servicenow.com/docs/access?context=audit-user-roles&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US) {#r_ContextualSecurity__ul_cst_3dc_qkb} ## Security Attribute Conditions Starting with the Vancouver release, ACL rules support a Security Attribute Condition type in addition to the standard role, condition, and script fields. Security Attribute Conditions evaluate properties of the current user or session, such as group membership, authentication state, or network location, to determine whether access is granted. Security Attribute Conditions can be defined as local or existing: Local : The condition is saved only to the ACL where it is created. Conditions default to local. Existing : The condition references a Security Attribute condition already defined on another ACL, enabling reuse across multiple rules. For a complete list of built-in security attribute types and configuration details, see [Security Attributes Fundamentals](https://www.servicenow.com/docs/DOdpTe9XnNvbmAZ1fQvFug "A Security Attribute is highly configurable piece of information about a Subject or it’s Environment, when used in access controls, enables fine grain security configuration in a non-complex way.") and [Security Attribute Type](https://www.servicenow.com/docs/9gNkMK9tv6IP7UdIDc3Uag#security-attribute-scope "Security attributes support local or existing types.").