Master Cybersecurity Skills. Build a Real Career.

CyberArk Credential Provider (CP) vs Central Credential Provider (CCP): Complete Guide to Installation, Architecture, Licensing, SDKs, ASCP & Best Practices (2026)

  • Home
  • Blog
  • CyberArk Credential Provider (CP) vs Central Credential Provider (CCP): Complete Guide to Installation, Architecture, Licensing, SDKs, ASCP & Best Practices (2026)
Image
  • July 01 2026

CyberArk Credential Provider (CP) vs Central Credential Provider (CCP): Complete Guide to Installation, Architecture, Licensing, SDKs, ASCP & Best Practices (2026)

CyberArk Credential Provider (CP) vs CCP Complete Guide 2026 | Installation, Architecture, SDKs & Best Practices

Learn CyberArk Credential Provider (CP), Central Credential Provider (CCP), ASCP, Application Password SDK, licensing, architecture, installation, password synchronization, best practices, system requirements and real-world implementation in this complete 2026 guide.


CyberArk Credential Provider (CP) vs Central Credential Provider (CCP): The Complete 2026 Guide

Modern enterprises no longer allow privileged passwords to remain hardcoded inside applications, configuration files, PowerShell scripts, shell scripts, scheduled tasks, or source code repositories. Hardcoded credentials are one of the biggest reasons organizations suffer credential theft, lateral movement, ransomware attacks, and insider threats.

CyberArk solves this challenge through Secrets Manager Credential Providers, allowing applications to retrieve credentials securely from the CyberArk Digital Vault without exposing passwords to developers or administrators.

Instead of storing credentials inside application code, applications request passwords dynamically whenever they need them. CyberArk validates the application identity, retrieves the latest password from the Vault, and securely returns it during runtime.

This approach provides:

✔ Eliminates hardcoded passwords

✔ Automatic password rotation

✔ Runtime credential retrieval

✔ Complete audit logging

✔ High availability

✔ Better application security

✔ Compliance with PCI-DSS, ISO 27001, SOX, HIPAA and GDPR

In this guide, you'll learn everything about Credential Provider (CP), Central Credential Provider (CCP), Application Server Credential Provider (ASCP), Application Password SDKs, licensing, installation, architecture, caching, password synchronization, compatibility, best practices, and real-world deployment.


What is CyberArk Credential Provider (CP)?

CyberArk Credential Provider (CP) is an agent installed directly on the application server where the application is running.

Instead of embedding passwords inside configuration files, the application simply requests the password from the local Credential Provider.

The Credential Provider securely communicates with the CyberArk Vault, retrieves the password, stores it inside a secure encrypted local cache, and returns it to the application.

Because the Credential Provider runs locally on the application server, password retrieval is extremely fast and continues working even if temporary network issues occur.

Credential Provider Highlights

■ Installed locally on every application server

■ Secure encrypted credential cache

■ Native SDK support

■ CLI support

■ High performance

■ High availability

■ Anti-tampering protection

■ Automatic synchronization with CyberArk Vault


Why Organizations Use Credential Provider

Traditional applications often contain credentials like this:

Database Username = Administrator

Password = Welcome@123

Anyone with access to the configuration file can immediately compromise the application.

Credential Provider completely removes this problem.

Instead of reading passwords from configuration files, applications request passwords securely during execution.

Example:

Application

↓

Credential Provider

↓

CyberArk Vault

↓

Password Returned Securely

No password is ever visible to developers or stored inside the application source code.


How Credential Provider Works

The Credential Provider follows a secure authentication process before providing any credentials.

Step 1

Application starts.

Step 2

Application requests a password using the SDK or CLI.

Step 3

Credential Provider validates:

Application Name

Operating System User

Machine Address

Executable Path

Hash Validation (where applicable)

Safe Permissions

Step 4

Credential Provider securely contacts the CyberArk Digital Vault.

Step 5

Password is retrieved.

Step 6

Password is securely cached.

Step 7

Password is returned to the application.

The entire process usually completes in milliseconds.


What is CyberArk Central Credential Provider (CCP)?

While Credential Provider works locally, Central Credential Provider (CCP) provides the same capability through a centralized web service.

Instead of installing Credential Provider on hundreds of servers, organizations deploy CCP on a dedicated Microsoft IIS server.

Applications communicate with CCP using secure REST API calls.

CCP retrieves passwords from the Vault and returns them securely.

This dramatically reduces deployment effort.

Central Credential Provider Features

■ IIS-based web service

■ REST API

■ Centralized deployment

