Delinea
D Secret Server Cloud and Delinea Platform API
Workloads reach Secret Server Cloud with a static secret: a Platform service user's password used as an OAuth client secret, an application account password, or an SDK onboarding key. Access tokens last an hour, but no OIDC, cloud identity or token exchange exists. Machine accounts are least-privilege, API-managed and show last login, but never expire and are not GitHub partner-revoked. Outbound, every cloud integration wants a pasted access key, JSON key or client secret.
Docs: docs.delinea.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound C
How a workload running anywhere authenticates to this product.
Delinea Platform service user (client_credentials grant, the service user's password is the client_secret) or a Secret Server application account (password grant on /oauth2/token), each returning a bearer token valid for up to an hour. The SDK for DevOps (tss) onboards with a rule name plus a static onboarding key and optional IP allowlist, then caches client credentials on disk.
- docs.delinea.com checked 2026-10-22
“Service users are specifically designed for non-interactive, programmatic access to the platform.”
- docs.delinea.com checked 2026-10-22
“Integrations use the service user's password as the OAuth 2.0 client_secret when requesting an access token with the client_credentials grant type.”
- docs.delinea.com checked 2026-10-22
“API authentication: MFA does not apply. Integrations authenticate with the service user's password only.”
- docs.delinea.com checked 2026-10-22
“A Client Credentials - Platform service account credential (client ID and secret)”
- docs.delinea.com checked 2026-10-22
“The access token is valid for a specific period up to 3600 seconds.”
- docs.delinea.com checked 2026-10-22
“Some Secret Server features, such as Session Connector, authenticate directly to Secret Server's oauth2/token endpoint using SS-native Application Accounts rather than Platform Service Users.”
- docs.delinea.com checked 2026-10-22
“Secret Server has user and application accounts. Both types of accounts can access Secret Server via the REST API.”
- docs.delinea.com checked 2026-10-22
“Clients must provide a generated additional key string when authenticating.”
- docs.delinea.com checked 2026-10-22
“Secret Server will only allow clients to use this rule if they connect from a valid IP address.”
- docs.delinea.com checked 2026-10-22
“Entra ID authentication is not supported”
- docs.delinea.com checked 2026-10-22
“IWA is only available for Secret Server On-Premises.”
- docs.delinea.com checked 2026-10-22
“Application accounts (exempted by design)”
- docs.delinea.com checked 2026-10-22
“Because client credentials are static and must be handled by your automation, prefer the federated cloud authentication methods (AWS IAM, Azure MSI, GCP service accounts) when the workload runs in a cloud provider.”
Graded on Secret Server Cloud as reached through the Delinea Platform. Every documented machine path starts from a long-lived secret: the Platform service user's password (sent as client_secret; MFA does not apply to API auth), a Secret Server application account password (password grant; application accounts are exempt from "Prevent Direct API Authentication"), or the SDK's onboarding key, which with an optional CIDR allowlist mints client credentials that tss stores on disk (DPAPI on Windows, a customer-supplied certificate on Linux, otherwise unencrypted). The resulting tokens are short-lived (up to 3600 s; refresh tokens bounded by the API session timeout), hence C. No OIDC, JWT bearer, GitHub Actions, cloud workload identity or token-exchange path exists for workloads on Secret Server Cloud or the Platform API; Platform "federation" (Entra, Okta, Ping, ADFS and others) and Secret Server OpenID Connect are human sign-in, the scripting guide states Entra ID authentication is not supported for scripts, and Integrated Windows Authentication is on-premises only. Sibling: DevOps Secrets Vault (DSV) does accept AWS IAM, Azure managed identity and GCP service-account identity for workloads (its "OIDC" provider is human login via Thycotic One), but DSV is a separate product and does not lift this grade. Moves to B or A only if the Platform or Secret Server accepts a federated workload token.
Outbound D
How this product reaches into your cloud, repos, or other SaaS.
External vault links (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, DSV sync), customer-managed encryption keys (AWS KMS, Azure Managed HSM) and discovery (AWS, GCP, Entra ID) all authenticate with a static credential stored as a secret: an IAM user access key, a GCP service-account JSON key, an Entra app client secret, or a Vault token or AppRole SecretID. Minimum permissions are documented and Secret Server can rotate several of these keys itself.
- docs.delinea.com checked 2026-10-22
“AWS only allows programmatic integration through access keys.”
- docs.delinea.com checked 2026-10-22
“The account used to do this requires the following AWS IAM permissions to discover users and access keys:”
- docs.delinea.com checked 2026-10-22
“Fill in the text boxes with asterisks for the username, access key, and secret access key using the recorded values from the last step.”
- docs.delinea.com checked 2026-10-22
“The included, default SecretsManagerReadWrite policy in the Attach Permissions Policies table should suffice.”
- docs.delinea.com checked 2026-10-22
“Be sure to save both the access key ID and the secret access key!”
- docs.delinea.com checked 2026-10-22
“Secret Server authenticates using a JSON service account key.”
- docs.delinea.com checked 2026-10-22
“Two permission approaches are supported: predefined IAM roles (recommended) or a custom set of minimum permissions.”
- docs.delinea.com checked 2026-10-22
“Click the Create button. This creates and downloads a JSON private key file.”
- docs.delinea.com checked 2026-10-22
“Client Secret: Type in the Client Secret (Value) for the Azure AD Application.”
- docs.delinea.com checked 2026-10-22
“The App Registration / Service Principal used by the credential secret requires the following minimum Azure Key Vault data plane permissions for secret management operations:”
- docs.delinea.com checked 2026-10-22
“Type in your Azure Managed HSM Principal Secret (the secret value of the client secret).”
- docs.delinea.com checked 2026-10-22
“The minimum required Microsoft Graph application permissions for discovery are:”
- docs.delinea.com checked 2026-10-22
“Secret Server provides two HashiCorp Vault credential templates—pick the one that matches the auth method created in Vault.”
- docs.delinea.com checked 2026-10-22
“Secret Server can push its secrets to DevOps Secrets Vault by creating a secret based on the "DevOps Secret Vault Client Credentials" template, which holds the client credentials for a DevOps Secrets Vault tenant.”
- docs.delinea.com checked 2026-10-22
“With Remote Password Changing (RPC), secrets can automatically change remote account passwords when a secret expires, either immediately or on a defined schedule.”
- docs.delinea.com checked 2026-10-22
“This template rotates the client secret of an App Registration through the Microsoft Graph API, authenticating as a privileged “rotator” App Registration.”
Checked: external vault links to AWS Secrets Manager (IAM user access key), Azure Key Vault (Entra app client secret), Google Cloud Secret Manager (service-account JSON key), HashiCorp Vault (token or AppRole RoleId/SecretId) and DSV (DSV client credentials); Secret Server Cloud customer-managed keys in AWS KMS (IAM access key) and Azure Managed HSM (app client secret); discovery of AWS IAM/EC2 (access key), GCP (JSON key) and Entra ID (app client secret). None offers an IAM role with external ID, GCP impersonation or workload identity federation, or an Azure federated credential, and the AWS discovery page says access keys are the only option. D rather than F because each integration documents minimum permissions (IAM actions, GCP custom role, Key Vault data-plane rights, Graph application permissions; the AWS Secrets Manager walk-through does default to the broad SecretsManagerReadWrite managed policy) and Secret Server's own remote password changing can rotate AWS IAM keys, GCP service-account keys and Entra app client secrets it holds. Distributed engines run in your network but the docs give them no ambient-identity option for these integrations. Delinea Platform's separate cloud entitlement products were not graded here.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | Fails. Secret Server application accounts never expire. Platform identity policies have a "Maximum password age" (default 365 days) and an optional account expiration date, but 0 disables the age, any account can be flagged "Password never expires" over the policy, and expiry is described as a prompt to change the password at sign-in; the docs do not say an aged password stops client_credentials API auth. A changeable default is not an enforced expiry (same call as elastic-cloud-api). The SDK client's roughly 90-day key rotation is its local config-encryption key, not the onboarding key or account credential.
|
| ✓ Rotation via API | The Secret Server REST API (published 11.4 guide) creates users with isApplicationAccount, resets passwords, deletes users, creates and deletes SDK client rules, reads onboarding keys and revokes SDK client accounts; /v1/oauth-expiration expires issued tokens. Platform service users are created in the UI per the docs; the Platform Identity API reference is a JS-rendered page and its user-management calls were not verified.
|
| ✓ Scoped keys | Service users and application accounts are purpose-built machine principals with their own roles and per-secret/folder permissions; SDK clients inherit the application account bound to their rule. Service users can sign in to the Platform UI by default unless an identity policy disables interactive login.
|
| ✓ Last-used visible | The credential is the account's password, so the account's last login (Platform user page, Secret Server User lastLogin field) plus the SDK client audit tab serve to find dead machine credentials, the same reading as snowflake's login history. The docs do not state explicitly that client_credentials token issuance updates "last login"; a reviewer may want to confirm.
|
| ✗ Leak revocation | Neither Delinea nor Thycotic appears in GitHub's supported secret scanning patterns table, so a leaked service user password, application account password or SDK onboarding key is not reported to Delinea. These credentials are free-form passwords and base64 keys with no recognizable prefix.
|
Notes
One card for Secret Server Cloud and the Delinea Platform API it is fronted by (Platform service users auto-create a matching Secret Server application account). Self-hosted Secret Server adds Integrated Windows Authentication, which is Windows-domain Kerberos rather than federation and is not available in the cloud. DevOps Secrets Vault is a separate Delinea product with cloud-identity workload auth (AWS IAM, Azure MSI, GCP) and would merit its own card. Three of five hygiene checks pass; an enforced maximum lifetime on service-user secrets and GitHub partner revocation would add the rest. Inbound moves to B or A only if workloads can present a federated token (GitHub Actions OIDC, cloud workload identity, or a bring-your-own issuer); outbound moves up with an IAM role, GCP impersonation or Azure federated credential option on any integration.
Badge
[](https://wif.tax/p/delinea-secret-server/)