SOC 2 Controls for SSH Access: CC6 and CC7 Mapped (2026)

Quick Summary: What You’ll Learn

• Which SOC 2 Trust Services Criteria actually cover SSH access (CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, CC7.2), quoted, not paraphrased.
• The concrete SSH control that satisfies each one, with sshd_config lines checked against the OpenSSH manual.
• The evidence an auditor will ask for on each control, and how to produce it without a PAM platform.
• Where a Type II audit usually catches teams out on SSH, and where termique fits (and where it doesn’t).

If you are preparing for SOC 2 and your engineers SSH into production, someone will eventually ask which SOC 2 controls for SSH access you have and how you prove they work. SOC 2 won’t answer that for you. The framework never says “disable password authentication” or “use certificates”. It states outcomes, and you pick the controls that achieve them. That freedom is useful, but it also means a lot of teams show up to the audit with good SSH hygiene and no clean story of which criterion each setting supports. This guide is that story.

Which SOC 2 controls apply to SSH access?

SSH access is logical access to production systems, so most of it lands in the CC6 series (Logical and Physical Access Controls), with monitoring in CC7.2. These are the criteria from the AICPA’s 2017 Trust Services Criteria (with the revised points of focus) that an auditor will map your SSH controls to (criteria text quoted, shortened where you see “…”):

• CC6.1: “The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events…” For SSH: how people authenticate to servers at all. Keys or certificates, no shared accounts, no passwords.
• CC6.2: “Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users… user system credentials are removed when user access is no longer authorized.” For SSH: approval before a key lands on a server, and key removal at offboarding.
• CC6.3: “The entity authorizes, modifies, or removes access… based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties…” For SSH: who can reach which hosts, as which user, and who can become root.
• CC6.6: “The entity implements logical access security measures to protect against threats from sources outside its system boundaries.” For SSH: port 22 not open to the whole internet. Bastion, VPN, or allow-listed source ranges.
• CC6.7: “The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission…” For SSH: encrypted transport (SSH gives you this) plus control over file transfer and forwarding.
• CC7.2: “The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors…” For SSH: authentication logs and command logs that someone actually reviews.

Two things to keep in mind before mapping controls:

• The criteria are the requirement; the controls are yours. Your auditor tests the controls you describe in your system description. If you say “all production SSH uses short-lived certificates”, that is what gets tested, so don’t write down controls you only partly run.
• Type I vs Type II changes what “evidence” means. A Type I report checks that the controls are designed and in place on one date. A Type II report checks that they operated across the whole review period, so the auditor samples dates and people and expects records from months ago. Our post on SOC 2 audit trail requirements covers the logging side of that in more depth.

How do you satisfy CC6.1 for SSH authentication?

CC6.1 is about the authentication mechanism itself. For SSH, an auditor wants to see three things: individual identities (no shared deploy or ubuntu login used by five people), a strong authentication method, and that the configuration is enforced, not just documented.

A baseline sshd_config that supports CC6.1:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AuthenticationMethods publickey

Notes from the sshd_config(5) manual worth knowing before you paste this:

• PasswordAuthentication defaults to yes, so you have to turn it off explicitly.
• PermitRootLogin defaults to prohibit-password, which still allows root with a key. Setting it to no forces people to log in as themselves and escalate with sudo, which is what gives you per-person attribution later.
• AuthenticationMethods publickey means only public key authentication completes a login. If you require a second factor, this is also where you would list several methods that must all succeed.

Before you reload sshd, keep a second session open and test a fresh key login from a new terminal. Locking yourself out of a production host is a bad way to start an audit period.

Evidence the auditor asks for: the effective configuration, not the file. sshd -T runs extended test mode and prints the effective configuration to stdout, which is the honest answer to “is this actually enforced?”:

sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|authenticationmethods)'

Capture that output per host (or per image, if hosts are built from a golden image) on a schedule, and you have dated evidence for a Type II sample.

How do you prove CC6.2 onboarding and offboarding for SSH keys?

CC6.2 has two halves: access is authorized *before* credentials are issued, and credentials are *removed* when access ends. SSH makes the second half hard, because a public key in authorized_keys keeps working until someone deletes it, on every host it was copied to.

There are two workable patterns:

• Static keys with a single source of truth. Keys live in config management (Ansible, Puppet, cloud-init, or similar), each key is tied to a named person, and a merged change with an approval is your authorization record. Offboarding is a change that removes the key everywhere. Evidence: the approved change for a sample of joiners and leavers, plus a scan of authorized_keys across hosts showing the leaver’s key is gone.
• SSH certificates from a CA. Servers trust a CA via TrustedUserCAKeys, and engineers get short-lived certificates instead of permanent key entries. From ssh-keygen(1):