■ Secure credential cache

■ Load balancing support

■ Multi-region deployment

■ Runtime password retrieval

■ Easy application integration


How Central Credential Provider Works

The communication flow is simple.

Application

↓

HTTPS REST API

↓

Central Credential Provider

↓

Credential Provider

↓

CyberArk Vault

↓

Credential Returned

Applications never directly communicate with the Vault.

Instead, CCP performs all secure communication.


Credential Provider vs Central Credential Provider

Feature Credential Provider Central Credential Provider
Installation Every application server Dedicated IIS Server
Performance Excellent Excellent
Local Cache Yes Yes
Network Dependency Minimal Requires CCP Availability
SDK Support Yes REST API
Deployment Distributed Centralized
Best For Mission Critical Applications Large Enterprise Environments
High Availability Local Cache Load Balanced CCP
Authentication Local Centralized

Which One Should You Choose?

CyberArk itself recommends selecting the solution based on application criticality.

Choose Credential Provider when

Mission Critical Applications

Financial Systems

Payment Platforms

Healthcare Applications

Applications requiring maximum availability

Low latency environments


Choose Central Credential Provider when

Hundreds of application servers

Cloud-native applications

Microservices

REST API integrations

Organizations avoiding local agent installation

Multi-region deployments


CyberArk Credential Provider Architecture

A standard deployment includes the following components:

                CyberArk Vault

                     │

          Central Policy Manager

                     │

        Password Vault Web Access

                     │

        ----------------------------

          Credential Provider

                 OR

     Central Credential Provider

                     │

            Application Server

                     │

          Database / Target System

Every password request is authenticated, audited, encrypted, and monitored.


Components Used by Credential Providers

1. CyberArk Digital Vault

The Digital Vault stores privileged credentials securely using military-grade encryption.

It acts as the trusted repository for all application secrets.

Every password request is audited and logged.

If you're new to the Vault architecture, read our detailed guide:

CyberArk Vault Server Components – Complete Guide


2. Password Vault Web Access (PVWA)

PVWA provides administrators with a web interface to manage Safes, onboard application accounts, configure authentication methods, and define application permissions.

Using PVWA, administrators can:

Create Applications

Assign Safe Permissions

Manage Accounts

Configure Platforms

Review Audit Logs

Generate Reports

Learn more here:

CyberArk PVWA Complete Guide


3. Central Policy Manager (CPM)

The CPM ensures passwords remain compliant with enterprise security policies by automatically changing, verifying, and reconciling passwords.

Whenever a password changes, the Credential Provider cache is synchronized automatically, ensuring applications always receive the latest credential without requiring code changes or downtime.

For a deep dive into CPM workflows, password rotation, and reconciliation, read:

CyberArk CPM Complete Guide


Application Password SDKs in CyberArk Credential Provider

One of the biggest strengths of CyberArk Credential Provider (CP) is its Application Password SDKs, which allow developers to retrieve credentials securely without exposing passwords in source code. Instead of hardcoding usernames and passwords, applications make a simple SDK or API call to fetch credentials dynamically from the CyberArk Vault.

The SDKs communicate with the locally installed Credential Provider, which authenticates the requesting application and returns the requested secret after validating access permissions.

Supported Application Password SDKs

■ C/C++ SDK
■ Java SDK (Java 8 and later LTS versions)
■ .NET Framework SDK (4.8 and later)
■ .NET Standard SDK (Windows & Linux)
■ Command Line Interface (CLI)

Because the SDK communicates with the local Credential Provider, applications never need to know where passwords are stored or how they are managed. This abstraction simplifies development while dramatically improving security.


Why Dynamic SDK Linking is Recommended

CyberArk recommends dynamic linking instead of static linking when integrating the Application Password SDKs.

When dynamic libraries are used, SDK upgrades can be performed without recompiling the application, making maintenance significantly easier and reducing downtime during version upgrades.

Benefits of Dynamic Linking

■ Easier SDK upgrades
■ No application recompilation
■ Reduced maintenance effort
■ Improved compatibility with future Credential Provider releases
■ Lower operational risk during upgrades


What is Application Server Credential Provider (ASCP)?

While the Credential Provider secures passwords used by custom applications, many enterprise applications store database credentials inside application server configuration files rather than source code.

CyberArk introduced the Application Server Credential Provider (ASCP) to solve this challenge.

ASCP integrates directly with enterprise application servers and automatically replaces hardcoded datasource credentials without requiring any application code modifications.

This means organizations can secure existing enterprise applications without involving development teams or changing application logic.


