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.
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.
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
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.
The Credential Provider follows a secure authentication process before providing any credentials.
Application starts.
↓
Application requests a password using the SDK or CLI.
↓
Credential Provider validates:
Application Name
Operating System User
Machine Address
Executable Path
Hash Validation (where applicable)
Safe Permissions
↓
Credential Provider securely contacts the CyberArk Digital Vault.
↓
Password is retrieved.
↓
Password is securely cached.
↓
Password is returned to the application.
The entire process usually completes in milliseconds.
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
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.
| 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 |
CyberArk itself recommends selecting the solution based on application criticality.
Mission Critical Applications
Financial Systems
Payment Platforms
Healthcare Applications
Applications requiring maximum availability
Low latency environments
Hundreds of application servers
Cloud-native applications
Microservices
REST API integrations
Organizations avoiding local agent installation
Multi-region deployments
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.
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:
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:
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.
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
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.
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
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
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.
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
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.
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.
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.
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.
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.
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
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
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
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
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
| 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.
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.
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.
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.
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
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.
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.
Expand your CyberArk knowledge with these in-depth guides from SecApps Learning:
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
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.
Your email address will not be published. Required fields are marked*
Copyright 2022 SecApps Learning. All Right Reserved
Comments ()