User Access Review for Cloud Servers: SSH Keys, Admins, and Permissions

A user access review is a recurring check of who and what can reach cloud systems, which privileges each identity holds, why that access still exists, and whether it should be kept, reduced, rotated, disabled, or removed.

For small infrastructure teams, the review should cover human accounts, SSH keys, Windows and RDP users, API keys, service accounts, network exposure, recovery access, and offboarding together. Raff Technologies supports 3,000+ customers and 15,000+ VMs, and our infrastructure reviews repeatedly show the same failure pattern: temporary access is easy to grant but much harder to remember months later unless ownership and removal are explicit.

This guide focuses on the recurring review process. For the wider decision about how administrators should reach infrastructure in the first place, start with Bastion Host vs VPN vs Public SSH.

The access review framework ends every item with a decision

An access review should produce changes, not merely a spreadsheet that says the review happened.

For every user, key, token, service account, and privileged path, answer five questions:

1. Who or what owns it?
2. Which systems can it reach?
3. Which actions can it perform?
4. Is that access still required today?
5. What should happen next?

Every item should end in one of five states:

A privileged access item without a named owner and current purpose should not remain active.

Use a stricter review when the account can change networking, delete backups, export customer data, modify billing, create administrators, or alter production systems. Those actions have a larger failure impact than read-only monitoring or application support.

Identities, credentials, privileges, and reachability belong in one review

Checking only dashboard users misses important access paths.

A contractor may be removed from a cloud account while their SSH key remains trusted on a VM. A Windows account may be disabled while a shared Administrator password remains unchanged. A former engineer's API token may still run in CI/CD. A VPN user may be active even after application access has been removed.

Review these layers together:

Identity answers who may act. Reachability answers who can attempt to connect. Privilege answers what an authenticated identity can actually do.

From Raff infrastructure work, the useful review unit is therefore not “a user account.” It is the complete path from identity to resource to privilege. Removing one layer while leaving another active can create the appearance of offboarding without actually removing access.

SSH, Linux, and Windows access need named ownership

SSH keys are easy to distribute and easy to forget. Each trusted key should have a known owner, purpose, server scope, review date, and removal condition.

Remove or rotate a key when:

• its owner left the team;
• the private key may have been copied or exposed;
• several people share one key;
• the key is trusted by more servers than required;
• nobody can identify its owner;
• the automation or project that used it has been retired.

CISA documents SSH authorized keys as a persistence mechanism that attackers can abuse. Unexplained keys are therefore an access risk, not merely untidy configuration.

Linux reviews should also cover active users, service users, sudo groups, direct root access, interactive shells for service accounts, scheduled tasks, deployment users, and credentials stored in home directories. A developer who needs logs does not automatically need unrestricted sudo.

Windows reviews should include:

• RDP users;
• local Administrators membership;
• shared Administrator credentials;
• disabled but reusable users;
• vendor and contractor accounts;
• saved credentials on jump hosts or staff devices;
• public RDP exposure;
• successful and failed logon evidence where retained.

A user may need RDP access without needing local Administrator rights. Keep daily application access separate from server administration wherever the workload permits it.

If SSH or RDP exposure itself has become difficult to justify, use Private vs Public Admin Access to reconsider the network path rather than only reviewing accounts on the existing path.

Machine identities require the same discipline as human users

API keys and service accounts can be more persistent than human accounts because nobody notices them until an automation fails.

Review credentials used by:

• CI/CD pipelines;
• infrastructure automation;
• monitoring agents;
• backup jobs;
• applications;
• integrations and webhooks;
• command-line tooling;
• migration or support scripts.

Each machine identity should have:

A credential without an owner cannot be safely rotated. A service identity without a current service should be disabled or removed.

Do not keep long-lived secrets in source code, reusable VM images, tickets, shared chat, or broadly accessible documentation merely because an automation is inconvenient to change.

Offboarding is the highest-priority access review event

A periodic review can wait for its scheduled date. Offboarding should not.

When an employee or contractor leaves, remove every relevant access path:

• cloud dashboard or project membership;
• Linux users and SSH keys;
• Windows and RDP accounts;
• sudo and administrator groups;
• VPN, bastion, or other private-access membership;
• API keys and tokens tied to the person;
• repositories and CI/CD systems;
• password managers and secrets;
• monitoring and incident tooling;
• DNS and domain administration;
• billing access;
• customer environments;
• backup, snapshot, and recovery administration.

