TPRM vendor portal external access securitySummary The vendor portal is fully leveraging the service portal capabilities. In this regard, it has nothing technically specific to its implementation or its security access, it is all based on the platform capabilities and network access. However, as the targeted users to access the vendor portal are external users, it requires to provide access to users from outside of the internal customer network. Description Opening the network for external presents some security risks that need to be addressed. There are several possible solutions to mitigate the risk: Use 2 separate data-synchronized instances to limit exposure of corporate/sensitive data.Use a reverse proxy.Modify ACLs to filter based on IP address at the authorization level.Institute IP checks at the authentication level.Create customer-managed public facing web page to collect data, get status requests, authenticate accounts and make web services calls back to ServiceNow instance. For customers: Who have instance-wide IP restriction enabled using IP address access control.And want to allow external users/vendors to access the instance from outside the trusted network boundary.And do not want to opt for multi-instance. For interactive sessions, the admin can create a post-authentication context policy to allow: External user/vendor (identified by role/group) to access the instance from any network.Internal users (identified by role/group) to access the instance only from the trusted network. This policy check happens only once at the time of login before session establishment. For any network change within a logged-in session, we have another policy context (Session validation context) that can be used to employ a similar policy. For non-interactive sessions (REST API, SOAP API, and non-public processors), we recommend customers to apply Global API access policies. REST API access policyGlobal SOAP API Access PolicyProcessor access policy Two important points to note here: All adaptive authentication protections apply to non-public resources only. This means that public resources (public API, public processor, public UI page, public portal page, public portal widget, public KB article, public catalog item, public table, sys_public records, public CCSI, etc.) will be available outside the trusted network. This is an important difference in the security posture with this change. So, before they decide to move away from IP address access control, we advise customers to audit their public resources first so they can choose to either be okay with having these resources available on the internet or make them non-public. For any non-public resource not protected by the Adaptive authentication framework, we recommend that customers use Adaptive authentication API in the existing access controls to enforce IP restrictions. (ACL script, scripted user criteria etc.). All these protections are available with the platform without requiring any additional license. The customer can install these plugins and apply the granular IP-based protections. In addition, if the customer has a use case of allowing users from untrusted networks but with limited privileges, we recommend them to use Zero trust access. Zero trust access is a licensed offering. It is available as a standalone SKU and also as part of the ServiceNow vault bundle. Finally, as these solutions do not provide the same assurance level as IP address access control, we advise customers to perform thorough testing from a security perspective. So that you know, this is a recurring requirement from VRM/TPRM/HRSD customers.