Delinea Secret Server Hardening Guide

A Secret Server instance holds the passwords, keys and API credentials for the systems an organisation cares about most, so a weak configuration turns the vault into the single best target on the network. Delinea Secret Server ships with sensible defaults, but many of the controls that matter (unlimited vault access, API refresh tokens, application accounts, IP restrictions, syslog output) are left for the administrator to decide. This guide sets out a hardening baseline for Secret Server on-premises and Secret Server Cloud, including the Delinea Platform controls that sit in front of it, based on the vendor's public documentation. It is written for PAM engineers, identity architects and auditors who run or review a Secret Server estate. It does not cover Privilege Manager or Server PAM, and it does not recommend any product.

Key takeaways

Split the god-mode permissions. Unlimited Vault Access (UVA) and Administer Configuration Unlimited Vault Access should sit with a tiny, monitored group, never with day-to-day administrators.
Machine access is most of the attack surface. Application accounts, SDK clients and Platform service users read secrets without a human in the loop, so each needs its own identity, narrow folder permissions and an IP restriction.
Refresh tokens are a deliberate choice. Enable them only with a finite Maximum Token Refreshes Allowed and a short API session timeout; unlimited refreshes mean the setting should stay off.
Patch the web tier quickly. The April 2024 SOAP API authentication bypass showed that the API surface itself can be the vulnerability, and that audit review is part of remediation.
Get the audit trail out of the box. Syslog/CEF output over Secure TCP to a SIEM, plus workflow controls such as Require Comments and checkout, make privileged access attributable.

How identity and access work in Delinea Secret Server

Secret Server stores credentials as secrets, each built from a template and placed in a folder. Access is granted through folder and secret permissions (View, Edit, Owner and similar) to users and groups, while roles carry application-wide permissions such as Administer Users or Administer Configuration. Secret policies apply security settings (checkout, approval, comments, session recording) to whole folders, which is how most organisations enforce workflow at scale.

Who can reach the vault falls into four groups:

Interactive users: local Secret Server accounts, Active Directory synchronised accounts or SAML users from an identity provider. Second factors can come from SAML, email, TOTP, RADIUS or Duo.
Application accounts: non-interactive users created with the Application Account box ticked. Integrations such as Jenkins use them to call the API with a custom role and access only to the secrets they need.
SDK clients: applications onboarded through SDK Client Management. Each onboarding rule maps to an application user account and can carry IPv4 restrictions and a rule key.
Platform service users: when Secret Server runs behind the Delinea Platform, API clients obtain a token with the OAuth client credentials grant from the Platform identity endpoint (scope xpmheadless) and then call the Secret Server API with a bearer token. The vendor documents token lifetimes of up to roughly 3,600 seconds. Some components, such as the Session Connector, still use Secret Server application accounts against the native oauth2/token endpoint.

Deployment	Who hardens the host and database	Network restriction mechanism	Customer focus
Secret Server on-premises	Customer: IIS, Windows, SQL Server, encryption key storage	Per-user IP address restrictions in Secret Server, plus firewalls	Web tier, SQL rights, key protection, roles, API settings, patching
Secret Server Cloud (standalone)	Vendor	Per-user IP address restrictions	Roles, MFA, application accounts, Distributed Engine hosts, log export
Secret Server Cloud on the Delinea Platform	Vendor	Platform IP restrictions: WAF allowlist via support (up to 110 entries), Corporate IP Ranges, Authentication Rules; legacy Secret Server restrictions apply to vault calls only	Platform policies and service users as well as vault roles

See the Privileged Access Management Guide for the wider PAM model this sits in.

Admin roles and privileged access

Secret Server's role permissions are granular, which is useful only if the dangerous ones are tracked. The vendor's hardening guidance separates Administer Configuration Unlimited Vault Access from Unlimited Vault Access so that configuring UVA and using it are different duties. The permissions below deserve named owners and quarterly review.

Role permission	Why it is sensitive	Recommended holder
Unlimited Vault Access	Reads every secret regardless of folder permissions	Break-glass only, alerted on use
Administer Configuration Unlimited Vault Access	Controls who can turn UVA on	Different person from UVA holders
Administer Role Permissions / Administer Role Assignment	Can grant any other permission, including the two above	Small PAM platform team
Administer Configuration (Security)	Changes MFA, login and API settings	PAM platform team, change controlled
Administer Export	Exports secrets as clear-text CSV	Nobody by default; grant per task
Administer Scripts / Administer Distributed Engine Configuration	Code and engines that run with privileged credentials on targets	Platform engineers, peer reviewed
Rotate Encryption Keys / Administer Backup	Key material and full data copies	Named custodians
Administer Create Application Accounts	Creates non-interactive identities that bypass MFA	PAM platform team with a request process
Web Services Impersonate	Acts as other users through the API	Avoid; justify each grant
Bypass SAML Login / Bypass Direct API Authentication Restriction	Gets around SSO and the Prevent Direct API Authentication control	Break-glass account only

