---
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


---

# Credential aliases for Discovery

# Credential aliases for Discovery {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read  
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.

Without credential aliases, Discovery schedules can access all credentials that are defined in
the instance. This behavior might not be desirable in some circumstances, particularly for
credentials with elevated privileges. Credential aliases provide more control over which
credentials a Discovery schedule is allowed to use and prevents the unnecessary exposure of
credentials with elevated privileges.

## How credential aliases work {#discovery-credential-alias__section_wf2_bms_w2c}

A business rule called **Insert Discovery Affinity \& Cred Aliases** (previously named **Insert Discovery Affinity**) runs when a record (a task for performing Discovery) is
inserted into the ECC Queue.

The business rule attaches the credential aliases defined in the Discovery schedule to the probe. When the probe reaches the MID Server to perform discovery, the MID Server uses these credentials to access the target device.  
The business rule can populate two parameters on the ECC Queue record:

* credential_tag: The list of sys_alias ID values defined in the Discovery schedule, which correspond to the Credential alias field on the credential records.
* credential_id: Populated when an affinity record exists for the target device.

Both parameters are optional, so a record can carry neither, one, or both.  
The MID Server then selects a credential in the following order:

1. The MID Server keeps only credentials that match the command type for the probe, such as SSH, Windows, or SNMP.
2. The MID Server filters the remaining credentials by tag. A credential stays eligible if it is linked to a tag value defined on the schedule, or if the record has no credential_tag parameter. Otherwise, the MID Server drops the credential.
3. The MID Server applies [affinity](https://www.servicenow.com/docs/JF7bdmTAB~w~NHmntCCgqg "Credential affinity is an association between a set of credentials and a device on your network."). If a credential's sys_id matches the credential_id value for the device, the MID Server moves that credential to the top of the list. The MID Server tries the remaining credentials in the sequence set by their Order value.
{#discovery-credential-alias__ol_mpx_nqx_fkc}

The MID Server iterates until it finds a credential that works.

If the business rule determines that an affinity exists for the device, the rule identifies the proper credential_id to use. This is the sys_id of the credential referenced by the affinity record in the
dscy_credentials_affinity table.

When the platform encounters an affinity with a credential alias value, the business rule checks whether the credential that the affinity references has the specified alias. If the credential has the alias, the business rule
selects the credential_id of the alias and passes that value to the MID Server.

If a credential alias is defined for a schedule and the schedule is configured to use that alias, the schedule ignores any previously existing credential-to-target affinity. This occurs only if the credential itself is not
associated with any other credential alias. If the credential does not have any credential alias, any other affinities that exist for the target system are checked. As a result, an affinity credential that does not have a tag
value on the schedule is dropped at the tag filter. The credential is not attempted, even if it authenticated in a previous scan. Adding or changing schedule tags can therefore change which credential the MID Server selects.

Credential tags scope to the Discovery schedule and its IP ranges, not to an individual target device.

## Create a Discovery credential alias {#ariaid-title2}

Create the alias and then add that alias to a credential in the credential record.
You can add a credential to multiple aliases and add multiple credentials to a single
alias.

### Before you begin

Role required: admin, credential_admin (read access only), connection_admin (read access only)

### About this task

A Discovery schedule only uses credentials that are contained in the aliases defined for that schedule.  
Note:  
If a credential alias is defined for a schedule, it will ignore any previously existing credential affinity between the credential and the target that is discovered in a schedule that is setup to use that credential alias.

### Procedure

1. Create an alias.
   1. Navigate to Connections \& CredentialsConnection \& Credential Aliases.
   2. Click New.
   3. Enter a unique name for the alias and select Credential for the alias Type.
   4. Click Submit.  
      The Credentials related list appears. You can add new credentials for this alias in this list but not existing credentials.
   {#create-discovery-credential-alias__substeps_lkx_w1c_j2b}
2. Configure a credential for the new alias.
   1. Navigate to Connections \& CredentialsCredentials.
   2. Select an existing credential from the list or click New to create a new credential.
   3. In the credential record, unlock the Credential alias field and select the alias you created.  
   4. Save or submit the record.
   {#create-discovery-credential-alias__substeps_mng_3bc_j2b}
3. Return to Connections \& CredentialsConnection \& Credential Aliases and open your new alias.  
   The credential you attached to the alias now appears in the related list.
4. To create an additional credential for this alias, click New in the related list and select a credential type.  
   The alias name is pre-populated in the Credential alias field of the credential record.
5. Complete the fields in the form and submit the record.

*[\>]: and then