Use file permissions to protect local key material, but do not mistake that for full access governance. Certificate controls manage trust and expiry, while logging proves use and supports review. Teams need both layers if they want access control that is both secure and explainable.
How SSH certificate controls and file permissions fit different layers
SSH file permissions and ssh certificate solve different problems, so treating them as substitutes leaves gaps. File permissions protect private keys on disk and reduce local exposure. Certificates, by contrast, bind trust to an issuing authority, set expiry, and make revocation or rotation more governable. The practical question is not which one is “better”, but which control layer each one actually enforces.
For teams running shared infrastructure or large fleets, the distinction matters because local hardening alone does not tell you who is entitled to connect, and certificate policy alone does not protect a key that has been copied out of place. Good SSH governance starts by separating storage protection from access authority and then making sure both are visible in operations.
That is why the strongest implementations treat key file mode settings as a baseline hygiene control, while certificate lifecycle, issuance policy and trust anchors provide the real access boundary. SSH Key and SSH Certificate Management Guide covers the operational side of governing keys, certificates, bastions and orphaned access paths.
Why certificates add governance that file permissions cannot
File permissions can stop another local user from reading a private key, but they do not express who should be allowed to authenticate, for how long, or under what conditions. SSH certificates do those things through signed trust, short validity windows, and policy decisions at issuance time. That makes certificates the control that can actually encode access intent, rather than merely protecting the local secret that enables the connection.
This matters most where teams need fast revocation, short-lived access, or separation between identity proofing and connection approval. A certificate can expire cleanly even when a private key remains present, which reduces the operational burden of long-lived SSH keys and makes stale access easier to eliminate. For a broader machine-identity view of that lifecycle problem, Machine Identity, PKI and Certificate Lifecycle Guide explains how certificate expiry, renewal and automation change the control model.
Teams should also remember that certificate trust is only as strong as the issuing process behind it. If issuance is weak, overly broad, or poorly audited, the certificate becomes a convenient wrapper around bad access policy. In other words, certificates improve governance only when the CA, validity rules and principal mapping are tightly managed.
Why logging is the layer that makes SSH access explainable
Logging serves a different job again: it shows whether the control was actually used, by whom, and when. Without logs, a valid certificate may prove that access was technically possible, but not whether the access was appropriate, expected, or reviewed. For teams operating under audit or incident-response pressure, that difference is critical.
Strong SSH logging should capture certificate identity, source, target, session start and end, and any privilege escalation or command recording that the environment supports. The goal is not to log everything indiscriminately, but to preserve enough evidence to reconstruct access decisions and challenge suspicious activity. If the organisation cannot answer “who connected, with what authority, and for what duration”, the control stack is incomplete.
Logging also closes the gap between local protection and central governance. File permissions can show that a private key was protected on disk, but logs show whether the resulting credential was used in a way that fits policy. That is what makes SSH controls explainable rather than merely technically correct. Privileged Access Management Guide is useful here because session recording, just-in-time access and reviewability are part of the same accountability layer.
Risk and Threat Considerations
Teams that rely on file permissions alone tend to miss the larger failure mode: a protected private key can still be long-lived, broadly reusable, and difficult to attribute after use. If an attacker copies the key, local permissions no longer matter, and if the environment lacks certificate expiry or reliable logging, the compromise can persist silently.
Failure mechanism: weak local permissions protect only the file, not the authority embodied by the key, while absent or weak certificate governance leaves no enforced expiry or revocation path. Poor logging then removes the evidence needed to spot misuse or scope the blast radius.
Impact: stolen or overexposed SSH material can turn into durable access, weak accountability, and delayed incident response, especially where multiple administrators, environments, or jump hosts share similar trust paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH key and certificate lifecycle depends on managing issuance, rotation and revocation. |
| AU-2 — Event Logging | SSH access needs session and authentication logging to make use attributable and reviewable. | |
| AC-6 — Least Privilege | SSH certificate scope should limit access to only the hosts and roles actually needed. | |
| Recommendation — Manage SSH keys and certificates with defined issuance, rotation, and revocation rules. Log SSH authentication and session events with enough detail for review and incident response. Constrain SSH certificate privileges to the minimum access required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SSH certificate policy and file permissions are both access-control mechanisms needing governance. |
| A.8.15 — Logging | SSH session logging provides audit evidence for use and review of privileged access. | |
| Recommendation — Define and enforce SSH access rules through documented access-control policy. Enable and retain SSH logs that support traceability and review. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | SSH permissions, certificates and logging all support access control management. |
| Recommendation — Centralise SSH access control, review entitlements, and remove stale access. | ||
Practitioner Guidance
What to prioritise: treat file permissions as the first line of local protection, but make certificate policy the real access-control boundary and logging the proof layer. If one of those three is missing, the overall control is weaker than it appears.
What to verify: confirm that SSH certificates have short enough lifetimes, issuance is restricted to trusted principals, and logs retain enough context to tie each session back to a certificate, host and user action. If you cannot reconstruct access after the fact, you do not yet have explainable governance.
Common mistake: teams often harden authorized_keys or private-key permissions and stop there. That reduces casual exposure, but it does not solve stale access, revocation, or session accountability.
Practitioner takeaway: the right balance is layered, not either-or, file permissions protect the secret, certificates govern the right to use it, and logging proves that the right was exercised within policy.
Related resources from NHI Mgmt Group
- How can security teams know whether SSH certificate controls are working?
- How should security teams manage file transfer workflows when relying on cloud-based SSH access controls?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?