When a sysadmin moves to another team, gets promoted, or leaves, a lot of what they know about the network goes with them. Sysadmin handover documentation should keep that knowledge in the organization, especially the part that is easiest to lose: which ports are open on public IPs, why they are open, and who still needs them. This article covers what a useful handover document contains, how to check it against an external scan, and the mistakes that leave forgotten services listening for years.
The goal is simple. On their first day, the incoming admin should be able to explain every open port on every internet-facing server, without messaging someone who now works three floors away or at another company.
Why Port Knowledge Disappears During Role Changes
Most infrastructure knowledge is never written down. It sits in shell history, in a firewall rule commented “temp – remove after migration”, or in the memory of the person who opened TCP 8443 at 2 a.m. during an outage in 2023.
When that person changes roles, the rule stays and the context is gone. Six months later, nobody knows whether the listener on 8443 is a vendor’s remote support portal, an old Tomcat manager, or something worse. Nobody is willing to close it either, because nobody knows what would break.
This is how forgotten services happen. They are rarely the result of negligence. They come from handovers that covered the runbooks and the on-call rotation and skipped the attack surface.
What Sysadmin Handover Documentation Should Contain
An experienced infrastructure lead treats the handover as an inventory exercise first and a knowledge transfer second. The document needs to answer, for every externally reachable service, five questions:
What is listening – port, protocol, and the actual software and version (for example OpenSSH 9.6p1 or nginx 1.24.0), not just “web server”.
Why it is exposed – the business reason, ideally with a ticket or change request reference.
Who owns it – a named person or team, not “infra”. Keeping port ownership records current makes this part of the handover almost automatic.
How access is restricted – source IP allowlists, VPN requirements, MFA, or nothing at all.
When it should be reviewed or removed – an expiry date for anything temporary.
Beyond the port table, a good handover also covers credentials and where they are stored (a vault path, never the secrets themselves), cloud security group names, firewall management access, scheduled jobs that open or close ports, and any third-party vendors with standing access.
Step-by-Step: Running the Handover Against Reality
The outgoing admin’s description of the environment is a starting point, not the truth. Follow this sequence over 1-2 weeks before the transition:
Step 1: Run a fresh external scan. Scan every public IP from outside the network, covering all 65,535 TCP ports and at least the common UDP ports (53, 123, 161, 500, 1194, 51820). An internal netstat or ss output shows what is bound locally. Only an external scan shows what the internet actually reaches.
Step 2: Compare the scan with the written documentation. Every open port goes into one of three groups: documented and expected, undocumented but explainable, or unknown. That third group is where the risk is.
Step 3: Walk through the unknowns together. The outgoing and incoming admin sit down and trace each unknown port to a process, a config file, and a reason. Budget 30-60 minutes per server for anything older than two years.
Step 4: Close or justify. Anything nobody can justify gets closed during a planned window, with a rollback plan. Anything justified gets written into the baseline.
Step 5: Freeze the baseline. The cleaned-up port list becomes the reference the new admin monitors against. If you already create port security baselines for your servers, the handover becomes a baseline review instead of an archaeology project.
A Realistic Handover Scenario
Picture a mid-sized hosting environment with 40 public IPs. The departing admin hands over a tidy Confluence page listing SSH, HTTPS, and SMTP. The external scan finds 14 more open ports.
Most of them have boring explanations: an IPMI interface on 623/UDP that should have been on the management VLAN, a Webmin instance on 10000 installed for a one-off task, and an Elasticsearch 7.x node on 9200 that a developer exposed for “a quick test” in 2022. Two have no explanation at all, and they turn out to be a decommissioned monitoring agent still listening on its default port.
None of these were in the documentation. All of them would have stayed open indefinitely, because the departing admin had simply stopped seeing them.
Common Mistakes During Sysadmin Transitions
The most frequent mistake is treating the wiki as the source of truth. Documentation describes what someone intended. The scan shows what is actually exposed. When the two disagree, the scan is right, every time.
The second mistake is disabling the outgoing admin’s accounts before the handover is finished. Security teams are right to revoke access quickly, but cutting SSH keys and console access on day one means the unknown ports from Step 3 never get explained. A better approach is to keep read-only access for 5-10 working days, then remove it completely and log the revocation.
The third mistake is forgetting what the person personally owned. Departing admins often have SSH keys in authorized_keys files on servers they never documented, API tokens in CI systems, and home-IP entries in firewall allowlists. One stale allowlist entry for a residential IP can sit on a production firewall for years after the ISP has reassigned that address to someone else.
The Myth That Good Admins Don’t Need Handover Docs
There is a widespread belief that a competent replacement can work out the environment alone, given time. That is partly true. A skilled admin will eventually map everything.
“Eventually” is the problem. Attackers scanning IPv4 space with tools like Masscan or ZMap can sweep the entire range in under an hour. A forgotten Redis instance does not wait for the new admin to reach it in their third month. The handover exists to close the gap between “the person who knew left” and “the new person has worked it out”.
When the Standard Approach Doesn’t Fit
Teams with fewer than 10 people often have no incoming admin at all. The work goes to a developer or a managed service provider. In that case the handover document matters even more, and it should be written for someone who may not know what IPMI is.
Air-gapped and strictly on-prem environments have little internet exposure, but the same discipline applies to internal segments. Regulated industries covered by PCI DSS 4.0, ISO 27001:2022, or NIS2 should treat the handover record as audit evidence: a dated scan, a signed-off port inventory, and a record of revoked access.
FAQ
How long should a sysadmin handover take?
For an environment with 10-50 public-facing servers, plan for 1-2 weeks of overlap. Smaller setups can be done in 2-3 days if a current port baseline already exists.
Should the handover include passwords?
No. The document should point to where credentials are stored, such as a HashiCorp Vault path or a 1Password vault. After the transition, rotate every shared credential the outgoing admin could access.
What if the previous admin has already left?
Start with an external scan and treat every port as unknown until proven otherwise. Check git history, ticket systems, and firewall change logs to rebuild the reasoning behind each open port.
Making the Handover Stick
A handover only works if the result is kept up to date afterwards. Store the port inventory next to a documented legitimate open ports policy, re-run the external scan 30 days after the transition, and compare it with the frozen baseline. Any differences at that point belong to the new owner. That is the real sign the handover is finished: every open port has a current owner who can explain it.