How ASCP Works

Traditionally, an application server stores database credentials in XML or datasource configuration files.

Example:

Datasource.xml

Username = AppUser

Password = Welcome123

ASCP intercepts the datasource request and replaces the password with the latest credential retrieved securely from the CyberArk Vault.

The application remains completely unaware of the change.

Application Server

↓

ASCP

↓

Credential Provider

↓

CyberArk Vault

↓

Database Connection Established

Benefits of Application Server Credential Provider

Key Advantages

■ No application code changes required
■ Eliminates hardcoded datasource passwords
■ Automatic password rotation support
■ Zero downtime during password updates
■ Secure database connectivity
■ Works with existing enterprise applications


Supported Application Servers

CyberArk ASCP supports most enterprise Java application servers used across banking, healthcare, telecom, manufacturing, and government organizations.

Supported Platforms

■ Apache Tomcat
■ IBM WebSphere Liberty
■ IBM WebSphere Classic
■ Oracle WebLogic
■ JBoss Enterprise Application Platform (EAP)
■ WildFly

ASCP supports popular databases such as Oracle, Microsoft SQL Server, IBM DB2, and PostgreSQL.


What is the z/OS Credential Provider?

Many financial institutions, insurance companies, and government organizations still run critical workloads on IBM z/OS mainframes.

To secure privileged credentials in these environments, CyberArk provides the z/OS Credential Provider.

Unlike the standard Credential Provider, the z/OS version retrieves passwords through a remote Central Credential Provider (CCP) deployed on Windows Server.

This architecture enables secure password retrieval while maintaining compatibility with mainframe applications.

z/OS Credential Provider Highlights

■ Supports IBM z/OS 2.5 and later
■ Java SDK integration
■ Remote password retrieval through CCP
■ Secure communication with CyberArk Vault
■ Supports Privilege Cloud integration


Password Change Process in CyberArk

One of the biggest advantages of CyberArk is automatic password lifecycle management.

Whenever passwords are changed, applications should continue functioning without interruption.

CyberArk achieves this through seamless synchronization between the Vault, CPM, and Credential Provider cache.


Three Password Management Methods

1. Manual Password Management

Administrators manually change passwords on the target system and then manually update the CyberArk Vault.

Suitable only for small environments where password rotation is infrequent.


2. Semi-Automatic Password Management

Administrators trigger password rotation manually from PVWA, but the Central Policy Manager (CPM) performs the actual password change automatically.

This approach reduces human error while allowing administrators to control the timing of password changes.


3. Fully Automatic Password Management

This is the recommended approach for enterprise deployments.

CPM automatically:

■ Generates random passwords
■ Changes passwords on target systems
■ Verifies successful password updates
■ Reconciles failed changes if required
■ Updates the CyberArk Vault
■ Synchronizes Credential Provider cache

Applications continue working without requiring any configuration updates.


Password Synchronization Workflow

The synchronization process ensures that applications always retrieve the latest credential.

CPM

↓

Changes Password

↓

Updates Vault

↓

Credential Provider Refreshes Cache

↓

Application Requests Password

↓

Latest Password Returned

This eliminates password mismatch issues that often occur with manually managed credentials.


Credential Provider Installation Overview

Installing the Credential Provider is straightforward when the CyberArk core components are already deployed.

The Provider is installed directly on the server hosting the application.

High-Level Installation Steps

Step 1
Verify Digital Vault connectivity.

Step 2
Install the Credential Provider package.

Step 3
Register the Provider with the Vault.

Step 4
Configure Vault parameters and Safe access.

Step 5
Define application authentication rules.

Step 6
Activate the application so credentials are cached.


Credential Provider Best Practices

A secure deployment requires more than simply installing the software.

CyberArk recommends several best practices that significantly improve security and operational resilience.

Recommended Best Practices

■ Use Privileged Session Manager (PSM) for administrative access to Credential Provider servers.

■ Protect CP servers with Endpoint Privilege Manager (EPM).

■ Never store passwords inside scripts or configuration files.

■ Use dynamic SDK libraries instead of static libraries.

■ Rotate application credentials automatically using CPM.

■ Restrict Safe permissions following the principle of least privilege.

■ Monitor Credential Provider logs regularly.

■ Enable auditing for all application password requests.

To understand secure privileged session monitoring in detail, read:

CyberArk Privileged Session Manager (PSM) – Complete Guide


Supported Operating Systems

CyberArk Credential Provider v14.2 supports a broad range of enterprise operating systems, making it suitable for heterogeneous environments.

 