ssh-keygen -s /path/to/ca_key -I [email protected] -n alice -V +8h /path/to/alice_key.pub

-I sets the key identifier that the server logs when the certificate is used, -n sets the principals (usernames) the certificate is valid for, and -V sets the validity interval. A certificate that expires in hours means offboarding mostly happens on its own: stop issuing, and access ends when the last certificate expires. For a compromised key before expiry, sshd_config supports RevokedKeys, which accepts a plain list or a Key Revocation List built with ssh-keygen -k. One warning from the manual: if the RevokedKeys file is unreadable, public key authentication is refused for all users, so deploy it carefully.

We compared the two approaches in SSH certificate authority vs public key auth for teams. For SOC 2, either is fine. What fails audits is a third pattern: keys added by hand, by whoever had root, with no record.

Evidence the auditor asks for: HR or ticket records for joiners and leavers in the period, the matching approval for each key (or certificate issuance log), and proof the leaver’s access ended within your stated SLA. For key inventories, ssh-keygen -l -f ~/.ssh/authorized_keys prints the fingerprint of every key in the file, which is easier to match against a register than raw base64.

What does least privilege (CC6.3) look like for SSH?

CC6.3 is where “everyone in engineering can SSH into everything as a sudoer” gets written up. The criterion asks you to give access based on role and to consider least privilege and segregation of duties. For SSH that usually means:

• Restrict who can log in at all, per host class. AllowGroups limits login to users whose primary or supplementary group matches. Pair it with groups from your directory (prod-ssh, db-ssh) so access follows role, not individual edits on each box.
• Separate login from root. Engineers log in as themselves; sudo rules decide who can escalate and to what. That gives you two layers an auditor can test separately.
• Scope service accounts. CI and automation keys should use authorized_keys options like a forced command or source-address restriction, so a leaked deploy key can’t open an interactive shell.

Evidence the auditor asks for: a periodic access review. Someone with authority looks at who has SSH access to which systems, confirms it still matches their role, and signs off; removals get ticketed. Quarterly is a common cadence, but use whatever you wrote in your policy and stick to it. If that review is currently a spreadsheet someone rebuilds from memory, see how to run an SSH access review without spreadsheets.

How does CC6.6 apply to SSH exposed to the internet?

CC6.6 covers threats from outside your system boundary. Port 22 open to 0.0.0.0/0 is the obvious finding. The fix is to put a boundary in front of SSH:

• A bastion host that is the only machine reachable from outside, with everything else accepting SSH only from the bastion. Our bastion host and ProxyJump setup walks through the client side.
• Or a VPN / zero-trust network, with SSH only on private addresses.
• Or, at minimum, security group or firewall rules that allow SSH only from known office or VPN ranges.

The bastion pattern also helps CC7.2, because it gives you one choke point where authentication and session logs are guaranteed to exist.

Evidence the auditor asks for: firewall or security group rules showing SSH is not open to the world, and a network diagram that matches them.

Where does CC6.7 come in for file transfer and forwarding?

SSH encrypts transport, so the “protects it during transmission” part of CC6.7 is largely covered by using SSH (and SFTP) instead of plaintext protocols. The part teams forget is *restricting movement*. Agent forwarding, TCP forwarding and unrestricted SFTP are all ways data or credentials leave their intended boundary. Not every environment needs to turn them off, but you should be able to say which hosts allow what and why. Agent forwarding in particular is worth a deliberate decision; we covered the risk in SSH agent forwarding security risks.

What SSH logging does CC7.2 need?

CC7.2 asks you to monitor for anomalies and analyze them. Logging alone doesn’t meet it; someone or something has to look. For SSH there are two layers:

• Authentication events. sshd writes to syslog or the journal at LogLevel INFO by default. Each successful login records the user, source address and method, and for public key logins the key’s fingerprint, so you can attribute a login to a specific key. If you use certificates, the -I key identifier shows up here too. Don’t raise LogLevel to DEBUG in production; the manual notes that DEBUG logging violates users’ privacy and is not recommended.
• What happened inside the session. Authentication logs tell you who got in, not what they did. For that you need command or session logging: auditd execve rules (which track the original login identity even after sudo), session recorders like tlog, or a tool that logs commands at the client or proxy. The tradeoffs are covered in SSH session logging options compared.

Then the part auditors actually test for CC7.2:

