A common mistake is treating network devices as plumbing instead of security controls. Teams often delay firmware updates, leave default passwords in place, or assume unmanaged devices are safe because they are simple. In practice, switches, routers, firewalls, WAPs, and VPN appliances all need continuous inventory, configuration review, and access control to stay defensible.
Why network infrastructure fails when it is treated as “just hardware”
Teams usually get into trouble when they see routers, firewalls, switches, WAPs, and VPN appliances as static connectivity components rather than security-relevant assets. The common failure is not one dramatic misconfiguration, it is operational neglect: devices drift from approved settings, default credentials survive far too long, and inventory becomes stale as the environment changes.
That blind spot matters because network gear often sits at the boundary between trusted and untrusted traffic. If the boundary device is weak, the rest of the stack inherits that weakness. Inventory, configuration baselines, and access rules are therefore part of the control plane, not administrative overhead.
Well-run teams treat these devices as part of the security perimeter and verify them on a schedule, especially after upgrades, topology changes, or emergency changes. The practical test is whether the team can say what is deployed, who can administer it, and whether the current state still matches the approved design.
Where the control failures usually appear
The most common mistakes are predictable because they cluster around lifecycle and change management. Firmware is deferred until a maintenance window that never arrives, management interfaces are left reachable from broad networks, and local or shared admin accounts outlive the people who created them. Even “simple” devices become riskier when they are unmanaged, because simple does not mean harmless.
Another recurring failure is assuming that a network device is secure because it is vendor supplied or physically installed in a locked room. Physical placement does not compensate for poor authentication, excessive administrative reach, weak segmentation, or absent logging. The security question is not whether the box is present, it is whether the box still enforces the intended trust boundary.
If teams want a useful shortcut, they should ask whether the device can still be authenticated to, managed, and changed by the right people only. If the answer is unclear, then the device is already outside the effective control envelope and should be treated as an exposure, not an asset with a known posture.
Risk and Threat Considerations
Network infrastructure is attractive to attackers because it can expose credentials, redirect traffic, weaken segmentation, or create persistent access paths that are harder to spot than endpoint compromise. A neglected device can become both an entry point and a traffic manipulation point, especially when management access is broad or firmware is outdated.
Failure mechanism: Stale firmware, default or shared administrative access, and weak device inventory let attackers reuse trusted management paths or abuse existing trust relationships to alter routing, filtering, or remote access behavior.
Impact: The result can be traffic interception, lateral movement, loss of segmentation, unauthorized configuration change, or prolonged persistence inside a core network control layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Network gear needs hardened baselines and drift control. |
| CIS 5 — Account Management | Default and shared admin accounts are a core failure mode for infrastructure devices. | |
| CIS 12 — Network Infrastructure Management | This directly covers routers, firewalls, switches, and remote access appliances. | |
| Recommendation — Maintain approved device baselines and continuously validate configuration drift. Remove default accounts and tightly govern administrative access to network devices. Inventory, secure, and monitor network infrastructure devices as governed assets. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Administrative access to network infrastructure depends on strong authentication and access control. |
| PR.MA — Maintenance | Firmware updates and maintenance windows are central to keeping devices defensible. | |
| DE.CM — Continuous Monitoring | Stale inventory and configuration drift require ongoing monitoring to detect exposure. | |
| Recommendation — Restrict management access and enforce strong authentication for infrastructure administration. Patch and maintain network devices on a defined cadence with tracked exceptions. Monitor device state continuously so configuration drift and exposure are detected early. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Administrative access should only be granted after trustworthy identity proofing or binding. |
| Recommendation — Use strong identity assurance before allowing privileged management access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Default passwords, device credentials, and exposed secrets are a recurring infrastructure weakness. |
| NHI-03 — Least Privilege and Authorization | Excessive administrative rights widen the impact of a compromised network device account. | |
| NHI-06 — Visibility and Discovery | The answer hinges on continuous inventory and discovery of network devices and their access paths. | |
| Recommendation — Rotate and protect device credentials and secrets throughout their lifecycle. Limit device administration to the minimum permissions needed for operation. Keep an authoritative inventory of devices, owners, and management interfaces. | ||
Practitioner Guidance
What to verify: Confirm that every network device has an owner, is in inventory, has current firmware status, and is reachable only through approved management paths. A device that cannot be found in inventory or cannot be reviewed without special effort is usually the one that will fail during an incident.
What to prioritise: Start with devices that terminate remote access, enforce segmentation, or touch internet-facing traffic. Those systems have the largest blast radius, so configuration drift or delayed patching there has the greatest operational consequence.
Common mistake: Treating “unmanaged” as “low risk.” Unmanaged infrastructure often has the weakest visibility, the least reliable change history, and the highest chance of carrying old credentials or outdated code.
Practitioner takeaway: The right standard is not whether the device still functions, but whether its configuration, access paths, and update posture are continuously defensible under change.
