PAM focuses on brokering and controlling access before a session starts, while authorized keys on the destination host decide whether a key can be used once it arrives. In SSH environments, both matter, but destination-side control is essential because a public key placed on the host can create direct access even when a PAM workflow exists. That is where many bypasses appear.
Where PAM and authorized keys control different parts of the SSH path
PAM and destination-host authorized keys solve different problems in the SSH flow. PAM sits in the authentication and policy path before a session is established, so it can centralise approval, context, and account rules. Authorized keys are evaluated on the destination host, so they determine whether the presented key is accepted locally, regardless of any upstream workflow.
The practical difference is scope. PAM can decide whether access should be brokered at all, but authorized keys decide whether the target system will trust that specific public key for that account. If the host still accepts the key directly, the session can bypass a central approval model even when the organisation believes PAM is in control.
For teams comparing the two, the question is not which one is “stronger” in the abstract. It is whether policy is enforced at the chokepoint that actually matters for the access path you are trying to control. In SSH, destination-side trust is often the final enforcement point, which makes host-side key management operationally critical.
Why destination-host key trust changes the security outcome
Destination-host authorized keys are powerful because they bind access to a local trust decision. That means the security outcome depends on whether the right keys are present, whether they are removed on time, and whether file or account controls prevent unauthorized modification. Centralized authentication does not remove that dependency unless it also controls the host’s local trust material.
This is where bypasses tend to appear. If a key is added to NHI Lifecycle Management Guide or if it survives an offboarding event, the host can continue to grant direct access long after the intended approval path changed. In practice, the local authorized_keys file can become a standing access path unless rotation, removal, and review are disciplined.
The same pattern is familiar in broader identity and secret governance. The Ultimate Guide to NHIs is useful here because SSH keys behave like access-enabling material that must be inventoried, rotated, and removed with the same care as other long-lived credentials. When that local material is unmanaged, the host becomes the authority, not the policy workflow.
How practitioners decide which control owns the access decision
Use PAM when the security objective is centralized brokering, approval, session control, and auditability before access starts. Use host-side authorized keys when the destination system must make the final allow-or-deny decision for specific accounts and you need that trust to exist on the endpoint itself. Most real environments need both, but they must be designed so one does not silently undermine the other.
That design choice becomes especially important when access is privileged or operationally sensitive. A PAM workflow may record intent and enforce checks, but if the destination host still accepts a stale or overly broad key, the local account can be reached directly. A strong implementation therefore treats host key distribution, removal, and review as part of the control plane, not as an afterthought.
For deeper reading on the access-governance side, Ultimate Guide to NHIs, Key Challenges and Risks and Lifecycle Processes for Managing NHIs are the most relevant internal navigation points. They frame the operational reality that access material on a host must be governed across its full lifecycle, not just at issuance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | SSH authorized keys are access-enabling material that must be governed and rotated. |
| NHI-03 — Privilege and Access Management | The question contrasts centralized brokering with local host access enforcement. | |
| NHI-05 — Lifecycle and Offboarding | Stale authorized keys create persistent SSH access after ownership or approval changes. | |
| Recommendation — Inventory and rotate SSH keys with the same discipline as other long-lived access credentials. Enforce least privilege so host-level keys cannot bypass centralized access policy. Remove SSH keys promptly during offboarding and approval changes. | ||
| CIS Controls v8 | 5 — Account Management | SSH access depends on controlling account and key assignment on destination hosts. |
| 6 — Access Control Management | PAM and authorized keys are competing enforcement points for SSH access decisions. | |
| Recommendation — Review and remove stale SSH access paths from destination accounts. Centralize SSH access decisions and prevent direct host-key bypasses where possible. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The topic is fundamentally about how SSH access is authenticated and authorized. |
| GV.OC — Organizational Context | Choosing PAM versus host keys depends on the intended control boundary and ownership. | |
| PR.DS — Data Security | Private keys and authorized_keys files are sensitive access material that must be protected. | |
| Recommendation — Align authentication and authorization so destination-host trust cannot override policy. Define which team owns SSH trust material and the approval boundary. Protect SSH key material as sensitive access data on both broker and destination systems. | ||
| NIST Zero Trust (SP 800-207) | 3 — Policy Engine and Access Decisions | PAM represents a policy-driven access decision before the session begins. |
| 4 — Policy Enforcement Point | The destination host is an enforcement point when it validates authorized keys locally. | |
| Recommendation — Place SSH authorization decisions behind a policy engine rather than only on the host. Harden the host enforcement point so local key trust cannot be altered casually. | ||
Practitioner Guidance
What to verify: Confirm whether PAM is actually enforcing the SSH path, or whether destination hosts still accept keys directly. If the host can still authenticate a key without the broker, you do not have a single control point, you have overlapping controls with a possible bypass route.
Decision rule: If the risk is unauthorized direct access, treat host-side authorized keys as the decisive enforcement point and govern them with the same rigor as any other long-lived access credential. If the risk is session oversight or approval workflow, PAM adds value, but it does not substitute for host cleanup and key revocation.
Common mistake: Teams often assume “PAM in place” means SSH is centrally controlled. In reality, the destination host may still be the last system that matters, so stale keys, copied keys, or unmanaged file changes can preserve access after the central workflow changes.
Practitioner takeaway: The safest model is to treat PAM as the broker and the host key as the final authority, then verify that both are aligned so no old key can outlive its intended approval or ownership.
Related resources from NHI Mgmt Group
- What is the difference between GitHub app access and shadow integrations using API keys or SSH keys?
- What is the difference between SSH keys and SSH certificates for server access?
- What is the difference between strong SSH key policy and platform-generated SSH keys for developer access?
- What is the difference between hiding SSH keys from users and relying on vault-based access workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
