---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Get started with credentials

# Get started with credentials {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 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 Get started with credentials

The MID Server utilizes credentials from the Credentials \[discoverycredentials\] table to access resources for Discovery, Orchestration, Service Mapping, and Cloud Management.
Proper configuration of these credentials is essential for effective network resource management.
Show full answer Show less  

## Key Features

* **Credential Usage:** Windows MID Servers default to using the service host's login credentials. For Linux/UNIX and network devices, SSH and SNMP credentials are utilized.
* **Encryption:** Credentials are stored encrypted and are only accessible through a specific decryption process, ensuring security.
* **Credential Order:** Users can assign an order value to credentials to prioritize which are attempted first, optimizing discovery and orchestration processes.
* **Credential Affinity:** After initial identification, a relationship is created between credentials and devices, facilitating quicker subsequent access.
* **Credential Aliases:** These allow for filtering and management of credentials in Discovery and Orchestration, helping to prevent the use of sensitive credentials.
* **External Credential Stores:** For enhanced security, external repositories (e.g., CyberArk) can be utilized for storing credentials outside the instance.

## Key Outcomes

By effectively managing credentials, customers can enhance the efficiency of their MID Server operations, ensure the security of sensitive information, and streamline access to network resources. Proper configuration leads to faster discovery and orchestration activities, while the use of external stores can further improve security and compliance. Implementing credential aliases allows for tailored credential management during workflows, ensuring appropriate access based on the context of operations.  
The MID Server uses the credentials you create in the Credentials
\[discovery_credentials\] table to access resources for Discovery, Orchestration, Service Mapping,
and Cloud Management.

## How MID Servers use credentials

By default, Windows MID Servers use the login credentials of the MID Server service on the
host machine to discover Windows
devices in the network. You should [Configure Windows MID Server service credentials](https://www.servicenow.com/docs/access?context=mid-server-install-prereqs&version=australia&pubname=australia-servicenow-platform&section=t_ConfigMIDSvrSvcCredentials&ft:locale=en-US) so that they have at least local administrator
privileges. For Linux and UNIX machines and network devices, the
MID Server uses the SSH and SNMP credentials configured in the instance in DiscoveryCredentials.

MID Servers that Orchestration uses must have access to the necessary
credentials to execute commands on computers in the network, as specified by the [Workflow activities](https://www.servicenow.com/docs/access?context=c_WorkflowActivities&version=australia&pubname=australia-build-workflows&ft:locale=en-US). Orchestration can use the same SSH and SNMP credentials as Discovery, but has two additional credentials designed for specific Workflow
activities: Windows (for [PowerShell activities](https://www.servicenow.com/docs/access?context=c_OrchestrPowerShellActivities&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US)) and VMware.

## Encryption and decryption

The platform stores credentials in an encrypted field on the Credentials
\[discovery_credentials\] table. Once they are entered, they cannot be viewed.  
When the MID Server requests credentials, the ServiceNow AI Platform decrypts the credentials using the following process:

1. The credentials are decrypted on the instance with the password2 fixed key.
2. The credentials are re-encrypted on the instance with the MID Server's public key.
3. The credentials are encrypted on the load balancer with SSL.
4. The credentials are decrypted on the MID Server with SSL.
5. The credentials are decrypted on the MID Server with the MID Server's private key.

{#credentials-getting-started__ol_avb_25r_x4}  
Note:  
The platform does not have separate encryption keys for multi-tenant instances.

## Credential order

Credentials can be assigned an order value in the [Credentials
Form](https://www.servicenow.com/docs/oyZysCmQfqZDwOJqzRKD0w#r_WindowsCredentialsForm "Windows credentials provide access to Windows computers. This credential type is available for Discovery and Orchestration."), which forces the application to try all the credentials at their disposal in a certain sequence. If you do not specify an order value, the application tries the credentials in the Credentials \[discovery_credential\] table randomly, until it finds one that works. For example, when:

* Orchestration attempts to run a command on an SSH server, such as a Linux or a UNIX machine.
* Discovery attempts to query an SNMP device, such as a printer, router, or UPS.
{#credentials-getting-started__ul_ldk_zpt_vlb}  
After identifying the credentials for a device, Discovery and Orchestration create an affinity between the credentials and the device using the Credential Affinity `[dscy_credentials_affinity]` table. All subsequent discoveries or Orchestration activities attempt to match the credentials in this table with a device for which an affinity exists. If credentials for a device change, Discovery and Orchestration try all available credentials again until they create a new affinity.  
Note:  
If Orchestration and Discovery are installed, and credential alias is enabled, multiple affinities can exist. In this case, the platform looks up credentials for each affinity and inserts the credential for the affinity with the lowest order into the probe.  
Ordering credentials is useful in the following situations:

* The credentials table contains many credentials, with some used more frequently than others. For example, the table contains 150 SSH credentials, and five of those credentials are used to log in to 90% of the devices. It is good practice to configure those five credentials with low-order numbers, which place them at the top of the execution list. Discovery and Orchestration work faster when they try these common credentials first. After the first successful connection, the ServiceNow AI Platform knows which credentials to use the next time for each device.
* The ServiceNow AI Platform has aggressive login security. For example, configure database credentials with a low-order value if Solaris database servers in the network only provide three failed login attempts before locking out the MID Server.
{#credentials-getting-started__ul_xfy_53s_x4}

## Credential aliases

Credential aliases are available for [Discovery](https://www.servicenow.com/docs/qpaRpO1J~HM9iymT~DTDow#discovery-credential-alias "Credential aliases for Discovery allow an administrator to use specific credentials on Discovery schedules. You can configure behaviors for your aliases that determine how strictly the system enforces their use.") and [Orchestration](https://www.servicenow.com/docs/1Ej9xbaR3yei~oOBM9bScA "Credential alias gives an administrator more control over the credentials used in Orchestration activities.").  
Aliases for Discovery enable an administrator to:

* Employ a credential filtering behavior with configurable levels of compliance.
* Assign multiple credential aliases to a Discovery schedule.
* Prevent the creation of credential affinities that use inappropriate or sensitive credentials. To learn more, see [credential affinities](https://www.servicenow.com/docs/JF7bdmTAB~w~NHmntCCgqg "Credential affinity is an association between a set of credentials and a device on your network.").
{#credentials-getting-started__ul_pqv_xls_h2b}  
Aliases for Orchestration enable workflow creators to:

* Assign individual credentials to any activity in an Orchestration workflow
* Assign individual credentials to any action in Flow Designer
* Assign different credentials to each occurrence of the same activity type in an Orchestration workflow.
* Assign different credentials to each occurrence of the same action in designer flow.
{#credentials-getting-started__ul_ft1_qxd_hbb}

## External credential stores

If you do not want credentials stored in your instance, you can use external credential
repositories. External credential stores save the credentials in an external site that your
instance can access. [CyberArk](https://www.servicenow.com/docs/ScmlHT4Ia_0wY5kmxjtI3Q "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.")
is the only supported external credential store. However, other external stores can be
configured using the ServiceNow API.

*[\>]: and then


