How to audit network security

A network security audit answers one question: does the network's actual state match what you believe its state to be? In every audit worth the name, the answer is no somewhere: a forgotten port-forward, a switch on firmware from 2021, a "temporary" firewall rule from a contractor who left two years ago. The point isn't to pass; it's to find the gaps before someone else does.

This is a defensive audit of infrastructure you own or are authorised to test. Port-scanning networks you don't have permission to assess is illegal in most jurisdictions. Get written authorisation if you're auditing on someone else's behalf.

Step 1. Build the device inventory

You can't secure what you don't know exists. Start from your sources of truth and reconcile them against reality:

1. Export the DHCP lease table and ARP table from your router or core switch.
2. Pull the client list from each wireless access point.
3. Walk the static IP assignments from your addressing documentation.

Every entry gets a row: IP, MAC, hostname, owner, purpose. For entries you can't identify, run the MAC through the MAC Address Lookup tool; the manufacturer prefix usually tells you whether the mystery device is a printer, a phone, or something that shouldn't be there. Anything still unidentified after that is a finding: locate it physically or block it.

The inventory is also where you catch scope creep. The smart TV in the conference room, the contractor's NAS, the test VM nobody decommissioned: all attack surface, all usually absent from the official asset list.

Step 2. Review external port exposure

This is the highest-value step in the audit. Every port open to the internet is a standing invitation, and most networks expose more than their operators think.

From outside your network (or using a web-based checker), test your public IP against the high-risk list:

Use the Port Checker to test each port against your public IP, and follow how to check open ports for the full procedure including internal scanning. For every open port, the question is not "is it dangerous?" but "can I name the service behind it, the person responsible for it, and the reason it must be reachable from the internet?" Three names or it gets closed. The reasoning behind which ports matter and why is covered in more depth in our port security primer.

Don't forget UPnP: many consumer and SMB routers let internal devices open inbound ports automatically. Check the router's UPnP port-mapping table; it's a common source of exposure nobody configured deliberately. Disable UPnP unless something genuinely requires it.

Step 3. Audit DNS and domain hygiene

DNS is part of your attack surface and frequently ignored in audits:

• Run your domains through the DNS Lookup tool and verify every record is one you recognise. Stale A records pointing at deprovisioned cloud IPs are subdomain-takeover candidates.
• Check that SPF, DKIM, and DMARC TXT records exist and are correct. Missing email authentication makes your domain trivially spoofable.
• Verify NS records point only at your actual DNS provider.
• Confirm your registrar account has MFA enabled and domain transfer lock is on. A hijacked registrar account bypasses every other control you have.

Internally, check what resolver your clients actually use. Devices hard-coded to random public resolvers bypass any DNS filtering you've deployed.

Step 4. Verify certificates and encryption

For every TLS service you expose:

• Certificate is valid, not expired, and covers the hostname actually in use.
• No services still accepting TLS 1.0/1.1 or SSLv3.
• Internal admin interfaces aren't running on plain HTTP with self-signed certs that have trained users to click through warnings.

On the wireless side: WPA2 or WPA3 only, WPS disabled, and no "temporary" open SSID that became permanent.

Step 5. Review firewall rules and access controls

Export the full firewall ruleset and read it line by line. You're looking for:

• Any-any rules. A rule allowing all sources to all destinations exists in most rulesets that have been alive more than a year. Each one is a finding.
• Rules with no hits. Most firewalls track per-rule hit counts. A rule with zero hits in 90 days is either dead (remove it) or protecting against something rare (document why it stays).
• Rules without comments or owners. If nobody can explain a rule, schedule its removal and see who complains.
• Inbound NAT/port-forwards that should have come up in step 2; reconcile the two lists. A forward in the config that didn't show as open externally, or vice versa, means your mental model is wrong somewhere.

Then access controls more broadly:

• Default credentials. Test every piece of network gear (routers, switches, APs, cameras, printers) for factory logins (admin/admin, admin/password, blank). Printers and cameras are the classic misses. Default credentials on a management interface is a critical finding, every time.
• Shared admin accounts. One account per human, so logs mean something.
• MFA on everything that supports it: firewall admin, registrar, DNS provider, cloud consoles.
• Stale accounts. Compare admin user lists against the current staff list.

Step 6. Check firmware and patch levels

For every device in the step 1 inventory, record current firmware version against the vendor's latest release. Pay particular attention to:

• Internet-facing gear (router, firewall, VPN appliance); these are patched first or compromised first.
• Anything end-of-life. A device that no longer receives security updates needs a replacement plan or strict segmentation away from everything else.
• IoT devices, which often never auto-update.

Enable automatic updates wherever the device supports it and the operational risk is acceptable.

Step 7. Document findings and drive them to closure

An audit without a findings document is a walk-through. For each finding, record:

ID:          F-007
Finding:     RDP (3389) forwarded to 10.1.20.14 from WAN
Severity:    Critical
Evidence:    Port checker result, router NAT table screenshot
Owner:       J. Smith
Remediation: Remove forward; access via VPN
Due:         2026-06-17

Severity-rank ruthlessly: exposed admin interfaces and default credentials first, missing DMARC records later. Then schedule the next audit: quarterly for the external port review (it's fast), annually for the full pass. The follow-up audit's first task is verifying the previous findings actually got fixed; unresolved repeat findings are themselves a finding.

TL;DR

1. Inventory every device from DHCP/ARP/AP data; identify unknowns via MAC Address Lookup.
2. Test external exposure with the Port Checker; every open port needs a named service, owner, and reason.
3. Audit DNS records, email authentication, and registrar security with the DNS Lookup tool.
4. Verify certificates, kill legacy TLS, check Wi-Fi encryption.
5. Read the firewall ruleset line by line; remove any-any and orphan rules.
6. Hunt default credentials and stale admin accounts; record firmware versions.
7. Write findings with owners and due dates. Re-audit to confirm closure.

Related

• How to check open ports - the full port-scanning procedure for step 2
• Why open ports matter - the threat model behind the port review
• How to secure a home network - the same principles scaled down