Who Can Get Into Your Server? A 30-Minute Access Audit

Ask a small team who has access to their production server and you'll usually get two or three names. Go and check, and the real list is longer: a contractor from last year, an agency that built the original site, an SSH key nobody can match to a person, a control panel login three people share.

None of those accounts are a problem on the day they're created. They become one when the reason for them ends and the access doesn't.

Access outlives the reason for it

Verizon's 2026 Data Breach Investigations Report, the largest in its 19-year history, found that exploiting software vulnerabilities has overtaken stolen credentials as the most common first step in a breach. That headline undersells credentials. Look at the full path of an attack rather than just the opening move, and credential abuse appears in 39 percent of breaches, more than any other technique.

The report also looked at what happened before ransomware attacks. Half of the organizations hit had a credential leak or infostealer infection in the 95 days beforehand. The login was already out there, waiting to be used.

The practical lesson is not that passwords are bad. It's that every working login is a door, and most teams have more doors than they think.

Where access hides on a typical server

When people audit access, they usually check one place. Attackers check all of them. On a typical web server, logins live in at least seven:

• The hosting account that can reboot, rebuild or cancel the server
• SSH, including every key in every user's authorized keys file
• The control panel, such as cPanel/WHM, and any sub-accounts
• The CMS admin, such as WordPress administrator accounts
• Database users, especially any that accept remote connections
• API tokens and deploy keys used by CI pipelines, backups and integrations
• The domain registrar and DNS, which can redirect everything without touching the server at all

That last one gets missed most often. Someone who controls your DNS doesn't need your server password to take over your site or your email.

Four controls that do most of the work

Turn on MFA everywhere a login can change something. Start with the hosting account, the registrar and the CMS admin. These are the accounts where one stolen password does the most damage, and MFA means a leaked password alone is no longer enough.

Use SSH keys, and turn off root login. Password-based SSH is the easiest login on the internet to brute-force. Keys remove that, and disabling direct root login means an attacker has to compromise a named user first.

One person, one account. Shared logins make it impossible to know who did what, and impossible to remove one person without changing the password for everyone. If three people use the same control panel login, you have three people who might have reused that password somewhere else.

Remove access the day the reason ends. Contractors, agencies and former staff are the most common source of forgotten access. Make removal part of ending the engagement, not a cleanup task for later.

There's a fifth control worth adding once these are in place: keep management interfaces off the public internet. If SSH and admin panels are only reachable through a VPN, most automated attacks never reach the login page. We covered how that works in Why You Should Consider a VPN for Your Cloud Environment.

The 30-minute access audit

You don't need a tool to start. You need a list.

1. List every login across the seven places above. Write down who it belongs to.
2. Match each one to a current person and a current reason. Anything you can't match is the first thing to remove.
3. Check MFA on the hosting account, registrar and CMS admins. Turn it on where it's off.
4. Rotate anything shared. If a password or key has been used by more than one person, replace it.
5. Write down the date. Do it again next quarter, and again any time someone leaves.

Most teams find at least one login they can't explain. That's the point of doing it.

How access works on InMotion Cloud

OS hardening is part of every InMotion Cloud plan. Our engineers configure servers to reduce exposure from the start: denying SSH root login, restricting database access and disabling services you don't need. We can also put management access behind a VPN so admin interfaces aren't exposed to the internet.

If something does go wrong, managed incident response is included too. Our engineers block the threat, investigate how it got in and put fixes in place so it doesn't happen the same way twice.

One limit, stated plainly. We can lock down the server and the paths into it. We can't see who on your team shared a password, and we can't turn on MFA for your domain registrar or remove a contractor from your CMS. Access is partly infrastructure and partly habit, and the habit half stays with you. We're glad to help you build the checklist.

If you'd like a second set of eyes on how access to your environment is set up, talk to an InMotion Cloud engineer.