ASD ISM 2161Verify Network Device Firmware and Configuration Against Known-Good Baseline
Compare each network device's firmware and running configuration to an approved baseline after patching, when something looks wrong, and at least every month.
Plain language
Network devices such as routers, switches, firewalls and wireless controllers run two things an attacker would love to quietly alter: the firmware (the device's operating software) and the running configuration (the rules and settings it applies right now). This control asks you to keep an approved, known-good copy of both for every device and then check the live device against that copy at three points: straight after any patch or firmware update, whenever the device or the network starts behaving strangely, and on a routine cycle no longer than a month. It matters because network devices sit in the path of all traffic and are a favoured foothold. Implanted firmware or a single added configuration line (a new admin account, a changed ACL, a mirrored port, a diverted route) can persist for months without anyone noticing, because the device keeps forwarding packets normally. A post-patch check confirms the update landed cleanly and nothing rode in with it. An anomaly-triggered check turns a vague "the firewall is acting odd" into a concrete answer about whether the device has been tampered with. The monthly floor catches slow drift and changes that slipped past change management.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for networkingTopic
Network device integrity
Official control statement
The integrity of network device firmware and running configurations is verified against an approved known-good baseline following patching, on detection of anomalous behaviour and at least monthly.
Why it matters
Without baseline verification, unauthorised firmware implants or configuration changes on network devices can go undetected indefinitely. An attacker who has modified a device can intercept, redirect or copy traffic, open persistent remote access, weaken firewall rules or disable logging, and the organisation has no reliable way to tell a trusted device from a compromised one. A failed or tampered patch may also leave a device in an unknown state that undermines every other control depending on the network. Detection is delayed until the damage is visible, and incident response is slower because there is no trusted reference to compare against.
Operational notes
Day to day, the network team maintains an approved baseline per device (or per device class where configurations are templated) that records the sanctioned firmware version and hash plus the approved running configuration. The baseline is updated only through the change process, so that every legitimate change moves the baseline and every unexplained difference stands out.
Verification runs at three triggers. After patching, the engineer who applied the update (or the automation that did) confirms the installed firmware matches the approved version and image hash and that the running configuration still matches the baseline, then records the result in the change ticket. When monitoring, help-desk tickets or the SOC flag anomalous behaviour on or around a device, an integrity check is added to the triage steps and its result feeds the incident record. Independently of both, a scheduled job compares every in-scope device at least monthly and reports differences to a named owner.
Differences are treated as findings: either the change is traced to an approved ticket and the baseline is corrected, or it is unexplained and handled as a potential security incident. The team keeps the schedule, the exception list and the results so the cycle can be shown to have run.
Implementation tips
- Network team lead: build and approve a known-good baseline for every in-scope network device by capturing the sanctioned firmware version and image hash together with the approved running configuration, storing it in a version-controlled repository that only the change process can update.
- Network engineers: add a post-patch verification step to the patching procedure, so that after every firmware or software update the engineer confirms the installed image and hash match the approved version and diffs the running configuration against the baseline before closing the change ticket.
- Network operations team: deploy a configuration-management or monitoring tool that pulls running configurations and firmware details from all devices on a schedule of at least monthly, diffs them against the stored baseline and raises an alert to a named owner for any difference.
- SOC and network on-call staff: write an integrity check into the triage playbook for anomalous device or network behaviour, so that whenever an alert or ticket indicates something unusual the responder compares the affected device's firmware and running configuration to the baseline and records the result in the incident.
- Change manager: require that every approved change to a network device also updates the baseline record, and review the monthly verification results to confirm that every reported difference is either matched to an approved change or escalated as a security incident.
Audit / evidence tips
- AskAsk for the approved known-good baseline records for a sample of network devices, including firmware version, image hash and running configuration.Look atCheck that a baseline exists for each sampled device, that it is marked as approved, and that its history shows updates tied to change records.GoodEvery in-scope device has a current, approved baseline held under change control, with no devices missing and no unapproved edits.
- AskAsk for the scheduled integrity verification results for the last three months.Look atConfirm the comparison ran against all in-scope devices at least once in each month and that each run covered both firmware and running configuration.GoodThere is an unbroken monthly record, coverage matches the device inventory, and any gaps are explained and approved.
- AskAsk for recent network device patching change tickets.Look atLook for a recorded post-patch verification step showing the installed firmware and running configuration were compared to the baseline before the change was closed.GoodEach patching ticket contains the verification result and the engineer who performed it, with no tickets closed without the check.
- AskAsk for incident or alert records where a network device showed anomalous behaviour.Look atCheck whether an integrity check against the baseline was performed as part of the response and what it found.GoodAnomaly responses consistently include a firmware and configuration comparison, and the outcome is documented in the incident record.
- AskAsk for the list of differences the verification process reported and how each was handled.Look atTrace a sample of differences to either an approved change that updated the baseline or a security incident that was investigated.GoodNo difference is left unexplained; each is closed as an approved change or escalated and resolved as a potential compromise.
Cross-framework mappings
How ISM-2161 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.20 | ISM-2161 requires verifying network device firmware integrity and running configuration against an approved known-good baseline after pat... | |
handshakeSupports(3)expand_less | ||
| Annex A 8.8 | ISM-2161 requires validating network device firmware and configurations against an approved baseline after patching and when anomalous be... | |
| Annex A 8.9 | ISM-2161 requires comparing network device firmware and running configurations to a known-good baseline on a defined schedule and after r... | |
| Annex A 8.32 | ISM-2161 requires routine and event-driven verification that network device firmware and running configuration match an approved baseline | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Networking
See all Guidelines for networking controls, or browse the full ASD ISM library.