One of the most common misconceptions about Privileged Access Management is that all secrets are simply stored in a database.
In reality, IBM Security Verify Privilege (ISVP), powered by Secret Server, uses a layered encryption architecture designed to protect sensitive information even if an attacker gains access to the SQL Server database.
However, many administrators are unaware that the platform can add another layer of protection to its encryption key by leveraging the Windows Data Protection API (DPAPI).
With a single administrative action, organizations can significantly strengthen the protection of the platform's encryption key but this feature also introduces important operational considerations that every administrator should understand.
Layered Encryption by Design
IBM Security Verify Privilege stores secrets in SQL Server in encrypted form rather than as plaintext.
According to the product architecture, Secret Server uses a layered encryption model.
Each Secret is encrypted using its own AES-256 encryption key, while those per-secret keys are themselves protected by a Master Encryption Key (MEK) stored in the encryption.config file. This layered approach means that access to the database alone is not sufficient to recover plaintext secrets.
What Does DPAPI Protect?
DPAPI does not encrypt the entire database.
Instead, it protects the Master Encryption Key stored in the encryption.config file.
Normally, Secret Server reads this key to encrypt and decrypt the per-secret encryption keys used to protect secret values.
When DPAPI protection is enabled, Windows encrypts the encryption.config file using the local machine's Data Protection API.
As a result, even if someone copies the encryption.config file from the server, it cannot simply be used on another Windows machine because the file is protected using the original server's machine-specific DPAPI keys.
Enabling DPAPI Is Simple
One of the advantages of this feature is how easy it is to enable.
Administrators can enable DPAPI directly from the Secret Server interface by navigating to:
Admin
└── Configuration
└── Security
└── Encrypt Key Using DPAPI
After confirmation, Secret Server protects the encryption key using Windows DPAPI.
Likewise, if necessary, the protection can later be removed through the same interface.
Why Enable DPAPI?
DPAPI provides an additional defense-in-depth layer.
Without DPAPI, possession of both:
is sufficient to rebuild the environment and decrypt the stored secrets.
When DPAPI protection is enabled, the encryption.config file becomes tied to the Windows machine on which it was encrypted.
This means that copying the database together with the DPAPI-protected key file to another server is not enough to access the stored secrets. The target server would not possess the Windows DPAPI machine keys required to decrypt the encryption key.
Important Considerations Before Enabling DPAPI
Although enabling DPAPI is straightforward, administrators should understand the operational implications before clicking the button.
The most important recommendation from Delinea is:
Back up your encryption key before enabling DPAPI.
The documentation explicitly recommends backing up the original encryption.config file before protecting it with DPAPI because a DPAPI-encrypted file can only be used on the server where it was encrypted. This backup becomes critical for disaster recovery scenarios.
Disaster Recovery Planning
Disaster Recovery planning becomes even more important when DPAPI is enabled.
At a minimum, organizations should ensure they have protected backups of:
-
SQL Server database
-
encryption.config
-
database.config
These configuration files should be stored securely because they are required during recovery procedures.
The documentation also recommends protecting the original, unencrypted encryption.config in a secure offline location before applying DPAPI protection, specifically to support disaster recovery if the original web server cannot be recovered.
Upgrades and Server Migration
DPAPI also affects operational activities such as upgrades and server migrations.
For clustered deployments, Delinea recommends:
-
backing up the encryption key before enabling DPAPI,
-
enabling DPAPI individually on each web server,
-
and during upgrades, copying application files while preserving the existing database.config and encryption.config files on secondary nodes to avoid removing DPAPI protection.
Similarly, administrators planning to rebuild or migrate a Secret Server installation should understand how DPAPI protection impacts recovery planning before beginning the migration.
Clustering Considerations
DPAPI can be used in clustered Secret Server environments.
However, because DPAPI protection is machine-specific, each web server participating in the cluster must protect its own local copy of the encryption key after the unencrypted key has first been distributed to every node.
This is an important deployment step and should be considered when adding additional web servers to an existing cluster.
DPAPI or HSM?
DPAPI is one option for protecting the Master Encryption Key.
For production environments with the highest security requirements, Delinea recommends protecting the encryption key with a supported Hardware Security Module (HSM).
HSM-based protection provides stronger protection than machine-based DPAPI and is the recommended approach for organizations with strict regulatory or security requirements. DPAPI remains a practical defense-in-depth option when HSM deployment is not appropriate.
Defense in Depth
One of the strengths of IBM Security Verify Privilege is that security does not rely on a single protective mechanism.
Instead, multiple layers work together:
-
Encrypted SQL database
-
Per-secret AES encryption
-
Master Encryption Key
-
Optional DPAPI protection
-
Optional HSM integration
-
NTFS permissions
-
IIS and operating system security controls
This layered architecture significantly increases the effort required to compromise privileged credentials.
Conclusion
IBM Security Verify Privilege already employs a robust layered encryption model to protect privileged credentials.
By enabling DPAPI, organizations can add another layer of protection around the platform's Master Encryption Key with only a few clicks through the administration interface.
However, stronger protection also requires careful operational planning.
Before enabling DPAPI, administrators should ensure that the required configuration files are securely backed up and that disaster recovery, clustering, upgrades, and migration procedures take DPAPI protection into account.
When implemented correctly, DPAPI provides an effective defense-in-depth enhancement that strengthens the protection of one of the most critical components of the Secret Server architecture the encryption key itself.