Privileged access management and secrets management both store credentials in a vault, so organisations often buy one and expect it to cover the other, and the gap that results is almost always a machine credential nobody controls. PAM is built around a person opening a privileged session: request, approve, broker, record, revoke. A secrets manager is built around code retrieving a credential through an API: authenticate the workload, check policy, issue or return the secret, log it. This guide sets out a reference architecture that uses both, shows where each leaves non-human identities (NHIs) uncovered, and gives a clear ownership model for the parts they share: vaulting, rotation and discovery. It is for identity, platform and security architects who run, or are about to buy, one or both. The wider split between PAM, IGA and NHI management is in PAM vs IGA vs NHI Management; this page goes deeper on the PAM and secrets manager boundary.
Key takeaways
- Split by the consumer of the credential. If a person uses the access interactively, PAM brokers it. If code, a pipeline or an agent uses it, a secrets manager issues it. Sensitivity alone does not decide the tool.
- The control is different, not just the vault. PAM's value is approval, session isolation and recording; a secrets manager's value is workload authentication, fine-grained policy, short leases and API-speed retrieval.
- Each has an NHI blind spot. PAM sees the service accounts someone onboarded; a secrets manager sees only secrets stored in it. Neither discovers keys in code, CI variables or SaaS integrations by itself.
- One credential, one system of record. When both tools rotate the same password, applications break or someone disables rotation. Decide which system owns each credential class and integrate the other.
- Both vaults are tier 0. The PAM system and the secrets manager each hold the keys to everything they manage, so their own admin access, bootstrap credentials and break-glass paths need the strictest controls in the estate.
The short answer
You need PAM if people administer servers, databases, network devices, cloud consoles or directories with privileged accounts. You need a secrets manager if applications, pipelines, containers or AI agents use credentials. Almost every organisation of more than a few dozen engineers has both problems, so the real decision is which credentials go where and how the two systems connect.
- Do I need PAM if I have a secrets manager? Yes, if humans hold standing admin rights. A secrets manager can store an admin password, but it does not broker an RDP or SSH session, hide the credential from the user, record keystrokes or enforce approval before access.
- Can PAM manage application secrets? Partly. Many PAM platforms offer an application credential retrieval interface, which suits a fixed set of known applications. High-churn workloads, dynamic database credentials, short-lived cloud tokens and container-scale request volumes are what secrets managers are designed for.
- Which one is for NHIs? The secrets manager is the main runtime control for machine credentials. PAM still matters for NHIs that are also high-privilege accounts on infrastructure, such as a domain service account or a database owner account, because those need rotation and monitoring like any admin account.
Side-by-side comparison
| Dimension | Privileged access management | Secrets manager |
|---|---|---|
| Primary consumer | Human administrators, third-party support staff | Applications, CI/CD pipelines, containers, scripts, AI agents |
| Access pattern | Interactive session, minutes to hours, low volume | API call, milliseconds, high volume and bursty |
| How the requester proves identity | Workforce SSO with phishing-resistant MFA, often from a privileged access workstation | Workload identity: platform token, cloud role, Kubernetes service account, OIDC federation, or a bootstrap credential |
| Core controls | Approval workflow, credential check-out or injection, session proxy, recording, just-in-time elevation | Path or resource policy, leases and expiry, dynamic secret generation, encryption as a service, versioning |
| Does the user see the secret? | Ideally not: the proxy injects it into the session | Yes, by design: the workload receives the value |
| Rotation trigger | After each check-out, on a schedule, or on reconciliation drift | On a schedule, on lease expiry, or never needed for dynamic secrets |
| Audit evidence | Who asked, who approved, session video or command log | Which identity read which secret version, from where, and when |
| Typical owner | Identity or security operations team | Platform engineering with security setting policy |
| Failure impact | Admins locked out or uncontrolled; break-glass needed | Applications fail to start or renew; outage across services |
How each works
PAM: the human session path
- Request: the administrator signs in to the PAM portal with SSO and MFA and asks for a target and role, with a ticket reference.
- Approve: a rule, a peer or a manager approves. NCSC describes multi-party approval, where "An administrator's credential is only released if a different, authorised individual(s) approve it", and rule-based auto-approval tied to a ticket.
- Broker: the PAM proxy opens the RDP, SSH, database or web console session and injects the vaulted credential, or issues a temporary credential or elevation. NCSC's just-in-time model gives the administrator a "Temporary" credential with constrained validity.
- Record: the session is recorded or command-logged and can be terminated live.
- Revoke: on session end the account is checked in and its password rotated, or the temporary role expires.
The design goal is that the human never holds a reusable privileged secret. See the JIT Access Guide and Credential Vaulting vs Just-in-Time Elevation for the two PAM models.
Secrets manager: the machine retrieval path
- Authenticate: the workload presents a platform-issued identity. OWASP recommends avoiding static bootstrap credentials and using workload identity such as Kubernetes service accounts or OIDC federation to authenticate to the secrets manager.
- Authorise: policy maps that identity to the specific secret paths it may read. OWASP advises separating the permission to exchange an identity token from the permissions to read specific secrets.
- Issue or return: a static secret is returned, or a dynamic credential is generated with a short lease. OWASP: "Dynamic secrets should be used where possible to reduce the surface area of credential reuse."
- Renew or expire: the workload renews the lease while it runs; the credential is revoked at lease end. OWASP notes that "Restarting the application does not itself revoke stolen credentials", so revocation must be explicit.
- Log: every read, renewal, failure and administrative change is recorded with the requesting identity.
The design goal is that the credential is short-lived, scoped to one workload and never handled by a person. See the Secrets Management Guide and Dynamic Secrets and Ephemeral Credentials Guide.
Threat model and failure modes for each
| Threat | PAM | Secrets manager |
|---|---|---|
| Main threat addressed | Misuse or theft of admin credentials (T1078 Valid Accounts), session hijacking (T1563) | Credentials in files and code (T1552.001), long-lived static keys |
| Attack on the tool itself | Vault admin compromise exposes every privileged account; NCSC states "The PAM system is itself an attack surface" | Theft of secrets from the store via a compromised identity (T1555.006 Cloud Secrets Management Stores) |
| Bypass | Direct logon to targets with accounts never onboarded, or local admin accounts outside the vault | Secrets copied to environment variables, config maps or CI variables outside the store |
| Over-broad access | Safes or policies granting whole teams access to all accounts | Wildcard path policies; OWASP: "engineers should not have access to all secrets in the secrets management system" |
| Bootstrap weakness | PAM's own service and integration accounts with static passwords | Secret zero: a static token used to authenticate the workload |
| Availability failure | Admins cannot reach systems during an incident | Workloads cannot start, renew leases or rotate |
Hardening for each vault is covered in Securing the PAM Vault and Securing the Secrets Manager; bootstrap design is in the Secret Zero Bootstrap Guide.
NHI coverage gaps in each
Map the OWASP Non-Human Identities Top 10 (2025) against the two tools and the gaps become clear. Neither tool alone covers the list; together they cover most of it, with discovery and ownership left as a separate job.
| NHI type or risk | What PAM covers | What a secrets manager covers | Gap to close |
|---|---|---|---|
| Domain and local service accounts | Vaulting, password rotation, dependency updates for known services | Can store the password for an app that reads it | Unknown service accounts; convert to managed accounts where possible |
| Database application credentials | Rotation of a fixed application account | Dynamic per-instance credentials with leases | Shared accounts used by many apps |
| Cloud access keys and API keys (NHI7 Long-Lived Secrets) | Limited: stored as generic secrets | Storage, rotation, or replacement with short-lived cloud credentials | Keys created directly in consoles and never stored centrally |
| CI/CD pipeline credentials | Rarely in scope | Runtime retrieval and OIDC-based short-lived credentials | Secrets stored as CI variables; OWASP prefers that the deployed service fetches its own secrets at runtime |
| SSH keys for automation | Key vaulting and rotation for onboarded hosts | Signed short-lived SSH certificates where supported | Keys in authorized_keys files nobody tracks |
| Secret leakage (NHI2) | Not addressed | Reduces copies by central retrieval | Secret scanning in code, tickets and chat |
| Improper offboarding (NHI1) | Account removal for onboarded accounts | Secret deletion and revocation | Owner tracking and decommission triggers |
| Human use of NHI (NHI10) | Detects humans checking out service account passwords | Shows human identities reading machine secrets | Policy that forbids it, and alerting |
| AI agent credentials | Session brokering when an agent drives an admin tool | Scoped, short-lived tokens injected at runtime | Per-agent identity and delegation; see Credential Vaulting for AI Agents |
The discovery gap is structural. PAM onboards what it is told about, and a secrets manager holds what developers put in it. Credentials created elsewhere need a separate discovery and reconciliation process: see Privileged Account Discovery and Onboarding and Secrets Scanning vs Secrets Management.
Where they overlap: vaulting, rotation and ownership
The overlap causes most of the operational pain. Three rules prevent it.
- One system of record per credential: a credential is mastered and rotated in exactly one tool. If an application reads a PAM-rotated service account password, either the application retrieves it from PAM's application interface or PAM pushes the new value to the secrets manager on rotation. Never let both rotate independently.
- Rotation belongs to the consumer's system: human admin accounts rotate on check-in in PAM; machine credentials rotate, or are replaced by dynamic credentials, in the secrets manager. Human passwords used with SSO are excluded from routine rotation; OWASP says to rotate user credentials only on suspicion of compromise.
- Vault the vaults: OWASP recommends securing the primary secret of a secrets manager in a secondary system. In practice the secrets manager's root and recovery material are a PAM-managed break-glass item, and PAM's own recovery keys sit in an offline split-knowledge process.
| Credential class | System of record | Rotates it | Other system's role |
|---|---|---|---|
| Human admin accounts on servers, network devices, databases | PAM | PAM on check-in or schedule | None |
| Cloud console admin roles | PAM or cloud JIT | Role expiry | None |
| Windows service accounts used by legacy apps | PAM | PAM, with dependency updates | Secrets manager receives the value if apps read it there |
| Application database credentials | Secrets manager | Lease expiry or schedule | PAM brokers human DBA access separately |
| API keys, tokens, certificates for workloads | Secrets manager (certificates may sit with a machine identity platform) | Secrets manager or issuer | None |
| Secrets manager root, unseal and recovery material | PAM break-glass | After each use | Secrets manager is the protected target |
Ownership model: the security or identity team owns PAM policy and operations. Platform engineering usually runs the secrets manager, with security owning the policy standards (path structure, lease limits, authentication methods allowed) and reviewing exceptions. Each secret path or PAM safe has a named business or engineering owner who answers the review question "is this still used, and by what?".
Reference architecture using both
- Identity layer: workforce identity provider for people, with phishing-resistant MFA; platform workload identity (cloud roles, Kubernetes service accounts, OIDC tokens from CI) for machines.
- Human path: administrator on a privileged access workstation, through SSO, to the PAM portal; PAM approves and proxies the session to targets, injects credentials or grants a time-bound role, records, and rotates on check-in.
- Machine path: workload authenticates to the secrets manager with its platform identity, receives scoped or dynamic credentials, renews while running, and loses access at lease end.
- Integration points: PAM pushes rotated values for shared legacy accounts into the secrets manager, or applications use PAM's credential retrieval interface for that small set; the secrets manager's root material is a PAM break-glass item; both send logs to the SIEM with a common identity key.
- Discovery and inventory: scanners and cloud APIs feed one NHI inventory that records which system owns each credential, so anything found outside both tools becomes a ticket.
- Agents: AI agents get their own workload identity and retrieve scoped tokens from the secrets manager; when an agent operates an administrative tool on a person's behalf, the action goes through PAM so the session is approved and recorded.
Decision criteria
| Situation | Lead with | Why |
|---|---|---|
| Audit finding on shared admin passwords or third-party support access | PAM | Approval, recording and vendor session control are the evidence auditors ask for |
| Secrets found in repositories, CI variables or container images | Secrets manager | Gives developers a supported place to retrieve credentials at runtime |
| Cloud-native, little on-premises infrastructure | Secrets manager plus cloud JIT for console roles | Few interactive sessions to broker; most risk is machine credentials |
| Large Windows and database estate with many service accounts | PAM, then secrets manager for new applications | Service account rotation with dependency handling is a PAM strength |
| Regulated environment requiring session evidence (for example payment card systems) | PAM for admin access, secrets manager for application credentials | Session evidence and machine credential control are both requirements |
Small versus large: a 50-person software company may start with a cloud provider's secrets service and its native just-in-time role elevation, adding full PAM only when it has servers or contractors needing brokered sessions. A large enterprise usually runs both, and the main risk is two teams buying overlapping tools without a system-of-record map.
Worked scenario: payments platform with both tools
A payments company has 400 engineers, a PAM platform for 1,200 admin accounts, and a secrets manager used by about half of its microservices. An audit finds 300 database passwords in CI variables and a service account whose password PAM rotates every 30 days, which breaks the nightly batch job each month until someone hard-codes it.
- Map ownership: classify every credential as human admin (PAM), shared legacy service account (PAM master, pushed to the secrets manager), or machine credential (secrets manager).
- Fix the batch job: PAM keeps rotating the service account, and on each rotation writes the new value to the secrets manager path the job reads at start-up. The hard-coded copy is removed and the account's interactive logon is denied.
- Move CI secrets: pipelines authenticate to the cloud and the secrets manager with OIDC tokens; services fetch their own database credentials at runtime, moving to dynamic credentials with short leases for the main databases.
- Close the human path: DBAs reach production databases only through PAM sessions; application credentials are no longer readable by human identities except through a recorded break-glass request.
- Test and roll back: each service moves in a canary release; the old CI variable stays disabled, not deleted, for one release cycle, then is deleted and the underlying credential rotated.
Detection and measurement
- PAM signals: logons to managed targets that did not come through the PAM proxy, check-outs of service account passwords by humans, sessions outside approved windows, and failed rotations.
- Secrets manager signals: reads by unexpected identities or from unexpected networks, spikes in secret reads, attempts to use expired leases, policy changes and root token use. See the Secrets Access Logging and Detection Guide.
- Cross-tool signals: a credential used from a host that neither the PAM proxy nor the expected workload runs on.
Metrics:
- Percentage of privileged human sessions brokered through PAM rather than direct logon.
- Percentage of machine credentials retrieved at runtime from the secrets manager rather than stored in files or CI variables.
- Share of machine credentials that are dynamic or short-lived (see How to measure secret age and rotation coverage).
- Credentials with more than one system rotating them (target: zero).
- Credentials found by discovery that are in neither tool, and median time to onboard or remove them.
Common failure patterns
- Dual rotation: PAM and the secrets manager both rotate one credential and applications fail, so rotation gets turned off everywhere.
- PAM as a developer secret store: developers check out service account passwords through PAM and paste them into config, turning a session control into a distribution channel.
- Secrets manager as an admin password book: human admin passwords stored as secrets, with no approval, brokering or recording.
- Static secret zero: every workload authenticates to the secrets manager with the same long-lived token stored next to the application.
- Inventory equals vault: teams report "100 per cent vaulted" based on what each tool holds, while keys in code and SaaS integrations are never counted. See Secrets Sprawl vs Vault Sprawl.
- No break-glass for either: a vault outage during an incident leaves admins and services without access, and people create untracked workarounds.
Framework mapping
| Control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Main tool |
|---|---|---|---|
| Restrict and manage privileged accounts | AC-6(5) Privileged Accounts, AC-2(6) Dynamic Privilege Management | PR.AA-05 | PAM |
| Session evidence for privileged use | AU-14 Session Audit, AC-6(9) Log Use of Privileged Functions | PR.PS-04 | PAM |
| Remote administrative access | AC-17 Remote Access | PR.AA-05 | PAM |
| Machine credential issuance and rotation | IA-5 Authenticator Management, IA-9 Service Identification and Authentication | PR.AA-01 | Secrets manager |
| Key and secret protection | SC-12 Cryptographic Key Establishment and Management, SC-28 Protection of Information at Rest | PR.AA-01 | Both |
| Monitoring use | AU-12 Audit Record Generation | DE.CM-03 | Both |
CIS Controls v8.1 Control 5 Account Management and Control 6 Access Control Management cover both tools; ISO/IEC 27001:2022 Annex A 8.2 Privileged access rights maps mainly to PAM and 5.17 Authentication information to both. NCSC's secure system administration principles include "Use privileged access management" and "Log and audit administration activities".
Practitioner checklist
- Write a credential class map: for each class, the system of record, who rotates it, and the owner.
- Broker all human privileged sessions through PAM and alert on direct logons to managed targets.
- Move machine credentials to runtime retrieval from the secrets manager, preferring dynamic or short-lived credentials.
- Replace static secret zero tokens with workload identity authentication.
- Eliminate dual rotation: integrate PAM to push rotated values where legacy apps share an account.
- Block humans from reading machine secrets except through a recorded break-glass process.
- Feed both tools' logs and a discovery inventory into one NHI view keyed by identity and owner.
- Treat both vaults as tier 0, with separate admin accounts, tested backups and documented break-glass.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure system administration
- NCSC: Use privileged access management
- OWASP: Secrets Management Cheat Sheet
- OWASP: Non-Human Identities Top 10 (2025)
Related NHI Mgmt Group resources: PAM vs IGA vs NHI Management · Password Manager vs Secrets Manager · Secrets Manager vs KMS vs HSM · Machine Identity Management vs Secrets Management