Rotate shared credentials the departing person could use. Removing a named account is not enough if the person still knows a shared password, holds a copied private key, or has an active token.

Contractor access should ideally receive an expiry condition when it is granted. A temporary permission with no end date is structurally likely to become standing privilege.

Review cadence should follow risk and change rate

There is no universal interval for every environment, but small teams need a repeatable baseline.

Increase frequency when the team changes rapidly, contractors are common, customer-sensitive data is involved, or contractual controls require stronger evidence.

A stable two-person project may use a lighter process than an MSP managing many customer environments, but neither should depend on memory alone.

Evidence makes access decisions defensible

The access inventory shows who can act. Logs and activity records help show who did act.

Useful evidence can include:

• SSH login history;
• sudo activity;
• Windows security events;
• cloud account changes;
• API-key use;
• firewall and VPC policy changes;
• deployment records;
• password-manager activity;
• backup restore and deletion events;
• incident records.

NIST SP 800-53 treats account management and least privilege as continuing controls rather than one-time setup tasks. Access changes as people, services, and responsibilities change.

Do not preserve access merely because usage is unclear. Investigate ownership and dependencies, then make an explicit decision. “Nobody knows” is a reason to investigate, not a permanent access justification.

The review should measure business actions, not only role names

Role names can hide excessive privilege. Review what an identity can actually do.

High-impact actions include:

• create or delete VMs;
• change firewalls, VPCs, or routes;
• add SSH keys or administrators;
• view or change secrets;
• restore or delete recovery points;
• change DNS;
• alter billing or payment settings;
• export customer data;
• manage other administrators.

A user who needs to restart one application may not need permission to delete backups. A support contractor may need logs without database export rights. A deployment identity may need to update one service without becoming a general-purpose administrator.

Least privilege becomes easier to evaluate when access is described as actions rather than titles.

The review meeting should produce owners and deadlines

A lightweight review can follow this sequence:

1. Inventory users, keys, tokens, service identities, and privileged access paths.
2. Assign a named owner to every item.
3. Compare current access with the owner's current role or workload.
4. Review public and private network reachability.
5. Check recent use where reliable evidence exists.
6. Choose keep, reduce, rotate, disable, or remove.
7. Assign the change to an owner.
8. Apply and verify the change.
9. Confirm emergency access still works as designed.
10. Record unresolved dependencies and the next review date.

The output should be a change list with owners and due dates. A completed checklist without applied changes is not a successful access review.

Raff provides the infrastructure surfaces that teams should review

Raff gives customers administrative control over Linux and Windows workloads, so access ownership remains an important part of operating those systems.

A Raff-focused access review can include:

• Raff VM for trusted SSH keys, Linux users, root/sudo access, and VM-level administration;
• Windows VM for RDP users, local Administrators, and Windows administration;
• Raff Security for public exposure, firewall rules, and security-group boundaries;
• Raff VPC for private reachability, routes, and service-to-service access;
• Data Protection for who can create, restore, manage, or delete recovery points.

Current Raff VPC provides 25 Gbps unmetered private traffic with managed NAT, DNS, and DHCP. Raff VM traffic uses 3 Gbps truly unmetered ports, and each VM includes 3 free automated backup slots. Those capabilities create infrastructure surfaces that should be governed; they do not replace named users, SSH key ownership, Windows account management, or application-level authorization.

A private VPC path also should not become implicit trust. Review which administrators and workloads can actually reach sensitive services after entering the private network.

For the underlying access architecture, return to Bastion Host vs VPN vs Public SSH. For public-versus-private administration specifically, use Private vs Public Admin Access.

Conclusion

A user access review keeps cloud privileges aligned with the team and systems that exist today rather than the organization that existed when access was first granted.

Review human and machine identities, credentials, privileges, network reachability, and recovery access together. Give every item a named owner and current purpose, treat offboarding as immediate, use evidence where available, and end every review with an applied decision: keep, reduce, rotate, disable, or remove.

Return to Bastion Host vs VPN vs Public SSH when the review shows that the administration path itself needs redesign, or continue with Private vs Public Admin Access when direct SSH or RDP exposure is the main concern.

Sources

• NIST SP 800-53 Rev. 5: Security and Privacy Controls
• CISA: SSH Authorized Keys
• Raff Security
• Raff VPC
• Raff VM
• Raff Windows VM
• Product details reviewed: 2026-08-13