> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/pam/get-started/what-is-datadike-pam.md).

# What is DataDike PAM

What DataDike PAM does and the problem it solves: it holds the credentials of privileged accounts, hands them out without showing them, brokers the sessions that use them, and records each one.

DataDike PAM is a privileged access management solution. It holds the credentials of the privileged accounts on your infrastructure, gives authorized people the use of those credentials without showing them, brokers the sessions they open, and keeps a record of what happened in each one.

The model is one mediated point. The user authenticates to the solution as themselves; the solution authenticates to the target with the stored credential; the traffic passes through the solution, so it can be restricted while it runs and replayed afterwards. The user needs no route to the target and never learns its password.

If the vocabulary is new — asset, account, platform, authorization — read [Core concepts](/pam/get-started/core-concepts.md) first. That page describes the objects; this one describes the product.

## The problem it solves

Privileged credentials spread. The `root` password is shared between administrators, a service account password is pasted into a script, a database password sits in a configuration file, and operators reach targets directly from their workstations. That pattern has four costs:

* **No attribution.** Several people know the same password, so an action on the target cannot be tied to a person.
* **No evidence.** Nothing records what was typed or seen, so an incident cannot be reconstructed.
* **No revocation.** Withdrawing one person's access means changing a password on every target that person knew.
* **Exposure.** The target must be reachable from the operator's workstation, which means the network has to permit it.

DataDike PAM removes the shared secret from circulation. The credential stays in the vault, the person authenticates as themselves, and every access travels through a route that is authorized, filtered, and recorded.

## How an access happens

1. **The user authenticates to the solution**, with multi-factor authentication when the [login policy](/pam/administration/access/login-policies.md) requires it. Login can also be restricted by source IP and by time of day.
2. **Authorizations decide what they see.** A user with no [authorization](/pam/administration/access/authorizations.md) sees no assets, whatever else they may hold. Access can be standing, or requested on demand as [just-in-time access](/pam/administration/access/just-in-time.md).
3. **Approval, when the rule requires it.** A request waits for the approvers named on the rule; two or more approvers gives dual custody.
4. **The credential is retrieved from the vault** and injected into the target's login by the solution. The password is not shown to the person asking for the access, and where policy does allow it to be revealed, the user must re-authenticate first.
5. **The session is opened through the solution** — directly, through a jump host, or over a reverse path from a network that accepts no inbound connections.
6. **The session is watched while it runs.** Commands are captured and classified, [command filters](/pam/administration/access/command-filtering.md) alert on or block what they match, an auditor can watch and terminate a live session, and behaviour analytics scores the access for anomalies.
7. **When the session ends**, temporary grants are revoked automatically, and revoking a grant terminates the sessions running under it.
8. **The record remains.** The session entry, its replay, the commands typed, and the files transferred stay in the [audit trail](/pam/administration/audit/audit-trail.md) for the configured retention period.

## What it manages

| Category               | What it covers                                                                                    |
| ---------------------- | ------------------------------------------------------------------------------------------------- |
| Servers                | Windows Server (2003 to 2025) and Windows desktops, Linux distributions, Unix and AIX (5L to 7.3) |
| Databases              | Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, Redis, ClickHouse, DB2, Dameng           |
| Network devices        | Switches, routers, firewalls and out-of-band consoles, over SSH and Telnet                        |
| Container platforms    | Kubernetes clusters                                                                               |
| Web and cloud          | Web applications, and the consoles of Azure, AWS and GCP                                          |
| Published applications | RemoteApp on Windows and virtual applications on Linux, without publishing a whole desktop        |

Sessions run either in the browser — web terminal, remote desktop, database client, file explorer — or through the user's own client, such as PuTTY, `mstsc.exe`, or DBeaver. The solution is the proxy in both cases, and both are recorded. See [Connection methods](/pam/administration/sessions/connection-methods.md).

## How credentials are handled

The vault is the centre of the product. Secrets are stored in the solution's own encrypted vault, or the storage is delegated to a corporate vault you already run — HashiCorp Vault, Azure Key Vault, or AWS Secrets Manager. See [The credential vault](/pam/administration/accounts/vault.md).

Around it:

* **Discovery** finds assets on the network and in cloud accounts, and collects the accounts that already exist on them, so that an account nobody registered stops being invisible.
* **Rotation** changes passwords on a schedule, after use, or on expiry, across servers, databases, web applications, network devices and mainframe, over SSH, WinRM, RPC or REST. See [Rotate credentials](/pam/administration/accounts/rotation.md).
* **Reconciliation** detects that the solution has lost control of a password and changes it using another credential to take control back.
* **Application-to-application access** serves secrets to scripts, scanners and pipelines through an API, so credentials stop being embedded in source code and configuration files.

{% hint style="info" %}
**Key custody.** The vault's encryption key stays under the customer's exclusive control. When an external HSM or KMS is used over PKCS#11, the master key never leaves the customer's cryptographic device. Neither DataDike nor the partner performing the deployment has access to the vault key, and the product carries no backdoor for it.
{% endhint %}

{% hint style="warning" %}
Recovery of the backup encryption key can be split across several administrators, so that a predefined number of them must be present to reassemble it. This is deliberate: the point is that the vault key is never in one person's possession.
{% endhint %}

## Agentless, with two exceptions

Nothing has to be installed on a managed target. Account collection, password changes and session brokering all run over protocols the target already exposes — SSH, WinRM, RDP, the database protocols — so onboarding a device does not mean a software rollout.

Two optional agents exist, and knowing why keeps the claim honest:

| Agent                  | Why it exists                                                                                                                                                                          |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows endpoint agent | Collects asset information, runs local tasks, and integrates with Windows account management on servers where that is wanted                                                           |
| Connector              | Installed on an isolated machine that has no jump host in front of it, so the machine can publish itself over a reverse path. See [Broker](/pam/administration/connectivity/broker.md) |

Neither is required to manage an asset.

## Where it runs

* As an appliance in your own data centre, or as a service hosted by DataDike.
* On a single node, or as a high-availability cluster of several nodes behind one virtual address, with the database, cache and shared storage replicated between them.
* The access components are independent per protocol, so they can be scaled and upgraded one at a time without stopping the product.
* The console is reached over HTTPS from Firefox, Chrome, Edge, Opera or Safari. The interface is available in Portuguese, English, Spanish and French.

See [Architecture and components](/pam/get-started/architecture.md) for what those pieces are and how a session travels between them.

## Related pages

* [Core concepts](/pam/get-started/core-concepts.md) — the objects and the vocabulary
* [Architecture and components](/pam/get-started/architecture.md) — the software that runs the product
* [A tour of the console](/pam/get-started/console-tour.md) — where everything lives
* [Onboard your first managed asset](/pam/get-started/first-managed-asset.md) — the whole model in one exercise