MFA for everyone: enable Auto-Enable Two Factor for New Users so new local and synchronised accounts get a second factor without manual steps, and prefer SAML to an identity provider with phishing-resistant authentication.
Break-glass account: keep one local administrator outside SSO for when the identity provider fails, store its credentials in a physical safe as the vendor advises, and alert on every login. See the Break-Glass Account Guide.
Workflow on the most sensitive secrets: use secret policies for Requires approval for access, Owners and approvers also require approval, multi-tier approval for domain and cloud root credentials, Require Comments (optionally tied to ticket system integration), Check Out for a fixed interval such as 30 minutes with Change Password on Check In, and Hide Launcher Password where users should launch sessions without seeing the password. Change Password on Check In needs remote password changing configured first.
Session recording: the vendor advises recording only critical, highly privileged secrets because recording is resource intensive, and reviewing who holds the administer session monitoring, view session monitoring and view session recording permissions. See the Privileged Session Management Guide.

Integrations, API tokens and service accounts

Integrations are where most of a Secret Server's credentials leave the vault. The BeyondTrust breach, where a stolen API key for a remote support SaaS product let an attacker reset local application passwords and reach US Treasury workstations, shows how much damage one privileged platform key can do. Treat every machine path into Secret Server the same way.

One application account per integration: create it with the Application Account option, give it a custom role carrying only the permissions it needs (the vendor's Jenkins example uses View Secret and View Launcher Password), and share only the specific secrets or folders. Never reuse a human administrator's account in a pipeline.
SDK onboarding rules: in SDK Client Management, give every rule an IPv4 restriction and require the rule key, so a leaked configuration cannot be onboarded from anywhere. Changing the reset token revokes and reinitialises clients, which is your kill switch after a suspected compromise. The SDK encrypts its configuration and, in the .NET Standard version, stores the key in the user's home directory by default; run SDK clients under dedicated service users so that directory is not shared.
Refresh tokens: Enable Web Services and Enable Refresh Tokens for Web Services are separate settings. Refresh tokens are single use and live for the API session timeout plus 15 minutes; set Maximum Token Refreshes Allowed to a finite number, because with unlimited refreshes a stolen token chain never ends.
Prevent direct API authentication: where users authenticate through SAML, block direct username and password authentication to the API, and keep the Bypass Direct API Authentication Restriction permission for the few accounts that genuinely need it.
Platform service users: scope their Secret Server permissions to the use case, store the client secret in a secrets store rather than in scripts, and refresh tokens on expiry instead of requesting long sessions. See the Machine-to-Machine OAuth (Client Credentials) Guide.
Per-user IP restrictions: assign IP ranges (CIDR is supported) to application accounts. A user with no restriction can log in from any address; 127.0.0.1 is always allowed. On the Delinea Platform, use Platform IP restrictions and Authentication Rules instead.
SOAP versus REST: prefer the REST API. SOAP works only from Windows PowerShell (not PowerShell 6 and later), and the 2024 authentication bypass affected SOAP endpoints only.

See the Service Account Security Guide for lifecycle controls that apply to these identities outside the vault.

Logging and detection

Secret Server records secret views, edits, checkouts, password changes and configuration changes in its audit tables. Those records only help if they leave the system and someone looks at them.

Syslog/CEF export: enable Syslog/CEF Log Output, set the server, port and protocol, and use Secure TCP (TLS) on port 6514 rather than UDP. Choose the Syslog/CEF Site so the right Distributed Engine or web node sends the events. Write Syslogs As Windows Events is available where Windows event forwarding is the collection path.
Platform events: when using the Delinea Platform, forward Platform authentication and policy events as well as vault events, because login and IP decisions happen there.
Alerts: Administer Event Subscriptions lets you raise notifications on specific events; subscribe owners to access of their most sensitive secrets.

Behaviour to detect	Signal in Secret Server data	ATT&CK technique
Bulk or unusual secret retrieval by an application account	Spike in secret view events from one account or a new source IP	T1078 Valid Accounts
Use of stolen API or refresh tokens	API calls from an IP outside the account's normal range, token refresh chains	T1550.001 Application Access Token
Credential guessing against the login page	Repeated failed logins and account lockouts	T1110 Brute Force
Permission or MFA changes	Role permission, role assignment and security configuration audit entries	T1556 Modify Authentication Process
Exploitation of the web or API tier	Unauthenticated SOAP or API activity, unexpected admin sessions after patch advisories	T1190 Exploit Public-Facing Application
Secrets copied out of the vault into files	Export events, launcher password views	T1552.001 Credentials In Files

Metrics that show the controls work:

Number of accounts holding Unlimited Vault Access or Administer Export (target: break-glass only).
Percentage of application accounts and SDK rules with an IP restriction (target: 100%).
Percentage of tier 0 secrets under a secret policy with checkout or approval.
Days from a Delinea security release note to production patch.
Percentage of interactive users with MFA enforced, and break-glass logins per quarter with a matching incident or test record.

See the SIEM Guide for building the detections downstream.

Hardening baseline

The vendor's Security Hardening Guide is the primary source for the settings below. Roll them out in phases so that integrations do not break unannounced.

Inventory first: export the list of roles and their permissions, application accounts, SDK onboarding rules, users with IP restrictions and current Configuration settings. This is your rollback reference.
Web tier (on-premises): force HTTPS, enable HSTS (the documented default max age is 31,540,000 seconds), disable weak ciphers and protocols, remove IIS headers that disclose versions, and make sure the application pool identity is not a local administrator.
Database (on-premises): give the Secret Server account db_owner on its own database only, remove dbcreator after installation, disable the sa login and use Windows authentication to SQL Server.
Encryption keys (on-premises): protect encryption.config with DPAPI or an HSM (EFS is an alternative), back it up to a controlled location, and plan encryption key rotation with the Rotate Encryption Keys permission held by named custodians. See the Secrets Management Guide.
Login settings: set Maximum Login Failures to 5 or fewer, turn off Allow Remember Me, turn off Allow Approval for Access from Email, enable Frame Blocking, turn off Allow HTTP Get and enable File Restrictions for attachments.
MFA and SSO: enable Auto-Enable Two Factor for New Users, move administrators to SAML with the identity provider's strongest factor, and block direct API authentication for SAML users.
Roles: separate UVA from UVA configuration, remove Administer Export and Web Services Impersonate from standing roles, and review role assignments.
Machine identities: convert shared accounts used by scripts into dedicated application accounts, add IP restrictions, require rule keys on SDK rules and set a finite Maximum Token Refreshes Allowed. Pilot on one integration, watch the audit log for failures for a week, then extend. Rollback is removing the IP restriction or reverting the setting recorded in step 1.
Workflow: apply secret policies with approval, comments and checkout to tier 0 folders first, then tier 1.
Logging and patching: enable secure syslog, confirm events arrive in the SIEM, and subscribe to Delinea release notes so security fixes are applied on a defined timescale.

Small versus large estates: a small team on Secret Server Cloud can skip the host, SQL and key steps (the vendor runs them) and should spend the effort on roles, MFA, application accounts and log export. A large on-premises estate with many Distributed Engines needs all ten steps, a change board for role permission changes and an owner per folder tree.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Roles, UVA split, application accounts	AC-2, AC-6	PR.AA-05	5.4, 6.8	A.8.2
MFA, login limits, break-glass	IA-2, AC-7	PR.AA-01	6.5	A.8.5
API tokens, rule keys, SDK secrets	IA-5	PR.AA-01	5.2	A.5.17
Encryption keys, HSM, TLS	SC-12, SC-8	PR.DS-01	3.10, 3.11	A.8.24
Syslog export and review	AU-2, AU-6, SI-4	PR.PS-04	8.2, 8.11	A.8.15, A.8.16

Common misconfigurations

UVA held by the admin group: one compromised administrator then reads every secret. Split the permissions and alert on UVA use.
Integration running as a person: a pipeline authenticating with an engineer's account inherits that person's access and breaks when they leave. Use an application account per integration.
Refresh tokens with no limit: enabling refresh tokens without a finite Maximum Token Refreshes Allowed gives a stolen token chain indefinite life.
Application accounts without IP restrictions: an account with no IP range can be used from any address, including an attacker's.
Slow patching of the API tier: the April 2024 SOAP authentication bypass (fixed on-premises in 11.7.000001, with cloud SOAP endpoints blocked on 13 April 2024) needed patching and an audit review for suspicious activity. Estates that patch quarterly carry such exposures for months.
Audit trail left inside the vault: with no syslog output, an attacker with administrative access can act without anyone outside Secret Server seeing it.

Practitioner checklist

List every holder of Unlimited Vault Access, Administer Export, Web Services Impersonate and the bypass permissions; reduce to break-glass only.
Confirm Auto-Enable Two Factor for New Users is on and administrators sign in through SAML.
Set Maximum Login Failures to 5 or fewer and turn off Allow Remember Me and Allow Approval for Access from Email.
Give each integration its own application account with a custom role, folder-scoped permissions and an IP restriction.
Require rule keys and IPv4 restrictions on every SDK onboarding rule and record how to change the reset token.
Set a finite Maximum Token Refreshes Allowed, or leave refresh tokens off.
Apply approval, Require Comments and checkout with password change on check-in to tier 0 folders.
On-premises: force HTTPS with HSTS, remove dbcreator, disable sa and protect encryption.config with DPAPI or an HSM.
Send Syslog/CEF over Secure TCP 6514 to the SIEM and test an alert for UVA use.
Track Delinea release notes and patch security fixes within a defined window.

Delinea Hardening Guide: Securing Secret Server and Platform Credentials