--- 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 --- # External credential storage # External credential storage {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 External Credential Storage External credential storage allows a ServiceNow instance to securely store and manage credentials used by Discovery, Orchestration, and Service Mapping in an external credential repository instead of directly within ServiceNow credential records. This approach enhances security by keeping sensitive credential data outside the ServiceNow platform and leveraging third-party vault solutions like CyberArk or BeyondTrust. Show full answer Show less ## How It Works The MID Server plays a central role by retrieving credential identifiers from the ServiceNow instance and then resolving these identifiers to actual credentials using a customer-provided Java Credential Resolver JAR file. This resolver interfaces with the external vault to securely fetch the necessary user names, passwords, or tokens. * The MID Server downloads credential objects that include credential IDs linked to the external vault. * During Discovery or Orchestration jobs, the MID Server passes the credential ID, target IP, and credential type to the Credential Resolver. * The Credential Resolver communicates with the vault (sometimes via a vendor-supplied caching application) to retrieve usable credential details. * The MID Server caches credentials briefly in encrypted memory to optimize performance but does not store credentials persistently on the instance. * Credential affinity rules still apply, ensuring correct credential use per device or target. ## Supported Vault Integrations Currently, ServiceNow supports integration with CyberArk and BeyondTrust vaults for external credential storage. CyberArk integration includes native MID Server support and can handle OAuth 2.0 credentials, allowing OAuth client ID and secret to be stored externally and managed seamlessly by the MID Server. ## Configuration and Management * The External Credential Storage feature is enabled via the **Enable External Credential Storage** property in Discovery and Orchestration settings once the plugin is activated. * When enabled, the Credentials record view changes to show an external storage-specific interface, including a credential ID column. * The MID Server refreshes its credential cache automatically to align with external credential storage usage. * If external credential storage is disabled, all external credentials are set to inactive. Re-enabling the feature requires manual reactivation of credential records. * Logging is provided by the MID Server to track credential resolution and errors, aiding troubleshooting. * The plugin is available upon request and requires configuration to connect to the chosen external vault. ## Benefits for ServiceNow Customers * Enhanced security by removing credential storage from the ServiceNow instance. * Centralized credential management through enterprise-grade vault solutions. * Seamless credential retrieval and caching optimized for Discovery, Orchestration, and Service Mapping workflows. * Support for modern authentication methods such as OAuth 2.0 via external vaults. * Improved credential lifecycle management with vendor-specific caching and update mechanisms. An instance can store credentials used by Discovery, Orchestration, and Service Mapping in an external credential repository rather than directly in a ServiceNow credentials record. The instance maintains a unique identifier for each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID Server obtains the credential identifier from the instance, and then uses a customer-provided JAR file to resolve the identifier from the repository into a usable credential. Currently, the ServiceNow® platform supports the use of the [CyberArk vault](https://www.servicenow.com/docs/Rpk8fNFrUbzuFNPp2Ik0_w "The MID Server integration with the CyberArk vault enables ServiceNow Orchestration, ServiceNow Discovery, and ServiceNow Service Mapping to run without storing any credentials on the instance.") or BeyondTrust for external credential storage. ## External credential storage architecture {#c_ExternalCredentialStorage__section_t4l_m4z_1cb} Figure 1. External credential storage architecture ## Credential process flow {#c_ExternalCredentialStorage__section_t21_p4z_1cb} The MID Server retrieves credentials from an external store using this process: 1. MID Server downloads credential objects from the ServiceNow Credentials \[discovery_credentials\] table that contain the corresponding credential ID from the target vault. 2. As each probe or pattern runs from Discovery or Orchestration jobs, the MID Server requests the credential by passing information such as credential ID, target IP address, and credential type to the Credential Resolver Java Jar file. The details about the correct credential object to retrieve from the vault are determined by the Credential Resolver. Many Credential Resolvers such CyberArk call an application supplied by the third-party vault vendor running on same machine as the MID Server. That application can often be configured to cache credentials and knows to update the cache when a credential changes in the vault, which is very important to avoid unnecessary network calls to the vault each time MID Server requests a credential. The Credential Resolver (using optional vendor application if present) makes a call to the vault to get the actual user name, password, etc. For Credential Resolvers supplied out-of-box (only CyberArk today), the MID Server only caches a credential for up to several seconds using encryption in MID Server process memory. This means the MID Server can make multiple requests to the Credential Resolver for the same credential even when discovering a single device. Contact third party vendors for information about caching implementations for other Credential Resolvers. 3. MID Server executes the probe with the appropriate credential. {#c_ExternalCredentialStorage__ol_aqc_wf4_cv} Note: Credential affinity still applies. The mechanism remains the same, since the only real difference from the MID Server's perspective is that the real credential details (user name and password) come from the third party vault. ## External credential storage logging {#c_ExternalCredentialStorage__section_zk3_d3d_ybb} The MID Server posts log messages about external credential storage. If the repository encounters an error while attempting to resolve a credentials request, the MID Server posts log messages with this prefix: `Problem with client's CredentialResolver:` ## Components installed with External Credential Storage {#c_ExternalCredentialStorage__section_bgf_3rz_1cb} Business rule : The External Credential Storage business rule performs the following tasks when an administrator makes any change to the Enable External Credential Storage property: * Changes the view for the Credentials record list and form to the External Storage view. This view enables users to see the Credential ID column in the list. * Instructs the MID Server to refresh its credentials cache in preparation for a change in the way credentials are obtained. {#c_ExternalCredentialStorage__ul_w1x_gyv_2y} Property : A property called Enable External Credential Storage \[com.snc.use_external_credentials\] enables or disables the External Credential Storage plugin after it's activated. The property is located in Discovery DefinitionProperties and OrchestrationMID Server Properties, and is enabled when you activate the plugin. If you disable external credential storage with the system property, the system automatically sets all the external credentials to inactive in the instance. If you re-enable the feature with this property, the system doesn't reset the external credential records to active. You must reactivate each [credential record](https://www.servicenow.com/docs/9_R8bXnL1z2xzA~ViO2fXg#r_WindowsCredentialsForm "Windows credentials provide access to Windows computers. This credential type is available for Discovery and Orchestration.") manually. * **[Request external credential storage for Discovery and Orchestration](https://www.servicenow.com/docs/N2pqjoNiUa0S4LfprnIJtw)** The External Credential Storage plugin is available by request. * **[External credential storage configuration](https://www.servicenow.com/docs/M4BXkIOB4E0DMTvVPPMnbA#external_cred_storage_configuration)** Configure your instance to obtain credentials from a remote repository. * **[CyberArk credential storage integration](https://www.servicenow.com/docs/Rpk8fNFrUbzuFNPp2Ik0_w)** The MID Server integration with the CyberArk vault enables ServiceNow® Orchestration, ServiceNow® Discovery, and ServiceNow® Service Mapping to run without storing any credentials on the instance. * **[OAuth 2.0 authentication via MID Server using external credential storage](https://www.servicenow.com/docs/Li2d3pZY3VgMxB6rHPyyCA)** Store OAuth 2.0 credentials-client ID and client secret-in the CyberArk vault instead of the ServiceNow instance. The MID Server gets the credentials from the CyberArk vault, when required to get the OAuth token. The token is stored in the MID Server and refreshed automatically upon expiry. *[\>]: and then