Windows

Windows Server 2016, 2019, 2022, 2025

Windows 11 (Developer Endpoints)

Linux

RHEL 8/9/10

Oracle Linux 8/9

Ubuntu 22 LTS / 24 LTS

Rocky Linux 8/9/10

Debian 12

CentOS Stream 9/10

UNIX

AIX 7.2 / 7.3

Solaris SPARC 11.4

CyberArk Licensing for Credential Providers

Each installed Credential Provider consumes an AppProvider license. During installation, CyberArk automatically creates a Vault user (by default named Prov_) for that instance.

Administrators can review available and consumed licenses through the License Capacity Report in the PrivateArk Client.

Licensing Tips

■ One Credential Provider installation = One AppProvider license
■ Plan capacity before large-scale deployments
■ Monitor License Capacity Reports regularly
■ Ensure sufficient licenses before adding new application servers

CyberArk Central Credential Provider (CCP) System Requirements

Before deploying the Central Credential Provider (CCP), ensure that the server meets CyberArk's supported platform and software requirements. Since CCP is hosted on Microsoft IIS and serves credentials to multiple applications, it should be deployed on a dedicated, well-secured server with adequate resources.

Supported Windows Server Versions
 

■ Windows Server 2016

■ Windows Server 2019

■ Windows Server 2022

■ Windows Server 2025

 

IIS Prerequisites

The following IIS components must be installed before configuring CCP:

Required IIS Features
 

■ IIS 10 with Desktop Experience

■ ASP

■ ASP.NET 4.x

■ .NET Extensibility 4.x

■ ISAPI Extensions

■ ISAPI Filters

■ IIS 6 Management Compatibility

Minimum Hardware Requirements

Component Requirement
CPU 2 Cores
Memory 4 GB RAM
Disk Space 115 MB Installation + 400 MB Logs
.NET Framework 4.8 or Later

For production environments, allocating additional CPU and memory is recommended, especially when CCP serves multiple business-critical applications.


Credential Provider Compatibility Matrix

Maintaining version compatibility is essential for a stable CyberArk deployment. Running unsupported combinations of Vault, Credential Provider, or SDK versions may lead to authentication failures or unsupported configurations.

Component Supported Version
Credential Provider v14.2
Digital Vault 12.2 and Later
Central Credential Provider v14.2
Application Password SDK v12.x and Later
Privilege Cloud Supported

Best Practice: Always deploy the same major version of the Credential Provider and the Application Password SDK to avoid compatibility issues.


Central Credential Provider Authentication

CCP does not return credentials to every requester. Every application must be authenticated before a password is released.

CyberArk validates one or more application characteristics before granting access.

Common Authentication Methods
 

■ Application Name

■ Executable Path

■ Windows Domain User

■ Machine IP Address

■ Hostname

■ Operating System User

■ Safe Permissions

This layered authentication model ensures that even if someone knows the REST API endpoint, they cannot retrieve credentials unless the application matches the configured identity.


Real-World Use Cases of CyberArk Credential Provider

Credential Providers are used across nearly every industry where applications require privileged credentials.

1. Database Applications

Enterprise applications often require database credentials to connect to Oracle, Microsoft SQL Server, PostgreSQL, or IBM DB2. CP or CCP retrieves these credentials dynamically, eliminating hardcoded database passwords.


2. Banking Applications

Financial institutions use Credential Providers to secure credentials for payment gateways, core banking systems, ATM services, and SWIFT integrations. Automatic password rotation helps meet strict regulatory requirements.


3. DevOps and CI/CD Pipelines

Credential Providers integrate with automation tools to securely retrieve credentials during deployment, avoiding the need to store secrets in pipeline configuration files.


4. Middleware and Enterprise Applications

Organizations running WebLogic, Tomcat, JBoss, or WebSphere use ASCP to replace plaintext datasource passwords without modifying application code.


5. Scheduled Tasks and Windows Services

Legacy Windows Services and scheduled jobs often rely on service accounts. CyberArk ensures these credentials are securely managed and updated without manual intervention.


6. Cloud and Hybrid Environments

Organizations with hybrid infrastructures use CCP to provide centralized secret retrieval for applications running on-premises and in cloud environments, reducing deployment complexity.


CyberArk Credential Provider Troubleshooting

Even with proper implementation, administrators may encounter issues during installation or runtime. The following are common problems and their solutions.

Problem: Application cannot retrieve password.

Possible Cause: Application authentication mismatch or insufficient Safe permissions.

Recommended Action: Verify application definitions in PVWA and confirm Safe membership.

