Discovery without storing a password: integrating the ServiceNow MID Server with CyberArk CCP (REST)

[Prashanth Pendo]

Discovery is only as good as its access. ServiceNow Discovery and Service Mapping have to authenticate to thousands of target servers, network gear, databases, and cloud accounts. That means credentials. And credentials are exactly what your security team loses sleep over.

The usual approach is to store those secrets, encrypted, on the platform and hand them to your MID Servers. It works. But for teams that have standardised on a privileged access vault, "keep a copy over here too" is a non-starter. Secrets belong in one place, rotated on one schedule, audited through one system.

That's what CyberArk's Central Credential Provider (CCP) gives ITOM. Instead of holding a password, the MID Server fetches each secret from CyberArk at the moment it's needed over HTTPS, authenticated with a client certificate and uses it to probe the target. Nothing sensitive is persisted in ServiceNow. Rotation happens in the vault, and Discovery just keeps working.

Two ways to resolve credentials

Worth knowing up front: this REST-based CCP integration is new. ServiceNow and CyberArk built it together, announced it in January 2026, and shipped it in response to direct customer demand, and it doesn't replace the older method. It joins it. You now have two supported ways to resolve CyberArk credentials from the MID Server, and you can pick whichever suits your environment:

• REST API (new): Retrieve credentials over CyberArk's REST APIs, a lighter path with fewer moving parts to install and maintain.
• AIM SDK (existing): Stay on the established SDK-based method if it's already serving you well in production.

Both cover the same ground, every credential resolution type, simple queries and complex ones alike, so the choice comes down to what fits your security architecture and how your team prefers to work. The rest of this post walks through the new REST approach.

How credential resolution actually works

When you enable external credential storage, the credential record in ServiceNow stops holding a secret. It becomes a pointer and it tells the MID Server which account to ask CyberArk for.

At Discovery time, the flow looks like this:

1. Discovery needs to authenticate to a target and requests the mapped credential.
2. The MID Server calls the CyberArk CCP web service (AIMWebService) over HTTPS, identifying itself with its application ID and a client certificate, and naming the safe and object to retrieve.
3. CCP confirms the request came from an allowed machine and that the client certificate matches the one registered on the application, then returns the secret.
4. The MID Server uses the secret to probe the target, and never writes it back to the instance.

Because the secret is fetched fresh every time, a rotation in CyberArk is picked up on the very next call. No re-keying in ServiceNow, and no stale password sitting in the ServiceNow instance.

Before you start

• A CyberArk CCP (AIMWebService) deployment your MID Servers can reach over HTTPS.
• The accounts you want Discovery to use, stored in a CyberArk safe, with the CCP application granted permission to retrieve them.
• A client certificate (PFX) for the MID Server plus its password, and the CCP portal's SSL certificate so the MID Server can trust the endpoint.
• A clear network path from each MID Server to the CCP endpoint.
• On the ServiceNow side: external credential storage enabled, and the CyberArk credential resolver JDK is ready to import.

Step 1: Set up the ServiceNow instance

Import the credential resolver. Import the CyberArk credential resolver into the instance once. It teaches the platform how to resolve external credentials from CyberArk, and it's a one-time activity and you don't repeat it for each MID Server.

Create the external credential record. Create a credential and mark it for external storage. Instead of typing a password, you point it at the vault:

Field	Value
External credential store	True
Credential ID	<safeName>:<CredentialID>
Credential storage vault	CyberArk CCP
Lookup key	Credential ID

The Credential ID (<safeName>:<CredentialID>) is the map to the vault, so the MID Server knows exactly which object to ask for.

 

Step 2: Configure the MID Server

Each MID Server that resolves credentials needs three things: the parameters that switch it into CyberArk mode, the client certificate it authenticates with, and trust for the CCP portal's certificate.

Add the parameters to config.xml, adjusting the values for your environment:

xml

