CyberArk SECRET-SEN key terms

Any machine or software entity that authenticates to systems, such as an application, service account, container, script, or automation job, as opposed to a human user logging in interactively.

The uncontrolled spread of credentials, API keys, and connection strings across source code, configuration files, wikis, and endpoint scripts, which multiplies exposure risk and makes rotation impractical.

A password, key, or token written directly into source code or a static configuration file, where it is copied into repositories, build artifacts, and backups that are hard to purge.

A stored secret that a program uses to prove its identity to a target system, typically delivered at runtime rather than embedded in the program's code or deployment package.

The CyberArk component that stores privileged credentials in a centralized digital vault, enforces access policy, and automates rotation, retrieval, and audit of those secrets.

The hardened repository that holds encrypted secret data and audit records; it is the trust anchor of the deployment and is reached through the Vault server service rather than direct database access.

The layered design in which clients talk to a Vault server, which mediates all access to encrypted storage, so no component exposes the underlying data store directly to consumers.

A client-side component or library that applications and tools use to fetch secrets from the Vault at runtime, often through a standardized interface, so credentials never sit in code or config.

The browser-based interface administrators and authorized users employ to manage safes, accounts, and policies, and to request, retrieve, and monitor privileged credentials.

A thick-client administrative tool for the Vault that supports tasks such as safe creation, file management, and log review, with access governed by Vault-level authorization.

A logical container inside the Vault that groups accounts and files and carries its own membership list and permissions, forming the primary unit of access control.

A user or group granted a defined set of permissions on a safe, such as retrieve, list, add, update, or approve, which together determine what actions that identity can perform there.

The Vault-wide set of settings that governs behavior across all safes, including password complexity, rotation intervals, dual control, and connection restrictions, unless a safe overrides them.

A policy requiring two authorized approvers to confirm an action such as retrieving a password or changing a safe's configuration, so no single person can act alone.

A person or account permitted to request and retrieve a specific privileged credential, typically after supplying a reason and, where required, obtaining approval.

The process of adding a privileged account to the Vault, including its target address, logon details, platform assignment, and safe placement, so it can be managed and rotated.

A reusable configuration object that tells the Vault how to connect to a target system and how to change, verify, and reconcile passwords for accounts of that system type.

The component that executes platform logic to automatically change and verify account passwords on target systems according to policy, without human involvement.

A rotation pattern using two paired accounts on a target system, where one is active while the other is being changed, so applications always have a working credential available.

The scheduled or on-demand replacement of a credential's value by the Vault, followed by verification that the new value works on the target system before it is relied upon.

The method by which a program proves its identity to the Vault before retrieving secrets, using mechanisms such as certificates, hashes, or trusted network paths.

A unique identifier assigned to a registered application in the Vault, used together with authentication data to authorize that program's secret retrieval requests.

A client library that plugs into an application's configuration or connection stack so the program can request credentials from the Vault at runtime instead of reading them from files.

Fetching secrets programmatically through a vendor-supplied software development kit, which handles authentication, request formatting, and error handling inside the application's own code.

A web service that authenticates requesting applications and returns the current credential value over a secured channel, letting many programs obtain secrets without direct Vault connectivity.

Supplying credentials to build and deployment jobs at execution time from the Vault, so pipeline definitions and artifacts never contain long-lived secrets.

Automated inspection of repositories, images, and file shares to detect exposed credentials, which are then reported, revoked, and replaced with vault-managed references.

The end-to-end workflow of finding exposed credentials, rotating or revoking them, removing them from source and history, and preventing recurrence through policy and automation.

The tamper-evident record of who accessed which secret, when, from where, and for what stated reason, retained in the Vault to support investigations and compliance reporting.

Recording and reviewing privileged sessions to target systems, providing evidence of what an authorized user actually did after retrieving a credential.

The practice of granting each identity only the specific safes, accounts, and actions it needs, reducing the blast radius if a credential or application is compromised.

Granting a credential or permission only for the window in which it is needed, then removing it, rather than leaving standing access in place indefinitely.

The initial credential an application needs in order to authenticate and retrieve its other secrets, which itself must be protected by a strong, non-static mechanism.

A short-lived secret issued on demand and automatically expired after use, limiting the value an attacker gains from capturing it.

A recorded relationship showing that one managed account's password is used by another system or service, so rotation order and coordination can be planned safely.

A privileged account the Vault uses to reset a managed account's password when the normal change process fails, restoring control without manual intervention.

The step after a password change in which the Vault logs on with the new value to confirm it works, flagging the account if the target rejects it.

The discipline of controlling, monitoring, and auditing elevated accounts and sessions across an environment, of which secrets management for applications is one part.