Problem: Password returned is outdated.

Possible Cause: Cache synchronization delay.

Recommended Action: Check CPM status and ensure synchronization completed successfully.

Problem: CCP REST API returns authentication errors.

Possible Cause: IIS configuration, SSL certificate issues, or application authentication failure.

Recommended Action: Validate IIS bindings, certificates, and application authentication settings.

Problem: Provider cannot connect to the Vault.

Possible Cause: Network connectivity or firewall restrictions.

Recommended Action: Verify connectivity, required ports, DNS resolution, and Vault service availability.

If you're looking to master CyberArk troubleshooting, including CP, CCP, Vault, CPM, PVWA, and PSM issues, explore our training:

CyberArk Errors & Troubleshooting – 100+ Video Course


Security Best Practices for Production Environments

Deploying Credential Providers securely is just as important as installing them.

Production Security Checklist
 

■ Install CP only on trusted application servers.

■ Restrict administrative access using Privileged Session Manager (PSM).

■ Protect servers with Endpoint Privilege Manager (EPM).

■ Enable automatic password rotation using CPM.

■ Apply the principle of least privilege for Safes and applications.

■ Regularly review audit logs and monitoring logs.

■ Keep Credential Provider, SDKs, and Vault versions aligned.

■ Use HTTPS with valid certificates for CCP communication.

■ Test password synchronization after every password rotation.

 


Frequently Asked Interview Questions

1. What is the difference between Credential Provider and Central Credential Provider?

Credential Provider is installed locally on each application server and offers high performance through a secure local cache. Central Credential Provider is hosted on an IIS server and provides centralized password retrieval over REST APIs, reducing deployment effort.


2. Does Credential Provider store passwords?

No. It maintains an encrypted secure cache containing only the credentials required by authorized applications. The CyberArk Digital Vault remains the authoritative source of secrets.


3. Can CCP be load balanced?

Yes. CCP supports load-balanced deployments, making it suitable for high-availability and multi-region environments.


4. Which CyberArk component rotates application passwords?

The Central Policy Manager (CPM) automatically changes, verifies, reconciles, and synchronizes passwords according to organizational policies.


5. What is ASCP?

Application Server Credential Provider (ASCP) secures datasource credentials used by application servers such as WebLogic, WebSphere, Tomcat, and JBoss without requiring application code changes.


6. Is Credential Provider supported on Linux?

Yes. CyberArk supports several Linux distributions, including RHEL, Ubuntu, Oracle Linux, Rocky Linux, Debian, and CentOS Stream.


7. Does Credential Provider support IPv6?

No. As of the current supported versions, Credential Provider and Central Credential Provider support IPv4 only.


Related CyberArk Articles

Expand your CyberArk knowledge with these in-depth guides from SecApps Learning:

 


Learn CyberArk Credential Provider & CCP from Industry Experts

Want hands-on experience with installing, configuring, administering, and troubleshooting CyberArk Credential Provider and Central Credential Provider?

Our instructor-led course covers:

 

✔ Credential Provider Installation

✔ CCP Installation on IIS

✔ Safe & Application Configuration

✔ Application Authentication

✔ SDK Integration

✔ ASCP Configuration

✔ Password Rotation & Synchronization

✔ High Availability & Load Balancing

✔ Real-world Labs & Troubleshooting

👉 Enroll Now:
CyberArk Credential Provider (CP) & Central Credential Provider (CCP) Installation and Administration Course


Conclusion

CyberArk Credential Provider (CP) and Central Credential Provider (CCP) are foundational components of the CyberArk Secrets Manager ecosystem. By eliminating hardcoded credentials, enabling secure runtime password retrieval, and integrating with the Digital Vault and CPM, they help organizations strengthen application security while maintaining operational efficiency.

For applications that demand the highest levels of performance and resilience, Credential Provider offers local caching and minimal latency. For organizations seeking simplified deployment across large or distributed environments, Central Credential Provider provides centralized, scalable secret retrieval through secure REST APIs.

When combined with CPM for automated password rotation, PVWA for administration, and PSM for privileged session protection, Credential Providers become an integral part of a mature Privileged Access Management (PAM) strategy.

By following the best practices, compatibility guidelines, and deployment recommendations covered in this guide, organizations can confidently secure application credentials, improve compliance, and reduce the risk of credential exposure across on-premises, cloud, and hybrid environments.

Comments ()

Leave a reply

Your email address will not be published. Required fields are marked*

Recent Post

Copyright 2022 SecApps Learning. All Right Reserved