<parameter name="ext.cred.use_cyberark" value="true"/>
<parameter name="ext.cred.safe_folder" value="Root"/>
<parameter name="ext.cred.cyberark.ccp_endpoint" value="https://cyberark-ccp.example.com/AIMWebService/api/Accounts"/>
<parameter name="ext.cred.cyberark.app_id" value="ServiceNow_MID_Server"/>
<parameter name="ext.cred.cyberark.cert_path" value="D:\certificate.example.com.pfx"/>
<parameter name="ext.cred.cyberark.cert_password" value="example-password"/>
<parameter name="ext.cred.cyberark.check_revocation" value="false"/> <!-- Optional -->

A quick tour of what these do: use_cyberark turns on CyberArk resolution for this MID Server; safe_folder is the folder within the safe where the account lives (often Root); ccp_endpoint is the AIMWebService URL the MID Server calls; app_id is the CyberArk application that you created (more details in Step 4); cert_path and cert_password point to the client certificate (PFX) used to authenticate; and check_revocation controls whether certificate revocation checking is performed.

Deploy the client certificate. Place certificate.example.com.pfx at the path you set in cert_path (here, D:\certificate.example.com.pfx). This is the certificate the MID Server presents to CCP.

Trust the CCP portal certificate. The MID Server runs on Java, so it has to trust the CCP portal's SSL certificate before it will complete the HTTPS handshake. Import that certificate into the MID Server's JRE truststore with keytool, run from the MID Server's \agent\jre\bin directory:

keytool -import -alias <cert alias> -file <cert location path> -keystore <mid jre/security/cacerts path>

This is the right way to establish trust; the handshake succeeds because the CCP certificate is in the truststore.

 

Step 3: Configure the CyberArk application

On the CyberArk side, CCP needs to know this MID Server is allowed to ask for secrets, and how to recognise it. Three things:

• Create the application in CyberArk CCP. This is the identity (app_id) the MID Server authenticates as, and it's what you grant retrieve permission on the safe.
• Add the MID Server's IP address to the allowed list, so CCP only answers requests from machines you trust.
• Register the client certificate's serial number on the application, so CCP can match the certificate the MID Server presents and confirm it's genuine.

Together, the allowed IP and the registered certificate serial are what let CCP authenticate the MID Server.

 

Step 4: Verify connectivity

Before you run Discovery, confirm the connectivity. From the MID Server host, open the CCP endpoint URL in a browser:

https://cyberark-ccp.example.com/AIMWebService/api/Accounts

You should reach the service and get a response, typically an error about required parameters, which is fine; it means the endpoint is live and trusted. A certificate warning tells you the portal certificate needs importing into the truststore. A connection error points at the network path or the endpoint URL.

Once the endpoint responds cleanly, run a quick Discovery or credential test against a known target. When it authenticates and no password ever touches the instance, you're done.

A few things that trip people up

• A TLS handshake failure almost always means the CCP portal certificate isn't in the MID Server's cacerts yet; re-run the keytool import from the correct jre/bin.
• A 403 from CCP usually means the request isn't recognised: check that the MID Server's IP is on the allowed list and the certificate serial is registered on the application.
• "Credential not found" points at the Credential ID mapping (<safeName>:<CredentialID>) or the safe_folder value.
• If nothing resolves at all, confirm the application actually has the retrieve permission on the safe.

Why it's worth the setup

Yes, this is a few more moving parts than typing a password into a credential record. But look at what you get. Your privileged secrets never leave CyberArk. Rotation is automatic; change it once in the vault, and every MID Server picks it up on the next call. Every retrieval is logged, where your security team already looks. And your Discovery data keeps flowing, current and complete, without anyone having to make a security exception.

That's the quiet goal of good ITOM: the platform does the heavy lifting so your people can trust it and get back to the work that actually needs them.

Further reading:

• the ServiceNow product documentation for configuring the MID Server for CyberArk CCP.
• ServiceNow and CyberArk: New REST API Integration for Enhanced Credential Management