Eric Sommers
We continue to see software updates breaking networks. This has always been an issue, so why do we keep doing it? Bad data....
Software updates are not required to stay compliant with SOC2, ISO, and PCI.
Or maybe bad guidance is more accurate. And to be fair, "where" the device is in the network being updated is everything. Core, security, and datacenter environments are one thing; our access layers are another.
Our access layers on average, account for 60-70% of your entire network estate. This article is only about those last device connections like closet switches, access points, or anything else plugged into that last switch, providing network access to that last endpoint.
One of the most recent FUD reasons raised when discussing either used network hardware or alternatives to OEM maintenance, like our CovrEDGE, was the "need to have access to" iOS updates. For the access layer, the "need for access to IOS updates" has always been based on a hypothetical "if this happened" scenario. Hence, the FUD. FUD Monster literally has said, "If you don't have access to IOS updates and something happens, you'll lose your job!!"
That's #FUD101 and has kept the "we only buy new" crew from logically analyzing their actual need for access to IOS updates.
In the last 5 years, 148 "High" security vulnerabilities have been issued for Catalyst IOS-XE builds. To comply with the notion that someone out there is current, that would have required a NetOps team to have made 29.6 (unexpected or unplanned) image changes per year. That's 2.5 image changes per month. Now multiply this by the number of switches you have in your network. And don't forget at least 2 weeks per new image to work through change management safeguards. The need to have access to IOS updates in our Access layer, along with whether anyone is successful in maintaining a standard current image is fake news....
Frightened NetOpps engineer fires, "This is why we need automation to deploy software updates!!" Also fake news. Analyze the cost of access network cloud management platforms in relation to the benefit it provides.
Can you give me even one example of a failure that occurred when you did not deploy an update in your access layer? That's assuming you hardened your LAN configurations, which is what this article is about! The simple fact is that updating software has caused significantly more issues than not, and "access to IOS updates" is not required to maintain compliance.
Did you know IOS development for security vulnerabilities in the 3850s stopped in October 2025? Does that mean they all need to be replaced ASAP? Of course not!!
Hardening your L2 configuration without relying on software updates is about maximizing security using configuration, physical controls, and procedural mitigations. If done properly and accompanied with a configuration attestation memo, we're compliant.
A hardened LAN configuration is a set of deliberate security controls and settings applied to your switches to harden the device, reduce attack surface, and prevent common LAN-based attacks (e.g., spoofing, rogue devices, VLAN hopping, credential theft, etc).
We have completed templates available upon request for varying platforms and images, but I've included below a few examples for a 3850 on 16.9. These configurations enforce least privilege, strong authentication, network segmentation, encrypted management, centralized logging, and control-plane protection, satisfying SOC 2 CC6/CC7/CC8 and ISO 27001 Annex A network, access control, and monitoring requirements without requiring software upgrades.
The following SOC2 requirements are addressed in the following example:
-
CC6.1 – Logical access controls and secure configuration
-
CC6.2 – User authentication and authorization
-
CC6.3 – Protection against brute-force attacks
- CC6.6 – Network segmentation
- CC6.7 – Secure administrative access
- CC6.8 – Protection of monitoring interfaces
-
CC7.1 – Preventive security measures to reduce attack surface
-
CC7.2 – Detection of anomalies and security events
-
CC7.4 – Logging consistency for investigation
- CC8.1 – Change management controls
1. System Identification, Configuration Integrity, and Baseline Hardening (SOC2: CC6.1 / CC7.1):
hostname SW-3850-Hardened-Config
service password-encryption
no service pad
no service dhcp
no service tcp-small-servers
no service udp-small-servers
no service config
no ip source-route
no ip finger
no ip rcmd rcp-enable
no ip rcmd rsh-enable
no ip domain-lookup
no ip gratuitous-arps
no ip http server
no ip http secure-server
no cdp run
no lldp run
no ip igmp snooping
2. Time Synchronization & Logging Integrity (SOC2: CC7.2 / CC7.4):
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
ntp authenticate
ntp server <IP ADDRESS> key 1
ntp authentication-key 1 md5 <KEY>
ntp trusted-key 1
3. Authentication, Authorization, and Account Security (AAA) (SOC2: CC6.2 / CC6.3):
aaa new-model
aaa authentication login default local
aaa authorization exec default local
aaa authentication login CONSOLE local
aaa authentication login VTY local
aaa authorization exec VTY local
aaa session-id common
username admin privilege 15 secret <PASSWORD>
enable secret <PASSWORD>
login block-for 120 attempts 3 within 60
login delay 5
4. Secure Management Access (SSH, ACLs) (SOC2: CC6.1 / CC6.7):
crypto key generate rsa modulus 4096
ip ssh version 2
ip ssh time-out 30
ip ssh authentication-retries 2
access-class MGMT-ACL in
transport input ssh
ip access-list standard MGMT-ACL
permit 10.10.10.0 0.0.0.255
deny any
5. Centralized Logging & Audit Trails (SOC2: CC7.2 / CC7.4):
logging buffered 64000 warnings
logging host <IP ADDRESS>
logging trap warnings
logging console critical
logging monitor warnings
archive
log config
logging enable
notify syslog
6. Network Segmentation & Management Isolation (SOC2: CC6.1 / CC6.7):
vlan 10 USERS
vlan 20 VOICE
vlan 30 WIFI
vlan 40 GUEST
vlan 99 MGMT
vlan 999 INACTIVE PORTS
interface vlan 1
shutdown
7. Access Port Protections (Layer 2 Security) (SOC2: CC6.6 / CC7.1):
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky
ip verify source
ip dhcp snooping vlan <VLANs>
ip arp inspection vlan <VLANs>
spanning-tree bpduguard enable
storm-control broadcast level 1.00
storm-control multicast level 1.00
8. Trunk & Control Plane Protection (SOC2: CC6.6 / CC7.1):
ip access-list extended CP-MGMT
class-map MGMT-TRAFFIC
policy-map CONTROL-PLANE-POLICY
control-plane
service-policy input CONTROL-PLANE-POLICY
9. Configuration Retention (SOC2: CC8.1)
write memory
The above example is only partially complete. For a completed hardened template, please provide your platform and current image to your Edgeium account manager, and we'll send back a completed hardened config along with supporting documentation for your auditor.
Don't believe access to software updates are required to stay compliant. It's simply not true.
Secondary-market resellers are the only thing preventing Cisco from forcing the adoption of cloud management platforms and subscription-based licensing on you.
Don't let the FUD Monster scare you into wasting money. Partner with a secondary market company like Edgeium and free up 50% of your network budget to be allocated towards other initiatives that provide value!!
Thank you for reading!