• Ship logs off the host. A log that the same root user can edit is weak evidence. Forward to a central store where engineers with production SSH can’t delete entries.
• Alert on a short list of real signals. Logins from unexpected networks, logins to root, repeated failed authentication, access outside on-call hours to sensitive hosts. Fewer, reviewed alerts beat a dashboard nobody opens.
• Keep a review record. A ticket or a short note each week or month saying “reviewed SSH auth alerts, nothing unusual” (or what was found and done) is the difference between a control that exists and one that operated.

What evidence should you have ready for each control?

A compact checklist you can hand to whoever owns the audit:

• CC6.1: sshd -T output per host class, dated; list of shared accounts (ideally none) with justification for any that remain.
• CC6.2: sample of joiners and leavers with matching key or certificate approvals and removal timestamps; current key register with fingerprints.
• CC6.3: latest access review with sign-off; AllowGroups and sudoers configuration; service-account key restrictions.
• CC6.6: firewall or security group rules for SSH; network diagram; bastion configuration.
• CC6.7: documented decision on agent and TCP forwarding per environment.
• CC7.2: sample of authentication logs from the central store, alert definitions, and the review record for the period.

The written policy that ties these together is its own document; our compliance-ready SSH access policy template is a starting point for that.

Where does termique fit into SOC 2 SSH controls?

termique is an SSH client, so it sits on the engineer’s side of the connection. It does not replace server-side controls: sshd_config, AllowGroups, firewall rules and central log shipping still have to exist on your infrastructure, and nothing in a client can enforce them.

What it can help with, based on what the docs describe for the Pro plan:

• Command logs per host (CC7.2 support). When command logging is enabled on a host, entries record a timestamp, session ID, the input (and terminal output, if enabled), whether input was pasted, and the termique user who ran the session. That is useful who-ran-what context on shared hosts. Be clear about its limits for audit purposes: these logs are stored on the termique backend in plaintext, not end-to-end encrypted, and the host owner can delete logs older than a given date. Treat them as operational context alongside your server-side, append-only logs, not as your tamper-evident record.
• Host sharing without handing out the password (CC6.2, CC6.3 support). A Pro user can share a host with teammates; the credential is re-encrypted for the recipient on acceptance, and the owner can revoke access. Two honest caveats from the docs: there are no permission levels (a shared host gives full connect access), and revoking doesn’t remove the recipient’s local copy of the host entry. For SOC 2 offboarding, still rotate the server-side credential.
• Credentials encrypted end to end. Passwords and private keys are encrypted on the device before sync, so the server only holds ciphertext. Hosts, groups and snippets sync as plaintext metadata.

termique is a free, native ssh manager we build, with end-to-end encrypted credentials. Command logs and host sharing are on Pro at $5/month (or $40/year), and the Teams roster on Pro includes up to 5 teammates. If your team is small and SSH is the least-instrumented access path in your audit scope, it’s a cheap way to add per-person command context on shared hosts. If you need session recording with enforced retention, an access proxy or PAM tool is the better fit.

FAQ

Does SOC 2 require SSH keys instead of passwords?

No. SOC 2 doesn’t name specific authentication methods. CC6.1 requires logical access security that protects your systems, and your auditor judges whether your chosen controls do that. In practice, key or certificate authentication with passwords disabled is the easiest position to defend, and password-only SSH to production tends to draw questions.

Which SOC 2 criteria cover SSH access?

Mainly CC6.1 (authentication and access security), CC6.2 (granting and removing credentials), CC6.3 (least privilege), CC6.6 (protection from outside the boundary) and CC6.7 (protecting data in transit), with CC7.2 for monitoring. Depending on how you deploy changes, CC8.1 (change management) can also touch SSH if engineers change production by hand.

Do we need a PAM tool to pass SOC 2?

Not necessarily. A small team can pass with sshd hardening, keys or certificates managed in config management, a bastion, central logging and a documented access review. A PAM or access proxy makes evidence easier to produce at scale, especially session recording and just-in-time access, but SOC 2 doesn’t require one.

How long should SSH logs be kept for SOC 2?

SOC 2 doesn’t set a fixed number. Your retention has to cover the full Type II review period so the auditor can sample from it, and it has to match what your own policy says. Pick a window that covers the review period with some margin, write it down, and make sure your log store actually enforces it.

Are SSH certificates better than keys for SOC 2?

They make CC6.2 easier because access expires automatically and each certificate carries an identifier that shows up in logs. Static keys work too if they are tied to named people, managed from one source of truth, and removed at offboarding. Pick the one your team will actually operate consistently for the whole audit period.

Try termique free

If you want per-person command context on shared hosts and an SSH client that keeps credentials end-to-end encrypted across macOS, Windows, Linux and iOS, download termique and start on the free plan.