What is the difference between changing port 22 and real SSH hardening?

Changing port 22 mostly reduces background scanning noise. Real hardening changes the trust model by restricting algorithms, limiting authentication abuse, controlling forwarding, and shifting access to short-lived identity-bound credentials. One is a transport tweak, while the other reduces the chance that a valid session becomes an uncontrolled access path.

Why This Matters for Security Teams

Changing SSH port 22 can cut down on noisy internet scans, but it does not change how access is granted or abused. Real SSH hardening is about reducing the blast radius of a valid login: stronger key management, fewer permitted algorithms, tighter forwarding rules, and shorter-lived access paths. That matters because SSH often becomes the quiet control plane for administrative access, deployment automation, and break-glass workflows.

This is the same pattern seen across broader non-human identity governance. NHI Mgmt Group research shows that 71% of NHIs are not rotated within recommended time frames, and Ultimate Guide to NHIs — What are Non-Human Identities explains why rotation, visibility, and offboarding matter as much as initial issuance. The NIST Cybersecurity Framework 2.0 also treats access control as an ongoing function, not a one-time setup.

In practice, many security teams encounter SSH abuse only after a valid key has already been reused, copied, or embedded into automation, rather than through intentional access review.

How It Works in Practice

Port changes are usually a noise-reduction tactic, not a security model. Real SSH hardening starts with identity and authorization: who can connect, from where, to what, and under which conditions. That means using per-user keys or certificates, disabling password authentication where possible, restricting root login, and limiting what an authenticated session can do once established. If SSH is part of NHI operations, the same logic applies to service accounts, deployment agents, and privileged automation.

A practical hardening baseline includes:

• Enforce modern cryptography and remove weak ciphers, MACs, and key exchange options.
• Use short-lived credentials where possible, including JIT-issued access for admins and automation.
• Bind access to workload or user identity instead of relying on a shared static key.
• Disable unused forwarding features such as agent forwarding, X11 forwarding, or arbitrary TCP tunnels.
• Log and alert on new keys, unusual source addresses, and unexpected session duration.

For non-human workloads, the best practice is evolving toward identity-bound access and ephemeral secrets rather than long-lived SSH keys. The NHI guidance at Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it connects rotation and governance to real operational risk, while NIST Cybersecurity Framework 2.0 reinforces least privilege and continuous monitoring as core controls. SSH should be treated as a controlled identity path, not just a network service.

These controls tend to break down in legacy environments that depend on shared admin keys and unmanaged jump hosts because there is no clean place to enforce per-session identity or revocation.

Common Variations and Edge Cases

Tighter SSH hardening often increases operational overhead, so organisations have to balance security gain against deployment friction and support burden. That tradeoff is real when teams manage thousands of servers, vendor access, or brittle scripts that assume static keys and open forwarding.

There is no universal standard for every environment, but current guidance suggests different priorities by use case. For internet-facing bastions, reducing scan noise by moving the port may be acceptable as a secondary control. For production systems, however, the focus should be on PAM integration, RBAC, JIT access, and strong logging. In automation-heavy environments, SSH certificates or workload identity are often a better fit than raw keys because they support short-lived trust and easier revocation.

Edge cases include embedded devices, air-gapped systems, and third-party managed platforms where SSH options are limited. In those cases, hardening may need compensating controls such as strict source IP allowlists, session recording, command restrictions, and aggressive key rotation. The key distinction is simple: a port change hides the door, while real hardening controls what happens after the door is opened.

For teams mapping this to formal programmes, NIST Cybersecurity Framework 2.0 provides the governance wrapper, while the NHI lifecycle guidance in Ultimate Guide to NHIs — What are Non-Human Identities helps translate that into credential rotation and offboarding discipline.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?